Lab Protocol

Centrifying Labs Protocol
A key goal of this blog is to provide step-by-step instructions and examples to solve the challenges of Identity and Access in Unix and Linux platforms.  To make the most of the materials shared on this site we are proposing the following: Let's not reinvent the wheel and reuse what we have widely available.

The Business Problem is the lab driver
Labs will be designed to solve a real-world issue.  They will help to be reference designs, however, the audience should understand that a small lab is not the same as the real world.  Each business problem will be outlined from the point of view of the Unix Administrator, Security Analyst and IT Manager.  If there's considerations from the Windows Admin perspective, they will be addressed during the solution stage (Plan-Do-Check-Adjust).

Infrastructure:  Windows and Active Directory
Microsoft Technet has an excellent resource in their Test Lab Guides.  What this means to you is that any infrastructure we leverage on the Windows side will come from their guidelines.  This way we follow a uniform example across the board.   All examples on this blog will leverage the base configuration test lab guide for Windows Server 2008 R2.  Here's a diagram:

What does the Base Test Lab Guide provide:
- A corporate network (corpnet) 10.0.0.0/24
- A functioning AD forest  (corp.contoso.com):  LDAP, Kerberos and Group Policy
- Name resolution services
- Working websites and file shares
- A properly configured Certificate Authority and Certificate Revocation lists

DC1 is the domain controller
APP1 is the application server
CLIENT1 is the Windows client, most of the work will be performed from there
The Centrify consoles will be installed here.
Expect EDGE and INET1 to get introduced in DMZ-like scenarios (won't be needed for a while) so its safe to say that you'll be OK with the 3 initial VMs first.

Infrastructure:  UNIX and Linux

The infrastructure will vary depending on the use case, here's a summary of the Unix and Linux VMs:
- CEN1, will be running CentOS 64 bit with the personal version of IBM DB2 (Express) and Apache
- SUSE1 will be running SUSE 10 SP3 with the personal version of Oracle
- SOL1 will be running Solaris 10.

Notes and modifications on the Base Configuration TLC

• On page 14, the TLC recommends to set the "Domain member: Maximum machine account password age" to 999.  This means that the computer's password will change in close to 3 years.  In a real production environment, this defaults to 30 days. This has implications on mutual computer authentication.
• I recommend to set the "Interactive Logon: Prompt user to change password before expiration" to 30 days.  This will make the notification effective 30 days before the password expires.
• Set up a Corporate Disclaimer:  by modifying the "Interactive logon:  Message text for users attempting to log on"  GPO.

Our modified Lab will look like this:

Stay tuned.  Our first lab and diagram will be posted soon.