After working with the Centrify DirectControl 3.0.x product, and since I haven't seen much information on the web about it, I thought I would post my own experiences with the product.  This isn't a critique of the product, but rather, a Microsoft/Windows consultant's experience with the product, and background on the product for people wanting to understand and learn more about the product and related technologies.

Terms and Definitions
Before we get started, a couple of basic product terms needs to be understood by the reader.  I'll do my best to describe terms not covered in this section when I introduce them in later posts.

Agent:

The client daemon or service that is installed onto the Unix, Linux or MacOS hosts.

Admin Console:

The primary management tool used to administer the zones and Unix identity information within AD. 

Zones:

From the CDC Admin Guide: 

"A Centrify DirectControl zone is similar to an Active Directory domain or an NIS domain. Zones allow you to organize the computers in your organization in meaningful ways to simplify system management and the migration of account information from existing local files, NIS databases, LDAP servers, and other sources to Active Directory. "

What this really means:

• Zones are used to control who can log onto a Unix system
• Zones define the UNIX identity data available to the Unix hosts (User ID, Group ID, etc.)
• A zone is NOT an OU, and you cannot apply GPOs to the zones.
• You can delegate some basic permissions to the zones.

The following rules apply to zones:

• A computer can only be a member of a one zone
• A zone can contain multiple computers
• Users and groups are added to a zone.

There are 3 zone types available with DirectControl.  The difference between the three is how the data is actually stored within Active Directory.  For the purposes of these series, we will assume that the R2/RFC2307 Schema and zones have been used, as there really is very little justification in using the other zone types.

The three zone types available are:

•  Standard zone:  A standard zone stores Unix properties using the Centrify DirectControl data model. Within a standard Centrify DirectControl zone, Unix computers are treated as Active Directory clients served by the Active Directory domain controllers

• Microsoft Services for UNIX (SFU) zone:  A SFU zone stores Unix properties using the SFU schema extension. Within a Microsoft Services for UNIX zone, Unix computers are treated as NIS clients accessing a Network Information Services server and domain. If you select this type of zone, then click Next, you are then prompted to select the Windows domain and the NIS domain associated with the Windows Services for Unix (SFU) schema.

• If you have raised the functional level of the Active Directory forest to Windows Server 2003, you can also choose to create zones that store Unix properties according to the RFC 2307 specification by selecting the Standard RFC-2307 zone type.

Service Connection Point:

 A Service Connection Point (SCP) is used by Centrify to map the Unix identity data back to a real user, group, or computer Object, eliminating the need for redundant user and group objects.

More Information: http://msdn2.microsoft.com/en-gb/library/ms683956.aspx

RFC2307 Schema:

The  schema standard implemented with Windows Server 2003 R2 to enable the PosixGroup and PosixAccount classes, which allow for RFC (read: standardized) compliant ways of storing Unix identity data into AD and enable applications to read and use the data, if required.

PosixAccount and PosixGroup Shadow Classes

The PosixAccount and PosixGroup are used by DirectControl to store the Unix identity information in Active Directory.  This information is tied to the SCP object in the zone, and read by the Unix host at logon, etc.  These classes contain information such as Unix ID (UID, similar to a SID), Group ID (GID), shell, home directory, primary group, etc.  These are only possible with the R2 schema implemented, and the DirectControl zones created as an RS/RFC2307 capable zone  

http://msdn2.microsoft.com/en-gb/library/ms683907.aspx

http://msdn2.microsoft.com/en-gb/library/ms683908.aspx

Kerberos

Kerberos, developed by MIT in the late 1980's, is a network authentication protocol.  It is an open standard, and was adopted by Microsoft for use with Active Directory, moving Windows authentication from the proprietary NTLM to an interoperable authentication scheme.

Why Authenticate Unix Clients to Active Directory? 

As Windows admins, we are used to the basic network authentication and authorization model with NT4 and Active Directory domains and forests.  Unix admins, however, don't necessarily follow such models.  By enabling Unix clients to Windows, the following benefits are realized:

• Single source for user account and group membership data:  By reducing the overall user account stores, it becomes much easier to manage user identities, provision and decommission users, and reduce the user burden of remembering multiple passwords.  Additionally, as the groups are stored in AD, it becomes easier to manage group memberships as well.
• Enable Single Sign On (SSO) or Reduced Sign On (RSO):  By leveraging the native AD authentication protocol (remember Kerberos), we can do some really cool stuff like forwarding tickets.  As an example, Centrify provides a kerberized PuTTY and OpenSSH product.  From a Windows 2000 or higher system, and user can open a SSH session to a client, and not have to provide credentials as part of the Unix logon process.  Taking this a step further, the user can "jump" to another server with another SSH connection, and have the 1st Unix host forward the credentials to the 2nd Unix host, and so on and so forth.  This also incurs some security risk, which is outside the scope of this article.  Additionally, Centrify provides agents for systems such as Apache and BAE to enable SSO to those systems as well.
• Leverage Group Policies:  DirectControl understands several native Windows GPO settings, such as a logon banner and time settings, as well as support for managing the agent configuration on the system.  This can be extended by an organization. 
• Reduce the need for additional directory systems:   Typically, Unix administrators would use a NIS domain or an LDAP directory such as Netscape's for A&A.  This requires additional hardware, support, and perhaps integration with these systems and other directories, especially with provisioning systems.  By using AD, you can leverage what you have today.
• Regulatory compliance:  By having all the user accounts in one place (AD), it becomes much simpler to track and audit user accesses.  One such example is the SOX requirements of ensuring that user identities are managed and decommissioned appropriately.  Organizations have a much more difficult time doing this when accounts are stored on local hosts, in the passwd file.

That concludes Part 1.   In later parts, I will focus on preparing your environment, installation of the agent, and other caveats that I have come across.