Export (0) Print
Expand All
Expand Minimize
4 out of 5 rated this helpful - Rate this topic

Chapter 3: Using Centrify DirectControl to Develop, Stabilize, Deploy, Operate, and Evolve End State 2

Published: June 27, 2006
On This Page

Introduction and Goals Introduction and Goals
Preparing Your Environment Preparing Your Environment
Developing the DirectControl Solution Developing the DirectControl Solution
Stabilizing Your Test Deployment Stabilizing Your Test Deployment
Deploying the DirectControl Solution Deploying the DirectControl Solution
Operating the DirectControl Solution Operating the DirectControl Solution
Evolving the DirectControl Solution Evolving the DirectControl Solution

Introduction and Goals

The Centrify DirectControl commercial solution enables a rapid implementation of End State 2. In the Windows Security and Directory Services for UNIX Guide, End State 2 is defined as the solution that lets UNIX clients use Kerberos to authenticate to Active Directory and use Lightweight Directory Access Protocol (LDAP) to retrieve authorization and identity information from Active Directory. This chapter describes how to prepare, develop, test and stabilize, and deploy the DirectControl solution to reach this End State 2 goal in an environment that includes Windows-based and UNIX-based or Linux-based computers. It also explains how to operate the solution and how you might want to further evolve your implementation of DirectControl in the future to take advantage of the full set of Active Directory services.

The Centrify DirectControl suite uses the Microsoft® Windows Server™ 2003 Active Directory® directory service to provide secure and centralized management of identities, access control, and policy for computers running UNIX, Linux, or Macintosh operating systems. Deploying the Centrify DirectControl solution enables you to consolidate all computer, user, and group accounts in Active Directory and use Active Directory for all authentication, authorization, and directory services.

DirectControl also includes features that extend identity management to include controlling access to applications running on UNIX, Linux, or Macintosh platforms. These include Web applications and application servers such as Apache HTTP Server Project (including Apache Tomcat), JBoss, IBM WebSphere, and BEA WebLogic.

This chapter introduces you to the DirectControl solution but does not cover all aspects of configuring or using this product. Although DirectControl supports multiple UNIX and Linux platforms and Apple Macintosh OS X, the information here focuses on implementing DirectControl to achieve End State 2 with computers running Red Hat Linux version 9 and Sun Solaris UNIX version 9. The procedures in this chapter are specific to Red Hat 9.

For more information about Centrify DirectControl, including detailed information and steps for other supported operating systems, review the Centrify DirectControl Administrator’s Guide that is included with the product and other information available on the Centrify company Web site at http://www.centrify.com.

Chapter Organization

As described in “About This Guide,” the Windows Security and Directory Services for UNIX Guide is organized around the principles of the Microsoft Solutions Framework (MSF) Process Model and its five phases (Envisioning, Planning, Developing, Stabilizing, and Deploying) for managing IT projects, as well as the Microsoft Operations Framework (MOF) Operating Quadrant for improving operational efficiency.

The technology solution chapters in this volume, including both commercial solutions and several custom solutions, are built on the Envisioning Phase and Planning Phase chapters earlier in this guide—Volume 1: Chapter 2, “Envisioning Your Windows Security and Directory Services Solution” and Volume 2: Chapter 1, “Choosing the Right Technology and Planning Your Solution.”

The commercial solution chapters, including Centrify DirectControl, present information about the stages for preparing, developing, stabilizing, deploying, operating, and evolving the solution in a single chapter. This differs from the structure used for the custom solutions, which present the preparing and developing stages together but require separate chapters for the stabilizing, deploying, operating, and evolving stages.

For a depiction of the structure of the chapters in this volume, you might find it helpful to review Figure 0.2, "Volume and chapter structure of the Windows Security and Directory Services for UNIX Guide" in "About This Guide."

Intended Audience

All team leads should read each section of this chapter. In addition, specific sections of this chapter should be read by all team members who share a specific role.

  • Preparing. The primary audience for the Preparing section includes members of the Development and Test Roles who are responsible for setting up the development lab or test lab.

  • Developing. The primary audience for the Developing Phase section is the Development Role. However, members of the User Experience (documentation and usability) and Test Roles are also responsible for specific tasks, such as setting up the development lab; performing verification testing; and creating or updating site preparation and deployment checklists as well as pilot and deployment plans.

    Some development work might continue into the Stabilizing Phase in response to test results.

  • Stabilizing. The primary audience for the Stabilizing Phase section includes the Test, Development, and Release Management Roles.

  • Deploying. The primary audience for the Deploying Phase section is the Release Management Role.

  • Operating. The audience for the Operating section is systems administrators, computer security personnel, IT support staff, and members of the operations group responsible for both UNIX-based or Linux-based computers and the Windows environment.

  • Evolving. The audience for the Evolving section includes all teams. It is especially appropriate for:

    • Developers. Application developers can learn how to extend applications to take advantage of the security and directory infrastructure that has been enabled by the DirectControl product.

    • Deployment and Operations Staff. Deployment, operations, and support staff can learn how to apply centralized policy and configuration settings across their UNIX-based computers by using the Group Policy capabilities of DirectControl. Other topics of interest for administrators are also covered in the discussion about evolving the solution.

Knowledge Prerequisites

Ensure that your team possesses the knowledge requirements stated in “About This Volume” and identified in the “Project Team Skills Template” job aid. Members of the Development, Test, and Release Management Roles and all team leads involved in implementing the Centrify DirectControl solution should review the information in this chapter and the following list of resources before completing planning or starting any development or testing.

CAUTION   Before you complete your planning preparations, it is important that you are familiar with the information specifically about the Centrify DirectControl solution contained in this chapter.

Development, Test, and Release Management team members should review the following DirectControl product documentation, especially information about DirectControl zones:

  • Centrify DirectControl Administrator’s Guide

  • Centrify DirectControl Evaluation Guide

  • Centrify white papers, which are available from the Centrify Corporation:

    • "Active Directory and DirectControl: The Right Choice for Enterprise Identity Management and Infrastructure Consolidation," April 2005.

    • “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration,” February 2005.

These documents are available with the Centrify DirectControl product. See the next subsection, "Software Prerequisites," for information about how to obtain the DirectControl product.

All team leads should review the following Microsoft information:

For more information about MSF, MOF, and the UMPG, see "About This Volume" in this guide.

Software Prerequisites

To develop and deploy the Centrify DirectControl solution for End State 2, you need to acquire the DirectControl software. The DirectControl software is available on a single CD, which includes all of the software and documentation components referred to in this chapter for both Windows and the various supported UNIX and Linux platforms.

You can either request an evaluation copy or purchase Centrify DirectControl licenses directly from the Centrify Corporation. The DirectControl evaluation license enables unlimited use of the software for any number of computers and users for a 30-day period.

To contact Centrify, you can:

  • Visit the Centrify company Web site: http://www.centrify.com.

  • Send e-mail to Centrify: info@centrify.com.

  • Call Centrify: 1-650-961-1100.

In addition to obtaining the DirectControl software and meeting the prerequisites listed in “About This Volume,” you must have Active Directory configured and deployed in order to effectively implement this solution. For more information about these prerequisites, see “Preparing Your Environment” later in this chapter.

Overview of Centrify DirectControl Technology

The Centrify DirectControl solution integrates Windows and UNIX environments in a unique way, giving Active Directory users and groups access to resources stored on UNIX or Linux hosts and allowing UNIX or Linux users, groups, and computers to be imported into and managed through Active Directory.

When you use DirectControl to achieve End State 2, you can:

  • Specify which Active Directory users and groups can log on to a specific UNIX-based computer or group of computers.

  • Control user access to UNIX-based computers across the entire Active Directory forest, regardless of the organizational structure you use or where users are defined in that structure.

  • Map local UNIX accounts, such as the root user, to Active Directory accounts for centralized control over access and passwords.

  • Identify specific local UNIX accounts to be authenticated locally instead of through Active Directory.

  • Migrate multiple existing UNIX account information stores into Active Directory, as needed.

  • Enable authenticated users to connect to Web applications without being prompted to log on again with their Active Directory credentials (single sign-on).

  • Take advantage of Active Directory Group Policy to apply settings and controls for UNIX users and computers.

To enable integration, Centrify DirectControl provides components that are installed in the Windows environment and components that are installed on each UNIX-based or Linux-based computer.

This overview includes the following topics:

  • Overview of DirectControl software components for Windows

  • Overview of DirectControl software components for UNIX

  • How DirectControl stores UNIX user attributes in Active Directory

  • How DirectControl imports existing UNIX accounts into Active Directory

  • How DirectControl manages role-based access control

  • How DirectControl zones facilitate a phased deployment

Overview of DirectControl Software Components for Windows

When you run the Centrify DirectControl setup program on a Windows-based computer, you can choose which components to install. You can choose from both required and optional components.

Required:

  • Centrify DirectControl property extensions for Active Directory. You must install one of the options for the Centrify Active Directory property extensions that you are prompted to select when you run the DirectControl installation program.

    These property extensions must be installed on at least one computer that is joined to an Active Directory domain and has the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in installed. MMCs are graphical user interface (GUI) consoles that host administrative tools for Windows called snap-ins. The property extensions update the Active Directory forest to store additional UNIX-specific attributes for each user account that uses the native Active Directory schema.

    For more information about these property extensions, see the section "How DirectControl Stores UNIX User Attributes in Active Directory" later in this overview.

  • Centrify DirectControl Administrator Console. You must install this console on at least one computer that can access Active Directory domains. The Centrify DirectControl Administrator Console provides a central location for managing UNIX users, groups, and computers and for performing administrative tasks, such as importing accounts, running reports, and analyzing account information.

Optional:

  • DirectControl Documentation. Documentation, release notes, and online help for the Centrify DirectControl Administrator Console are optional. You can install one or more of them on any Windows-based computer.

  • DirectControl NIS Map Extensions. The DirectControl Network Information Service (NIS) Map Extensions component is optional. You can install it on at least one computer if you want to import and manage NIS maps, such as netgroup or auto.master, in Active Directory.

  • DirectControl Administrative Template. The DirectControl Administrative Template for Group Policy is optional. You can install it on at least one computer on which the Group Policy Object Editor console is installed.

Overview of DirectControl Software Components for UNIX

When you run the Centrify DirectControl installation script on a UNIX-based computer, a core Agent package of services that handles communications between programs on the UNIX platform and Active Directory is installed. You can also install optional components that require additional steps to activate, such as the DirectControl authentication and authorization module for Apache or the DirectControl Network Information Service (NIS).

The following figure depicts DirectControl software components that run on a UNIX-based computer.

Figure 3.1. Simplified view of the Centrify DirectControl architecture

Figure 3.1. Simplified view of the Centrify DirectControl architecture

The following table briefly defines each component shown in the preceding figure.

Table 3.1. Centrify DirectControl Architecture Components

Component

Description

DirectControl daemon (adclient)

The DirectControl Active Directory client daemon (program), adclient, manages all direct communications with Active Directory as well as all operations provided through the other DirectControl services.

DirectControl service library

Service libraries are included with DirectControl to handle Kerberos, LDAP, and Active Directory–specific calls. These libraries are used by the various DirectControl modules.

CLI tools

The DirectControl command-line interface (CLI) programs enable you to perform common administrative tasks, such as join or leave the Active Directory domain, change user passwords, or collect diagnostic information. You can use these command-line programs interactively or in scripts to automate tasks.

Kerberos cache, keytab, and configuration files

DirectControl automatically sets up and maintains Kerberos system files and services on the UNIX-based computer. For example, DirectControl automatically configures the krb5.conf file, and DirectControl automatically maintains state files such as the Kerberos krb5.keytab file.

Offline cache

When a user logs on to the UNIX-based computer, the user's credentials are cached locally so that the user can continue to log on to the computer for future sessions, even when a domain controller is not available or the network is offline.

Kerberized applications (for example, ssh, nfs)

Applications that use Kerberos for authentication can use DirectControl to authenticate to an Active Directory server.

UNIX login applications (for example, login, ftp, ssh)

Standard UNIX applications that use Name Service Switch (NSS) or pluggable authentication modules (PAM), described next, to locate a name service or an authentication mechanism can use Active Directory for these services through DirectControl.

NSS module

The Name Service Switch (NSS) defines the types of system databases that can be used for applications running on UNIX or Linux systems. For example, entries are included for directing user account queries to one or more backend user account databases. These include local files (such as /etc/passwd), NIS, or LDAP. Applications that need access to user information, such as for mapping a user name to a user ID, can use NSS to look up the information in an implementation-independent way, regardless of the backend database that is used.

The DirectControl NSS module enables standard operating system services that do not use PAM or Kerberos to look up information in Active Directory. NSS updates the /etc/nsswitch.conf file to use the DirectControl daemon to access information that is stored in Active Directory through LDAP.

For more information about NSS, see Volume 1: Chapter 1, “Overview of Authentication and Authorization Technologies and Solution End States,” and see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."

PAM module

Pluggable authentication modules (PAM) is a flexible mechanism for authenticating users. PAM provides a way to develop programs that are independent of the authentication scheme. Programs that need authentication services will automatically use the mechanism that is defined by the PAM system. Different authentication modules can be attached to different programs based on local configuration files. PAM is typically used on UNIX and Linux systems to automate authentication and session creation for a user logging on to the system.

The DirectControl PAM module, pam_centrifydc, works with the adclient daemon to provide a number of services, such as checking for password expiration, filtering for users and groups, and creating the local home directory and default user-profile files for new users. The pam_centrifydc module is automatically placed first in the PAM stack in the /etc/pam.d/system-auth file to ensure that it takes precedence over other authentication modules. For more information about PAM, see Volume 1: Chapter 1, "Overview of Authentication and Authorization Technologies and Solution End States," and see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."

Apache

The Apache Web server can be configured to use Active Directory for backend directory and authentication services.

Apache SPNEGO module

The DirectControl Apache SPNEGO module provides silent authentication services for Apache Web applications using Active Directory as the authentication authority. This allows Microsoft Internet Explorer to silently and securely pass the client user identity to a Web application hosted on an Apache Web server that runs on a UNIX-based computer.

Note   SPNEGO stands for Simple and Protected GSS-API Negotiation Mechanism. SPNEGO is an HTTP authentication mechanism that is used by Microsoft Internet Explorer and by the Microsoft Internet Information Services (IIS) Web server for Kerberos-based user authentication.

SDK

The DirectControl Software Development Kit (SDK) can be used to create custom applications and scripts that integrate with Active Directory for authentication and directory services.

J2EE applications (WebLogic, WebSphere, Tomcat, JBoss)

Java 2 Platform Enterprise Edition (J2EE) application platforms such as the BEA WebLogic, IBM WebSphere, Tomcat, and JBoss platforms (and the applications that run on these platforms) can be configured to use Active Directory for backend directory and authentication services.

J2EE JAAS module

Java Authentication and Authorization Service (JAAS) is a standard Java package that provides interfaces to allow applications to perform silent or prompted authentication of user credentials. Centrify DirectControl includes a customized JAAS realm for J2EE applications that supports using Active Directory for authentication.

J2EE SPNEGO module

The DirectControl J2EE SPNEGO module uses Active Directory as the authentication authority to provide silent authentication services for J2EE Web applications.

JNI wrapper

The Java Native Interface (JNI) wrapper provides an interface between the DirectControl service library and JNI. JNI is a programming interface in the Java Virtual Machine from Sun used for calling native platform elements, such as GUI routines.

Group Policy service

The DirectControl Group Policy service interacts with the Group Policy system on the Windows-based server and ensures that applicable policies are correctly executed on the UNIX-based computer.

System configuration files

System configuration files can be used to control Group Policy objects that run on the UNIX platform.

Virtual registry

DirectControl maintains a virtual registry that is used to store configuration settings that get executed by the DirectControl Group Policy system.

NIS daemon (adnisd)

The optional DirectControl Active Directory Network Information Service (NIS) daemon, adnisd, can be installed on at least one computer if you want to store NIS maps in Active Directory and publish the information through DirectControl.

NIS client applications

Local and remote NIS client systems and applications can use DirectControl NIS to access directory information stored in Active Directory.

NIS cache

NIS information is cached locally on a system that runs the DirectControl NIS daemon. This reduces network traffic and load on Active Directory domain controllers.

The following subsections provide more detail about the most important components of the Centrify DirectControl architecture.

Centrify DirectControl Daemon (adclient)

The core component of the Centrify DirectControl Agent is the adclient daemon. The DirectControl adclient daemon handles all direct communications with Active Directory and works in conjunction with all other DirectControl Agent modules to perform the following key activities:

  • Locates domain controllers. Locates the appropriate domain controllers for the UNIX-based or Linux-based computer based on Active Directory forest and site topology.

  • Verifies domain membership. Provides Active Directory with credentials that verify that computer is a valid member of the domain.

  • Manages user credentials. Delivers and stores user credentials so that users can be authenticated by Active Directory and can sign on even when the computer is disconnected from the network.

  • Caches information to improve performance. Caches query responses and other information to reduce network traffic and the number of connections to Active Directory. The cache contents and all communications with Active Directory are encrypted to ensure security. The daemon caches positive and negative query results for better performance.

  • Manages Kerberos. Creates and maintains the Kerberos configuration and service ticket files so that all existing Kerberized (Kerberos-enabled) applications work with Active Directory without any additional manual configuration.

  • Synchronizes clock. Synchronizes the local computer’s time with the clock maintained by Active Directory to ensure the time stamp on Kerberos tickets issued by the Windows Key Distribution Center (KDC) are within a valid range.

  • Resets computer password. Resets the password for the local computer account in Active Directory at regular intervals to maintain security for the account’s credentials.

  • Provides services to other modules. Provides authentication, authorization, and directory look-up services to the other DirectControl modules, for example, to the PAM or Java modules.

The DirectControl adclient daemon must be running on the UNIX-based or Linux-based computer for that computer to have access to the information stored in Active Directory.

Centrify DirectControl for PAM-enabled Services (pam_centrifydc)

The Centrify DirectControl PAM module, pam_centrifydc, provides the interface between the standard UNIX authentication libraries used by most system applications and the DirectControl adclient daemon that manages direct communications between a UNIX or Linux host and Active Directory. The pam_centrifydc module provides the following services:

  • Kerberos-based user authentication for PAM-enabled services. Services such as login, sshd, telnetd, and ftpd, which are typically configured to use PAM, can authenticate users configured to use Kerberos tickets and Active Directory. After the user is authenticated, the DirectControl daemon stores the Kerberos credentials locally in an encrypted cache so that the credentials are available for other applications to use.

  • Disconnected authentication. When users log on and are authenticated successfully through Active Directory, the pam_centrifydc module caches their credentials so that they can log on and be authenticated when the computer is disconnected from the network or when the Active Directory domain controller is not available.

  • Automatic home directory creation. When a new user logs on and is authenticated through Active Directory, the pam_centrifydc module automatically creates a home directory for the user if the home directory for the user does not already exist. The path to the home directory corresponds to the home directory attribute for the user stored in Active Directory.

  • Account conflict checking. When users log on, the pam_centrifydc module checks for user name and user ID (UID) conflicts between users enabled for UNIX or Linux access in Active Directory and local user accounts defined in the /etc/passwd file. If a conflict exists, the logon succeeds, but a warning appears when the user logs on and an event is written to the local UNIX system log.

  • User and group filtering for fine-tuned access control. You can use Group Policy to grant or deny users or groups access to any computer or group of computers managed by DirectControl. Your Group Policy settings are enforced through the pam_centrifydc module.

  • Local override flexibility. DirectControl allows you to enable one or more user accounts that are always authenticated locally by using the /etc/passwd file instead of Active Directory.

  • Password administration. DirectControl provides a command-line program, Active Directory password (adpasswd), that lets UNIX or Linux users change their Active Directory password from the UNIX-based or Linux-based computer. The pam_centrifydc module enforces Active Directory password policies for length, complexity, expiration, and history.

Centrify DirectControl Name Server Switch (nss_centrifydc)

The Centrify DirectControl NSS module, nss_centrifydc, performs user and group name lookups and file-based authorization for program and application requests through LDAP. The adclient daemon stores the responses locally in an encrypted cache to enable support for disconnected operation and to ensure faster performance, reduced network traffic, and improved security caching. In addition, the DirectControl NSS module provides the following features:

  • User and group filtering to selectively look up information in Active Directory. Through configuration options or Group Policy, you can handle lookup requests for specific users and groups locally instead of through Active Directory. For example, 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 (which contains local user account information) or /etc/group file (which contains local group information) 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 that particular programs not 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.

How DirectControl Stores UNIX User Attributes in Active Directory

The Active Directory schema defines each object, and its attributes, that can be stored in Active Directory. The schema is a description of the object classes (the various types of objects) and the attributes for those object classes.

For each class of object, the schema defines the attributes that object class must have, the additional attributes it may have, and the object class that can be its parent. Schema definitions are themselves also stored as objects—Class Schema objects and Attribute Schema objects—in Active Directory.

UNIX-based 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 the usual 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-based computer must look up certain fields that (by default in versions of the Windows Server 2003 operating system prior to R2) do not have an equivalent in Active Directory. Some of these fields include user ID (or UID, which specifies the user's unique numeric ID), primary group (or GID, which 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). 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, Windows Services for UNIX 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-based computers. These fields, provided to Active Directory by Windows Services for UNIX, include NIS Domain, UID, Login Shell, Home Directory, and Primary group name.

DirectControl supports the methods described in the following subsections for storing UNIX user attributes in Active Directory.

Microsoft Windows Server 2003 R2 RFC 2307 Schema

Microsoft implemented a new UNIX schema for the release of Windows Server 2003 R2 in 2005. Centrify fully supports this new schema and plans to continue to track and support any UNIX schema extensions that Microsoft releases in the future. Windows Server 2003 R2 includes support for RFC 2307 as part of its default installation. The RFC 2307 schema can also be deployed on servers running versions of Windows Server 2003 or Windows 2000 Server earlier than Windows Server 2003 R2. You can use the Microsoft-supported tool ADSI Edit to add the R2 UNIX schema attributes to a pre-R2 domain.

Note   The procedures in this chapter were developed and tested with Active Directory servers that are running a version of Windows Server 2003 prior to R2.

DirectControl Zones

DirectControl simplifies the whole schema extension issue by simply eliminating the need for any schema extensions even if your Active Directory servers are running a version of Windows earlier than Windows Server 2003 R2. Instead, DirectControl automatically stores UNIX user attributes in a well-defined Active Directory storage class under the Program Data container hierarchy, which is reserved for use by applications. 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.

Using the DirectControl zones feature, multiple sets of UNIX user attributes can be tied to a single Active Directory user. You can use either the Active Directory Users and Computers snap-in or the Centrify Administrator Console to manage these attributes. If your organization has already deployed Microsoft-supported UNIX schema extensions, such as the UNIX extensions included with Windows Services for UNIX (described next), you can configure DirectControl to use that storage mechanism in addition to or as an alternative to DirectControl zones.

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 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.

Zones are also useful for organizations that want to establish strict role-based access control (RBAC) restrictions for UNIX-based computers, groups, and users. For example, you can add Active Directory users or groups as members of a zone if the users or groups have a requirement to access computers in that zone. Other users or groups who are not members of the zone cannot access the computers in that zone.

For more information about DirectControl zones, including how to accommodate legacy UNIX identity stores, see the white paper, “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration” on the Centrify company Web site at http://www.centrify.com.

For more information about how DirectControl handles RBAC, see "How DirectControl Manages Role-based Access Control" later in this overview.

Windows Services for UNIX Schema Extensions

The Windows Services for UNIX product includes a method for extending the Active Directory schema by adding storage fields for UNIX attributes. DirectControl fully supports using these Microsoft-supported schema extensions. If your organization has deployed the Windows Services for UNIX schema extensions, DirectControl can treat them as a separate zone. Other zones can be used side-by-side with the Windows Services for UNIX zone, which gives your organization a considerable degree of flexibility for establishing a consolidated identity solution that best meets your needs.

CAUTION   Extending the Active Directory schema is not reversible and therefore requires care. To reduce the chance that problems might arise during the extension process, the recommended practice is to select extension mechanisms that Microsoft supports, such as Windows Services for UNIX. Before you extend the schema, see "Extending the schema" in the Windows Server 2003 Help and Support Center.

The example in the following screenshot displays Windows Services for UNIX schema attributes as a DirectControl zone on the Centrify Profile tab for Jeff Hay. If Windows Services for UNIX is already installed, the Centrify Profile tab appears on the user properties page in Active Directory Users and Computers after you run the DirectControl Setup Wizard. (You can also view or modify Windows Services for UNIX settings by using the UNIX Attributes tab.)

Figure 3.2. Windows Services for UNIX schema attributes appear as a Centrify zone on the user properties page in Active Directory Users and Computers.

Figure 3.2. Windows Services for UNIX schema attributes appear as a Centrify zone on the user properties page in Active Directory Users and Computers.
How DirectControl Imports Existing UNIX Accounts into Active Directory

Typically, you have existing UNIX account information that must be mapped to Active Directory users and groups. You can do this by using the Centrify DirectControl Administrator Console to selectively import UNIX account information into Active Directory and specifying how those existing accounts map to Active Directory users and groups. For existing users, the importation process does not import the user's UNIX password. When you import UNIX users into Active Directory, you are given the option to create an Active Directory account for users who do not have an existing Active Directory account.

Preparing for the importation process requires that you first determine where UNIX users' account information is stored currently and how you will resolve any account conflicts that might occur.

Determining Current UNIX Account Store

Before you import existing UNIX account information into Active Directory, you must first ascertain where existing UNIX account information is stored in your UNIX environment. The three most common repositories for storing UNIX account information are the following:

  • Local text files. Local UNIX configuration files, such as /etc/passwd and /etc/group, that store local user and group accounts.

  • NIS server. A Network Information Service (NIS) server and the databases or maps that store users, groups, and other network-related information for NIS domains.

  • LDAP server. A central LDAP server that stores user and group account information for a network of UNIX-based computers.

Depending on your environment, you might need to import information from one or more of these sources. Therefore, the first step to take in planning to import existing information is to determine whether the information is stored in NIS, NIS+ (an enhanced version of NIS), LDAP, or local UNIX files, or a combination of such UNIX-based stores.

Resolving Multiple Identities with DirectControl Zones

One of the unique features of the DirectControl solution is the capability to import multiple legacy UNIX account stores into DirectControl zones and thereby map a single Active Directory user account to multiple UNIX IDs. Although it might seem desirable to use a single user name for both UNIX and Windows, accommodating existing directories and systems might make this impossible—at least initially.

The following simple example helps illustrate this problem. The current environment might have a NIS directory service in which the naming convention is firstname.lastname for users (for example, jeff.hay) and UIDs are in the range 10,000–99,999. The example organization also includes a collection of UNIX-based computers that have no centralized directory but instead store user account information locally on the UNIX-based computer with a different set of policies—user names are first-initial plus the last name (for example, jhay) and UIDs start at 500.

If you consolidate the two UNIX identities into a single identity, the consolidation can cause substantial disruption for some users because:

  • They must use new logon names on some computers.

  • They must reset file ownerships.

  • In some cases (for example, mail files based on a user name), they must change file names. If your organization has thousands of users, this task is enormous.

You can avoid this type of problem by using DirectControl zones. With this approach, you can import each legacy directory store into separate zones in Active Directory. For the example described in the preceding paragraph, you can use the following procedure.

To use DirectControl zones to resolve multiple identities (example)

  1. Import directory information:

    1. Import the NIS directory store into a zone called nis-zone. 

    2. Import the /etc/passwd information from the non-NIS UNIX-based computers into a zone called passwd-zone.

  2. Create many-to-one maps. Map each user listed in each zone to the appropriate Active Directory account in a many-to-one relationship.

    In this example, map both of Jeff Hay's UNIX accounts to a single Active Directory account by linking the Active Directory user account called Jeff Hay to both his UNIX account with the user name jeff.hay and UID of 10029, and to his other UNIX account with the user name jhay and UID of 527.

    After you map these accounts, users can log on to their UNIX-based computers with their previous logon name and their Active Directory password with no disruption. For example, the user Jeff Hay can log on with either jeff.hay or jhay and, in both cases, use his Active Directory password. There is no need to change ownerships or file names.

For detailed information about how to use the Centrify zone approach to migrate UNIX user accounts to Active Directory, see the white paper “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration,” available at http://www.centrify.com.

How DirectControl Manages Role-based Access Control

Role-based access control (RBAC) refers to a technique of managing users based on their roles within an organization and establishing policies for members who share the same role.

For example, all auditors in your finance department might belong to the group role described as "financial auditors," and only those employees should have read-write access to consolidated financial reports. If those reports are stored on three regional UNIX-based computers, you might also want to restrict access to those computers to the set of people who are financial auditors.

Even if your organization initially or eventually decides to consolidate user names and UIDs so that each user uses a single name for logging on to both UNIX-based and Windows-based computers, DirectControl zones can still play a role as a method for managing RBAC for your UNIX-based computers. The following subsections use a series of example procedures for protecting financial data to illustrate how you can use DirectControl to manage RBAC.

Restricting Access by Using Zones for RBAC

You can use a Centrify DirectControl zone to restrict access to UNIX-based computers containing financial data to employees in the financial auditor role.

To use zones to restrict access (example)

  1. Place restricted UNIX-based computers in a zone. Using the Centrify Administrator Console on a Windows-based computer joined to the domain, place the UNIX-based computers to which you want to restrict access into their own zone called, for example, the audit-systems zone.

  2. Add auditors to that zone. Grant only auditors logon access to these computers by adding them as members of the zone using the Centrify Administrator Console.

Restricting Access by Using Active Directory for RBAC

Alternatively, you can use an Active Directory group to restrict access to UNIX-based computers containing financial data to employees in the financial auditor role. Your organization might already use Active Directory groups to manage some form of role-based access control for Windows-based computers. For example, all auditors in the finance department might be members of an Active Directory group called "finaudit."

With DirectControl, you can restrict access to the UNIX-based computers by group. DirectControl includes a file, /etc/centrifydc/centrifydc.conf, that controls the settings for numerous parameters related to how DirectControl operates. One of these parameters is the pam.allow.groups setting.

To use Active Directory to restrict access (example)

  1. Open centrifydc.conf. On each UNIX-based computer that contains financial data, open the /etc/centrifydc/centrifydc.conf file.

  2. Configure a restriction. Specify the following setting:

    pam.allow.groups: finaudit

    This setting restricts access to the UNIX-based computer to people who are members of the finaudit Active Directory group. As described later in this chapter, this configuration setting could also be managed centrally by using Group Policy.

Allowing Access to Active Directory–enabled UNIX Applications

DirectControl lets you use Active Directory properties to enable access to certain UNIX applications. You can use this feature to explicitly define which applications are Active Directory–enabled on each UNIX-based computer. Active Directory–enabled applications use Active Directory authentication, authorization, and other services to control access to certain features within the application.

For example, if you have a Web-based application running on a Tomcat server, you can enable Active Directory authentication for that server and then apply restrictions to certain pages based on Active Directory credentials.

You can, for instance, use Active Directory group membership to restrict access to a page that contains financial information to members of the finaudit Active Directory group. When a user tries to access the page, Tomcat checks whether the user is a member of the finaudit group. A user who is a member is granted access to the page without being prompted to reenter Active Directory credentials. A user who is not a member is denied access to the page.

Using Group Policy with DirectControl to Manage GPOs

An important feature of DirectControl lets you create Windows Group Policy objects (GPOs) for UNIX-based computers. Group Policy is particularly effective in regulating policy or applying settings across a large number of computers.

Continuing the earlier financial example, you can use the following procedure to manage GPOs.

To use DirectControl to manage GPOs (example)

  1. Log on. On a Windows-based computer with Active Directory Users and Computers and the DirectControl Administrator Console installed, open Active Directory Users and Computers.

  2. Create an OU:

    1. In the left pane, select the domain that you use for the DirectControl deployment.

    2. Right-click the domain name, select New, and then click Organizational Unit.

    3. In the Name dialog box, give the new OU a unique name, such as Finance Computers.

  3. Move auditors' computers into the new OU. Move each of the UNIX-based computers that contain financial information used by auditors into this new Active Directory OU:

    1. Right-click a UNIX-based computer account in its current OU.

    2. Select Move 

    3. Select the name of the new OU (in this example, Finance Computers), and then click OK.

  4. Allow only auditors to access auditors' computers.

    1. Configure a GPO for this OU to enforce setting the pam.allow.groups attribute with the value finaudit.

      This setting means that only members of the finaudit Active Directory group can access the UNIX-based computers in this OU. For more information, see "Creating a Centrify DirectControl Group Policy Object" in the Centrify DirectControl Administrator’s Guide.

    2. Apply this policy to the OU.

      This policy now governs all UNIX-based computers in this OU.

At the same time, you can also configure other policies to implement role-based access control, for example, for other groups of computers.

For detailed information about how to use Group Policy with DirectControl, see the Centrify DirectControl Administrator’s Guide.

Applying Security Controls

You can use role-based access control for administrators and operators as well as for end users. Most organizations restrict access to the Administrator account for security reasons. For that reason, Centrify has added the capability to delegate administration of zones to nonprivileged users.

In addition, most organizations restrict access to the root password on critical UNIX-based computers. Ideally, you should manage control over root accounts centrally and apply policies for password complexity, password aging, and other security-oriented policies to the root account on each UNIX-based computer or on groups of computers.

Assigning Management Privileges for Each Zone

You can use the Centrify DirectControl Administrator Console to give specific users and groups permission to perform certain types of administrative tasks within each zone.

For example, assume that you have a zone called Finance and you want to set up different types of permissions for the different kinds of administrators who manage computers in this zone. Through the Centrify DirectControl Administrator Console, you can assign specific permissions to individual users and groups. You can assign:

  • The ITStaff group full control, which allows members of that group to perform all administrative tasks.

  • The FinanceAdmins group permission to read and modify zone information and zone membership.

  • The FinanceUsers group permission to read zone information but perform no other tasks.

  • The users jeff.hay and lori.penor permission to delete zones.

To delegate which users and groups have control over zone objects (example)

  1. Log on. On a Windows-based computer, open the Centrify DirectControl Administrator Console.

  2. Select a zone. In the console tree, select Zones, and then select the zone you want. For example, open the default zone.

  3. Configure who can control zone objects:

    1. Right-click the default zone that you selected, and then click Delegate Zone Control.

    2. At the Welcome page, click Next.

    3. Click Add, and then use Find, with search criteria if necessary, to locate the user or group to which you want to delegate control.

    4. Click OK. After you finish adding users or groups, click Next.

    5. From the list, select the tasks you want to delegate to the user or group. For example, if you want members of the selected group to be able to modify zone information, select the Modify Zone Information task.

    6. Review your selections, and then click Finish.

Mapping Privileged Local UNIX Accounts to Active Directory Accounts

As described later in the section, “Optionally Mapping Local UNIX Accounts to Active Directory,” DirectControl includes support for mapping any local UNIX account to an Active Directory account. Before you deploy DirectControl, establish a policy for how your organization wants to handle certain local UNIX accounts, such as the root account. In some cases, consider the use of Group Policy as a method for applying a consistent policy of local account mapping across a large number of computers.

For more information about how to map user accounts—either individually or by using Group Policy—see the Centrify DirectControl Administrator’s Guide.

How DirectControl Zones Facilitate a Phased Deployment

A good approach for reaching a fully deployed End State 2 solution in your production environment is to roll out the deployment in phases. Performing a phased deployment is recommended in organizations with large numbers of UNIX-based computers or many different legacy directory systems. The DirectControl zones feature is particularly useful in helping organizations to compartmentalize the project into manageable phases.

If your organization has multiple legacy directory systems—either central directories such as NIS or local directories that use /etc/passwd—you might choose to use one zone for each directory that you move into Active Directory, dividing the migration project into subprojects, based on the number of zones. A good tactic is to start with a small zone.

The following table lists the high-level set of steps necessary to perform a phased deployment. For detailed steps, see "Deploying the DirectControl Solution" and "Stabilize the Production Deployment" later in this chapter.

Table 3.2. Example: Deploying DirectControl in Phases One Zone at a Time

Deployment Phase

Description

1. Deploy a small zone

Synopsis steps:

  1. Use the Centrify Administrator Console on a Windows-based computer to import a single /etc/passwd file into a single zone that has a small number of UNIX-based computers as members.

  2. Join the UNIX-based computers in that zone to Active Directory.

  3. Carefully monitor and resolve any issues that users or support staff experience.

2. Deploy a larger zone

After the first zone is fully deployed and stabilized, update your deployment documentation with information learned from the first deployment, and then deploy the next largest zone.

3. Deploy each remaining zone

Continue deploying zones one at a time until all legacy directory systems are successfully migrated to Active Directory.

You can use this strategy to complete the deployment and stabilization of the migration to Active Directory with minimal risk, little disruption, and manageable resource utilization.

For detailed information about using DirectControl to perform a phased migration of NIS or local directories to Active Directory, see the white paper “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration,” available at http://www.centrify.com.

Preparing Your Environment

The following sections describe how to prepare your environment for the Centrify DirectControl security and directory services solution for End State 2. Preparing your environment requires that you perform the following tasks:

  • Install and configure the first Active Directory domain controller.

  • Set up a second domain controller.

  • Prepare for training, testing, and deployment.

Install and Configure the First Active Directory Domain Controller

The Windows Server 2003 or Windows 2000 Server Active Directory domain controller stores and replicates directory data for the domain and provides authentication and authorization services, acting both as the Kerberos KDC and as the LDAP authorization data store.

When you set up your development environment, Microsoft recommends that you install and configure two domain controllers so that you can test UNIX or Linux authentication and authorization under failover conditions. Installing both domain controllers at the same time helps avoid replication issues.

Installing and Configuring Active Directory and DNS

The first step in setting up your development lab is to install a domain controller that is running the Domain Name System (DNS) service and to create a test forest.

For detailed steps showing how to install Active Directory and DNS on a domain controller, see Appendix L: "Installing and Configuring Active Directory and DNS in Your Lab." Use the steps in Appendix M to set up your first test Windows Server 2003 domain controller in your development lab. These procedures show you how to prepare the domain controller to provide Kerberos authentication and LDAP authorization services for UNIX-based computers.

IMPORTANT   It is possible to install the DNS service on a different server (either Windows or UNIX) than the domain controller or to install DNS on the domain controller later after you first install and configure the domain controller itself. For best results when deploying a solution that enables UNIX clients to authenticate to Active Directory, the recommended practice is to install and configure Active Directory and DNS at the same time. The procedures in this guide were developed and tested in a lab in which DNS is configured on the domain controllers as part of the Active Directory installation process.

Configuring the DNS Server

The preceding section assumes that you configure the DNS server role on the Active Directory domain controllers for your test environment; Appendix L: "Installing and Configuring Active Directory and DNS in Your Lab" provides the steps to do so.

If, however, you do not use the Windows Server 2003 Active Directory domain controller as the DNS server (as is assumed in this chapter) or if you do not allow dynamic updates, additional configuration steps are necessary:

  • For information about other DNS configuration options, see the Centrify DirectControl Administrator’s Guide (included with the DirectControl product).

  • For more information about installing and configuring DNS, see Appendix G: "Configuring DNS for a Heterogeneous UNIX and Windows Environment" in this guide, and see "Deploying Domain Name System (DNS)" in the Windows Server 2003 Deployment Guide at http://go.microsoft.com/fwlink/?LinkId=45677.

  • For more information about installing and configuring DNS, see "Deploying Domain Name System (DNS)" in the Windows Server 2003 Deployment Guide at http://go.microsoft.com/fwlink/?LinkId=45677.

Creating Test OUs, Users, and Groups

We recommend that you add all UNIX users, computers, and groups under a separate Active Directory organizational unit (OU). Using a separate container lets you manage UNIX objects in Active Directory separately from Windows objects, including applying unique Group Policy settings to the objects used by UNIX.

To create OUs , users , and groups for UNIX objects

  1. Log on with rights to add users and groups. Log on to a Windows-based computer on which Active Directory Users and Computers is installed with a user account that has rights to add new users and groups.

  2. Open Active Directory Users and Computers:

    • Click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

  3. Create a new OU to hold UNIX test users and groups. For example, create a new OU under the domain called MyUNIXTest:

    1. In the console tree, right-click the domain name, point to New, and then click Organizational Unit.

    2. In New Object – Organizational Unit, type MyUNIXTest under Name, and then click OK.

  4. Create OUs to hold UNIX test users , groups , and computers. For example, create OUs named UNIXUsers, UNIXGroups, and UNIXComputers under MyUNIXTest:

    1. Right-click MyUNIXTest, point to New, and then click Organizational Unit.

    2. In New Object – Organizational Unit, type UNIXUsers under Name, and then click OK.

    3. Repeat steps a and b to create OUs for UNIXGroups and UNIXComputers.

  5. Create two test user accounts. For example, create jeff.hay and lori.penor under the UNIXUsers OU:

    1. Right-click UNIXUsers, point to New, and then click User.

    2. In New Object - User, in First name, type Jeff; in Last name, type Hay; in User logon name, type jeff.hay, and then click Next.

    3. Type and confirm a password, clear User must change password at next logon, select Password never expires, and then click Next.

      CAUTION   In a test environment, you might want to choose these options. In a production environment, choose more secure options.

    4. Click Finish.

    5. Repeat steps a–d to create another test user account named Lori Penor, with a logon name of lori.penor.

  6. Create two test group accounts. For example, create FinanceUsers and FinanceAdmins under the UNIXGroups OU:

    1. Right-click UNIXGroups, point to New, and then click Group.

    2. In New Object - Group, in Group name, type FinanceUsers, and then click OK.

    3. Repeat steps a and b to create another test group account called FinanceAdmins.

Later, after DirectControl is installed and configured in your development lab, you will use these user and group accounts to perform a quick validation of the DirectControl solution and to verify authentication and authorization during the testing and stabilization stage.

You can also import user and group accounts from existing directories, such as a local /etc/passwd directory, a UNIX NIS directory, or an LDAP directory. For information about how to import an existing user directory store into Active Directory, see the section “Importing Existing UNIX Accounts into Active Directory” later in this chapter, and see the sections “Importing user and group information” and "Importing information from NIS maps or UNIX files" in the Centrify DirectControl Administrator’s Guide.

Verifying Time Synchronization

Check that all system clocks on the computers that you use in the test environment are synchronized and use the Network Time Protocol (NTP) or other mechanism to stay closely synchronized. This is a Kerberos requirement. All Kerberos tickets are time-stamped, and the Kerberos protocol has a narrow tolerance for discrepancies between system clocks.

By default, the DirectControl join Active Directory (adjoin) command (described later) performs this synchronization between the UNIX host and Active Directory when you join the domain.

For more information, see Appendix H: "Configuring Time Services for a Heterogeneous UNIX and Windows Environment."

Set Up a Second Domain Controller

Deploy a second domain controller using the same steps that you just completed to install the first domain controller. Installing at least two domain controllers is recommended because, if the first domain controller fails, the second one is available to support client computers.

After both domain controllers are installed, with the DNS service running on each one, all Active Directory changes, including DNS data, automatically replicate to the second domain controller. Although you can install a second domain controller at any time, installing it immediately after installing the first domain controller means that replication occurs quickly and avoids replication delays.

Prepare for Training, Testing, and Deployment

During the Developing Phase, described next, Development team members document the solution or solutions they deploy in the test lab. In addition, the User Experience, Test, and Release Management Roles prepare for the upcoming stabilization, deployment, and operations activities.

The following table summarizes the documentation and usability tasks that each team should perform during the Developing Phase.

Table 3.3. Documentation , Training , and Release Management Tasks during the Developing Phase

Role

Tasks

Development

  • Document configuration of the Centrify DirectControl solution.

  • Document prototype deployment scripts that you develop (if any).

  • Document issues that require troubleshooting during development and the resolution for each issue.

User Experience

  • Update training plan developed earlier in the Planning Phase with information learned in response to the practical experience gained in the development lab.

  • Prepare training materials for testers.

  • Prepare training materials for operations personnel.

  • Prepare informational or training materials for end users.

  • Work with developers to ensure usability of the tested solutions for administrators and end users.

Test

  • Perform functional testing for the solution developed in the test lab and provide feedback to developers.

  • Identify and document any issues or "pain points."

  • Design tests for the Stabilizing Phase that test the overall solution and ensure that any potential issues are stabilized. Update the test plan developed earlier in the Planning Phase using the “Test Plan Template” job aid.

  • Test configuration documentation written by the Development team.

  • Test training documentation written by the User Experience team.

Release Management

  • Update pilot and deployment plans developed earlier during the Planning Phase in response to the practical experience gained in the test lab.

  • Prepare checklists:

    • Site prep checklist. To prepare the production environment for deployment (site preparation).

    • Deployment checklist. To ensure a smooth rollout during deployment.

    • Handoff to operations checklist. To ensure a smooth handover to Operations after deployment is completed.

Developing the DirectControl Solution

During the Developing Phase, you will build the solution components. Because Centrify DirectControl is a commercially packaged product, "developing the solution" refers to building the installation in your test environment as a preliminary step to piloting and then deploying the DirectControl solution in your production environment. This section describes the tasks that you must perform in order to use the Centrify DirectControl suite to implement End State 2.

Although authentication and authorization services are treated separately in many parts of this guide, the DirectControl solution delivers a user experience for UNIX users that works much like the user experience on Windows clients. After you install DirectControl, when a user attempts to log on to a UNIX-based computer, the user enters a user name and password that is then validated by Active Directory through the underlying Kerberos authentication system. After the user is authenticated, Active Directory determines how the user can use the UNIX-based computer based on authorization properties associated with that user's account, the computer the user is logging on to, and the groups to which the user belongs. For example, a setting might be configured in Active Directory to prevent access to the computer at the time of day when the user attempts to log on. Even though the user is authenticated, the logon session fails because the user is not authorized to use the computer at that time.

In addition, other properties associated with the user account are now stored in Active Directory and can be used to establish the user’s session on the UNIX-based computer or can be used by applications on the UNIX-based computer. For example, the user’s UNIX home directory is stored as an attribute in Active Directory. After the user is successfully authenticated and authorized, this attribute is used to establish the user’s home directory, which is then used during the logon session on the UNIX-based computer.

DirectControl includes capabilities well beyond the scope of the End State 2 solution described in this chapter. For example, DirectControl includes a component for using Windows Group Policy to manage computer and user policies on UNIX-based and Linux-based computers. DirectControl also provides capabilities for seamless file sharing, a NIS pass-through server, and authentication modules for Web and application platforms. For more information related to capabilities in DirectControl that go beyond End State 2, see “Evolving the DirectControl Solution” later in this chapter, and see the Centrify company Web site at http://www.centrify.com.

Introduction and Goals

The information provided in this section, based on the activities of the MSF Process Model Developing Phase, focuses on using DirectControl to achieve End State 2.

Major Tasks and Deliverables

The major tasks in the Developing Phase for the Centrify DirectControl End State 2 solution are:

  • Develop the solution components.

  • Perform quick validation tests.

Develop the Solution Components

This section describes how to install and configure your development environment for the DirectControl End State 2 solution. The following subsections provide an overview of how to install and configure DirectControl:

  • Choosing DirectControl Zones or Active Directory Schema Extensions. Decide whether to use DirectControl zones, Active Directory schema extensions for Windows Services for UNIX, or both, for storing UNIX user data.

  • Installing Centrify DirectControl on Windows. Decide whether to use a trial or commercial license, and then run the setup program to install DirectControl components on a Windows Server 2003-based computer.

  • Configuring Active Directory with the First DirectControl Zone. Use the Centrify DirectControl Setup Wizard to update Active Directory and to configure the default zone.

  • Enabling Active Directory Groups and Users for UNIX. Use the Centrify DirectControl Setup Wizard to update Active Directory and to configure the default zone.

  • Installing the Centrify DirectControl Agent on UNIX or Linux. Run the DirectControl installation script and select the tasks to perform for the specific UNIX-based or Linux-based computer on which you want to install DirectControl.

  • Joining the Active Directory Domain. Run the adjoin command to add a selected UNIX-based or Linux-based computer to the Active Directory domain.

  • Restarting Running Services. Restart specific services on UNIX-based computers, or reboot to restart all services.

  • Optionally Mapping Local UNIX Accounts to Active Directory. Mapping local accounts for UNIX users to Active Directory accounts and how to perform such mapping.

In addition to the instructions described in the following subsections, you can also find information about installing and configuring DirectControl in the documentation that accompanies the product, including the Centrify DirectControl Administrator’s Guide.

Choosing DirectControl Zones or Active Directory Schema Extensions

As mentioned earlier, DirectControl supports both the use of DirectControl zones and the use of Windows Services for UNIX schema extensions for storing UNIX user attributes in Active Directory. DirectControl also supports the RFC 2307 schema extensions for UNIX that are included with Windows Server 2003 R2 by default.

Before installing DirectControl, you should evaluate whether to use Microsoft-supported UNIX schema extensions, DirectControl zones, or both mechanisms for storing UNIX user data.

For example:

  • Microsoft-supported UNIX schema extensions. If Windows Services for UNIX or Windows Server 2003 R2 is already in use in your organization and UNIX user information is already stored in Active Directory through the use of the Microsoft-supported UNIX schema extensions, it might be appropriate to use the existing UNIX Active Directory extensions and the existing user account information for your DirectControl solution.

  • DirectControl zones. If your organization has no plans to use Windows Services for UNIX or Windows Server 2003 R2, the most appropriate choice might be to use DirectControl zones.

  • Both. If you currently use Windows Services for UNIX or Windows Server 2003 R2 but also need to migrate other UNIX directory stores to Active Directory, the best approach might be to implement a solution that uses both Microsoft-supported UNIX schema extensions and DirectControl zones.

This document uses DirectControl zones to implements the solution. For more information about using the Microsoft-supported UNIX schema extensions with the DirectControl product, see the Centrify DirectControl Administrator’s Guide.

CAUTION   Extending the Active Directory schema is not reversible and therefore requires care. To reduce the chance that problems might arise during the schema extension process, the recommended practice is to select extension mechanisms that Microsoft supports. Before you extend the schema, see "Extending the schema" in the Windows Server 2003 Help and Support Center.

Installing Centrify DirectControl on Windows

This section covers choosing a trial or commercial license for Centrify DirectControl and describes how to install Centrify DirectControl Management Tools on a computer running Windows.

Managing DirectControl Licenses

Centrify DirectControl is commercially licensed software. A valid license key is required for extended use of the software. If you want to evaluate the software, you can opt to choose a 30-day trial license at the time that you install the software on a Windows-based computer. If, after the evaluation, you choose to purchase a license key, you can easily upgrade the product to a full commercial license through the Centrify DirectControl Administrator Console that you install in “Configuring Active Directory with the First DirectControl Zone” later in this section.

You can find information about licensing, prices, and evaluation copies of DirectControl through the Centrify company Web site at http://www.centrify.com or by calling the Centrify sales line at 1-650-961-1100.

Installing the Centrify DirectControl Components on Windows

Before you can add UNIX-based computers to Active Directory, you must use the setup program to install the Centrify DirectControl software on a Windows-based computer in the Active Directory forest. The setup program copies the necessary DirectControl files to the local Windows-based computer. You do not need any special permissions to run the setup program other than permission to install files on the local computer.

To install the Centrify DirectControl Management Tools on Windows

  1. Start installation. Insert the DirectControl CD into the CD drive of the Windows-based computer on which you plan to install the DirectControl software:

    • If autorun is enabled, you will see a DirectControl installation screen. Select Install Windows Console to start the installation, and then click Next at the Welcome page.

    • If the Centrify installation program does not start automatically, locate the Windows folder on the Centrify DirectControl CD or in the folders extracted from a Centrify DirectControl zip file, and then double-click Setup.exe to start the setup program.

  2. Accept license. Review the terms of the license agreement. If you accept the license agreement, select I agree to these terms, and then click Next.

  3. Configure options. Type your name and company name, select who can use this application on the computer, and then click Next.

  4. Choose components. Select the components that you want to install, and then click Next.

    Note   Typically, the first time you run the setup program, you accept the default option to install all components. However, you can choose a custom installation if you prefer to do so.

    • Click Next to install components in the default location

      – or –

    • Click Browse to choose a different location, and then click Next.

  5. Verify settings. Verify your installation settings, click Next, and then click Finish to complete the installation.

When you run the setup program the first time with the default components selected, the setup program installs the Centrify DirectControl Management Tools, which include:

  • The Centrify DirectControl property extensions for Active Directory Users and Computers.

  • The Centrify DirectControl Administrator Console and extensions for managing NIS maps in Active Directory.

  • The Centrify DirectControl Administrative Templates for configuring UNIX Group Policy settings.

  • The Centrify DirectControl Administrator Console Help and other documentation.

  • The Centrify DirectControl application program interface (API) packaged in a dynamic-link library (DLL). The Centrify DirectControl API provides the Component Object Model (COM) objects that convert Active Directory application objects into Centrify-enabled UNIX user, group, computer, and zone objects.

Configuring Active Directory with the First DirectControl Zone

When you start the Centrify DirectControl Administrator Console for the first time on the Windows-based computer on which you installed the DirectControl Management Tools, a Setup Wizard appears. The wizard helps you configure the default properties for your first Centrify DirectControl zone.

In addition, the Setup Wizard makes it easier for you to control where Centrify DirectControl container objects are placed and who has permission to modify the objects within those containers. Because the Centrify DirectControl Zone Setup Wizard creates container objects, however, you might need to log on with an account that has Enterprise Administrator privileges. This requirement depends on the specific permissions your organization has configured for different classes of users. For example, if your organization permits accounts with membership in the Domain Admins group or other types of accounts in order to create parent objects in Active Directory, membership in the Enterprise Admins group is not required.

You must complete all configuration steps, including those that set up the default zone, before you begin adding computers to the domain. For more information about any configuration step, see the Centrify DirectControl Administrator’s Guide.

To start the Setup Wizard and update the Active Directory forest

  1. Start Setup Wizard: On a Windows-based computer on which you installed the DirectControl Management Tools, open the Centrify DirectControl Administrator Console:

    • By double-clicking the Centrify DirectControl icon.

      – or –

    • By clicking Start, and then selecting Centrify DirectControl.

    At the Welcome page, click Next.

  2. Select credentials:

    • Select Use currently connected user credentials to use your current logon account

      – or –

    • Select Specify another user’s credentials to type a different user name and password.

    Click Next.

  3. Select license key options:

    1. Click Next to accept the default container location for license keys.

    2. Select Install the 30 day evaluation license keys, and then click Next.

  4. Select zone options:

    1. Select Create default zone container, and then click Next.

    2. Click Next to accept the default container location for zones.

    3. Select Create default Zone, and then click Next to configure the default zone.

    4. Click Next to accept the default location for the default zone.

  5. Accept UID , GID , and path:

    1. Click Next to accept the default numeric user identifier (UID) for new UNIX users in the default zone. This UID will be the first in the range of UID numbers used for users in the default zone.

    2. Click Next to accept the default numeric group identifier (GID) for new UNIX groups in the default zone. This GID will be the first in the range of GID numbers used for groups in the default zone.

    3. Click Next to accept the default home directory path for creating new UNIX home directories in the default zone.

  6. Select UNIX shell:

    • Select the type of UNIX shell to use by default for users in the default zone (for example, select /bin/sh or /bin/bash), click Set as default, and then click Next.

  7. Select Private group properties:

    1. Select Private group as the default primary group for users in the default zone, and then click Next. 

      Note   This option allows each UNIX user to have a private Active Directory group as the primary group. If you select this option, private Active Directory groups are created automatically when you add UNIX users.

    2. Select Create private group container, and then click Next.

    3. Click Next to accept the default container location for private groups.

  8. Add Centrify Profile properties to Active Directory:

    1. Select Set up property pages to allow the Centrify Profile properties to be displayed in Active Directory Users and Computers, and then click Next.

    2. Confirm your configuration settings, and then click Finish.

After you run the DirectControl Setup Wizard and configure Active Directory, DirectControl makes minor modifications to your Windows Active Directory environment. The following subsections describe some of these changes.

Zones UNIX Attribute Storage in Active Directory

After you run the DirectControl Setup Wizard, Centrify DirectControl information is stored in Active Directory and is visible in the Program Data node in the Active Directory Users and Computers console tree. This structured area, which is the standard area used to store application-related information, includes centralized Centrify license information and structures for each zone that is created.

Each zone area contains information about the UNIX-based computers that are members of the zone as well as information about users and groups that have access to the zone. Optionally, you can also store data under each zone structure that describes the NIS maps that apply to the zone.

Typically, you do not view or modify any of the zone information in the Program Data node in Active Directory Users and Computers directly. Instead, use the Centrify DirectControl Administrator Console or Active Directory Users and Computers user, group, or computer property pages to make additions or changes to DirectControl data.

Centrify DirectControl Administrator Console

The Centrify DirectControl Administrator Console is the main tool for managing all aspects of the DirectControl product. This tool uses the same interface that is used by Microsoft MMC tools and therefore can run side-by-side with Microsoft tools that you use to manage the Active Directory environment, such as Active Directory Users and Computers.

The following screenshot shows the top-level task screen for the DirectControl Administrator Console.

Figure 3.3. The Centrify DirectControl Administrator Console

Figure 3.3. The Centrify DirectControl Administrator Console

You can install the Centrify DirectControl Administrator Console on any Windows-based computer that is joined to the Active Directory forest. The console includes a comprehensive online help system that is installed with the console. Multiple consoles can be installed on computers across the forest. Because the information used by the console is stored centrally in Active Directory, a consistent view of the data is provided across multiple running instances of the console.

Modifications to Active Directory Users and Computers

If the Active Directory Users and Computers snap-in is installed on the Windows-based computer at the time that you run the DirectControl Setup Wizard, installing the DirectControl Windows components on a Windows-based computer modifies Active Directory Users and Computers. You can see the Centrify node and its subnodes added to the Active Directory Users and Computers snap-in under Program Data.

Another important change occurs on the properties page for a user or a group. A new tab called Centrify Profile is added to each user or group properties page so that you can view or modify UNIX attributes associated with the user or group along with other Active Directory properties. You can see an example of the Centrify Profile tab in Figure 3.5, “Centrify Profile properties tab for Jeff Hay's UNIX-enabled user account” in the section "Enabling Active Directory Groups and Users for UNIX" later in this chapter.

You can also use the Centrify DirectControl Administrator Console to modify these properties.

Enabling Active Directory Groups and Users for UNIX

When you use DirectControl to join a UNIX-based or Linux-based computer to an Active Directory domain, the same type of digital identity is used for the new UNIX or Linux account as is used for a Windows account. When you join a computer to the domain, a computer account is set up for the UNIX-based computer in Active Directory. You can view or edit this computer account in either Active Directory Users and Computers or in the DirectControl Administrator Console.

Although you typically create Active Directory user or group accounts by using Active Directory Users and Computers, you can also import users or groups from UNIX configuration files or from NIS domains (see "Importing Existing UNIX Accounts into Active Directory" later in this chapter, and see the sections "Importing user and group information" and "Importing information from NIS maps or UNIX files" in the Centrify DirectControl Administrator's Guide). After a user account is stored in Active Directory, you can enable or disable access to UNIX-based computers as needed.

Giving UNIX Access to Groups

Before giving UNIX access to users (covered in the next section), you must first create at least one UNIX-enabled Active Directory group account that you can use for the primary group identifier (GID) for all UNIX-enabled users (or for a subset of UNIX-enabled users). Depending on your site configuration, you might want to provide different default groups for different users when you deploy the DirectControl solution in your production environment.

You can use either of the following two methods to give an existing Active Directory group access to UNIX:

  • You can use Active Directory Users and Computers to open the Properties page for a group, and then click the Centrify Profile tab to specify UNIX properties for the group.

  • You can use the Centrify DirectControl Administrator Console to add an existing Active Directory group to any Centrify DirectControl zone.

The following procedure shows you how to use the second method.

To add Active Directory groups to a Centrify DirectControl zone

  1. Log on. On the Windows-based computer, open the Centrify DirectControl Administrator Console.

  2. Select a zone. In the console tree, click Zones, and then open the zone name to which you want to add the Active Directory group.

    For example, open the default zone.

  3. Add a group to the zone:

    1. Right-click Groups, and then click Add Group to Zone.

    2. Type a search string to locate the group, and then click Find Now.

      For example, type fin to display the groups FinanceUsers and FinanceAdmins, which you created earlier and which are used as example groups throughout this chapter.

    3. Select both groups in the results, and then click OK.

  4. Review settings:

    1. Review the UNIX profile settings in the Set Unix Group Profile dialog box for the FinanceAdmins group.

      Note   By default, DirectControl uses a UNIX group name that is compatible with any UNIX system by truncating the name to no more than 8 characters, converting the name to lowercase, and removing spaces and other incompatible characters.

      You can override this default behavior by typing a different UNIX group name. However, before you change the default behavior, check the documentation for the UNIX or Linux systems that you plan to join to the domain to ensure that you do not use an incompatible format for the group name.

      For this exercise, use FinanceAdmins as the group name. Make any changes, if necessary, to the GID, and then click OK.

    2. Review the UNIX profile settings for the FinanceUsers group.

      For this exercise, use FinanceUsers as the group name. Make any changes, if necessary, to the GID, and then click OK.

  5. View or change UNIX properties. After you add a group to the zone, you can view or change the UNIX properties by opening the group’s property page in Active Directory Users and Computers or in the DirectControl Administrator Console and selecting the Centrify Profile tab.

    The following screenshot shows an example of the Centrify Profile properties tab for a UNIX-enabled group.

    Figure 3.4. Centrify Profile properties for a UNIX-enabled group

    Figure 3.4. Centrify Profile properties for a UNIX-enabled group
Giving UNIX Access to Users

You can use either of the following two methods to give an existing Active Directory user access to UNIX:

  • You can use Active Directory Users and Computers to open the Properties page for a user, and then click the Centrify Profile tab to specify UNIX properties for the user.

  • You can use the Centrify DirectControl Administrator Console to add an existing Active Directory user to any Centrify DirectControl zone.

The following procedure shows you how to use the second method.

To add users to a Centrify DirectControl zone

  1. Log on. On the Windows-based computer, open the Centrify DirectControl Administrator Console.

  2. Select a zone. In the console tree, click Zones, and then open the zone name to which you want to add the Active Directory user. For example, open the default zone.

    1. Right-click Users, and then click Add User to Zone.

    2. Click Find Now.

    3. Select both Jeff Hay and Lori Penor in the results, and then click OK.

  3. Review settings:

    1. Review the UNIX profile settings for Jeff Hay. For this exercise, specify jeff.hay for the UNIX login name; set his default primary group to the Normal group called FinanceAdmins; make any other needed changes; and then click OK.

      Note   By default, DirectControl uses a UNIX logon name that is compatible with any UNIX system by truncating the name to no more than 8 characters, converting the name to lowercase, and removing spaces and other incompatible characters. You can override this default behavior by typing in another UNIX logon name. However, before you change the default behavior, check the documentation for the UNIX or Linux systems that you plan to join to the domain to ensure that you do not use an incompatible format for the logon name.

    2. Review the UNIX profile settings for Lori Penor. For this exercise, specify lori.penor for the UNIX login name; set her default primary group to the Normal group called FinanceUsers, make any other needed changes, and then click OK.

  4. View or change properties. After you add users to the zone, you can view or change their UNIX properties by opening the user’s property page in Active Directory Users and Computers or the DirectControl Administrator Console and selecting the Centrify Profile tab.

    The following screenshot shows an example of the Centrify Profile properties tab for Jeff Hay's UNIX-enabled user account.

    Figure 3.5. Centrify Profile properties tab for Jeff Hay's UNIX-enabled user account

    Figure 3.5. Centrify Profile properties tab for Jeff Hay's UNIX-enabled user account
Installing the Centrify DirectControl Agent on UNIX or Linux

The components for the Centrify DirectControl Agent that you need to install on each UNIX-based computer that you want to join to an Active Directory domain are bundled together in a platform-specific software package. The information included in this chapter focuses on implementing DirectControl with Red Hat Linux version 9 and Sun Solaris UNIX version 9. The procedures in this chapter were developed on a computer running Red Hat Linux 9.

Centrify supports over 50 platforms, including popular UNIX and Linux versions of Red Hat, Fedora, SuSE, Debian, Sun Solaris, HP-UX, IBM AIX, Macintosh OS X and VMware ESX. In addition, Centrify continually adds support for new operating system platforms. For the latest information about supported platforms, including UNIX, Linux, and Macintosh, see the Centrify DirectControl's Supported Platforms Web page at http://www.centrify.com/directcontrol/platforms.asp.

You can use either of the following two methods to install the components of the Centrify DirectControl Agent on any of the software platforms listed in the preceding paragraph:

  • Script method to install DirectControl Agent. Use the Centrify DirectControl installation script to automatically invoke the proper installation mechanism for a computer’s local operating system by specifying the appropriate command-line options.

  • Manual method to install DirectControl Agent. Manually install any package by running the appropriate installation command yourself.

If you want to install the package yourself, see the Centrify DirectControl Administrator’s Guide for the installation command to use for the specific version of Linux or UNIX running on the computer on which you want to install the package. The following steps assume that you choose the first method and use the Centrify DirectControl installation script to install the Centrify DirectControl Agent.

To install the Centrify DirectControl Agent on a Linux or UNIX-based computer

  1. Log on. On the Linux-based or UNIX-based computer, log on as or switch to the root user.

  2. Install or download DirectControl Agent. Depending on whether you choose to install the DirectControl Agent from a CD or download it, perform the appropriate step as shown in the following table.

    Table 3.4. Choose the Appropriate Option

    Install Agent from CD

    Download Agent from FTP or Web

    To mount the CD-ROM device, use the appropriate method for the local computer’s operating environment:

    • On Red Hat Linux, type:

      mount /mnt/cdrom
    • On Solaris, use the graphical desktop to mount the CD-ROM.

    Download the DirectControl Agent by using FTP or from the Centrify company Web site at http://www.centrify.com. You can find instructions on this Web site for accessing the download files.

  3. Change to a directory that contains install.sh. Change to the UNIX directory on the CD or to the directory where you downloaded the Agent package. For example, type:

    cd UNIX
  4. Start installation. Run the install.sh script to start the installation of DirectControl on the local UNIX-based computer. For example, type:

    ./install.sh

    Follow the prompts and provide the requested information, such as the user name and password to use to join the domain.

  5. Reboot. Restart the UNIX-based computer after the DirectControl software is installed. This is the recommended practice because some services must be restarted before they can use DirectControl logon services. A reboot automatically restarts all services and allows for proper operation with the DirectControl agent.

    If you prefer not to restart the UNIX-based computer, you can manually restart services, such as the secure shell (SSH) daemon, by typing:

    sh /etc/init.d/sshd restart

    You must also restart any other services that use the PAM system for authenticating logons or sessions.

Directory and File Changes Made to UNIX by DirectControl

When you complete the installation of the DirectControl Agent on the UNIX client, the local computer is updated with the directories and files for DirectControl listed in the following table.

Table 3.5. Directory and File Changes After Installing the DirectControl Agent

Directory

Contains

/etc/centrifydc

Centrify DirectControl Agent configuration files.

/etc/init.d

Centrify DirectControl Agent startup and shutdown script files.

/lib

NSS and PAM libraries.

/usr/share/centrifydc

Java, Kerberos, and service library files used by the Centrify DirectControl Agent and other modules to enable the following:

  • Centrify DirectControl for Apache

  • Centrify DirectControl for Tomcat

  • Centrify DirectControl for JBoss

  • Centrify DirectControl for WebLogic

  • Centrify DirectControl for WebSphere

  • Kerberos-related operations and other DirectControl operations

    Diagnostic and service startup files.

Mapper and script files for Group Policy.

/usr/share/man

Man pages (UNIX online manual or help pages) for various Centrify DirectControl commands.

/usr/sbin and /usr/bin

Command-line programs to perform Active Directory tasks, such as joining the domain or changing a user password.

/var/centrifydc

No files until you join the domain.

After you join the domain, several files are created in this directory to record information about the Active Directory domain to which the computer is joined, the Active Directory site the computer is part of, and other details.

Additional Changes Made to UNIX by DirectControl

The following subsections describe additional changes made to UNIX by DirectControl when you install the DirectControl Agent on a UNIX-based computer.

NSS

When you join a UNIX-based computer to an Active Directory domain with the DirectControl adjoin command, the NSS configuration file, /etc/nsswitch.conf, is automatically updated to use the Centrify DirectControl NSS module first.

Using the Centrify DirectControl adclient daemon and the service library, the Centrify DirectControl NSS module uses LDAP calls to access network information that is stored in Active Directory. The adclient daemon then caches responses locally to ensure faster performance, reduce network traffic, and allow for disconnected operation. The cache contents are encrypted to ensure the security of the responses.

PAM

When you join a UNIX-based computer to an Active Directory domain, the Centrify DirectControl PAM component is automatically placed first in the PAM stack so that Active Directory authentication takes precedence over other authentication methods. On Red Hat Linux systems, the file /etc/pam.d/system-auth is modified. On Solaris systems, the file /etc/pam.conf is modified.

In addition, PAM is configured with a number of default policy settings. You can customize these policies locally or through a combination of local and Active Directory settings.

Kerberos

When you install the DirectControl Agent on a UNIX-based computer, a full implementation of MIT Kerberos is also installed. Massachusetts Institute of Technology (MIT) is the original creator of Kerberos (see "Kerberos: The Network Authentication Protocol" at http://web.mit.edu/kerberos/www/). The MIT Kerberos implementations for UNIX and Linux systems are available as open source software and are widely used on both open source Linux platforms and commercial UNIX platforms. By including a fully functional Kerberos environment, DirectControl frees your organization from the task of finding a Kerberos environment that works correctly with Active Directory.

When you join a UNIX-based computer to an Active Directory domain, DirectControl automatically configures the UNIX-based computer with all of the correct settings needed to allow existing Kerberized applications to work with Active Directory. You do not have to configure this manually. This works only for existing Kerberized applications whose encryption types are supported by Active Directory.

The adclient daemon automatically creates and maintains the Kerberos configuration file, krb5.conf, and the krb5.keytab service ticket file. The configuration file is initially created with information collected by searching DNS and Active Directory, with the default domain set to the domain that the computer has joined. Whenever a logon or ticket validation is performed with a domain that is not in the configuration file, the configuration file is updated so that it includes the new domain. The default location of the krb5.conf and krb5.keytab files varies. DirectControl uses /etc/krb5.conf and /etc/krb5.keytab, which are the standard locations used by MIT Kerberos.

Although the adclient daemon can automatically update the file as needed, it does not destroy existing configuration entries that you might have added manually. Because of this, DirectControl works seamlessly with your existing Kerberos-enabled applications.

The following figure illustrates the NSS, PAM, and Kerberos services that are configured and enabled as part of the DirectControl configuration.

Figure 3.6. NSS

Figure 3.6. NSS , PAM , and Kerberos services enabled by DirectControl

DirectControl Daemons

The DirectControl software on the UNIX-based computer installs two daemons that start at system startup. The first is adclient, which is the most important element in the Centrify DirectControl Agent architecture. The second, adnisd, is an optional daemon to handle servicing NIS requests. They are described in further detail following:

  • adclient (required). The DirectControl adclient daemon manages all LDAP and Kerberos communications between Active Directory and the UNIX-based computer on which the daemon is installed. The adclient daemon also performs several key tasks related to synchronizing the local computer’s time with the clock maintained by Active Directory. Synchronization ensures that the time stamp on Kerberos tickets issued by the KDC are within a valid range The adclient daemon uses NTP to synchronize the clocks (alternatively, if you prefer, this default behavior can be disabled). If the clocks are already synchronized, adclient does not resynchronize them.

  • adnisd (optional). The DirectControl adnisd daemon intercepts requests to a NIS server for directory information and redirects these requests to Active Directory. Setting up and enabling the DirectControl NIS server is outside the scope of this chapter. For more information about configuring a UNIX-based computer with the DirectControl NIS server, see the Centrify DirectControl Administrator’s Guide.

Joining the Active Directory Domain

After you install Centrify DirectControl on a Windows-based computer and install the DirectControl Agent on one or more UNIX-based computers, you can join the UNIX-based computer to any Active Directory domain in the forest. You can also use existing Active Directory groups and user accounts to log on to UNIX-based computers and run directory-enabled or Kerberos-enabled UNIX programs.

Understanding the adjoin Command

You must run the adjoin command on each UNIX-based or Linux-based computer included in the deployment to join the UNIX-based computers to Active Directory. Use the following parameters.

adjoin [options] domain                                        

In addition to specifying the Active Directory domain name, you can specify one or more options. The key options for the adjoin command are described in the following table:

Table 3.6. Key Options for the adjoin Command

Option

Description

--user user[@domain]

Active Directory user

You must use a user account that has ”Add workstations to domain” privileges.

--password password

User’s Active Directory password

If you do not type the password when you specify the adjoin command, adjoin prompts you to provide the password.

--zone zone

DirectControl zone to which you want to join the UNIX-based computer.

If this option is not included, the computer is joined to the default zone.

For example, the user Jeff Hay has the right to join computers to the Active Directory domain, the password he uses is not24get, the zone to which he wants to join the computer is called HR, and the Active Directory domain to which he wants to join the UNIX-based computer is called contoso.com.

Jeff Hay types the following command to join the UNIX-based computer to Active Directory:         

adjoin --user jeff.hay --password not24get --zone HR contoso.com

Alternatively, if he wants to enter the password interactively, he can use the following command:

adjoin --user jeff.hay --zone HR contoso.com
Using adjoin to Join a UNIX-based or Linux-based Computer to Active Directory

The DirectControl install program, install.sh, will join the UNIX-based computer to the Active Directory domain by default. Alternatively, you can choose to join the domain at a later time. You can use the following procedure to join a UNIX-based or Linux-based computer to Active Directory if it is not already joined.

To join an Active Directory domain with Centrify DirectControl

  1. Log on. On a UNIX-based computer, log on as or switch to the root user.

  2. Join UNIX-based computer to Active Directory domain. Run the adjoin command to join the UNIX-based computer to an existing Active Directory domain. Use a fully-qualified domain name.

    For example, type the following command to join the sales.contoso.com domain and to place this computer in the default zone:

    adjoin sales.contoso.com

    If you do not use the --user option to specify a user, the adjoin command uses the domain Administrator account by default. If you specify a user account, that account must have the user right to add computers to the specified domain. In some organizations, this account must be a member of the Domain Admins group. In other organizations, the account might be any valid domain user account.

  3. Provide password. Type the password for the Administrator user account.

    If DirectControl successfully connects to Active Directory and joins the UNIX-based computer to the Active Directory domain, a confirmation message appears. A new Active Directory computer account is automatically created and the UNIX-based computer is configured to allow authorized users to log on.

In addition to creating a new Active Directory computer account and configuring the UNIX-based computer to allow authorized users to log on, the join operation also performs the following tasks:

  • Synchronizes the local computer’s time with Active Directory to ensure that the time stamp of Kerberos tickets is within the acceptable time period to allow for authentication.

  • Updates the Kerberos principal service names used by the host computer, generating new Kerberos configuration files, krb5.keytab files, and new service keys for the host and for the HTTP service.

  • Sets the password on the Active Directory computer account for the UNIX-based computer to a randomly generated password. The password is encrypted and stored locally to ensure that only DirectControl controls the account.

  • Starts the Centrify DirectControl daemon (adclient).

For more information about the options you can specify when joining a UNIX-based computer to an Active Directory domain, see the section “Joining UNIX-based Computers to Active Directory” later in this chapter and see the Centrify man page for the adjoin command or the Centrify DirectControl Administrator’s Guide.

Restarting Running Services

You might need to restart certain services on UNIX-based computers on which you install the Centrify DirectControl Agent to ensure that those services reread the system configuration files (such as the name service switch configuration file) that DirectControl updates. In general, any service that uses PAM to authenticate a user must be restarted.

The most common services that must be restarted are sshd (the secure shell [SSH] logon daemon) and gdm (the GNOME Display Manager [GDM] graphical logon program). If you use these services, you need to restart them.

For example, the following procedure shows you how restart sshd.

To restart sshd:

  • At a command prompt on the UNIX-based computer, type the following command:

    /etc/init.d/sshd restart

    – or –

    Reboot the computer to restart all services.

Because the applications and services running on different servers might vary, a good practice is to reboot each computer to ensure that all applications and services on the computer read the DirectControl configuration changes.

Optionally Mapping Local UNIX Accounts to Active Directory

The following subsections explain why you might want to map local accounts for UNIX users to Active Directory accounts and how to perform such mapping.

Mapping Privileged UNIX Accounts to Active Directory Accounts

By default, local UNIX user accounts are still valid on the UNIX-based computers that join the Active Directory domain. You can enable or disable access selectively for individual local users and groups, as needed, by modifying Centrify DirectControl Group Policy settings or the Centrify DirectControl configuration file on any computer. For some local UNIX accounts, however, you might want to control access by mapping a local user account to an Active Directory account.

Because mapping a local UNIX user account to an Active Directory account gives you better control over password policies, this technique is especially useful for controlling access to accounts that have special privileges. For example, the local superuser or root user account on each UNIX-based computer has broad authority. By mapping this account to an Active Directory account and password, you can:

  • Control access to the root user account because users cannot log on unless they know the Active Directory password for the account.

  • Ensure that Active Directory password policies are applied to the root user account password so that each root user password is complex enough and changed frequently enough to conform with established security policies.

How to map the root user account to Active Directory is described in the next subsection. Although mapping is especially useful for the root user account (you can use the local root account by logging on using root@localhost), you can also map any local UNIX user account to an Active Directory account. For example, many applications have their own special user account with permission to perform restricted operations. If you want to enforce Active Directory password policies for such an account or for any other local user account, you can do so by mapping the local UNIX account to an Active Directory account.

Mapping the Root Account to an Active Directory Account for Increased Security

The most likely candidate for account mapping is the root user because every UNIX-based computer has its own root user account. Typically, you do not want to create a single user in Active Directory for the root user account because doing so compromises the security of your network by giving anyone with the root password root-level access to every UNIX-based computer in the Active Directory forest.

To prevent this problem, DirectControl allows you to map the UNIX root user account to another user name in Active Directory for password validation. You can specify a separate Active Directory user account for each UNIX-based computer so that each root user has a unique name and password. Alternatively, you can use one Active Directory user account for all root users for a group of UNIX-based computers so that there are fewer accounts and passwords to manage.

If root account mapping is enabled, the UNIX root user is mapped to the Active Directory account called root_zonename by default. However, you can change the Active Directory account that is used for mapping the root account by using Group Policy or by modifying the computer’s Centrify DirectControl configuration file, /etc/centrifydc/centrifydc.conf. The account that root is mapped to must exist as an Active Directory user account.

Note   In most cases, each UNIX-based computer should have at least one account that can be authenticated locally to ensure that you can access the computer when Active Directory is not available or when the Centrify DirectControl daemon is not running. By default, the local override account is set to the local root user so that even if you map the root account to an Active Directory account, you can always log on locally using root@localhost and the local root account password. You can change the local override account or add additional local users by using Group Policy or by modifying the computer’s Centrify DirectControl configuration file, /etc/centrifydc/centrifydc.conf.

For example, if you have a group of computers in a DirectControl zone called WebFarm and you want to use one Active Directory password for the root account on all of these computers, you can create an Active Directory user account called root_WebFarm with the password &tiger1 and then map that account to the UNIX root user. When a user logs on to the UNIX-based computer as root, the user is authenticated with the password for the Active Directory account that you created.

If, in this example, the user logs on with a root user account and the password &tiger1, Centrify DirectControl checks the Active Directory password for the account (root_WebFarm) to which the root user is mapped. If the password &tiger1 is valid for the Active Directory account, the user is authenticated and allowed to log on.

To map the UNIX root user account to the default Active Directory root_ zonename user account

  1. Log on. On a Windows-based computer on which you ran the Centrify DirectControl Setup Wizard, open the Centrify DirectControl Administrator Console.

  2. Create an Active Directory account for mapping the UNIX root user. Create the Active Directory user account that you want to map to the local UNIX root user account.

    For example, if you want to use the same Active Directory account for the root account on all computers in the zone WebFarm, create an Active Directory user account called root_WebFarm with the password &tiger1.

  3. Map root to Active Directory account:

    1. On a UNIX-based computer, use a text editor such as vi to open the Centrify DirectControl configuration file /etc/centrifydc/centrifydc.conf.

    2. Modify the local account mapping, if necessary, so that the local root user is mapped to the Active Directory account you created.

      You can use environment variables such as $DOMAIN, $ZONE, or $HOSTNAME if you used the domain, Centrify zone, or host name in the Active Directory account name. For example:

      pam.mapuser.root: root_$ZONE

      By default, this line is already enabled in DirectControl. If you want to disable root account mapping, comment out this line. If you want to use environment variables for mapping or do not want to apply Group Policy settings, you can edit the configuration file as shown in this example. Alternatively, you can use the DirectControl User Map policy for UNIX-based computers to map local UNIX users and groups to Active Directory accounts.

There are numerous options for managing logging on to the root account in the event that the Active Directory domain controller is not available. For more information about mapping local UNIX accounts in Active Directory, see the Centrify DirectControl Administrator’s Guide.

Perform Quick Validation Tests

At this stage in the Developing Phase, it is advisable to run validation tests to ensure that the software is installed correctly and is providing basic services. Later, the section “Stabilizing Your Test Deployment” provides more comprehensive information about how to test the DirectControl solution.

Quick validation tests include:

  • Confirming configuration of users and groups.

  • Confirming UNIX-based computer membership in Active Directory.

  • Logging on to a UNIX-based computer with an Active Directory user account.

Confirming Configuration of Users and Groups

After completing the steps described earlier in the sections “Create Test OUs, Users, and Groups,” “Configuring Active Directory with the First DirectControl Zone,” and “Enabling Active Directory Groups and Users for UNIX,” you have:

  • A default zone with two users (jeff.hay and lori.penor).

  • Two groups (FinanceUsers and FinanceAdmins) enabled as members of the default zone.

For this validation test, you use the following procedure to check that lori.penor and FinanceUsers are configured correctly.

To confirm that lori.penor and FinanceUsers are configured correctly

  1. Log on. On a Windows-based computer on which you ran the Centrify DirectControl Setup Wizard, open Active Directory Users and Computers.

  2. Access Centrify Profile tab. Right-click Lori Penor, click Properties, and then select the Centrify Profile tab to see user properties similar to those in the following screenshot:

    Figure 3.7. Centrify Profile tab for Lori Penor

    Figure 3.7. Centrify Profile tab for Lori Penor
  3. Confirm configuration. Confirm that Lori Penor has been added to the default zone and that the Enable user access to this Zone setting is selected.

Confirming UNIX-based Computer Membership in Active Directory

The next validation test is to confirm that a UNIX-based computer is a member of the Active Directory domain.

After you use the install.sh script to install the DirectControl software for UNIX on a UNIX-based computer as described earlier in the section “Installing the Centrify DirectControl Agent on UNIX or Linux” and after performing the steps described earlier in the sections “Joining the Active Directory Domain” and “Restarting Running Services,” the UNIX-based computer is joined to Active Directory.

You can use the following procedure to confirm the UNIX-based computer’s membership in Active Directory on the UNIX-based computer itself or by using Active Directory Users and Computers.

To confirm Active Directory functionality on a UNIX-based computer

  1. Log on. On a UNIX-based computer, log on.

  2. Request Active Directory information. Type the following DirectControl Active Directory information (adinfo) command:

    adinfo --diag 
  3. Confirm client joined to domain. The host name for this computer in this example is redhat9-1. Confirm that the computer named redhat9-1 is joined to the Active Directory domain by looking for a confirmation line such as the following:

    Joined as: redhat9-1

    The complete output displays information about the Active Directory domain to which the UNIX-based computer is joined, including LDAP settings and Kerberos settings as well as network and DNS parameters.

  4. Check for adclient daemon. Confirm that the adclient daemon is running by executing the ps, or process status, command and looking for the instance of adclient. For example, type:

    ps -aef|grep adclient

    Look for output similar to the following:

    root   1585  1  0 14:50 ?   00:00:29 /usr/sbin/adclient 

    For more information about the ps command, see the UNIX man page for ps.

  5. Check NSS functionality. Confirm that NSS is using Active Directory correctly by running the get entry command, getent. For example, type:

    getent passwd 

    The output lists all Active Directory user accounts for members of the default zone and all local user accounts. This output should have a similar format to the format of the UNIX /etc/passwd file.

    CAUTION   This step assumes that you are running the getent passwd command in a development environment that contains a relatively small number of computers. Running this command on a large domain with thousands or tens of thousands of computers is not recommended.

For more information about:

  • The adinfo command, which displays information about the current DirectControl configuration, see the Centrify man page for adinfo.

  • The getent command, see the UNIX man page for getent.

To confirm a UNIX-based computer’s Active Directory account on a Windows-based computer

  1. Log on. On a Windows-based computer on which you ran the Centrify DirectControl Setup Wizard, open the Centrify DirectControl Administrator Console.

  2. Confirm UNIX-based computer's Active Directory account:

    1. In the Zones tree under the default zone, select Computers.

    2. Confirm that the computer name for the UNIX-based computer that you joined to the domain earlier now appears in the list of computers.

    3. Double-click the computer name, and then select the Centrify Profile tab to see a screen similar to the following:

    Figure 3.8. Confirming the UNIX-based computer now has an Active Directory account

    Figure 3.8. Confirming the UNIX-based computer now has an Active Directory account
Logging On to a UNIX-based Computer with an Active Directory User Account

The final step in validating the solution is to log on to a UNIX-based computer as an Active Directory user.

To use an Active Directory account to log on to a UNIX-based computer

  1. Log on as Lori Penor:

    1. On a UNIX-based computer, bring up a UNIX login prompt or a graphical logon screen.

    2. Log on with the lori.penor account and the Active Directory password that you defined earlier for the lori.penor account.

  2. Confirm configuration. Confirm that the system grants access to the user, creates a home directory, and starts a shell session. The following output shows a typical sequence:

    redhat9-1 login: lori.penor 
    Password: <password> 
    Creating home directory ... 
    [lori.penor@redhat9-1 lori.penor]$

If the logon is not successful, investigate the following:

  • Check that you correctly performed the steps in "Joining the Active Directory Domain" earlier in this section to confirm that the UNIX-based computer is joined to the domain.

  • Confirm that the user account exists in Active Directory and is enabled for the zone in the user’s Centrify Profile.

For additional information about troubleshooting logon issues, see the section “Simplifying Service Desk Operations” later in this chapter or consult the Centrify DirectControl Administrator’s Guide.

Successful completion of the quick validation tests in the preceding subsections confirms that the DirectControl software is installed and configured correctly.

Developing Phase Major Milestone: Scope Complete

This completes the Developing Phase for reaching End State 2 by implementing the Centrify DirectControl solution. Users on configured UNIX-based or Linux-based computers can now use Active Directory to authenticate through Kerberos and can access UNIX authorization and identity information in Active Directory through LDAP.

At this major milestone, you should gain formal approval from the sponsor and key stakeholders that all solution elements are built and that solution features and functionality are complete according to the functional specifications agreed upon during the Planning Phase.

You can now test and stabilize your DirectControl solution and then deploy it in your production environment.

Stabilizing Your Test Deployment

This section describes how to test and stabilize the Centrify DirectControl solution in order to prepare for deploying it in your production environment. Before you start testing, review the test plan created during the Planning Phase using the “Test Plan Template” job aid.

Note   In addition to the tests for DirectControl in this chapter, you might also want to review the tests in this volume that are designed for the custom solutions to obtain some additional ideas that you might be able to adapt for testing your DirectControl solution. You can find these tests in Volume 2: Chapter 5, "Stabilizing a Custom Solution." The tests in Chapter 5, "Stabilizing a Custom Solution" are not designed specifically for the DirectControl solution, and we did not use them to test the DirectControl solution.

Introduction and Goals

The purpose of the Stabilizing Phase is to improve the solution quality to a level that meets your acceptance criteria for release to production. Stabilizing Phase testing emphasizes usage and operation under realistic environmental conditions. In this phase, you prioritize the bugs that testing discovers, fix all high-priority bugs, and prepare the solution for release.

When you decide that a build is sufficiently stable to be a release candidate and after you complete preproduction testing, you deploy the solution to one or more pilot groups in the production environment.

Major Tasks and Deliverables

The major Stabilizing Phase tasks are:

  • Test the DirectControl solution.

  • Resolve issues.

  • Conduct a pilot.

Test the DirectControl Solution

This section describes how the Test team can test the DirectControl development environment to ensure that key capabilities are enabled and functioning correctly.

The primary activities described here include:

  • Preparing the test lab environment

  • Running tests

These tests help confirm that your development lab is working correctly but do not exhaustively stress every feature of the DirectControl solution. For additional information about testing the DirectControl product, including testing for scenarios beyond the scope of this chapter, see the documentation that comes with DirectControl and additional documentation available on the Centrify company Web site at http://www.centrify.com. In particular, see the “Troubleshooting authentication and authorization” section of the Centrify DirectControl Administrator’s Guide, which can help if you encounter problems or issues or if you require a higher level of debugging or diagnostics.

Preparing the Test Lab Environment

The tests described in this section assume that you have a lab set up as described earlier in the "Preparing Your Environment" and "Developing the DirectControl Solution" sections.

These tests also assume that you are familiar with the tests performed during the Developing Phase in the "Performing Quick Validation Tests" section. Any members of the Test and Release Management teams who did not participate in the Developing Phase should review the section "Developing the DirectControl Solution."

Assess Status of Test Lab Used by Developers

Assess the current state of the test lab and, if necessary, rebuild it:

  • Use current lab. If the test lab used in the Developing Phase is in a known stable state appropriate for testing, use the existing lab infrastructure to perform the steps described in this section.

  • Rebuild lab. If the test lab used in the Developing Phase is in an unknown or unstable state, rebuild the lab as described in "Preparing Your Environment" and "Developing the DirectControl Solution."

Expand Test Lab to Model Your Production Environment

During the Developing Phase, developing the DirectControl solution served as an initial proof of concept for the DirectControl implementation of the End State 2 solution that you plan to deploy in your production environment. Now, in the Stabilizing Phase, you must expand the lab to more accurately model your production environment and to address the objectives that you defined during the Planning Phase.

Running Tests

Perform the tests in the following subsections to determine if your development deployment is successful and stable:

  • Test joining a UNIX-based computer to Active Directory

  • Test Active Directory authentication

  • Test workstation authorization policies

  • Test account lockout policies

  • Test password management policies

  • Test offline authentication

  • Test additional administrative tasks

Test Joining a UNIX-based Computer to Active Directory

Use the steps described earlier in the section “Confirming UNIX Computer Membership in Active Directory” under “Performing Quick Validation Tests” to test whether a UNIX-based computer is joined successfully to the Active Directory domain.

A successful test shows that a UNIX-based computer appears as a domain member in both Active Directory Users and Computers and in the Centrify DirectControl Administrator Console on Windows. On the UNIX-based computer itself, you can use the adinfo and getent tools to determine the status of the join.

Test Active Directory Authentication

After a UNIX-based computer is joined to the Active Directory domain, you can test the use of an Active Directory user account to authenticate to the UNIX-based computer.

Note   Immediately after joining a Linux-based computer to the Active Directory domain, in order to use the GDM graphical logon interface to authenticate a user logging on with an Active Directory user account, you must first either restart the gdm daemon or restart the computer. On a computer running Solaris, you must log off any Common Desktop Environment (CDE) desktop sessions and then log on again. The dtlogin daemon automatically restarts when a user logs off.

To verify the authentication of an Active Directory user logging on to a UNIX-based computer

  1. Reboot. Restart the UNIX-based computer.

  2. Provide authentication credentials: 

    1. When prompted for the user name, type the Active Directory user logon name for the test user. For this test, type jeff.hay, and then press ENTER.

      Note   With DirectControl, users can log on with either their Active Directory "user logon name" or their UNIX "login name" as defined in their Centrify profile properties. For example, if the user Jeff Hay has an Active Directory logon name defined as jeff.hay and a Centrify UNIX login name defined as jhay, the user can type either name at the UNIX login prompt to authenticate the user. In both cases, the password required is the user’s Active Directory password. If these logon names are different, it is a good practice to test logging on with each name. To specify a domain for the user, use the syntax: user@domain. For example, jeff.hay@sales.contoso.com. The domain is not required for the default domain to which the computer is joined.

    2. For Password, type the Active Directory password for jeff.hay. When DirectControl connects to Active Directory to authenticate the account information, you are logged on to the UNIX-based computer in the default home directory for the user jeff.hay).

    3. If prompted for a new password, type a new password.

      If, when you created the user account, you checked the box to force a password change at the next logon, a message appears prompting you to provide a new Active Directory password for this account. After you update the password, the logon process continues.

  3. Check UID and GID. At a UNIX shell prompt, check the UNIX UID and GID assignments for the account. For example:

    • Type the following command to display the UID and GID of the currently logged on user:

      id 
    • Type the following command to display the current user’s home directory with the correct ownership and group names:

      ls -al 
    • Type the following command to display all of the groups (in addition to the primary group) that are retrieved for the currently logged on user:

      groups 
  4. Log off. Type exit to log off the current session.

Test Workstation Authorization Policies

With Centrify DirectControl, you can enforce Active Directory account policies for UNIX users and computers. For example, you can use Active Directory to specify which workstations users are allowed to log on to, to restrict the hours during which they are allowed to log on to those computers, or to limit a user's access to a specific computer.

To limit access to the UNIX-based computer for user Jeff Hay

  1. Log on. On a Windows-based computer on which you ran the Centrify DirectControl Setup Wizard, open Active Directory Users and Computers.

  2. Set logon restriction on Jeff Hay's account:

    1. Right-click Jeff Hay, and then click Properties.

    2. Click the Account tab, and then click Log On To.

    3. Click The following computers, type the computer name of the Windows-based computer that you are currently logged on to, click Add, and then click OK.

      This restricts the Jeff Hay account so that it can log on only to this Windows-based computer.

  3. Confirm restriction is active. On a different UNIX-based computer, log on as jeff.hay. The following message appears:

    Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.

    Your account is configured to prevent you from using this computer. Please
    try another computer.
  4. Remove logon restriction from Jeff Hay's account:

    1. On the Windows-based computer, open the Properties page for Jeff Hay in Active Directory Users and Computers.

    2. Click the Account tab, and then click Log On To.

    3. Click All computers, and then click OK.

      This removes the logon restriction so that you can continue to use the Jeff Hay account for the remainder of the test period.

Test Account Lockout Policies

You can use Centrify DirectControl to enforce account lockout policies if you first configure a lockout policy within Active Directory and use a Group Policy object (GPO) to apply the policy.

Configuring a Lockout Policy

If you do not already have an account lockout policy in place, you need to configure one to verify that the policy is correctly applied to the UNIX-based computer.

To configure an account lockout policy for this test

  1. Log on. On a Windows domain controller or server on which you ran the Centrify DirectControl Setup Wizard, open the Group Policy Object Editor.

  2. Access the Default Domain Policy. Use the Group Policy Object Editor to edit the Default Domain Policy object. For example:

    1. Click Start, click Run, type mmc, and then click OK.

    2. In the MMC console, click File, and then click Add/Remove Snap-in.

    3. Click Add, select Group Policy Object Editor, and then click Add.

    4. On the Welcome to the Group Policy Wizard page, click Browse, select Default Domain Policy, and then click OK.

    5. Click Finish, click Close, and then click OK.

  3. Define lockout policy:

    1. In the console tree, click the + symbol to expand Default Domain Policy, expand Computer Configuration, expand Windows Settings, expand Security Settings, expand Account Policies, and then click Account Lockout Policy.

    2. In the details pane, right-click Account lockout duration, and then click Properties.

    3. Select Define this policy setting to enable the setting with the default configuration of 30 minutes. Click OK to accept the settings suggested, and then click OK to accept that enabling Define this policy setting automatically changes the configuration settings for the Account lockout threshold and Reset account lockout counter after policies.

      If you accept the default settings, the account lockout policy is now configured to lock out an account after five invalid logon attempts, to keep the account locked for 30 minutes, and then to restore the lockout counter after 30 minutes.

Testing the Lockout Policy

After a lockout policy is defined, you need to test it on a UNIX-based computer with an Active Directory account to confirm that it works.

To test the account lockout policy on a UNIX-based computer

  1. Attempt to log on. On a UNIX-based computer, attempt to log on with the jeff.hay user name and an incorrect password. Repeat five consecutive times to lock the account.

  2. Remove the lockout on Jeff Hay's account:

    1. On a Windows-based computer on which you ran the Centrify DirectControl Setup Wizard, open Active Directory Users and Computers.

    2. Right-click Jeff Hay, and then click Properties.

    3. Click the Account tab and confirm that the Account is locked out option is selected (that is, confirm that the account is locked out).

    4. Clear the Account is locked out option to remove the lock, and then click OK.

Test Password Management Policies

With Centrify DirectControl, you can enforce Active Directory password policies that you configure for UNIX users and computers. For example, you can use Active Directory settings to require users to change their passwords the next time they log on, to use passwords of a certain length or complexity, or to specify a new password after a certain number of days.

If you configure any or all of these policies by setting them in Active Directory, DirectControl enforces the policies when users log on to UNIX-based computers. For example, the following procedure shows you how to configure a password policy for Jeff Hay.

To require a password change for user Jeff Hay

  1. Log on. On a Windows-based computer on which you ran the Centrify DirectControl Setup Wizard, open Active Directory Users and Computers.

  2. Configure password reset settings:

    1. Right-click Jeff Hay, and then select Reset Password.

    2. Type a new password, and then retype it to confirm it.

    3. Select User must change password at next logon, and then click OK.

  3. Confirm new settings are enabled. On a UNIX-based computer, log on as jeff.hay with the new password, and then respond to the prompts to create a new password.

Test Offline Authentication

Offline authentication is important because it enables users to log on and use computers that are disconnected from the network or that have only periodic access to the Active Directory domain. For example, users who have laptop computers must be able to log on and be successfully authenticated when they are not connected to the network.

To handle these offline situations, DirectControl securely caches user account information locally. After a user successfully logs on to a UNIX-based computer, the computer can use the cached credential information to authenticate the user at a later time if Active Directory is not available. You can configure the time limit after which cached credentials expire. By default, cached credentials expire after 10 days. (For more information, see the entry for adclient.cache.expires in "Customizing Centrify DirectControl configuration options" in the Centrify DirectControl Administrator’s Guide.)

To verify offline authentication

  1. Log on as root. On a UNIX-based computer, log on as the root user.

  2. Verify network connectivity. Type the following command to verify network connectivity from the UNIX-based computer to the domain controller:

    ping DomainControllerName 
  3. Disable network connectivity. Unplug the network cable on the UNIX-based computer to simulate disconnecting from the network.

  4. Verify lack of network connectivity. Type the following command to verify that the local UNIX-based computer is no longer communicating with the network:

    ping DomainControllerName 
  5. Log off root. Log off the root account.

  6. Log on as Jeff Hay. Log on as jeff.hay, and enter the Active Directory password for the account.

    Because you have logged on successfully with the jeff.hay account in earlier procedures in this chapter, you can log on with this account now with the previously cached credentials.

    If you try to log on with an Active Directory account that has not previously logged on successfully, the logon fails because there are no credentials in the cache.

  7. Reestablish connectivity:

    1. Reconnect the network cable on the UNIX-based computer.

    2. Log off as Jeff Hay, and then log on again as root.

Test Additional Administrative Tasks

You might want to try several other typical administrative tasks that are not demonstrated in this chapter. For example, you can test that the following tasks function as expected:

  • Disabling a user’s account in Active Directory Users and Computers to prevent the user from accessing any computer or application managed by DirectControl.

  • Setting the specific hours when a user is allowed to log on or specific hours when a user is denied access to a UNIX-based computer.

  • Changing the password for an Active Directory account on a UNIX-based computer by using the passwd or adpasswd command. (See the man page for adpasswd for more information about using the adpasswd command.)

  • Authenticating users from other trusted Active Directory domains by specifying their full domain user name. For example, if a UNIX-based computer is joined to the domain seattle.contoso.com and jeff.hay belongs to the paris.contoso.com domain, log on to the UNIX-based computer by using jeff.hay@paris.contoso.com.

Resolve Issues

The goal of testing by the Development and Test teams is to discover and track issues that need to be resolved and to learn from the testing experience to facilitate the pilot and production deployments.

Fixing Bugs

The Test and the Development teams work together in the reiterative process of troubleshooting and resolving bugs discovered during testing.

Integrating Experience into Deployment Planning

After performing the tests just described, you should adjust your planned deployment strategies based on what you have learned so far during the Developing and Stabilizing phases.

You should also evaluate the potential impact of your DirectControl deployment on server and network load. Your existing Active Directory infrastructure might need to be updated to handle the additional users.

Conduct a Pilot Deployment

After the Test team tests the Centrify DirectControl solution in a test environment and the Development team resolves any issues found in testing, the next step is for the Release Management team to conduct a pilot deployment by deploying the solution to one or more groups of typical users in your production environment.

Performing a pilot deployment helps you develop your deployment, loading, and operational expertise before you roll out the DirectControl solution to the entire organization. Before you start your pilot deployment, review the pilot plan created during the Planning Phase using the “Pilot Plan Template” job aid.

You can find complete instructions about how to conduct a pilot of the DirectControl solution in the Centrify documentation that comes with the product—those detailed instructions are not repeated here. This section provides a high-level outline of the steps required to successfully perform a pilot deployment.

You can install DirectControl on both UNIX and Windows-based computers at any time without negatively affecting any user action for computers running either operating system:

  • On the UNIX-based computers, the DirectControl components are inactive until you join the computer to the domain by using the adjoin command.

  • On the Windows-based computer, you can set up the default zone and other zones without any impact to the existing Active Directory or Windows environments.

This lets you install the software to be used for the pilot at any time that is convenient.

You can use the following table, which provides a synopsis of pilot tasks, as a checklist when you perform your pilot deployment.

Table 3.7. Checklist of Tasks to Perform a Pilot Deployment

Task

Action

1. Identify success criteria

Review success criteria identified during the Planning Phase in the pilot plan developed using the “Pilot Plan Template” job aid.

If appropriate, update the success criteria.

2. Identify pilot users

Identify a set of users who will participate in the pilot:

Select:

  • A set of users who have both UNIX and Active Directory accounts.

  • A set of users who have only UNIX accounts.

  • For the initial pilot, select knowledgeable users, such as help desk personnel.

After you successfully complete an initial pilot deployment with these users, you will expand the pilot to include a subset of users whose expertise is in an area other than IT. Try to select users whose access patterns allow you to install DirectControl on a controlled number of UNIX-based or Linux-based computers. This will reduce the amount of work required for the expanded pilot and will control the amount of rollback activity required in the event of a failure.

3. Identify pilot computers

Identify which computers you want to include in the pilot, and back up all system and data information.

4. Install DirectControl

Install the DirectControl software on a Windows-based computer in the pilot domain and on all UNIX-based or Linux-based computers included in the pilot:

  • For more information, see “Installing Centrify DirectControl on Windows” earlier in this chapter.

  • For more information, see “Installing the Centrify DirectControl Agent on UNIX or Linux” earlier in this chapter.

5. Choose user account store

Choose an established user account store from an existing UNIX-based computer to conduct the initial pilot.

For example, use:

  • A local /etc/passwd user account database.

  • A NIS identity store.

  • An LDAP-based store.

6. Import existing UNIX user accounts

Use the Import from UNIX tool in the Centrify DirectControl Administrator Console to import the user accounts stored in the /etc/passwd file or NIS or other identity store into Active Directory.

DirectControl places the imported user information in a pending import area until the UNIX account names can be matched with Active Directory account names. That is, at this point, the UNIX user account information is imported into a temporary area so that you can choose the ones you want to import into Active Directory.

For information about importing existing UNIX user accounts into Active Directory, see the section “Importing Existing UNIX Accounts into Active Directory” later in this chapter or refer to "Importing information from NIS maps or UNIX files" in the Centrify DirectControl Administrator’s Guide.

7. Create new user accounts

For users in the pilot group who currently have only a UNIX account, create new Active Directory accounts and UNIX-enable these accounts, as described earlier in the sections “Create Test OUs, Users, and Groups” and “Enabling Active Directory Groups and Users for UNIX.”

You must also set a password for each new user.

8. Prepare pilot users

To prepare the pilot users to switch their UNIX-based computers to begin using Active Directory authentication:

  • Conduct informational and training sessions to ensure that the pilot users know what to expect.

  • Teach pilot users how to use bug-tracking software so that they can report any problems that arise during the pilot deployment.

  • Inform users when the switch to Active Directory authentication will occur.

    Note   At this point, UNIX-based computers included in the pilot cannot yet use Active Directory authentication but continue to use the UNIX-based method of validating users.

  • Inform users what their Active Directory passwords are and that, after the deployment occurs, they must use only these passwords for logging on to their UNIX-based workstations.

  • For users new to Active Directory, provide any needed information or training.

  • Inform users that because the users' account information has been migrated from their existing UNIX directory store to Active Directory, they will log on using their existing UNIX logon name. They must use their Active Directory password because their existing UNIX password will no longer be active after the solution is deployed.

9. Join one UNIX host to domain

At the time scheduled for the switch to Active Directory, log on as root to one UNIX-based computer and use the adjoin command to join it to the Active Directory domain.

For more information, see “Joining the Active Directory Domain” earlier in this chapter.

10. Confirm join for one UNIX host

After you successfully run the adjoin command on one UNIX-based computer, test that the UNIX-based computer is correctly joined to the domain.

For more information, see “Performing Quick Validation Checks” earlier in this chapter.

11. Ask one user to log on

Ask a user participating in the pilot deployment to log on with Active Directory credentials (logon name and password) to the UNIX-based computer that is joined to the domain.

12. Join remaining UNIX hosts to domain

Log on as root to each of the remaining UNIX-based computers in the pilot and run the adjoin command to join those computers to the Active Directory domain.

After the initial pilot deployment, when you expand the pilot deployment to include a larger set of users, you should develop a script that lets you join multiple computers to the domain. Using a deployment script during the pilot helps ensure that you will be able to successfully join multiple computers to Active Directory when you are ready to deploy the DirectControl solution in your production environment.

13. Confirm join for all pilot users

Test that each UNIX-based computer is correctly joined to the domain.

For more information, see “Performing Quick Validation Checks” earlier in this chapter.

14. Log on remaining pilot users

Ask the rest of the users participating in the pilot deployment to log on to their UNIX-based computers with their Active Directory credentials (logon name and password).

Because the user information from the UNIX /etc/passwd file (or other UNIX-based store) now populates their UNIX attributes in Active Directory, members of the pilot group see no change in their UNIX user experience. Their selected shell program, home directory, UID, and GID are the same as before.

The only change for users is that they now need to use their Active Directory password to log on to their UNIX-based computers.

15. Ask pilot users to change passwords

Ask the UNIX users participating in the pilot to change their Active Directory passwords and log on again to confirm that password changes function correctly.

16. Let pilot users perform daily tasks

Ask the pilot users to perform their usual tasks so that their UNIX hosts interact with other infrastructure components and with a variety of applications on the network.

For example, for each pilot user, check that the following continue to function correctly:

  • Any application running on the UNIX-based computer.

  • Any server application for which the UNIX-based computer is the client.

  • Enterprise monitoring systems.

  • Systems that might be sensitive to changes in the Active Directory schema, such as identity management or directory synchronization systems.

17. Perform administrative tasks on servers

Perform a wide variety of typical administrative tasks on the Active Directory server and on other servers on which pilot users access resources. For example:

  • Add users.

  • Delete users.

  • Change Active Directory Group Policy objects (GPOs) that affect users or computers in the pilot.

18. Interview pilot users

Interview or send a questionnaire to the pilot users to determine whether the change to Active Directory authentication and authorization caused any problems or raised any issues for the users.

19. Resolve issues

Resolve any issues that you encounter or that the pilot users report. In addition to issues directly related to authentication and authorization, you should look for and resolve issues related to network and server traffic or security.

20. Update pilot and deployment plans

Based on your experience in deploying the pilot and on the feedback that you receive from users who participate in the pilot:

  • Update your pilot plan so that the larger pilot with non-IT users (that you will perform after completing this initial pilot) will go more smoothly.

  • Update your deployment plan (part of the master project plan).

  • Update (or write) training materials for operations personnel.

  • Update (or write) informational or training materials for end users.

21. Confirm success criteria have been met

Confirm that the pilot deployment has met the success criteria specified in "Identify success criteria" at the start of this checklist.

22. Perform a pilot with a set of typical end users

For the initial pilot just completed, you used knowledgeable users, such as help desk personnel.

Now, expand the pilot to include a set of users whose expertise is in an area other than IT.

This time, deploy the solution just as you plan to do for the full production deployment (see the "Deployment Plan Template" job aid).

Stabilizing Phase Major Milestone: Release Readiness Approved

This completes the Stabilizing Phase for reaching End State 2 by implementing Centrify DirectControl. You have tested the solution, resolved issues found, and successfully completed a pilot deployment.

At this point, your team and customers should agree that all outstanding issues have been addressed and that the solution is ready to be released into the production environment.

Deploying the DirectControl Solution

After you complete the testing and stabilization activities, you are ready to place all UNIX-based computer, user, and group accounts into Active Directory throughout your production environment. After you complete the Deploying Phase, you can use Active Directory to manage all of your authentication, authorization, and directory services.

Introduction and Goals

This section provides an overview of deployment-related tasks for the Centrify DirectControl solution and is not intended to be a comprehensive deployment guide.

IMPORTANT   For complete information about deploying the Centrify solution, see the Centrify DirectControl Administrator’s Guide.

Major Tasks and Deliverables

In the Deploying Phase, you perform the following major tasks:

  • Complete deployment preparations

  • Deploy DirectControl

  • Stabilize the production deployment

Complete Deployment Preparations

You can install DirectControl software components at any time on both UNIX and Windows platforms without extensive preparations because no changes are made that affect the user or administrator experience on those computers. However, before you begin the deployment, you should review the following subsections and follow the guidelines that apply to your organization:

  • Importing Existing UNIX Accounts into Active Directory

  • Preparing IT Support Staff and Users

Importing Existing UNIX Accounts into Active Directory

The information in the following three subsections summarizes how to prepare for and then import existing accounts for UNIX users into Active Directory. For more information, see "How DirectControl Imports Existing UNIX Accounts into Active Directory" earlier in this chapter, and see the sections "Importing user and group information" and "Importing information from NIS maps or UNIX files" in the Centrify DirectControl Administrator’s Guide.

Export UNIX User and Group Information

Depending on which type of UNIX–based account store is currently in use in your network, you might have to export existing UNIX directory information to a file before you can import that information into Active Directory.

To export UNIX user and group information (if necessary)

  • Export NIS or LDAP information. For UNIX directory–based systems such as NIS or LDAP, you can use the UNIX getent tool to export UNIX user and group information to a file. For example:

    • To create a file with user account information, run the following command on the UNIX-based computer before you join the computer to the Active Directory domain:

      getent passwd > /tmp/passwd
    • To create a file with group account information, run the following command:

      getent group > /tmp/group

    Later, you will use these two files, /tmp/passwd and /tmp/group, to import existing NIS or LDAP directory information into Active Directory.

  • Use /etc files directly. For UNIX systems that use the /etc/passwd and /etc/group text files as the UNIX authorization store, you can use the /etc/passwd and /etc/group files directly for importing the information into Active Directory (there is no need to perform an export).

Verify That Windows Server Can Access UNIX Information

Before performing the import of UNIX information into Active Directory, you need to be able to access the UNIX information from the Windows-based computer where the Centrify DirectControl Administrator Console is installed. For either NIS or LDAP files (/tmp/passwd and /tmp/group) or for local files (/etc/passwd and /etc/group), you can use any of the following methods:

  • FTP or SFTP. Use FTP or SFTP to transfer the files from the UNIX-based computer to the Windows-based computer.

  • Network share:

    • Copy the files to a network share that is configured to allow a Windows user to access the files on a UNIX-based computer.

      – or –

    • Copy the files to a network share that is configured to allow a UNIX user to transfer UNIX files to a Windows-based computer network share.

  • Physical media. Transfer the files from the UNIX-based computer to the Windows-based computer using physical media such as a floppy disk, a USB drive, or a writeable CD.

Import UNIX User and Group Information

Now that the Windows-based computer can access the UNIX directory information, you can import the directory information into Active Directory.

To import UNIX directory information into Active Directory

  • Use the Import from UNIX tool in the Centrify DirectControl Administrator Console to import the user and group accounts stored in the passwd and group files into Active Directory.

    For information about how to use the Import from UNIX tool to import these accounts, see "Importing information from NIS maps or Unix files" in the Centrify DirectControl Administrator’s Guide.

After you successfully complete the importation steps, the UNIX user account information is stored in Active Directory and linked to the appropriate Active Directory user accounts.

Preparing IT Support Staff and Users

Before you can deploy the DirectControl solution, you must prepare the IT support staff and UNIX user community.

Train IT Support Staff

Provide training to your IT support staff by conducting the following activities or by providing the following information:

  • Time scheduled for deployment. Make sure support staff are available at the time the deployment is scheduled to take place.

  • Location of project plans. Ask support staff to read all relevant plans related to the DirectControl deployment project.

  • Location of documentation. Make available all system and solution documentation so support staff can use them to help solve end-user issues that arise during the production deployment.

  • Pilot project experience and feedback. Explain the result of the pilot project, including any issues encountered during the pilot and the resolution for each issue.

  • How to administer Windows and Active Directory. For support staff members who are familiar only with supporting UNIX-based computers, provide training about Windows and Active Directory concepts and administration.

  • How to administer UNIX. For support staff members who are familiar only with supporting Windows-based computers, provide training about UNIX concepts and administration.

  • How to manage the DirectControl solution. The best single resource for learning how to administer DirectControl is to read the Centrify DirectControl Administrator’s Guide, which is included with the DirectControl product. This guide includes much more detail about administrative functions, including information about capabilities beyond the scope of this chapter.

  • How to operate the DirectControl solution in your network and business environment. Create an operations handbook with details about implementing common operations scenarios in your environment, such as adding a new UNIX-based computer or user to Active Directory.

  • How to report issues related to the DirectControl solution. If your organization uses a bug or problem-ticket system for tracking issues, set up a new subject area for this solution. Teach support staff members how to report DirectControl issues.

Prepare UNIX End Users

You must prepare end users’ UNIX-based computers and inform the UNIX user community about what to expect. If your organization has decided to consolidate UNIX identities, you must perform certain tasks to accommodate a user’s new identity on the UNIX-based computer. For example, if your organization decides to consolidate and use only one zone for all UNIX-based computers, each user will have only one UNIX user name and one UID.

The following example procedure assumes that you have decided to use only one zone.

To prepare users’ UNIX-based computers before DirectControl is deployed: one zone example

  1. Report new settings for each UNIX user. Review and note the new UNIX settings for each user, including the user’s UID.

    You can do this by running a user report for the zone in the Centrify Administrator Console on the Windows-based computer. For more information, see "Generating and viewing reports" under "Running reports" in the Centrify DirectControl Administrator’s Guide.

  2. Configure UID information for each UNIX-based computer. On each UNIX-based computer, if necessary, configure each user’s files with the correct UID information.

    Note   This step is required only if the user’s new UID differs from the user's old UID. The zone feature is most often used to avoid the need to change UIDs, so this step is needed only rarely. It becomes important when an organization decides to consolidate UID assignments into a single UID space without overlap or duplication.

    For example, if Jeff Hay is assigned a UNIX UID of 527 and his UNIX user name is jhay, execute the following steps on the UNIX-based computer that Jeff Hay uses:

    1. Log on to the UNIX-based computer as root.

    2. Change the directory to Jeff Hay’s current home directory.

    3. Run the chown command to reset Jeff’s files with a new UID. For example:

      find –user jhay | xargs chown 527

Inform end users about the upcoming deployment by providing the following information.

  • What date? Make sure that managers and end users know when the switch to Active Directory is scheduled to occur.

  • Which computers? Make sure that managers and end users know which UNIX-based or Linux-based computers are included in the new deployment.

  • Which password? Explain to users that, after the DirectControl deployment is complete, they must use a single Active Directory password to access their UNIX-based workstations. They cannot use their current UNIX password after the deployment because it will no longer be active on the computer.

Deploy DirectControl

This section provides checklists to use to confirm that your network infrastructure is ready for the deployment. It also describes how to join your UNIX-based computers to Active Directory to implement the transition to the use of Active Directory authentication and authorization for the UNIX-based computers.

Deploying the Infrastructure

With deployment preparations complete, you are ready to deploy the DirectControl infrastructure in your production environment. If your organization is large, perform a phased deployment, as described earlier in “Preparing for a Phased Deployment.”

You can use the following table, which provides a synopsis of these steps, as a checklist.

Table 3.8. Checklist of Tasks to Deploy the Windows Environment

Task

Action

1. Install DirectControl components on Windows

Install the DirectControl Windows components on a Windows-based computer joined to the Active Directory domain.

For specific steps, see "Installing Centrify DirectControl on Windows" under "Develop the Solution Components" earlier in this chapter.

2. Configure DirectControl zone

Configure at least one DirectControl zone.

For specific steps, see "Configuring Active Directory with the First DirectControl Zone" under "Develop the Solution Components" earlier in this chapter.

3. Import and map UNIX users

Use the Import from UNIX tool in the Centrify DirectControl Administrator Console to import user information from the existing UNIX directory systems or local /etc/passwd file into Active Directory.

Map the imported identities to the appropriate Active Directory users.

For specific steps, see "Importing Information from NIS maps or UNIX files" in the Centrify DirectControl Administrator’s Guide.

4. Import and map UNIX groups

Import UNIX groups, if necessary, configuring them as Active Directory groups.

Map the imported groups to the appropriate Active Directory groups.

For specific steps, see "Importing Information from NIS maps or UNIX files" in the Centrify DirectControl Administrator’s Guide.

5. Populate zones

Add users and groups to the appropriate zones.

For specific steps, see "Importing Information from NIS maps or UNIX files" in the Centrify DirectControl Administrator’s Guide.

After deploying the Windows environment, as summarized in the preceding table, you can deploy the UNIX-based computers, as summarized in the following table, which you can use as a checklist.

Table 3.9. Checklist of Tasks to Deploy the UNIX-based Computers

Task

Action

1. Install DirectControl components on UNIX

Install the DirectControl UNIX or Linux components on each computer to be joined to the Active Directory domain.

For specific steps, see:

  • "Installing the Centrify DirectControl Agent on UNIX or Linux" under "Develop the Solution Components" earlier in this chapter.

  • "Installing the Centrify DirectControl Agent on UNIX" and Appendix C: “Installing an agent software package manually" in the Centrify DirectControl Administrator's Guide.

    Appendix C includes separate installation instructions for several types of UNIX and Linux platforms, including Red Hat Linux, Solaris, Debian, HP-UX, and AIX, as well as Macintosh OS X.

2. Synchronize clocks

Synchronize the system clock on the UNIX-based or Linux-based computers with the system clock on the Active Directory domain controller.

For more information, see “Verifying Time Synchronization" under "Develop the Solution Components " earlier in this chapter

At this point, although the software is fully installed and ready to be enabled, the computers are still functioning in their predeployment state and all existing user and computer operations are functioning normally. You can initiate the deployment to Active Directory at any time, based on the constraints or requirements of your organization, by performing the tasks described next in "Joining UNIX-based Computers to Active Directory."

Joining UNIX-based Computers to Active Directory

You are now ready to switch your UNIX-based or Linux-based computers to use Active Directory authentication, authorization, and directory services. You should do this at the scheduled time that IT support staff and users expect the deployment to occur.

You can use the following table, which provides a synopsis of these steps, as a checklist.

Table 3.10. Checklist of Tasks to Join UNIX-based Computers to Active Directory

Task

Action

1. Join UNIX-based computers to domain

Use the adjoin command on all UNIX-based computers—all of them or a group at a time in a phased deployment—that you want to join to the Active Directory domain. Use one of the following methods:

  • In a smaller organization, run the adjoin command on each UNIX-based computer, using the following syntax:

    Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.

    adjoin –-user UserName --password Password
     --zone ZoneName DomainName
  • In a larger organization, use a script to run the adjoin command remotely on all UNIX-based computers that you want to include in the deployment.

For more information about the adjoin command, see “Joining the Active Directory Domain” under “Developing the DirectControl Solution” earlier in this chapter.

2. Restart services or reboot computers

Restart services on UNIX-based computers, or reboot the computers.

For more information, see "Restarting Running Services" in "Developing the DirectControl Solution" earlier in this chapter.

Stabilize the Production Deployment

Verify that your UNIX-based computers are joined to the Active Directory domain and confirm that the UNIX-based computers function correctly.

To check that your deployment is stable

  1. Verify successful join to Active Directory domain. Use the adinfo --diag command to ascertain the current configuration of each UNIX-based computer and to verify that it has joined the Active Directory domain. Look for output that says:

    Joined as: ComputerName

    For more information about using the adinfo command, see "Confirming UNIX Computer Membership in Active Directory" under "Performing Quick Validation Tests" earlier in this chapter.

  2. Check log on process. Ask a user to log on to a computer. Monitor the logon process to make sure that the logon works and that the user does not experience any difficulty logging on.

  3. Check log file. Review the contents of the /var/log/messages file (or similar file) on the UNIX-based computer. Look for problems or failures.

    By default, DirectControl logs errors, warnings, and informational messages in the UNIX syslog file (which is modified when DirectControl is installed) and in the /var/log/messages file along with other kernel and program messages. In addition, you can configure logging that is specific to DirectControl and record that information in the DirectControl log file, /var/log/centrifydc.log.

    For information about configuring log levels and about troubleshooting specific log errors, see “Configuring logging for Centrify DirectControl” in the Centrify DirectControl Administrator's Guide.

  4. If necessary , roll back. If the join fails or logons do not function correctly, you can run the DirectControl leave Active Directory (adleave) command to restore the UNIX-based computer to its previous state.

    You can find information about the adleave command in the DirectControl UNIX man page for adleave(1). Resolve any issues, and then retry the adjoin command.

  5. Perform additional tests described earlier in this chapter. Refer to the testing guidelines in "Performing Quick Validation Tests" in the section "Developing the DirectControl Solution," and to the guidelines in "Test the DirectControl Solution" in the section "Stabilizing Your Test Deployment" earlier in this chapter to perform the following tests (use the tests that are appropriate for your deployment):

    • Confirming Configuration of Users and Groups

    • Testing Workstation Authorization Policies

    • Testing Account Lockout Policies

    • Testing Password Management Policies

    • Testing Offline Authentication

    • Testing Additional Administrative Tasks

After the UNIX-based computers are stable, monitor them closely for the first few days. When you are satisfied that Active Directory authentication and authorization are functioning as expected, you can use DirectControl to enable Active Directory authentication for additional services, such as Web applications. Refer to the Centrify documentation for information about extending DirectControl to other services.

Deploying Phase Major Milestone: Deployment Complete    

Your deployment of the Centrify DirectControl solution to reach a stable End State 2 is complete. At this point, the following capabilities are enabled:

  • Users can use Active Directory credentials to log on to computers running Windows, UNIX, or Linux operating systems. The same user name and password can be used on each computer.

  • User information previously stored in one or more UNIX directory systems is now imported into Active Directory and is now linked to a valid Active Directory account for each user.

  • If you chose to import user information previously stored in one or more UNIX directories into DirectControl zones, users can also log on to UNIX-based or Linux-based computers with their previous UNIX or Linux user name and their Active Directory password.

  • Authentication for a user session is provided by Active Directory and Kerberos.

  • Standard Kerberos is fully functional on the UNIX-based computers.

  • Kerberized UNIX applications can now use Kerberos tickets from Active Directory and can support a single sign-on experience without requiring the user to reenter a user name and password.

  • Authorization data and directory information for users, groups, and computers is stored centrally in Active Directory and is accessible from UNIX-based computers and UNIX applications.

  • Administration of user authentication and authorization is now centralized in Active Directory through standard Windows-based mechanisms.

  • No separate maintenance is required on the UNIX-based computers to maintain authentication and authorization data.

  • Systems previously used for authentication and authorization data storage in the UNIX environment can now be retired.

After completing the deployment:

  • Obtain final customer approval of the project.

  • Conduct a project review.

  • Conduct a customer satisfaction survey.

  • Continue stabilizing the deployment during this period as you hand over responsibility for ongoing management of the DirectControl solution to the operations team.

The project is now ready to be handed off from the project team to the operations and support staff.

Operating the DirectControl Solution

This section addresses operation of the DirectControl End State 2 solution after deployment into your production environment is completed. The completion of the Deploying Phase marks the end of the final phase in the MSF project life-cycle, when the MSF Release Management team hands off the solution to Operations. From this point forward, operations personnel use the principles defined by Microsoft Operations Framework (MOF) to organize and guide their efforts to support the mission-critical interoperability solution. The operations guidelines provided here are organized according to the MOF guidelines described in detail at http://www.microsoft.com/mof.

Completing the move to a consolidated authentication, authorization, and policy solution based on Active Directory and Centrify DirectControl results in a number of operational benefits:

  • Operational costs are reduced because standard administrative tasks now require less time.

  • Security is easier to monitor and maintain through the robust security and policy features of Active Directory.

  • End-user productivity and satisfaction with Operations increases because the number of times forgotten passwords must be reset is greatly reduced.

Introduction and Goals

The operations guidelines provided in this section, which supplement the DirectControl product documentation, address aspects of the Windows environment that are modified as a result of deploying DirectControl.

The DirectControl-specific operations information provided here is an overview and is not intended to be a complete, comprehensive operations guide. For complete information about operating the Centrify DirectControl solution, see the Centrify DirectControl Administrator’s Guide.

Knowledge Prerequisites

Because the staff handling the operational activities of the new interoperability solution might be different from those who handled the Planning, Developing, Stabilizing, and Deploying Phases, they might be unfamiliar with the End State 2 solution-related features of Windows, UNIX, and DirectControl. Therefore, it is important that they review the background information provided here.

Ensure that the operations team possesses the knowledge requirements stated in “About This Volume” and identified in the “Project Team Skills Template” job aid.

Operations staff should:

  • Review this chapter—especially Windows and Active Directory–related tasks described earlier in this chapter if they are new to Windows.

  • Take the training described in "Train IT Support Staff" in "Deploying the DirectControl Solution" earlier in this chapter.

In addition, members of the operations team should review the documentation that comes with the Centrify DirectControl product:

  • Centrify DirectControl Administrator’s Guide

  • Centrify DirectControl Evaluation Guide

  • Centrify white papers:

    • "Active Directory and DirectControl: The Right Choice for Enterprise Identity Management and Infrastructure Consolidation," April 2005.

    • “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration,” which is available from Centrify Corporation.

Major Tasks and Deliverables

For the DirectControl solution, operations staff members manage tasks in the following MOF-defined service management functions (SMFs):

  • Change Management

  • System Administration

  • Directory Services Administration (including DirectControl zones administration and reporting and auditing for UNIX objects)

  • Security Administration

  • Service Desk

  • Capacity Management

This section provides information for each of these SMFs that is relevant to your DirectControl deployment. For a complete list and detailed description of all MOF SMFs, see the MOF site at http://www.microsoft.com/mof."

Change Management

Managing change for your DirectControl solution includes—but is not restricted to—the checklist of synopsis steps listed in the following table.

Table 3.11. Checklist of Tasks to Manage Updating DirectControl

Task

Action

Test operating system updates

Changes in the UNIX or Linux operating system as a result of operating system patches might affect the DirectControl solution. Be prepared to test that DirectControl continues to function correctly after an operating system update or to make adjustments as needed if the patch does affect DirectControl functionality.

Assess DirectControl updates

Put in place a formal process to assess new releases of the DirectControl product in terms of its suitability for redeployment in your organization.

Develop and test DirectControl updates

Develop and test each new release of DirectControl in a lab environment, using a process similar to that described in "Developing the DirectControl Solution" earlier in this chapter.

Update DirectControl Windows and UNIX components

Update DirectControl components for Windows and UNIX as described in "Developing the Solution Components" and "Deploy DirectControl" earlier in this chapter.

Update deployment script

When you update DirectControl, you must also update your deployment script.

Update plans and training

After completing each deployment of a new version of DirectControl:

  • Document any configuration changes for the DirectControl solution, any issues encountered, and the resolution for each issue.

  • Update your project plans, checklists, and training documentation for IT support staff and for end users.

System Administration

One of the major benefits of centralizing authentication and authorization services for UNIX-based computers in Active Directory is that you can now manage system administration for identity management from a single console.

For example, if a new user joins your organization, you set up the user account in one place—Active Directory. The first step is to add the user to Active Directory in the standard way using the Active Directory Users and Computers snap-in tool. However, you must perform a few additional steps to enable the user as a UNIX user, as illustrated in the following example procedure.

To enable an Active Directory user as a UNIX user

  1. Log on. On a Windows-based computer on which Centrify DirectControl is installed, open Active Directory Users and Computers.

  2. Add user to a zone:

    1. Right-click the user name, and then click Properties.

    2. Click the Centrify Profile tab. By default, a new user is not added to any UNIX zone.

    3. Click Add, and then click Find Now to look up the available zones.

    4. Select the appropriate zone, and then click OK.

  3. Enable user's access to zone:

    1. Confirm that the user is assigned an appropriate UID, Login name, Shell, Home Directory, and Primary group.

    2. Select the check box Enable user access to this Zone.

    3. Click OK or Apply.

If this is a Red Hat Linux-based computer, you do not need to perform any steps on the computer. The DirectControl agent software on the computer performs such tasks as automatically creating a home directory for the user (if one does not exist) when the user logs on. However, with Solaris, a home directory is not created automatically by default because most Solaris installations use network shares for home directories and automatically creating a network share home directory might not be the preferred method.

You use Active Directory Users and Computers and the Centrify DirectControl Administrator Console for most administrative tasks. These administrative tasks, which are similar to the example above, are documented in the Centrify DirectControl Administrator’s Guide. These tasks include:

  • Enabling and managing Active Directory groups for use on UNIX-based computers.

  • Managing zones.

  • Importing information from NIS maps or UNIX.

  • Using the DirectControl Information Service for NIS.

  • Running reports.

In addition, you can use Active Directory Users and Computers and the Group Policy Management Console to manage Group Policy settings for UNIX users and computers.

IMPORTANT   Actions performed on user accounts will now affect that user on both Windows and UNIX. For example, if you want to temporarily lock out the user from logging on to any computer that is joined to Active Directory, do this as usual by selecting Account is disabled on the account properties page for the user in Active Directory Users and Computers. After you configure this setting, the user cannot log on to any Windows or UNIX-based computer in the domain.

Directory Services Administration

Best practices for directory services administration are documented in other Microsoft operations guides, including the following:

For example, one recommended practice is to use OUs to help compartmentalize users, groups, and computers into logical containers. Each container might have its own GPOs for assisting with the configuration and policy for the members of the OU.

In addition, the deployment of the DirectControl solution opens new possibilities for management strategies related to directory services administration, especially as related to the use of zones, described next.

Administering DirectControl Zones

As described earlier in the overview, you can use DirectControl zones to compartmentalize groups of users or computers into logical units. For example:

  • Group users based on a legacy directory service—for example, place all previous members of the NIS domain HRdomain into a zone called HRzone.

  • Group users based on roles—for example, place all finance users and computers into a zone called finance.

  • Group together a logically related set of users and computers—for example, place all UNIX users and computers in Europe into a zone called Europe.

Zones can be a powerful new addition to your operational toolset. Eventually, however, you might want to reduce the number of zones into a system that is more aligned with current day-to-day use instead of maintaining an organizational method that is based on accommodating legacy systems.

For example, you might initially want to set up zones oriented around accommodating numerous UNIX directory systems that were imported into Active Directory (for example, one zone for NIS directory A, one zone for NIS directory B, and one zone for OpenLDAP directory C). However, after those directory systems are no longer relevant to your organization, you might choose to create new zones that are based on current organizational characteristics, such as by function or by region.

Because a user can be a member of multiple zones, you can add users to a newly defined zone (even a zone with no computer members) at any time. Gradually, you can move the UNIX-based computers from membership in a legacy directory zone into a zone set up around current organizational characteristics. However, to do this successfully, you must carefully check the impact of the user’s UNIX attributes in the new zone to make sure that settings, such as UID settings, are not in conflict with what the operating system and applications are expecting in the zone.

Because zones are transparent to the UNIX user, it might make sense for you to use zones as a way of compartmentalizing administration as opposed to using zones for organizational groups. For example, you might want to put all Red Hat Linux computers into one zone and all Solaris computers into a different zone because different operators might be administering these two groups of computers. In addition, with the new capability provided by DirectControl Group Policy, some policy settings might be applicable to one zone (for example, enforced SELinux settings in a Red Hat Enterprise Linux 4 zone) but not applicable to another zone.

For more information:

  • About managing zones, see the section “Managing Zones” in the Centrify DirectControl Administrator’s Guide.

  • About zone migration strategies, see the white paper “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration.”

Reporting and Auditing for UNIX Objects

One of the key strengths of the Centrify DirectControl solution is its robust reporting capability. DirectControl includes several standard reports that provide summarized and detailed information about your UNIX users, groups, computers, zones, and licenses. The “Running reports” chapter in the Centrify DirectControl Administrator’s Guide describes the reports that you can produce with DirectControl and how to generate and export the report data.

You can use the Centrify DirectControl Administrator Console to create reports about all of the UNIX users, computers, groups, and zones that you define and the properties associated with each of them. In addition to providing detailed lists of user names and properties, reports provide you with different views of the information. For example, you can view computers grouped by zone or users grouped by application license.

You can also use reports to periodically check the integrity of zones across the Active Directory forest and to verify which users have access to specific computers, zones, or applications. Reports can help simplify accounting and auditing of user access and can provide the information you require for business planning and regulatory compliance.

By default, reports include information for all UNIX users, groups, computers, or zones, depending on the type of report you select. You can, however, filter report information to include only specific zones, specific user accounts, or other attributes.

After you generate a report, you can export the report to a variety of formats. Because each time you select a report, you generate a new snapshot of your environment, exporting a report allows you to save the report content for comparison over time. Depending on the format you select, you can then print, distribute, format, and manipulate the report information. You can export the report to the following formats:

  • Microsoft Excel® (.xls)

  • Microsoft Word (.doc)

  • Rich Text Format (.rtf)

  • Adobe Acrobat (.pdf)

For example, after generating a report with information about all users who are enabled in each zone, you can export it to Microsoft Excel (.xls) format, and then import the information into an Excel Worksheet to create a Charge Back report on account usage for each department.

Security Administration

Security administration is crucial for any organization. Establish controls to ensure that operators are granted rights for administering the computers and attributes that are required as part of their job but are locked out from accessing or changing computer settings outside their areas of responsibility.

Active Directory fully supports delegated administration and the compartmentalization of systems and users within an organization. You can set up these divisions as separate OUs or as separate domains within the Active Directory forest, and then grant permissions to the appropriate groups for different types of tasks within each OU or domain.

The DirectControl solution expands the delegation concept by letting you assign the administration of each UNIX zone to the appropriate operators and administrators on a zone-by-zone basis.

Delegating Zone Administration

You can use the Centrify DirectControl Administrator Console to grant particular users and groups permission to perform specific types of administrative tasks within each zone. The section “Assigning Management Privileges for Each Zone” earlier in this chapter provides an example of using delegated zone administration to restrict administrators' access to only the functions and computers that are applicable to their jobs.

For more information about delegated administration capabilities and guidelines for using the DirectControl delegated administration features, see the Centrify DirectControl Administrator’s Guide that comes with the DirectControl product.

Administering Security Policy

The deployment of End State 2 with DirectControl lets UNIX clients use Active Directory to authenticate with Kerberos and use Active Directory LDAP to access UNIX authorization and identity information. This means that the operations group has several new controls available for security and policy administration.

Active Directory includes numerous capabilities for enforcing password policy, such as password length, password complexity, length of time a password can be used, and account lockout based on the number of logon failures. With DirectControl, all password policies applicable to Windows systems are now also applicable to UNIX-based computers and users. No additional administrative steps are required to enable this functionality. Because the UNIX system is a member of the Active Directory domain, the policies of the domain are automatically applied to all UNIX or Linux members.

Another key feature of DirectControl is the capability to map privileged local UNIX accounts to Active Directory accounts. The UNIX root account has full access to all data and can manipulate all settings on a UNIX-based computer. Centrally controlling the root account and other special UNIX accounts makes it more difficult for an unauthorized user to obtain access to escalated privileges on the UNIX system. In addition, password policies that apply to standard Active Directory user accounts now also apply to privileged UNIX accounts, thereby enforcing controls on these special accounts.

Service Desk

You can substantially simplify help desk and service desk operations now that a centralized Active Directory–based system is in place for controlling identity management and access across your organization’s Windows and UNIX systems.

Deploying End State 2 benefits help desk and service desk operations by:

  • Centralizing administration. You can now centrally perform such tasks as adding a user to a new group or granting access to a new computer for a user once instead of doing it separately for the Windows environment and one or more times for each UNIX or Linux environment.

  • Consolidating user passwords. You can now consolidate user passwords. According to the Gartner Group, which researches the IT industry worldwide, 30 percent of all help desk calls are requests for password resets (see “Escaping Password Purgatory” at http://www.forbes.com/intelligentinfrastructure/2005/08/03/usps-password-casestudy-cx_de_0803password.html).

    Before the migration to End State 2, your organization might have had dozens of directory systems and, as a result, users might have had accounts on many different systems—each with its own password. With numerous logon names and passwords to remember, the likelihood of a user forgetting the credentials for a particular system is high.

    Now, with a single consolidated identity management system for Windows, UNIX, and Linux, the user has only one user name to remember and only one password. Because this single password is the password that each user uses every day to log on to the user's primary computer, the likelihood that the password will be forgotten is greatly reduced.

If a user attempts to log on to a UNIX-based computer that is configured to use DirectControl and the logon fails, you can take a number of steps to get to the root cause of the problem. Typically, the problem is related to how the UNIX-based computer is joined to the Active Directory domain, local settings on the UNIX-based computer, or user settings in Active Directory.

The following procedures show how to investigate each of these potential problem areas.

To check the status of the UNIX-based computer’s relationship with the Active Directory domain

  1. Check connectivity between UNIX host and Active Directory. Log on to the UNIX-based computer as the local root user (whose authentication information is stored locally instead of in Active Directory) and make sure that there is network connectivity between the UNIX-based computer and an Active Directory domain controller.

    For example, use the ping command as follows:

    ping DomainControllerName 
  2. Check Active Directory information. Log on to the UNIX-based computer as root and run the DirectControl Active Directory information command, adinfo. The output from this command should appear similar to the following:

    Local host name:        redhat9-1
    Joined to domain:    contoso.com
    Joined as:            redhat9-1
    Preferred site:        Default-First-Site-Name
    Zone:                    contoso.com/Program Data/Centrify/Zones/default

    If the output displays an error, it is likely that the join was not done correctly. Run the DirectControl command to leave Active Directory, adleave; run the DirectControl command to join Active Directory, adjoin; and then repeat the adinfo step. If a problem still exists, check network connectivity and check the names that were used when the UNIX-based computer joined the domain.

    For information about how to use adjoin, see "Understanding the adjoin Command" and "Using adjoin to Join a UNIX-based or Linux-based Computer to Active Directory" earlier in this chapter.

    For more information about how to use adleave and adinfo, see "To check that your deployment is stable" in "Stabilizing the Deployment" earlier in this chapter.

  3. Check clock synchronization. If the output in step 1 does not show an error, check that the system clocks for the UNIX-based computer and the Windows-based computer are synchronized. If they are not in sync, reset the UNIX-based computer system clock using the date command. See the UNIX man page date(1) for the appropriate syntax for your UNIX or Linux operating system.

To check DirectControl settings on the UNIX-based computer

  1. Check denied users and groups. Log on to the UNIX-based computer as root and open the file /etc/centrifydc/centrifydc.conf in an editor, such as vi:

    1. Search for the line the starts with "

      pam.deny.users:
      "

      Make sure that the user who is trying to log on to the UNIX-based computer is not listed on this line, which lists users who are restricted from logging on to this computer.

    2. Search for the line that starts with "

      pam.deny.groups
      "

      Make sure that the user who is trying to log on to the UNIX-based computer is not a member of a group that is listed on this line.

  2. Check log file. If the problem persists, check the contents of the system log files or the centrifydc.log file after the user attempts to log on. You can use information in this file to help determine where there might be an issue with the configuration of the software or issues with the user’s account.

    You can find more information about how to use log files for troubleshooting DirectControl in "Troubleshooting authentication and authorization" in the Centrify DirectControl Administrator's Guide.

To check the user’s settings

  1. Look for local and Active Directory–enabled users. Log on to the UNIX-based computer and run the getent, or get entry, command:

    getent passwd 

    This command displays a list of local users as well as UNIX-enabled Active Directory users. Search the output for the user’s name:

    • If the name is not found but other Active Directory users are listed, it is likely that the user has not been added to the zone that the UNIX-based computer is a member of. Log on to a Windows-based computer where the DirectControl software is installed, and enable the user in the correct zone.

    • If no Active Directory users are listed in the output of the getent passwd command, the DirectControl software is not configured correctly or the Active Directory controller is not available.

  2. Check Active Directory account settings. If the user’s name is listed in the output of the getent passwd command, check the settings for the user account in the Windows-based DirectControl Administrators console or in Active Directory Users and Computers.

    For example, make sure the account has not been disabled or that the user has rights to log on to the UNIX-based computer.

To use DirectControl adclient debug mode to enable logging

  • Enable debug mode. Put the DirectControl adclient daemon that runs on the UNIX-based computer into debug mode by logging on as root on the UNIX-based computer and running the following command:

    /usr/share/centrifydc/bin/addebug on

    This enables extensive ongoing logging information related to the DirectControl software to be written to the UNIX log file /var/log/centrifydc.log. You can use this file to further diagnose the cause of any problems or to enable Centrify’s support staff to assist with resolving any issues.

For more information about resolving logon issues for users, see the chapter “Troubleshooting authentication and authorization” in the Centrify DirectControl Administrator's Guide.

Capacity Management

After you deploy the DirectControl solution, conduct a careful analysis of the new environment to ensure that your network and domain controllers have enough capacity to handle the new load of UNIX users and computers in the Active Directory domain. Although the DirectControl solution includes technology that reduces resource usage and domain controller traffic between a UNIX-based computer and the Windows domain controller, it is still important to evaluate the volume of traffic incurred by UNIX users and computers.

Determining Whether You Need More Resources

As a result of this capacity management analysis, you might need to make some changes to ensure optimal performance and availability.

For example, if your organization has a small number of UNIX-based computers in the same location as a large number of Windows-based computers, and all users accessing the few UNIX-based computers are existing Windows users, deploying DirectControl to implement End State 2 probably causes only a minimal impact on your network or domain controllers.

However, the following factors might require allocating additional resources:

  • If UNIX-based or Linux-based computers are in a different location than the domain controllers that they need to access, consider installing a domain controller closer to the UNIX-based computers.

  • If you need to ensure availability in the event of a network or server failure, ensure that you have an adequate number of domain controllers.

  • If you add a large number of UNIX users to the Active Directory domain, you must apply your standard measures for balancing domain controllers per number of users.

  • If you add a large number of UNIX-based computers to the Active Directory domain, you must apply your standard measures for balancing domain controllers per numbers of computers.

  • If you move a large number of UNIX-based computers from a local directory (that is, from /etc/passwd) to Active Directory because authentication and authorization requests are now done over the network, you might require additional network bandwidth.

Using DirectControl Caching to Facilitate Lookups

DirectControl employs a number of techniques for caching credentials and reducing the amount of network traffic required for information lookups in the directory. This is a major area of differentiation between the DirectControl solution and a custom solution based on open source technology.

For example, if a UNIX user executes the ls –l command at a UNIX command shell, a listing of files and their attributes, such as the owner of each file, are looked up and displayed. The file’s owner is stored as a number—the user’s UID—in the properties area for the file on the UNIX-based computer. Because the ls command displays the owner as a name, not a number, the ls command must look up the actual user name associated with the owner’s UID. Because UNIX UIDs and user names are stored in Active Directory, this lookup must be serviced by Active Directory. If a large number of files are displayed when the ls command is run, this creates a substantial amount of lookup traffic between the UNIX-based computer and the Active Directory server.

DirectControl reduces this traffic by caching the lookups so that the information does not have to be retrieved from the Active Directory server each time a lookup is required. Commands check the local cache first for the relevant information instead of retrieving the information from Active Directory every time. Some of the custom open source solutions discussed in this guide do not have a caching capability and therefore create substantially more network traffic and load on the Active Directory domain controllers when UNIX-based computers are set up to use Active Directory for authentication, authorization, and other directory services.

Operations Summary

Your deployment of the Centrify DirectControl commercial solution to reach a stable End State 2 state is now fully operational. The operations and support staff are maintaining the solution and performing day-to-day tasks, such as:

  • Managing various aspects of the DirectControl solution, including administration of the following:

    • The DirectControl product

    • Directory services

    • Security

    • DirectControl zones

  • Using the DirectControl solution to streamline service desk operations.

  • Using the reporting and auditing features of DirectControl.

Technically, the guidance for using the DirectControl product to reach a fully deployed and operational End State 2 in a production environment is now complete. However, there are other scenarios beyond the one defined by End State 2 where a centralized Active Directory solution for security and directory services can have major potential benefits for your organization. The next section explores some of these scenarios.

Evolving the DirectControl Solution

Now that you have used DirectControl to deploy an Active Directory–based solution for supporting computers running the UNIX or Linux operating systems, you might want to explore additional ways to take advantage of Active Directory’s infrastructure services beyond authenticated logons and authorization.

Introduction and Goals

This section explores how to extend the DirectControl solution to address some common real-world scenarios. It is designed to be an “eye opener” and to help you think about solution areas that were potentially not in scope when the migration to End State 2 was first envisioned.

Knowledge Prerequisites

Before reading this section, you should read the preceding sections of this chapter and familiarize yourself with the following documentation:

  • Centrify DirectControl Administrator’s Guide

  • Centrify DirectControl Evaluation Guide

  • Centrify’s technical white paper, “Centrify's Solution for Migrating UNIX Directories to Active Directory: Leveraging Centrify’s DirectControl and Zone Technology to Simplify Migration.”

You can obtain these documents from Centrify Corporation.

Determine Your Next Steps

The first step in evaluating how to extend your DirectControl solution is to understand how the UNIX-based computers are used, which applications are typically used, what types of additional IT services you want to enable, and what types of controls you need to apply to the computers in the network. Some of this research is summarized in the following subsections.

A Day in the Life of a Computing Session

It is important to understand what types of computing sessions you need to support. Are they logon sessions, and, if so, are they character-based logons or graphical logons? Are they on the local computer, or do users log on through a remote mechanism such as ssh? Many UNIX-based computers have few interactive users but are instead used as application servers or computers running database systems or Web applications. What role does Active Directory authentication and authorization need to play for these applications?

With DirectControl, users can use a variety of methods to log on locally or remotely but always with their Active Directory credentials. You can also enable session authentication for application sessions, again making use of the user’s existing Active Directory session credentials.

Single Sign-On

A seamless computing experience is typically more than just having a single user name and password for all computers. Users appreciate the single sign-on experience that is possible with the Windows desktop and server domain environment. How can this seamless, yet secure experience be extended to UNIX and Linux platforms and applications running on these computers?

DirectControl supports methods for single sign-on computing by using Kerberos ticket-based authentication and by using standard mechanisms such as Generic Security Service Application Program Interface (GSS-API) and Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) for silent application authentication and directory service–enabled applications.

Application Migration

Existing applications on UNIX or Linux were not built to be aware of Active Directory and therefore will not work in an Active Directory environment without modifications.

Or will they?

In reality, many UNIX applications can run in an Active Directory environment with a small number of configuration changes or minor code modifications. Some UNIX applications can be made to work with Active Directory only by using legacy mechanisms such as NIS. Other UNIX applications can take advantage of standards-based mechanisms for application and platform interoperability in an Active Directory environment.

DirectControl uses the existing UNIX or Linux operating system infrastructure for making Active Directory services available to computers running UNIX or Linux. After the deployment of the DirectControl solution, applications and services that are PAM-aware are now Active Directory–aware. Services that use the Name Service Switch (NSS) system can now transparently access Active Directory. DirectControl also includes an Active Directory–enabled NIS server that interacts with computers and applications that need to use the NIS protocol.

How Data Is Securely Accessed

File sharing and access to data on distributed systems are essential for most corporate computer users. How can an authenticated user on one UNIX-based computer access files located on other UNIX or Windows-based computers?

The Server Message Block (SMB) protocol is the standard for file sharing between Windows-based computers. Windows users can use their Active Directory credentials to access files on other Windows-based computers in a secure yet easy way. DirectControl extends the UNIX authenticated session capabilities to allow secure bi-directional file sharing between computers running UNIX, Linux, Macintosh, or Windows operating systems by using SMB protocols and solutions.

Enforcing Computing Access and Policy

Enforcing computing policy is now more than just a security or operations requirement. Compliance with legal and government mandates for data and system access—for both corporate and customer information—is becoming a major concern for corporations.

How can you extend Active Directory to better control and monitor UNIX-based and Linux-based computers? DirectControl handles this challenge at two levels:

  • You can manage computers more effectively by using Group Policy and other Active Directory–based tools to enforce policy and system configuration.

  • You can monitor the computers through robust reporting capabilities that are built into the Centrify Administrator DirectControl Console.

What About Other Platforms?

This chapter has focused on extending Active Directory security and directory services to UNIX-based and Linux-based computers.

What about other platforms, such as the Apple Macintosh, IBM AS/400, and mainframe computer platforms? Centrify has extended its product family to also support the Apple Macintosh OS X operating system. Having identity management for all such platforms tied to Active Directory and managed from one console—the Centrify DirectControl Administrator Console—means that users have only one set of credentials to remember across all computers and that administrators have only one interface to use to set up and manage identity.

Centrify plans to continue to invest in extended platform support based on input from customers.

The themes highlighted above are just a few of the areas that you might consider as next steps. Professional services organizations and consulting groups from vendors such as Centrify can help organizations explore possibilities beyond the scenarios covered in this chapter.

Although each of the areas summarized above could fill its own solution guide, it is worth highlighting two areas in more detail because they are likely to be scenarios for virtually every customer. The first topic addresses enabling UNIX applications to work with the authentication, authorization, and directory services infrastructure that is provided with Active Directory. The second topic covers some of the basic elements of extending security and access controls for UNIX-based computers through centralized Group Policy methods. The following subsections explore these topics.

Expand Single Sign-on Capabilities to Applications

Providing centralized authentication and authorization to UNIX-based computers to enable logons with Active Directory credentials offers major benefits for an organization. However, many companies see this as only the first step toward a single identity infrastructure that embraces sessions, applications, data, and beyond.

Active Directory uses Kerberos and LDAP standards-based technology, and DirectControl uses these same standards as well as de facto standards for enabling authentication and authorization services (for example, PAM or NSS). As a result, you can enable many applications to be Active Directory–aware with relatively little work. This section provides an overview of four technology areas that support extending applications with these services:

  • Kerberos

  • PAM

  • Web-based methods

  • NIS

All four of these application authentication and authorization mechanisms are supported in the standard DirectControl product.

Using Kerberized Applications

Kerberos has been a de facto standard for authentication on both Windows and UNIX platforms for many years. The basic Kerberos technology is available free from Massachusetts Institute of Technology (MIT) and other sources and is also available as commercial product technology in both network infrastructure products and in applications.

Kerberos is used as the default method for authentication in Active Directory. When a user logs on to a computer that uses Active Directory authentication, a Kerberos ticket is issued to the user and that ticket allows the user to access data, applications, other computers, and other sessions without having to present user credentials again. On a Windows-based network, much of the single sign-on experience that allows a user to browse network shares or run server applications such as Exchange is enabled through the Kerberos silent authentication and ticket mechanism.

Fortunately, in a UNIX environment, Kerberos is also well established. Many UNIX-based applications are already Kerberos-aware and include built-in support for making use of a user’s Kerberos ticket. These applications include telnet, SSH, and SMB-related technologies such as Samba.

When you install DirectControl on a UNIX-based computer and join that computer to an Active Directory domain, a complete standard Kerberos system is also automatically installed and correctly configured on that computer. Correctly configured means that the UNIX-based computer has joined the Active Directory Kerberos realm and that Kerberos requests are forwarded and correctly serviced by the Kerberos system running on the Active Directory server. To the UNIX-based computer, Active Directory looks like any other standard Kerberos authority. Therefore, you can expect most Kerberized applications to “just run” after DirectControl is installed. However, some Kerberized applications might require authentication methods that are not supported by Active Directory and will therefore not run with any Active Directory–based solution.

To demonstrate how this works, install a recent version of Samba (version 3.0.x or later, available from http://samba.org) on your UNIX-based or Linux-based computer. Make sure that the smbclient tool is also installed. The smbclient tool allows a UNIX user to browse an SMB file share on any computer, including a share on a Windows file server. An smbclient option lets Kerberos be used as the method for silently passing the user’s credentials to the domain controller.

You can use the steps in the following procedure to illustrate this capability.

To explore the capability of a Kerberos application using Active Directory credentials

  1. Log on to a Windows file server. Log on to a Windows file server (called, in this example, centrifyad).

  2. Create and configure a shared folder:

    1. Create a shared folder called Sharedir.

    2. Grant domain users write access on the new share.

  3. Log on to a UNIX client. Log on to a UNIX-based or Linux-based computer with an Active Directory user account.

  4. Copy a file to a Windows file share:

    1. Type the following command to change to the /etc directory so that you can copy a file to a Windows file share:

      cd /etc
    2. Type the following smbclient command with the -k option (that is, the option to use Kerberos silent authentication) to access the file share, and then copy a local file to that share using the put subcommand:

      smbclient -k //centrifyad/Sharedir
      put passwd
      dir

      The above commands produce the following output:

      $ cd /etc
      $ smbclient –k //centrifyad/Sharedir
      OS=[Windows Server 2003 3790] Server=[Windows Server 2003 5.2]
      smb: \> put passwd
      putting file passwd as \passwd (86.3 kb/s) (average 86.3 kb/s)
      smb: \> dir
      .                                 D            0    Tue Jul  5 21:52:36 2005
      ..                                D            0    Tue Jul  5 21:52:36 2005
      passwd                            A         1502    Tue Jul  5 21:52:36 2005
                  60745 blocks of size 65536. 21875 blocks available
      smb: \>
  5. Confirm that the file was copied correctly:

    1. On the Windows-based computer, open Sharedir and confirm that the file passwd was copied to the server.

    2. Right-click passwd, click Properties, and verify that passwd was created on Sharedir with the appropriate ownership and properties.

Numerous books are available for developers that describe how to write Kerberos-enabled client and server applications or that provide more detail on existing applications that support Kerberos. O’Reilly’s Kerberos: The Definitive Guide at http://www.oreilly.com/catalog/kerberos/index.html is a good reference for further information about Kerberos and Kerberos applications.

Using PAM-Aware Applications

The pluggable authentication modules (PAM) service is a technology that is supported on Linux, Sun Solaris, and other UNIX platforms as a means to provide a flexible mechanism for authenticating users regardless of the underlying authentication system. PAM supports the standard logon-enabled programs on UNIX (for example, login, ftpd) as well as other programs that rely on user authentication (for example, Samba or mail servers)

PAM relies on configuration files that direct the application to try one or more authentication methods when the user invokes an application session. For example, you can configure login to try the local password file first, and then try Active Directory authentication if the first method fails. After a user is authenticated, further action can be taken to service the session. For example, if a user does not have a home directory, it is possible to configure PAM to automatically create the user’s home directory on first logon.

According to the FAQ about Linux-PAM at http://www.kernel.org/pub/linux/libs/pam/FAQ:

"PAM provides a way to develop programs that are independent of authentication scheme. These programs need ‘authentication modules’ to be attached to them at run-time in order to work. Which authentication module is to be attached is dependent upon the local system setup and is at the discretion of the local system administrator."

DirectControl includes a PAM module, pam_centrifydc.so, which directs PAM requests to Active Directory. This PAM module is automatically configured as the initial authentication method in the master system-auth PAM configuration file. This means that any PAM-enabled application is automatically configured to use Active Directory authentication through DirectControl. For example, a user can log on to the computer using SSH with their Active Directory credentials. Because SSH is a PAM-based application, this capability is enabled without having to make any changes to the SSH daemon or to the SSH client.

For more information:

Using DirectControl for Web-based Single Sign-On

A variety of Web servers and Java-based application servers are available on Linux and UNIX platforms. In most cases, these Web platforms provide some type of native authentication and authorization system for Web developers to use for Web-based applications. With DirectControl, you can extend these native interfaces to seamlessly connect to Active Directory for authentication and authorization, enabling Web applications with a single sign-on capability.

Centrify provides authentication and authorization services for Web applications through custom modules that can be called directly from within a given Web application. These modules include the following:

  • DirectControl SPNEGO module. This module allows Microsoft Internet Explorer to silently and securely pass the client user identity to a Web application hosted on an Apache Web server that runs on a UNIX-based computer. SPNEGO is an HTTP authentication mechanism that is used by Microsoft Internet Explorer and by the Microsoft Internet Information Services (IIS) Web server for Kerberos-based user authentication. GSS-API libraries are also included with DirectControl.

    According to the GSS-API entry in the Internet FAQ Archives at http://www.faqs.org/faqs/kerberos-faq/general/index.html:

    "The GSSAPI is a generic API for doing client-server authentication. The motivation behind it is that every security system has its own API, and the effort involved with adding different security systems to applications is extremely difficult with the variance between security APIs. However, with a common API, application vendors could write to the generic API and it could work with any number of security systems.

    How does this relate to Kerberos? Included with most major Kerberos 5 distributions is a GSSAPI implementation. Thus, if a particular application or protocol says that it supports the GSSAPI, that means that it supports Kerberos, by virtue of Kerberos including a GSSAPI implementation."

  • DirectControl Java/J2EE modules. These modules provide the capability to authenticate and perform access control for Java/J2EE applications. For example, the Java Authentication and Authorization Service (JAAS) module is a general purpose module for logging on a user in the Java world. This is very similar to a PAM module; in fact, the JAAS authentication scheme is modeled on PAM. The JAAS module can operate in one of two modes:

    • Silent. In Silent mode, the user is not prompted for a user name or password. Instead, the module queries the underlying operating system to determine who this user is and, if the user is found, the module sets up the user’s credentials for later use.

    • Prompted. In Prompted mode, the JAAS module asks the application to prompt the user for a user name and password. When the user responds, the module then validates this data and stores the user’s credentials for later use.

  • DirectControl Tomcat module. The open source J2EE server, Tomcat, provides two main interfaces for controlling security: realms and authenticators. The realm specifies the mechanism for looking up user credentials in a database, and authenticators perform authentication by using a specific mechanism or protocol. Centrify DirectControl for Tomcat provides a JAAS realm that allows different authenticators, such as BASIC authentication and FORM authentication, to verify a user’s name and password combination against Active Directory.

    In addition to supporting the Centrify DirectControl JAAS realm, Centrify DirectControl for Tomcat provides an SPNEGO authenticator, which allows transparent authentication, that uses Kerberos tickets when users access the application through Internet Explorer. Installing Centrify Direct Control for Tomcat makes it easy for the application developer or IT administrator to map Tomcat roles to Active Directory groups to provide additional control over which users can access the application or perform certain tasks. Tomcat applications can use DirectControl to automatically map Active Directory groups to Tomcat role names.

    To use the SPNEGO authenticator for transparent authentication when users access the application with Internet Explorer, you need to modify the authentication method defined in the application’s web.xml file. For example, instead of using FORM or BASIC authentication, you can specify SPNEGO authentication.

    The Centrify DirectControl Evaluation Guide provides instructions for setting up an evaluation environment to demonstrate Active Directory authentication and authorization with the Tomcat Web server

You can find complete instructions for using the DirectControl SPNEGO, Java/J2EE, and Tomcat modules in the Centrify DirectControl Administrator’s Guide. You can find examples for demonstrating the capabilities of the modules in the DirectControl Evaluation Guide. DirectControl also provides Active Directory-based authentication and authorization modules for other J2EE application servers, including JBoss, BEA WebLogic, and IBM WebSphere.

Supporting Legacy NIS Applications

When Centrify DirectControl is installed on a UNIX-based computer, the Name Service Switch (NSS) configuration file, nsswitch.conf, is modified so that account lookup requests are passed to Active Directory through the DirectControl Active Directory client daemon, adclient. By sending these requests to Active Directory, DirectControl bypasses the standard Network Information Service (NIS) or other services.

In some organizations, however, bypassing NIS might be problematic. For example, you might use applications, such as the UNIX automount daemon (which automatically mounts a network file system when it is first accessed and later unmounts the file system when no activity occurs), that require access to a NIS server because they send requests directly to the NIS port and expect a NIS process to be listening there. You might also have computers or devices, such as Network Attached Storage (NAS) devices, on which you cannot install the Centrify DirectControl Agent but that need access to the account and group information that you store in Active Directory.

For computers and applications that submit lookup requests directly to a NIS server listening on the NIS port, DirectControl includes its own version of NIS. The Centrify DirectControl NIS feature relies on its own daemon process, the DirectControl Active Directory NIS daemon, or adnisd, to receive and respond to NIS client requests. Centrify DirectControl NIS is an optional addition to the Centrify DirectControl Agent and can be installed on one or more DirectControl-managed computers, as needed. After DirectControl NIS is installed and running, it functions just like a standard NIS server but responds to NIS client lookup requests by using information stored in Active Directory.

Although you can leave standard NIS servers in place on your UNIX network, using DirectControl NIS lets you centralize all directory service operations with Active Directory. After you import all relevant data into Active Directory and configure the NIS clients to use the Centrify DirectControl Network Information Service, you can decommission your legacy NIS servers.

The following figure illustrates the functionality of the NIS feature included with DirectControl.

Figure 3.9. DirectControl NIS example

Figure 3.9. DirectControl NIS example

The figure includes a zone of UNIX-based computers called "Finance Zone." UNIX-based computers that are not managed by DirectControl but need access to the information stored in Active Directory can be configured to send their NIS requests to the DirectControl-managed UNIX-based computer on which the DirectControl NIS daemon runs. The DirectControl NIS daemon passes these requests to adclient that, in turn, connects to Active Directory to retrieve the requested information. Active Directory returns the information from the data stored in the appropriate NIS map, and then the information is passed back through adnisd to the client that made the request.

NIS maps stored in Active Directory can be maps that are imported directly from an existing NIS server and domain or that are imported from existing text files. The Centrify DirectControl Administrator Console provides the interfaces for importing, creating, viewing, editing, or deleting the maps.

Enable Configuration and Access Control with Active Directory and Group Policy

One of the most requested features for Centrify’s DirectControl product is the requirement to extend the Windows Group Policy system to computers running UNIX, Linux, or Macintosh operating systems. For many companies, centralized policy and configuration control is just as important as centralized identity management.

Applying Domain-wide Policy Through Active Directory

After you deploy End State 2 in your production environment, a logical next step is to review policies and mandatory configuration settings that are currently enforced for Windows-based computers through Group Policy and to evaluate the potential applicability of these policies for computers running UNIX, Linux, or Macintosh operating systems. You can apply some of these policies directly with Active Directory without the need for any Group Policy components on the UNIX-based computer.

For example, most organizations establish a policy for password strength. You can view or modify this policy by using the Default Domain Security Settings console (displayed by clicking Domain Security Policy under Administrative Tools). After you save these settings, they automatically apply to UNIX users who use DirectControl for Active Directory authentication. This occurs because the Active Directory engine is used for authenticating the UNIX user and Active Directory is governed by these policy settings.

Figure 3.10. Typical Windows domain policy settings for password strength

Figure 3.10. Typical Windows domain policy settings for password strength
Applying Policy for UNIX Users and Computers with Group Policy

Ideally, if you want to apply specific Active Directory policies for UNIX-based computers, you do this from the same central system that handles Windows-based policy. To satisfy this requirement, Centrify DirectControl Group Policy lets you extend the configuration management capabilities of Windows GPOs to managed UNIX-based computers and users. Centrify DirectControl includes a Group Policy component that runs on the UNIX-based computer but is controlled through the Group Policy engine on Windows.

This section provides an overview of key concepts for working with Group Policy settings in an environment that includes UNIX users and UNIX-based computers. For detailed information about creating and managing Group Policy settings, see the Centrify DirectControl Administrator’s Guide and Windows or Active Directory documentation.

When you define Active Directory Group Policy settings, the settings are stored in a GPO. Each GPO can consist of configuration information that applies to computers, configuration information that applies to users, or sections of policy that apply specifically either to users or to computers. You link a GPO to an Active Directory OU, domain, or site, and then Windows applies the policy settings based on an established hierarchical order.

Because a GPO represents a complete collection of configuration details, each GPO includes configuration attributes stored in Active Directory objects and a set of Administrative Templates. Administrative Templates define the set of configuration options available and how the settings are displayed and configured in the Group Policy Object Editor. A default set of Administrative Templates is created with any new GPO. These Administrative Templates are stored as files with the .adm extension. The default Administrative Templates are primarily intended to provide configuration options for Windows users and computers.

With DirectControl, you can configure some settings in the default Administrative Templates that apply to UNIX users or computers. For most of the configuration settings that apply to UNIX users or computers, you must use the Centrify DirectControl administrative template, centrifydc.adm, which you can install when you run the DirectControl setup program on a Windows-based computer.

In a Windows environment, most of the configuration settings defined in GPOs are implemented through entries in the local Windows registry. For UNIX-based computers, local configuration details are typically defined through a set of configuration files stored in the /etc directory. In addition to having configuration information stored in different ways, the Window and UNIX environments typically require different specific configuration options to work properly. To address these differences between the platforms and to extend Group Policy settings so that they can apply to UNIX-based computers and users, Centrify DirectControl:

  • Provides its own administrative template to define UNIX-specific configuration settings.

  • Uses the adclient daemon to collect configuration details from Active Directory based on the GPOs and maintains a virtual registry of those configuration settings on the local UNIX-based computer.

The virtual registry is a collection of files that contain all Group Policy configuration settings from the Group Policy settings applied to the computer through the Group Policy hierarchy. DirectControl uses a set of mapping programs to read the files, determine the settings that are applicable to UNIX-based computers, and make the appropriate changes in the corresponding UNIX configuration files to implement the configuration specified.

The following figure illustrates how Active Directory Group Policy settings are applied to a UNIX-based computer through DirectControl.

Figure 3.11. How DirectControl applies Group Policy to a UNIX-based computer

Figure 3.11. How DirectControl applies Group Policy to a UNIX-based computer

Each GPO includes several default Administrative Templates (.adm files) that define the set of configuration settings available and how the configuration settings are presented in the Group Policy Object Editor. To include the DirectControl configuration settings for UNIX in a GPO, you need to add the Centrify DirectControl administrative template, centrifydc.adm, to the GPO in the editor. You can accomplish this by using the following procedure.

To add centrifydc.adm to the GPO

  1. Check prerequisites: 

    • Confirm that the Centrify DirectControl Windows software is installed on the Windows-based computer that you use to perform this procedure.

    • Confirm that the Group Policy Templates were installed when you installed DirectControl. If you are not sure whether the Group Policy Templates component is installed, rerun the DirectControl setup program on the Windows-based computer that you use for configuring Group Policy.

  2. Create Group Policy Object Editor console:

    1. Click Start, click Run, type mmc, and then click OK.

    2. In the MMC console, click File, and then click Add/Remove Snap-in.

    3. Click Add, select Group Policy Object Editor, and then click Add.

    4. On the Welcome to the Group Policy Wizard page, click Browse, select Default Domain Policy, and then click OK.

    5. Click Finish, click Close, and then click OK.

  3. Add centrifydc.adm to GPO:

    1. Expand the tree for Default Domain Policy, and then expand Computer Configuration.

    2. Right-click Administrative Templates, and then select Add/Remove Templates.

    3. In Add/Remove Templates, select Add.

    4. Browse to the inf directory in your Windows directory.

    5. Double-click centrifydc.adm.

    6. Select Close.

  4. View or modify Group Policy settings. You can view or modify Group Policy settings for computers or users in the domain as follows:

    • View or modify Group Policy settings for domain computers under Default Domain Policy – Computer Configuration – Administrative Templates – CentrifyDC Settings.

    • View or modify Group Policy settings for domain users under Default Domain Policy – User Configuration – Administrative Templates – CentrifyDC Settings.

  5. Assign values for template settings. After you add the Centrify DirectControl administrative template to a GPO, you can use the Group Policy Object Editor to assign values for the settings provided by the template. The following screenshot shows an example of a policy configured to deal with UID conflict resolution. With this example policy, when a user logs on, if PAM discovers that the user’s Active Directory record has the same UID or the same user name as a local system account, the system does not allow the user to log on.

    Figure 3.12. Example policy that disables user logon if a UID conflict exists

    Figure 3.12. Example policy that disables user logon if a UID conflict exists

Evolving Summary

The migration to End State 2 using Centrify DirectControl lets UNIX clients use Active Directory to authenticate with Kerberos and enables UNIX clients to access UNIX authorization and identity information with LDAP. The DirectControl solution is both flexible and extensible. Numerous features built into the DirectControl architecture support extending Microsoft-based authentication, authorization, access control, and policy well beyond centralized identity management for UNIX-based and Linux-based computers.

Support for identity-enabled applications that take advantage of your organization’s Active Directory investment can provide substantial benefits in terms of increased end-user productivity, enhanced ease of management, and improved access control and security. Features for controlling user, data, and application access enable organizations to better manage who gets access to what resources regardless of the platform that they use. The capability to track and report computer access and user privileges and, if necessary, take quick centralized action to remediate security issues helps you take control over heterogeneous computing platforms. These capabilities also help you stay compliant with regulatory authorities. All of these features and more are supported “out of the box” with the Centrify DirectControl suite.

For more information about the Centrify DirectControl product family, access to detailed white papers describing typical customer scenarios and product comparisons, or to obtain evaluation copies of the products covered in this chapter:

  • Visit the Centrify company Web site at http://www.centrify.com.

  • Send e-mail to Centrify: info@centrify.com.

  • Call Centrify: 1-650-961-1100.

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.