WINDOWS SECURITY AND DIRECTORY SERVICES FOR UNIX USING CENTRIFY DIRECTCONTROL
9
© CENTRIFY CORPORATION 2004-2005. ALL RIGHTS RESERVED.
PAGE 9
you might not want to use Active Directory for special system accounts, for groups, or
for a specific set of UIDs.
·
User and group override controls for fine-tuned access control
Through configuration options or group policy, you can handle override entries in the
/etc/passwd file or /etc/group file to provide custom access to local accounts or
groups.
·
Program filtering to prevent account conflicts with Active Directory
Through configuration options or group policy, you can specify programs that you do
not want to look up account information in Active Directory. You can use this feature
to ensure that local programs that create, manage, or use local user and group
information do not attempt to look up conflicting information in Active Directory.
Storing UNIX User Attributes in Active Directory
UNIX computers use a traditional set of information fields that are associated with a user
in the account information store. Regardless of whether the store is local (that is,
/etc/passwd) or in a central directory (for example, NIS or LDAP), these fields must be
present in order for a normal UNIX user experience to occur. Some of these information
fields have a similar field in Active Directory. For example, the Active Directory Display
Name field is similar to what is typically stored in the Gecos field in an /etc/passwd file
that is, the full name of the user.
However, a UNIX computer must look up certain fields that do not have an equivalent in
the Active Directory system. Some of these fields include User ID (specifies the user's
unique numeric ID), Principle Group (specifies the user's principal or primary group ID),
Home Directory (specifies the full path name of the user's home directory), and Shell
(specifies the initial program or shell that is executed after a user invokes the login
command or su command). In order to use Active Directory as a directory store for UNIX
accounts, some mechanism must be put in place to allow for the storage of these extra
information attributes and to tie those attributes to each user account.
Many solutions use the approach of extending the Active Directory schema to
accommodate the storage of additional attributes. For example, Microsoft Services for
UNIX (SFU) includes a mechanism to extend the default schema. After the default
schema is extended, every user in the domain has extra fields available for storing
information associated with accessing UNIX computers. These fields include NIS
Domain, UID, Login Shell, Home Directory, and Primary group name.
DirectControl supports two methods for storing UNIX user attributes in Active Directory
using DirectControl Zones or implementing the Microsoft SFU schema extensions.
DirectControl Zones
As described in the sections about conceptual and logical designs for DirectControl
solutions, Centrify DirectControl introduces a new mechanism for storing UNIX user
attributes. DirectControl takes advantage of a standard facility within Active Directory that
allows applications to store data in Active Directory under the Program Data container
hierarchy. In this container, DirectControl can store information in Zones. Each Zone can
include information about related computers, users, and groups that are joined to Active
Directory.
Because the Zone concept is extensible, users can be associated with multiple UNIX
identities in numerous Zones if required. For example, you can create Zones by importing
the user information from multiple legacy NIS directories in your organization. The UNIX-
related information associated with each user in each Zone can then be tied to an Active
Directory user account. Even if the user has a different user name or UID in each Zone,
the user can still be associated with a single Active Directory account and a single Active
Directory password.