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.