Centrify DC Admin Guide v3

Centrify DirectControl
Administrator’s Guide
Version 3.0
Centrify Corporation
Legal notice
This document and the software described in this document are furnished under and are
subject to the terms of a license agreement or a non-disclosure agreement. Except as
expressly set forth in such license agreement or non-disclosure agreement, Centrify
Corporation provides this document and the software described in this document “as is”
without warranty of any kind, either express or implied, including, but not limited to,
the implied warranties of merchantability or fitness for a particular purpose. Some states
do not allow disclaimers of express or implied warranties in certain transactions;
therefore, this statement may not apply to you.
This document and the software described in this document may not be lent, sold, or
given away without the prior written permission of Centrify Corporation, except as
otherwise permitted by law. Except as expressly set forth in such license agreement or
non-disclosure agreement, no part of this document or the software described in this
document may be reproduced, stored in a retrieval system, or transmitted in any form or
by any means, electronic, mechanical, or otherwise, without the prior written consent of
Centrify Corporation. Some companies, names, and data in this document are used for
illustration purposes and may not represent real companies, individuals, or data.
This document could include technical inaccuracies or typographical errors. Changes are
periodically made to the information herein. These changes may be incorporated in new
editions of this document. Centrify Corporation may make improvements in or changes
to the software described in this document at any time.
© 2004-2006 Centrify Corporation. All rights reserved. Portions of Centrify
DirectControl are derived from third party or open source software. Copyright and legal
notices for these sources are listed separately in the Acknowledgements.txt file included
with the software.
U.S. Government Restricted Rights: If the software and documentation are being
acquired by or on behalf of the U.S. Government or by a U.S. Government prime
contractor or subcontractor (at any tier), in accordance with 48 C.F.R. 227.7202-4 (for
Department of Defense (DOD) acquisitions) and 48 C.F.R. 2.101 and 12.212 (for
non-DOD acquisitions), the government’s rights in the software and documentation,
including its rights to use, modify, reproduce, release, perform, display or disclose the
software or documentation, will be subject in all respects to the commercial license
rights and restrictions provided in the license agreement.
Centrify and DirectControl are trademarks of Centrify Corporation in the United States
and/or other countries. Microsoft, Active Directory, Windows, Windows NT, and
Windows Server are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of any other companies and products mentioned in this document may be the
trademarks or registered trademarks of their respective owners. Unless otherwise noted,
all of the names used as examples of companies, organizations, domain names, people
and events herein are fictitious. No association with any real company, organization,
domain name, person, or event is intended or should be inferred.
Contents
About this guide 9

Intended audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Getting a preview of what’s in this release . . . . . . . . . . . . . . . . . . . . . . . . . 10
Using this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Conventions used in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Using online help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Where to go for more information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Contacting Centrify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 1 Introduction 17
Understanding identity and access management. . . . . . . . . . . . . . . . . . . 17
Why integrate with Active Directory?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
What is the Centrify DirectControl solution?. . . . . . . . . . . . . . . . . . . . . . . . 19
What can you do after you deploy DirectControl?. . . . . . . . . . . . . . . . . . . 24
Chapter 2 About the Centrify DirectControl architecture and operation 27

Understanding the integration of Windows and Unix . . . . . . . . . . . . . . . 27
Understanding DirectControl Management Tools . . . . . . . . . . . . . . . . . . 29
Understanding Centrify DirectControl Zones . . . . . . . . . . . . . . . . . . . . . . . 33
Understanding Centrify DirectControl Agents . . . . . . . . . . . . . . . . . . . . . . 34
Understanding the log-on process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Summary of how DirectControl works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 3 Planning the deployment of Centrify DirectControl 49

Planning Active Directory permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3
Planning changes to the Active Directory structure. . . . . . . . . . . . . . . . . 83
Planning to work with multiple forests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Planning how you will use zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Planning user account migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Planning group membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Planning NIS map migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Chapter 4 Installing Centrify DirectControl on Windows 99

Preparing for installation on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Installing Centrify DirectControl Management Tools . . . . . . . . . . . . . . .103
Starting Centrify DirectControl for the first time. . . . . . . . . . . . . . . . . . . 105
Updating from a previous release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Removing Centrify DirectControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Chapter 5 Installing the Centrify DirectControl Agent on Unix 115

Preparing for installation on Unix computers . . . . . . . . . . . . . . . . . . . . . 115
Installing the Centrify DirectControl Agent . . . . . . . . . . . . . . . . . . . . . . . 116
Verifying the DNS configuration on Unix . . . . . . . . . . . . . . . . . . . . . . . . . 119
Joining an Active Directory domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Updating from a previous release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Removing Centrify DirectControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Chapter 6 Managing zones 129

Using the Centrify DirectControl Setup Wizard . . . . . . . . . . . . . . . . . . . . 129
Creating a new zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Opening and closing zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Delegating control of administrative tasks. . . . . . . . . . . . . . . . . . . . . . . . 135
Changing zone properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Adding a computer to a zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Running reports for zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4 Administrator’s Guide
Chapter 7 Managing computers 143
Using zones for Linux, Unix, and Mac OS computers . . . . . . . . . . . . . . . 143
Understanding how a computer joins a domain . . . . . . . . . . . . . . . . . . . 145
Deciding who can join computers to the domain . . . . . . . . . . . . . . . . . . 147
Preparing computer accounts before joining . . . . . . . . . . . . . . . . . . . . . 149
Joining a domain interactively or using a script. . . . . . . . . . . . . . . . . . . . 150
Changing computer properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Allowing password resets for computer accounts. . . . . . . . . . . . . . . . . . 154
Changing the domain for a computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Leaving a domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Running reports for computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Customizing configuration settings for a computer . . . . . . . . . . . . . . . . 159
Using computer-based group policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Chapter 8 Managing users and groups 161

Understanding user access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Using private groups for Unix users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Adding standard Active Directory groups to zones. . . . . . . . . . . . . . . . . 163
Adding Active Directory users to zones . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Modifying the Unix profile for users or groups. . . . . . . . . . . . . . . . . . . . . 168
Applying password policies and changing passwords . . . . . . . . . . . . . . 169
Working in disconnected mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Mapping local Unix accounts to Active Directory . . . . . . . . . . . . . . . . . . 172
Setting a local override account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Importing user and group information . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Running reports for users and groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Customizing configuration settings for users and groups. . . . . . . . . . . 179
Using user-based group policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Contents 5
Chapter 9 Managing group policies for Unix users and computers 181
Understanding Group Policy Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
Understanding group policy for Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189
Adding Unix policies to a Group Policy Object. . . . . . . . . . . . . . . . . . . . . 193
Creating a Centrify DirectControl Group Policy Object . . . . . . . . . . . . . 195
Setting policies for Unix computers and users. . . . . . . . . . . . . . . . . . . . . 196
Linking a Group Policy Object to a container . . . . . . . . . . . . . . . . . . . . . . 203
Reporting group policy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Editing the Centrify DirectControl configuration file . . . . . . . . . . . . . . . 205
Defining custom group policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Chapter 10 Managing licenses 213

Understanding how licensing works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Adding license containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Viewing the license summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Adding license keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Deleting a license key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Running reports for licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Chapter 11 Importing information from NIS maps or Unix files 223

Understanding the information source . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Importing from NIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Importing from a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Moving pending information into Active Directory . . . . . . . . . . . . . . . . 226
Making imported information available to NIS clients . . . . . . . . . . . . . 231
Chapter 12 Using the DirectControl Information Service for NIS requests 233
Understanding the DirectControl Information Service . . . . . . . . . . . . . 233
Understanding how to deploy the adnisd daemon . . . . . . . . . . . . . . . . 236
Understanding NIS maps in Active Directory . . . . . . . . . . . . . . . . . . . . . . 237
Configuring the DirectControl Information Service . . . . . . . . . . . . . . . . 239
Configuring NIS clients to use Centrify DirectControl. . . . . . . . . . . . . . . 243
Configuring client authentication through adnisd . . . . . . . . . . . . . . . . . 246
Maintaining NIS maps in the Administrator’s Console . . . . . . . . . . . . . . 250
Discontinuing use of legacy NIS servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Chapter 13 Running reports 257

Understanding the importance of reports. . . . . . . . . . . . . . . . . . . . . . . . . 257
Understanding the information each report provides . . . . . . . . . . . . . . 258
Generating and viewing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Filtering report information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Displaying the group navigation pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Exporting and saving report information . . . . . . . . . . . . . . . . . . . . . . . . . 264
Printing reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Chapter 14 Troubleshooting authentication and authorization 267

Understanding diagnostic tools and log files . . . . . . . . . . . . . . . . . . . . . . 267
Analyzing zone information in Active Directory . . . . . . . . . . . . . . . . . . . 268
Configuring logging for Centrify DirectControl . . . . . . . . . . . . . . . . . . . . 270
Collecting diagnostic information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Working with DNS, Active Directory, and DirectControl . . . . . . . . . . . . 275
Filtering the objects displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Appendix A Using Centrify DirectControl Unix commands 283

Understanding when to use command line programs . . . . . . . . . . . . . 284
Displaying usage information and man pages. . . . . . . . . . . . . . . . . . . . . 285
Using adjoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Using adleave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Using adpasswd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Using adgpupdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Contents 7
Using adinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Using addebug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Using adrmlocal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Using adfinddomain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Using adsmb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Using adclient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Using runmappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Using OpenLDAP commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Appendix B Customizing Centrify DirectControl configuration options 323

Understanding how the configuration file is used . . . . . . . . . . . . . . . . . 323
Understanding the syntax in the configuration file . . . . . . . . . . . . . . . . 324
Customizing daemon parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Customizing Kerberos parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Customizing PAM parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Customizing NSS parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Customizing NIS parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Customizing group policy parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Appendix C Installing an agent software package manually 399

Installing DirectControl on Red Hat, SuSE, or VMware . . . . . . . . . . . . . 400
Installing DirectControl on Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Installing DirectControl on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Installing DirectControl on HP-UX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Installing DirectControl on AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Installing DirectControl on Mac OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Appendix D Setting the ports for Centrify DirectControl 405
Index 407
About this guide
CentrifyTM DirectControlTM delivers secure access control and

centralized identity management by seamlessly integrating UNIX,
Linux, and Mac OS X computers, and J2EE and web platforms
with Microsoft Active Directory. With DirectControl,
organizations can improve IT efficiency, better comply with
regulatory requirements, and move toward a more secure,
connected infrastructure for their heterogeneous computing
environment.
Intended audience
This Administrator’s Guide provides complete information for
installing, using, and customizing Centrify DirectControl. This
guide is intended for system and network administrators who are
responsible for managing user access to servers, workstations,
enterprise applications, and network resources.
Because Centrify DirectControl requires components to be
installed in both the Windows environment and the Linux, UNIX,
or Mac OS X environment, this guide assumes you have a working
knowledge of performing administrative tasks across these different
environments. If you are unfamiliar with any of the operating
environments you need to support with Centrify DirectControl,
you may need to consult additional, operating system-specific
documentation to perform certain tasks or understand certain
concepts.
This guide also assumes basic, but not expert, knowledge of how to
perform common tasks. If you are an experienced administrator,
9
Getting a preview of what’s in this release
you may be able simplify or automate some tasks described in this

guide using scripts or other tools.
Getting a preview of what’s in this release

This release of Centrify DirectControl includes updates for all of
the core DirectControl components. These updates include
support for new platforms, group policy support, extended NIS
support, and other enhancements. For a summary of what’s in this
release, the system requirements for installation, and any other
late-breaking information, see the Centrify DirectControl Release Notes
on the Centrify DirectControl CD or in the distribution package.
When the CD is inserted into the drive on a Windows computer,
an autorun program displays the default Centrify DirectControl
page. From this page, click Release Notes for an overview of
what’s in this release package and to review other topics.
Using this guide

Depending on your environment and role as a Centrify
DirectControl administrator or user, you may want to read
portions of this guide selectively. The guide provides the following
information:
Chapter 1, “Introduction,” provides an overview of identity
management and how Centrify DirectControl works, including
a summary of key features and benefits.
Chapter 2, “About the Centrify DirectControl architecture and
operation,” describes the key components that make up the
Centrify DirectControl architecture and how these components
provide authentication services.
Chapter 3, “Planning the deployment of Centrify
DirectControl,” provides information to assist Active Directory
administrators in planning a deployment of Centrify
DirectControl and migration to Active Directory, including
information about the permissions required to perform key
Centrify DirectControl tasks and suggestions for planning how
to use zones to suit your organization.
Chapter 4, “Installing Centrify DirectControl on Windows,”
provides step-by-step instructions for installing Centrify
DirectControl Management Tools on a Windows computer and
how to update Active Directory to get started using
DirectControl.
Chapter 5, “Installing the Centrify DirectControl Agent on
Unix,” provides step-by-step instructions for installing the
Centrify DirectControl Agent and the steps to take after
installation to get started.
Chapter 6, “Managing zones,” describes the strategies for
organizing your computers into zones, how to create new
zones, and how to manage zone properties.
Chapter 7, “Managing computers,” describes how to add Unix
computers to an Active Directory domain, how to modify
computer account properties for Unix computers, and how to
change the domain for a Unix computer.
Chapter 8, “Managing users and groups,” describes how to
define Unix-based profiles for Active Directory users and
groups and how to manage access for those accounts.
Chapter 9, “Managing group policies for Unix users and
computers,” provides an overview of group policy and describes
how to apply Centrify DirectControl group policies for Unix
users and computers.
Chapter 10, “Managing licenses,” describes how to view and
update Centrify DirectControl license keys.
Chapter 11, “Importing information from NIS maps or Unix
files,” describes how to import existing users and groups from
About this guide 11

Using this guide
an NIS domain or Unix configuration files into Active

Directory.
Chapter 12, “Using the DirectControl Information Service for
NIS requests,” describes the Centrify DirectControl Network
Information Service, how to configure computers and devices
to send NIS client requests to the DirectControl Network
Information Service, and how to manage NIS maps in the
Centrify DirectControl Administrator Console.
Chapter 13, “Running reports,” describes how to generate,
filter, and export information about Unix users, groups,
computers, and applications using Centrify DirectControl
reports.
Chapter 14, “Troubleshooting authentication and
authorization,” describes how to use diagnostic tools and log
files to retrieve information about the operation of Centrify
DirectControl.
Appendix A, “Using Centrify DirectControl Unix commands,”
provides reference information for the Centrify DirectControl
command line programs.
Appendix B, “Customizing Centrify DirectControl
configuration options,” describes the Centrify DirectControl
configuration file and how to customize its parameters.
Appendix C, “Installing an agent software package manually,”
provides platform-specific installation instructions for installing
the Centrify DirectControl Agent directly on a computer
without using the Centrify DirectControl installation script.
Appendix D, “Setting the ports for Centrify DirectControl,”
provides a summary of the port requirements for Centrify
DirectControl.
In addition to these chapters, an index is provided for your
reference.
Conventions used in this guide
The following conventions are used in this guide:
Fixed-width font is used for sample code, program names,
program output, file names, and commands that you type at the
command line. When italicized, the fixed-width font is used
to indicate variables. In addition, in command line reference
information, square brackets ([ ]) indicate optional arguments.
Bold text is used to emphasize commands, buttons, or user
interface text, and to introduce new terms.
Italics are used for book titles and to emphasize specific words or
terms.
For simplicity, Unix is used generally in this guide to refer to all
supported versions of the UNIX, Linux, and Macintosh OS X
operating systems unless otherwise noted.
The variable release is used in place of the specific release
number in the file names for individual Centrify DirectControl
software packages. For example,
centrifydc-release-sol8-sparc-local.tgz in this guide refers to the
specific release of the Centrify DirectControl Agent for Solaris

on SPARC available on the Centrify DirectControl CD or in a
Centrify DirectControl download package. On the CD or in the
download package, the file name indicates the Centrify
DirectControl version number. For example, if the software
package installs Centrify DirectControl version number 3.0.0,
the full file name is centrifydc-3.0.0-sol8-sparc-local.tgz.
About this guide 13

Using online help
Using online help

Centrify DirectControl provides task-based, reference, and
context-sensitive online help.
To access task-based help or search for help topics, click Help on
the right-click menu in the Centrify DirectControl Administrator
Console. To view context-sensitive help within dialog boxes, press
F1.
In addition, Centrify DirectControl documentation is available in
searchable Adobe Portable Document Format (PDF).
Where to go for more information

The Centrify DirectControl documentation set includes several
sources of information. Depending on your interests, you may
want to explore some or all of these sources further:
Centrify DirectControl Release Notes provides the most up-to-date
information about the current release, including system
requirements and supported platforms, and any additional
information, specific to this release, that may not be included in
other Centrify DirectControl documentation.
Centrify DirectControl Quick Start provides a brief summary of the
steps for installing Centrify DirectControl and getting started
so you can begin working with the product right away. All of the
topics and steps covered in the Quick Start are covered in greater
detail in this Administrator’s Guide.
Evaluation Guide provides information to help you set up an
evaluation environment and use Centrify DirectControl to test
typical authentication and authorization scenarios, such as
resetting user passwords for Unix computers, preventing a user
from accessing unauthorized Unix computers, or enforcing
specific lockout policies when users attempt to log on to Unix
computers using Centrify DirectControl.
Administrator’s Guide provides installation, administrative, and
reference information to help you install, deploy, customize,
and use Centrify DirectControl to manage Unix computers,
users, and groups through Active Directory.
Centrify DirectControl Authentication Guide for Apache describes
how to use Centrify DirectControl with Apache Web servers
and applications to provide authentication and authorization
services through Active Directory. If you are using Centrify
DirectControl with Apache, you should refer to this
supplemental documentation for details about how to configure
your Apache server to use Centrify DirectControl and Active
Directory.
Centrify DirectControl Authentication Guide for Java Applications
describes how to use Centrify DirectControl with J2EE
applications to provide authentication and authorization services
through Active Directory. If you are using Centrify
DirectControl with Java servlets, such as Tomcat, JBoss,
WebLogic, or WebSphere, you should refer to this
supplemental documentation for details about how to configure
your applications to use Centrify DirectControl and Active
Directory.
Individual Unix man pages for command reference information
for Centrify DirectControl Unix command line programs.
In addition to the Centrify DirectControl documentation, you may
want to consult the documentation for your Windows, Linux,
Unix, or Mac OS X operating system, or the documentation for
Microsoft Active Directory. This information can help you get the
most out of Centrify DirectControl.
About this guide 15

Contacting Centrify
Contacting Centrify
If you have questions or comments, we look forward to hearing
from you. For information about contacting Centrify with
questions or suggestions, visit our Web site at
www.centrify.com. From the Web site, you can get the latest
news and information about Centrify products, support, services,
and upcoming events. For information about purchasing or
evaluating Centrify products, send email to info@centrify.com.
Chapter 1
Introduction
This chapter provides an introduction to identity, access, and

configuration management and to the Centrify DirectControl
suite. It includes an overview of Centrify DirectControl features
and benefits.
The following topics are covered:
Understanding identity and access management
Why integrate with Active Directory?
What is the Centrify DirectControl solution?
What can you do after you deploy DirectControl?
Understanding identity and access management

For most organizations, it is critical to control access to computer
and application resources to prevent disruption of service, data
tampering, or security breaches. Managing who has access
efficiently and securely is especially difficult in heterogeneous
environments that may include a combination of Windows, Linux,
UNIX, and Mac OS X servers and workstations.
In cross-platform environments, securing access to computers and
applications typically involves managing multiple identity stores
with multiple authentication mechanisms. As the following figure
suggests, there are many authentication mechanisms available for
17
Unix and Linux systems, but they are typically isolated from each
other and managed separately.
Local accounts stored in NIS and NIS+ servers Kerberos realms and LDAP authentication for
local files on individual and account maps Key Distribution Center LDAP transactions
Unix servers and provide a central provide authentication
workstations repository for Unix for some users and
accounts services
Unix and Linux
computers
Windows computers Active Directory forests

with Kerberos
authentication and
LDAP directory service
Users who have access to more than one application or computer

platform often have multiple login accounts with conflicting user
name or password policy requirements. In addition, individual
applications and services may use any of these standard mechanisms
or have their own specialized authentication method.
Because managing user accounts and access using all of these
different mechanisms across an enterprise is impractical, Centrify
DirectControl provides a way to centralize and simplify the
management of user accounts and access to computers and
applications through Active Directory.

Many organizations already have a significant investment in their
Windows infrastructure, with Windows workstations often used as
desktop systems and Windows servers handling critical business
services such as messaging or database transactions. For Windows
2000, Windows XP, and Windows Server 2003, Active Directory
is the core technology for managing users, computers, and other
resources, and, therefore, is a requirement for any organization
that manages Windows resources.
In addition to being a key component of the organization’s
infrastructure, Active Directory provides a complete set of tools
for authentication, authorization, and directory service, making it
an ideal candidate for managing user accounts and access to
computer resources. By extending Active Directory to manage
Linux and Unix computers, Centrify DirectControl provides
administrators with a comprehensive identity and access
management solution while reducing administrative complexity
and overhead.

As the previous section suggests, the Centrify DirectControl
delivers secure access control and centralized identity management
by integrating UNIX, Linux, and Mac OS X servers and
workstations, and J2EE and Web platforms with Microsoft Active
Directory.
Through the Centrify DirectControl Agent, UNIX, Linux, and
Mac OS X servers and workstations can become part of an Active
Directory domain and act as Active Directory clients. Once part of
a domain, you can secure those systems using the same
authentication, access control, and group policy services you
deploy for Windows computers. Additional modules work with the
Centrify DirectControl Agent to provide services such as single
sign-on for Web applications and Samba integration. The Centrify
DirectControl Management Tools provide an Administrator
Console, extensions for Active Directory Users and Computers,
out-of-the-box reporting, and account migration tools.
Chapter 1 • Introduction 19
With the Centrify DirectControl suite, organizations with diverse

IT environments can leverage their investment in Active Directory
to:
Move to a central directory with a single point of administration
for user accounts and security policy.
Use Centrify DirectControl Zones to provide secure,
granular access control and delegated administration.
Extend Web single sign-on to internal end-users and external
business partners and customers.
Simplify compliance with regulatory requirements.
Deploy quickly without intrusive changes to the existing
infrastructure.
Moving to a central directory

By consolidating user accounts in Active Directory, organizations
can improve IT efficiency and move toward a more secure,
connected infrastructure for their heterogeneous environment.
Using DirectControl enables them to:
Strengthen security by consolidating user accounts into Active
Directory, making is easy for IT managers to disable the
accounts of departing employees, and locate and eliminate
security risks posed by orphan accounts.
Reduce infrastructure costs by eliminating redundant identity
stores, including legacy directories, un-secured NIS servers,
dedicated application databases and locally managed
/etc/passwd files.
Streamline operations by standardizing on a single set of Active

Directory-based tools, administrative training, and in-house
processes for account provisioning, maintenance, and other
tasks.
Establish consistent password policies across a heterogeneous
environment by enforcing Active Directory’s rules for password
complexity and expiration for all users regardless of where they
log in.
Enforce consistent security and configuration policies across
UNIX, Linux, and Mac OS X servers and workstations by
adding Centrify DirectControl group policy templates for
computer- and user-based configuration settings to Windows
Group Policy Objects.
Improve productivity and satisfaction for end-users, who now
have only one password to remember, and fewer Help Desk
calls to reset passwords or update user accounts.
Using Centrify DirectControl Zones for granular control

With its patent-pending zone technology, Centrify DirectControl
delivers the granular access control that real-world enterprises
need to securely manage heterogeneous environments. With
DirectControl, IT managers can:
Segregate logical collections of UNIX, Linux, or Mac OS X
computers into Centrify DirectControl Zones within Active
Directory. Computers can be organized by department,
geography, function, system type, or in any other grouping that
makes sense for a particular organization.
Use Active Directory’s role-based access model to allow users
and groups to log on only to the systems in the zones for which
they are authorized.
Grant system administrators the administrative privileges they
need only on the zones where there are computers they need to
manage without elevating their privileges for other computers
or zones.
Enforce consistent security and configuration policies that are
specific to the computers within a zone.
Extending single sign-on for web applications

Centrify DirectControl provides Active Directory-based single
sign-on for intranet and extranet Web applications running on
Apache and popular J2EE servers. Centrify DirectControl and the
Apache or J2EE add-on module provides:
Active Directory-based single sign-on (SSO) through Kerberos
and LDAP for end-users accessing intranet applications.
Federated identity authentication through Microsoft Active
Directory Federation Services (ADFS) for business-to-business
and business-to-customer extranet web applications.
Support for popular Web application servers running on UNIX,
Linux, or Windows.
Mapping between Active Directory users and groups and Web
application roles to leverage the existing Active Directory
infrastructure.
Simplify compliance with regulatory requirements

Centrify DirectControl simplifies the administrative, reporting,
and auditing tasks brought on by Sarbanes-Oxley, PCI, HIPPA and
other government and industry regulations. The combination of
Active Directory and Centrify DirectControl provides the
following benefits:
IT managers can reliably manage user accounts, set access
controls, and enforce security policies across the enterprise
from a single point of administration.
Zone-based access controls enable IT managers to limit
administrative rights and end-user access to sensitive systems,
and the Centrify DirectControl Administrator Console makes it
easy for IT managers to view and change zone-based access
controls.
Out-of-the box reports can be used to satisfy auditing
requirements and can identify the computers any specific user
can access, and which users can access any specific computer or
application.
By extending Active Directory’s password requirements and
Group Policy features to UNIX, Linux, and Mac OS X servers
and workstations, Centrify DirectControl enables IT managers
to enforce consistent, enterprise-wide security policies in a
manner that can be verified by auditors.
Centrify DirectControl ensures activity on UNIX, Linux, and
Mac OS servers and workstations is written to the proper
Active Directory logs, providing an audit trail for verifying
system access.
Deploying without changes to existing infrastructure

Centrify DirectControl’s support for open standards and its unified
architecture make it easy to deploy without making changes to your
existing Active Directory or network infrastructure. Centrify
DirectControl offers IT managers the following benefits:
Centrify DirectControl does not install any software on domain
controllers, and it does not require any changes to the Active
Directory schema to store UNIX identity data.
Centrify DirectControl supports the native Active Directory
schema, the Microsoft Services for UNIX (SFU) schema
extension, and the RFC 2307 Active Directory schema
introduced with Windows Server 2003 R2.
Centrify DirectControl can map multiple UNIX identities to a
given Active Directory account, and IT managers can access this
UNIX data in Active Directory using ADSI or LDAP
commands.
Centrify DirectControl’s unified architecture delivers identity
management, access control, and policy enforcement through a
core Centrify DirectControl Agent. Additional modules snap in
to this base agent to provide services such as SSO for Web

applications or Samba integration.
Centrify accelerates an organization’s productivity by offering
free downloads of Open Source tools such as OpenSSH and
PuTTY, which have been optimized to work seamlessly with
Active Directory through Centrify DirectControl.

Once the Centrify DirectControl Agent is deployed on a server or
workstation, that computer is considered a Centrify
DirectControl managed system.
When a computer is managed by Centrify DirectControl, an
administrator with the proper permissions can perform the
following common tasks:
Specify which Active Directory users and groups can log on to a
specific Unix computer or group of computers.
Control user access to Unix computers across the one or more
Active Directory forests, regardless of the organizational
structure you use and where users are defined in that structure.
Map local Unix accounts, such as the root user, to Active
Directory accounts for centralized control over the passwords,
or set specific local Unix accounts to be authenticated locally
rather than through Active Directory.
Define zones and zone properties and delegate the rights
necessary to manage Unix computer, user, and group accounts
in any zones to other users, as needed.
Configure and apply group policies for Unix computers and
users.
When a computer is managed by Centrify DirectControl,
authorized users can perform the following common tasks:
Log on to the Unix shell or desktop program and use Unix
programs and services such as telnet, ssh, and ftp.
Log on to a computer that is disconnected from the network or
unable to access Active Directory, if they have successfully
logged on and been authenticated by Active Directory
previously.
Manage their Active Directory passwords directly from the
Unix command line, provided they can connect to Active
Directory.
Chapter 2
About the Centrify DirectControl

architecture and operation
This chapter provides an overview of the Centrify DirectControl
architecture and discusses the operations associated with each of
the Centrify DirectControl components.
Understanding the integration of Windows and Unix
Understanding DirectControl Management Tools
Understanding Centrify DirectControl Zones
Understanding Centrify DirectControl Agents
Understanding the log-on process
Summary of how DirectControl works

Because the Centrify DirectControl suite provides an integration
layer between Windows and other operating environments, it
consists of the following primary components:
In the Windows environment, you need to install the Centrify
DirectControl Management Tools on a computer from
which you can access Active Directory. The Centrify
DirectControl Management Tools include required and optional
components for working with Unix-specific properties in
Active Directory, including the Centrify DirectControl
Administrator Console and Centrify DirectControl properties,
called the Centrify Profile, for Active Directory Users and
Computers.
27
On each server or workstation to be integrated into Active

Directory, you need to install the Centrify DirectControl
Agent. With the Centrify DirectControl Agent, when a Unix
computer joins the Active Directory domain, that computer
essentially becomes an Active Directory client for
authentication, authorization, policy management, and
directory services. Operationally, the interaction between the
Centrify DirectControl Agent and Active Directory is similar to
the interaction between a Windows XP client and its Active
Directory domain controller.
The following figure provides a simplified view of the integration
between Windows and Unix through Centrify DirectControl.
Centrify DirectControl Management Tools
Active Directory Users and Computers: Centrify Profile
Centrify DirectControl Administrator Console
Windows servers and workstations
Active Directory user Centrify DirectControl Agent

Account: chris Package
Password: &tiger1
UNIX and Linux servers and workstations
Before you can centrally manage access across different platforms

using Microsoft Active Directory, you need to:
Prepare the Active Directory environment by installing the
Centrify DirectControl Management Tools on at least one
Windows computer.
Ensure each Unix, Linux, or Mac OS computer can
communicate with an Active Directory domain controller to
present valid credentials for authentication. To handle this
communication, you need to install the Centrify DirectControl
Agent and join an Active Directory domain.
Use Active Directory and the Centrify DirectControl
Management Tools to enable and manage access and
authorization for users and groups who need to log on to or use
Unix, Linux, and Mac OS X computers.
The next sections provide a more detailed discussion of the
Centrify DirectControl Management Tools and Centrify
DirectControl Agent, including an overview of how Centrify
DirectControl zones are used, and a summary of what happens
when a user logs on to a Unix computer that has joined the Active
Directory domain.

As discussed in “Understanding the integration of Windows and
Unix” on page 27, the components you install on Windows are
collectively referred to as the Centrify DirectControl Management
Tools. The Centrify DirectControl Management Tools include both
required and optional components as follows:
The Centrify DirectControl Administrator Console is
required to be installed on at least one computer that can access
domains in Active Directory. The Centrify DirectControl
Administrator Console provides a central location for managing
Unix users, groups, and computers and performing
administrative tasks, such as importing accounts, running
reports, and analyzing account information.
The Centrify DirectControl property extensions for
Active Directory can be installed on any domain computer in
the forest. The first time you start the Centrify DirectControl
Administrator Console, a Setup Wizard guides you through the
steps for configuring Active Directory to store Unix-specific
attributes without modifying the Active Directory schema of
the forest.
Chapter 2 • About the Centrify DirectControl architecture and operation 29

The documentation, release notes, and online help for

the Centrify DirectControl Administrator Console are optional
and can be installed on any computer.
The Centrify DirectControl Extension for NIS Maps is
optional and can be installed on at least one computer if you
want to import and manage NIS maps, such as netgroup and
auto.master, in Active Directory.
The Centrify DirectControl Administrative Templates

for Group Policy is optional and can be installed on at least one
computer where the Group Policy Object Editor is available.
The following figure provides a simplified view of the architecture.
Windows environment Unix environment
DirectControl DirectControl Property

Administrator Console Extensions Centrify DirectControl Agents
adclient
adclient
Active Directory Domain Controller
adclient
About the Centrify DirectControl Administrator Console

The primary way you create and manage Unix users, groups,
computers, Centrify DirectControl zones and Centrify
DirectControl zone properties is through the Centrify
DirectControl Administrator Console. The Centrify DirectControl
Administrator Console is a Microsoft Management Console
(MMC) snap-in that allows you to centrally manage all of the
Centrify DirectControl information in the enterprise.
You can use the Centrify DirectControl Administrator Console to:

Manage access to all of your Unix, Linux, and Mac OS X
computers.
Set and modify user and group properties for all of your Unix,
Linux, and Mac OS X users and groups.
Create and manage Centrify DirectControl zones and zone
properties to simplify the process of giving users access to
specific computers and migrating Unix user accounts to Active
Directory.
Add Active Directory users and groups to Centrify
DirectControl zones.
Import user and group information from local password and
groups files or from NIS and NIS+ servers.
Import and maintain network information from NIS maps such
as netgroup, auto.master, and automount or create custom
NIS maps.

Generate and view reports describing Unix users, groups,

computers, and applications you have enabled for access
through Centrify DirectControl.
View and manage Centrify DirectControl licenses for
computers and applications.
For example, with the Centrify DirectControl Administrator
Console you can view the users with permission to access Unix
computers in different zones much as you would view Windows
users in a domain:
About the Centrify Profile

Once you have updated the Active Directory forest, Unix-specific
properties are displayed on the Centrify Profile tab when you view
the properties for a user, group, or computer in the Centrify
DirectControl Administrator Console or through Active Directory
Users and Computers, making the user experience consistent
whether you manage Windows systems, Unix systems, or both.
Understanding Centrify DirectControl Zones
One of the most important aspects of managing Unix, Linux, and
Mac OS X systems through the Centrify DirectControl
Administrator Console is the ability to organize computers and
user’s access to those computers using zones.
A Centrify DirectControl zone is similar to an Active Directory
domain or an NIS domain. Zones allow you to organize the
computers in your organization in meaningful ways to simplify
system management and the migration of account information
from existing local files, NIS databases, LDAP servers, and other
sources to Active Directory.
How you use zones will depend primarily on the needs of your
organization. In some organizations, a single default zone is
sufficient. In other organizations, using multiple zones may be a
necessity. In general, you use zones in one of two ways:
To group computers with similar properties and
requirements. For example, you may want to create one zone
for all of your Red Hat Linux workstations and another zone for
all of your Sun Solaris Unix servers because the users of the
Linux workstations prefer a different login shell, belong to a
different functional group in the organization, or have different
administrative needs than the users of the Solaris Unix servers.
To separate computers with conflicting properties
and requirements. For example, you may want to create
separate zones when a single user has multiple conflicting
identities on multiple computers.
In large organizations, Centrify DirectControl zones are especially
useful for migrating users and computers from NIS, NIS+, local
files, or LDAP to Active Directory. Using zones, administrators can
migrate existing user accounts to Active Directory users without
having to ensure that all Unix UIDs are unique throughout the
entire enterprise. Because there’s no need to rationalize the UIDs,
zones enable you to migrate the existing users quickly and easily

with minimal advance planning or impact to your existing

infrastructure. You can also use zones to organize computers along
departmental, geographical, or functional lines to better manage
access control and delegate administrative tasks. With Centrify
DirectControl zones, you can roll out Centrify DirectControl to
the user community using whatever strategy works best for your
organization.
Although zones can provide flexibility for managing user accounts
and computer access, Centrify DirectControl does not require you
to set up and use multiple zones. Instead, when you start the
Centrify DirectControl Administrator Console for the first time, a
Setup Wizard guides you through the configuration of a default
zone. You can use this single default zone as you add computers to
the domain for as long as it is practical to do so. You only need to be
concerned with planning and populating additional zones if you
determine multiple zones would be useful for your organization.
You can then create the additional Centrify DirectControl zones
when and if you need them.
For more information about planning and using Centrify
DirectControl zones, see “Using the Centrify DirectControl Setup
Wizard” on page 129.

The Centrify DirectControl Agent makes a Unix, Linux, or
Mac OS X computer look and behave like a Windows computer to
Active Directory. From a high-level view, the Centrify
DirectControl Agent performs the following key tasks:
Joins Unix or Linux computers to an Active Directory domain.
Communicates with Active Directory to authenticate users
logging on to the Unix or Linux computer, and caches
credentials for offline access.
Enforces Active Directory authentication and password policies.
Extends Active Directory group policies to manage the
configuration of Unix users and computers.
Provides a Kerberos environment so that existing Kerberos
applications automatically work transparently with Active
Directory.
Although the individual agents you install are platform-specific, the
Centrify DirectControl Agent is a tightly integrated a suite of
services that work together to ensure seamless operation between
existing Unix services and applications and Active Directory
authentication and authorization.
The following figure provides a closer look at the services provided
through the Centrify DirectControl Agent:
Unix infrastructure Apache server and Java/J2EE Kerberized
(login, ftp, ssh...) applications applications applications
Centrify Centrify Centrify Apache Centrify Centrify Centrify

CLI NSS PAM Module SDK JAAS SPNEGO
Centrify DirectControl Service Library
Centrify DirectControl
daemon
Kerberos cache, keytab
Centrify DirectControl Agent and configuration file
Offline credentials
and search results
As this figure suggests, the Centrify DirectControl Agent includes

the following core components:
The Centrify DirectControl daemon (adclient). The
adclient daemon handles all of the authentication,
authorization, and policy management interaction with Active
Directory and passes valid credentials along to the Unix shell
programs or Web applications that need this information.

The Centrify DirectControl Pluggable Authentication

Module, pam_centrifydc, enables any PAM-enabled
program, such as ftpd, telnetd, login, and sshd, to
authenticate using Active Directory.
The Centrify DirectControl NSS module updates the
nsswitch.conf to use the Centrify DirectControl daemon to
access information that’s stored in Active Directory through
LDAP. This module enables standard operating system look-up
services to look up and validate information using Active
Directory.
The Centrify DirectControl command line programs
(CLI) enable you to perform common administrative tasks,
such as join and leave the domain, change user passwords, and
collect diagnostic information from the Unix command
prompt. These command line programs can be used
interactively or within scripts to automate tasks.
The Centrify DirectControl Kerberos environment
provides a Kerberos configuration file and krb5.keytab file to
enable your Kerberized applications to authenticate through
Active Directory.
The Centrify DirectControl local cache stores user
credentials and other information for offline access and network
efficiency.
In addition to these core components, the Centrify DirectControl
Agent can also include the following add-on modules:
The Centrify DirectControl libraries for Apache,
Tomcat, JBoss, and WebLogic plug in to the native
authentication mechanisms for each Web server to enable you
to configure Web applications to use Active Directory for
authentication.
The Centrify DirectControl Network Information
Service (adnisd). The Centrify DirectControl Network
Information Service is a separate service that works in
conjunction with the Centrify DirectControl daemon to enable
you to store NIS maps in Active Directory and publish that
information to NIS clients through Centrify DirectControl.
Optional utilities and programs, such as updated Kerberos or
the OpenLDAP commands, that have been optimized to work
with Active Directory.
Understanding the activities of the daemon (adclient)

The most important element in the Centrify DirectControl Agent
is the Centrify DirectControl daemon, adclient, and its
service library that exposes the daemon’s functionality to all of
the other modules.
The Centrify DirectControl daemon runs as a single trusted service
and is automatically started when the system is first booted. It
handles all of the direct communication with Active Directory and
manages all of the operations provided through the other services.
The adclient daemon performs several key tasks of the Centrify
DirectControl Agent, including the following:
Locates the appropriate domain controllers for the local Unix,
Linux, or Mac OS X computer based on the Active Directory
forest and site topology published through the Windows DNS
server. If a domain controller becomes unavailable, the
adclient daemon automatically locates the next available
domain controller to ensure uninterrupted service.
Provides Active Directory with account credentials that verify
the computer is a valid member of the domain.
Delivers and stores user credentials so that users can be
authenticated by Active Directory and, once authenticated, can
sign on even if the computer is disconnected from the network
for mobile access or if Active Directory is unavailable.

Caches query responses and other information, including

positive and negative search results, to reduce network traffic
and the number of connections to Active Directory and to
ensure users can work uninterrupted and start new application
sessions using their login credentials. The cache and all
communication with Active Directory is encrypted to ensure
security. No communication is in clear text.
Creates and maintains the Kerberos configuration and service
ticket files to allow existing Kerberos-enabled applications to
work with Active Directory without any manual configuration.
Synchronizes the local computer’s time with the clock
maintained by Active Directory to ensure the timestamp on
Kerberos tickets issued by the KDC are within a valid range.
Resets the password for the local computer account in Active
Directory at a regular interval to maintain security for the
account’s credentials.
Provides all the authentication, authorization, and directory
look-up services retrieved from Active Directory to the other
Centrify DirectControl Agent services, for example, to the
PAM or Apache modules.
To perform these tasks, the Centrify DirectControl daemon and all
of the other Centrify DirectControl Agent services rely on an
internal service library of functions that enable the communication
with Active Directory and perform Active Directory operations.
This service library is not exposed directly for external use but is
accessed internally through programming interfaces.
Understanding Centrify DirectControl for PAM services

Pluggable Authentication Modules (PAM) are a common
mechanism for configuring authentication and authorization used
by many Unix programs and applications. If a program or
application uses PAM for authentication and authorization, the
rules for authenticating the user are configured in either the PAM
configuration file, /etc/pam.conf, or, more commonly, in
application-specific files in the /etc/pam.d directory.
Centrify DirectControl includes a customized Pluggable
Authentication Module (pam_centrifydc) that enables any
application that uses PAM, such as ftpd, telnetd, login, and
Apache, to authenticate users through Active Directory. When you
join a domain, the pam_centrifydc module is automatically placed
first in the PAM stack in system-auth, so that it takes precedence
over other authentication modules.
The pam_centrifydc module is configured to work with adclient
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
services provided through the pam_centrifydc module can be
customized locally on a computer, modified through Active
Directory group policy, or configured through a combination of
local and Active Directory settings.
Working in conjunction with the Centrify DirectControl daemon,
the pam_centrifydc module provides the following services for
PAM-enabled programs and applications:
Verifies the current user name and password for a session are a
valid user name and password in Active Directory.
Requests the PAM-enabled application to prompt for a
password when appropriate and verifies whether the
application-provided user name and password are valid in Active
Directory.
Checks whether the user’s password has expired in Active
Directory. If the password has expired, the pam_centrifydc
module prompts the user to change the password, and forwards
the new password to the Centrify DirectControl daemon,
which communicates the change to Active Directory.
Checks policy settings in the
/etc/centrifydc/centrifydc.conf file to determine whether

any access control policies are applied. For example, the

pam_centrifydc module uses the information in the
centrifydc.conf file to determine whether a local user
attempting to log on is mapped to an Active Directory account,
whether specific users or groups have been granted or denied
permission to log on to the local computer, or whether Active
Directory authentication should be ignored for a specific user or
group.
Creates the local home directory and default user profile files
for new users. The pam_centrifydc module uses skeleton files
to set up the user environment when new Active Directory
users log on to a Unix computer for the first time.
Most of these tasks are performed during a user login session as a
series of requests and replies from the pam_centrifydc module to
Active Directory through the adclient daemon for those programs
and applications that are configured to use PAM. Because PAM is
the most common authentication service used by Unix programs
and applications, the pam_centrifydc module is the most
commonly used for a typical log-on session. For a more detailed
description of a typical log-on process, see “Understanding the
log-on process” on page 43.
Understanding Centrify DirectControl for NSS

The Name Service Switch (NSS) provides a mechanism for
identifying sources of network information a computer should use,
such as local password and group files, NIS maps, NIS+ tables,
LDAP, and DNS, and the order in which these sources should be
consulted when looking up users, groups, host names, and other
information.
When you join a domain, the NSS configuration file,
nsswitch.conf, is automatically updated to use the Centrify
DirectControl NSS module first. Using the Centrify DirectControl
daemon and the service library, the Centrify DirectControl NSS
module accesses network information that’s stored in Active
Directory through LDAP.
When a Unix program or applications needs to look up
information, it checks the nsswitch.conf file and is directed to use
the nss_centrifydc module. The nss_centrifydc module directs
the request to Active Directory through the adclient daemon. The
adclient provides the information retrieved from Active
Directory, then caches responses locally to ensure faster
performance, reduce network traffic, and allow for disconnected
operation. The cache is encrypted to ensure the security of the
responses.
Understanding the Kerberos configuration

Kerberos is a network authentication protocol for client/server
applications that uses encrypted tickets passed through a central
Key Distribution Center to verify the identity of a user or service
requesting access. Because Kerberos is an industry standard and a
secure network authentication mechanism, you may already have
Unix programs and services that are configured to use it. To allow
those existing Kerberized applications to work with Active
Directory without manual configuration, the adclient daemon
automatically creates and maintains the Kerberos configuration file,
krb5.conf, and the krb5.keytab service ticket file to point
Kerberos-enabled services and applications to the Key Distribution
Center (KDC) in Active Directory.
The configuration file is initially created using information
collected by probing 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. Although the adclient daemon can
automatically update the file as needed, it does not destroy existing
configuration entries that you may have added by hand. Because of
this, Centrify DirectControl works seamlessly with your existing
Kerberos-enabled applications.

Understanding authentication for Web applications

In most cases, deployed Web applications provide some type of
native authentication and authorization module for Web developers
to implement. With Centrify DirectControl, you can extend these
native interfaces to seamlessly connect to Active Directory for
authentication and authorization, and, depending on the
configuration of the Web applications and the Web browsers that
access those applications, to provide transparent Single Sign-On
capability.
Much in the same way it supports authentication for basic Unix
services, such as login and telnet, the Centrify DirectControl
Agent provides authentication and authorization services to Web
servers and applications through server-specific plug-in modules.
These modules work in conjunction with the adclient daemon and
service library to provide silent and prompted authentication and
authorization when users access Web applications created in
Apache, Tomcat, JBoss, or WebLogic environments.
Because each Web application platform has its own development
environment and native authentication mechanisms, the specific
authentication mechanisms and methods supported can vary by
server platform. For example, 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 provides a customized JAAS realm for Tomcat and
JBoss applications to use Active Directory for authentication when
an application is configured to use the BASIC or FORM authentication
method.
For more information about configuring authentication services for
Apache, see the Centrify DirectControl Authentication Guide for Apache.
For more information about configuring authentication services for
Tomcat, JBoss, WebLogic, and other Java-based applications, see
the Centrify DirectControl Authentication Guide for Java Applications.
The Centrify DirectControl Agent components work together to
identify and authenticate the user any time a user logs on to a
computer using any Unix command that requires the user to enter
credentials. The following steps summarize the interaction to help
you understand the process for a typical log on request. The
process is similar, though not identical, for Unix commands that
need to get information about the current user or group.
Note The following steps focus on the operation of the Centrify
DirectControl Agent rather than the interaction between the
Centrify DirectControl Agent and Active Directory. In addition,
these steps are intended to provide a general understanding of the
operations performed through the Centrify DirectControl Agent
and do not provide a detailed analysis of a typical log on session.
When a user starts the Unix computer and is prompted to log in,
the following takes place:
1 The user enters a local Unix user name or an Active Directory
user name.
2 The Unix login process reads the PAM configuration file,
/etc/pam.conf, and determines that it should use the Centrify
DirectControl PAM service, pam_centrifydc, for
identification.
3 The Unix login process passes the login request and the user
name to the Centrify DirectControl PAM service for processing.
4 The pam_centrifydc service checks the pam.allow.override
parameter in the Centrify DirectControl configuration file to see
if the user name entered is an account that should be
authenticated locally.
If the user should be authenticated locally, the
pam_centrifydc service passes the login request to the next
PAM module specified in the PAM configuration file, for
example, to the local configuration file etc/passwd.

If the user is not an override account, the pam_centrifydc

service continues with the login request and checks to see if
the adclient daemon is running, then passes the login request
and user name to the adclient daemon.
5 The adclient daemon connects to Active Directory and queries
the Active Directory domain controller to determine whether
the user name included in the request is a Centrify
DirectControl user who has access to computers in the current
computer’s zone.
If the adclient daemon is unable to connect to Active
Directory, it queries the local cache to determine whether the
user name has been successfully authenticated before.
If the user account does not have access to computers in the
current zone or can’t be found in Active Directory or the local
cache, the adclient daemon checks the Centrify
DirectControl configuration file to see if the user name
specified is mapped to a different Active Directory user
account with the adclient.mapuser.username parameter.
If the user name specified is mapped to another Active
Directory account in the configuration file, the adclient
daemon queries the Active Directory domain controller or
local cache to determine whether the mapped user name has
access to computers in the current computer’s zone.
6 If the user has a Unix profile for the current zone, the adclient
daemon receives the zone-specific information for the user, such
as the user’s UID, the user’s local Unix name, the user’s global
Active Directory user name, the groups of which the user is a
member, the user’s home directory, and the user’s default shell.
7 The adclient daemon queries through the nss_centrifydc
service to determine whether there’s another user currently
logged in with same UID.
If there is a potential conflict between local user account and
the Unix profile for an Active Directory account, the adclient
daemon notifies the pam_centrifydc service of the potential
conflict.
The pam_centrifydc service checks the Centrify
DirectControl configuration file to determine to issue a
warning, ignore the conflict, or prevent the user from logging
on.
If the login continues, the pam_centrifydc service asks the
Unix login process for a password.
8 The Unix login process prompts the user to provide a password
and returns the password the user enters to the pam_centrifydc
service.
9 The pam_centrifydc service checks the pam.allow.users and
pam.deny.users parameters in the Centrify DirectControl
configuration file to see if any user filtering has been specified to
allow or deny access to specific user accounts. If any user
filtering has been specified, the current user is either allowed to
continue with the login process or denied access.
10 The pam_centrifydc service checks the pam.allow.groups and
pam.deny.groups parameters in the Centrify DirectControl
configuration file to see if any group filtering has been specified
to allow or deny access to members of specific groups. If any
group filtering has been specified, the current user is either
allowed to continue with the login process or denied access
based on group membership.
11 If the current user account is not prevented from logging on by
user or group filtering, the pam_centrifydc service queries the
adclient daemon to see if the user is authorized to log on.
12 The adclient daemon queries the Active Directory domain

controller through Kerberos to determine whether the user is
authorized to log on to the current computer at the current time.
13 The adclient daemon receives the results of its authorization
request from Active Directory and passes the reply to the
pam_centrifydc service.

14 The pam_centrifydc service does one of the following

depending on the content of the authorization reply:
If the user is not authorized to use the current computer or to
log in at the current time, the pam_centrifydc service denies
the user’s request to log on through the Unix login process.
If the user’s password has expired, the pam_centrifydc
service sends a request through the Unix login process asking
the user to change the password. After the user supplies the
password, log-in succeeds.
If the user’s password is about to expire, the pam_centrifydc
service notifies the user of impending expiration through the
Unix login process.
If the user is authorized to log on and has a current password,
the login process completes successfully. If this is the first time
the user has logged on to the computer through Centrify
DirectControl, the pam_centrifydc service creates a new
home directory on the computer in the location specified in
the Centrify DirectControl configuration file by the
parameter pam.homeskel.dir.
The following figure provides a simplified view of a typical log-on
process when using Centrify DirectControl.
Check /etc/centrifydc.conf settings for

override, allow, deny, password expiration
Check /etc/pam.conf
xxxxx
PAM-enabled pam_centrifydc xxxxx Active Directory
services xxxxx Domain Controller
Kerberos
adclient
applications
User starts a Unix log on
process using a command
such as login, telnet, ssh
Unix look-up nss_centrifydc Cached credentials
requests and search results
Check /etc/nsswitch.conf
Centrify DirectControl Agent Kerberos keytab and

configuration file

As discussed in the previous sections in this chapter, the Centrify
DirectControl suite is comprised of two main architectural
components that enable Unix users, groups, computers, and
applications to be integrated into the Active Directory
infrastructure:
The Centrify DirectControl Management Tools that enable you
to manage Unix users, groups, and computers from the
Windows environment.
The Centrify DirectControl Agent that enables the
authentication of Active Directory users to standard Unix
programs and services, including those configured to use PAM,
NSS, and Kerberos, and the authentication of Active Directory
users to Web server applications. The Centrify DirectControl
Agent also provides command line programs, so that Unix users
can update their Active Directory password or perform other

tasks using a command line interface that feels native and

appropriate for the Unix environment. Through the Centrify
DirectControl daemon and service library, the Centrify
DirectControl Agent components work together transparently
on the Unix system and connect transparently to Active
Directory for authentication of user and service credentials.
With the Centrify DirectControl Agent, the Centrify
DirectControl Management Tools, and Active Directory, you have
an integrated solution to identity and access management that
provides native operation for both Windows and Unix users and for
administrators in the cross-platform enterprise.
Now that you are familiar with both the Windows and Unix
components, you are ready to install these components on your
Windows and Unix computers and begin adding Unix, Linux, and
Mac OS computers to the Active Directory domain.
Chapter 3
Planning the deployment of Centrify

DirectControl
This chapter provides step-by-step instructions for installing
Centrify DirectControl and joining a computer to the domain.
Planning Active Directory permissions
Planning changes to the Active Directory structure
Planning to work with multiple forests
Planning how you will use zones
Planning user account migration
Planning NIS map migration

Centrify DirectControl requires some specific rights for
administrators to work with objects such as Unix users, groups,
and computers within Active Directory. As part of your
deployment planning process, you should review the rights
required to set up and manage Centrify DirectControl objects and
understand how to manually assign rights for managing Centrify
DirectControl objects, if needed.
Note At a minimum, all Centrify DirectControl actions require the
user to have generic Read permission. This permission is typically
granted to all Authenticated Users by default.
Understanding permission requirements for the Setup Wizard

In most cases, you run the Centrify DirectControl Setup Wizard to
guide you through the configuration of Active Directory for
49
Centrify DirectControl. The Setup Wizard updates Active

Directory with Centrify DirectControl objects and properties,
including some DirectControl-specific containers that are required
for proper operation.
To successfully perform these tasks, the user account that runs the
Setup Wizard must have specific rights. Because some of these
rights may be reserved for administrative accounts, other users may
not be able to perform all of the steps in the Setup Wizard.
To allow other user accounts to run the Setup Wizard, you can
manually create the appropriate container objects, then assign to
those objects only the specific permissions needed to correctly
complete the configuration of Centrify DirectControl. Users can
then use the Setup Wizard to select the appropriate container
objects and perform all of the necessary steps without being
members of an administrative group.
The following table describes the minimum rights that must be
applied to the Centrify DirectControl container objects or other
users to successfully complete the configuration of Centrify
DirectControl.
This target object Requires these permissions Applied to

Licenses container • Read All Properties This object only
• Create classStore Objects
• Modify permissions
• Write Description property This object and all
• Write displayName property child objects
Centrify DirectControl requires you to create or select at

least one parent container for license keys. By default, this
container object is:
domain/Program Data/Centrify/Licenses
You can create additional License containers, if needed,
through the Manage Licenses dialog box.
By default, all Authenticated Users have read and list
contents permission for the Licenses container and all of its
child objects. You can change these permissions if you want
to restrict access to the Centrify DirectControl Administrator
Console.
Zones container (or • Read All Properties This object only
any container used as • Create classStore Objects
a destination for a • Create container objects
new zone)
• Write displayName property This object and all
child objects
Centrify DirectControl requires you to create or select a
parent container object for creating new zones. By default,
this container object is:
domain/Program Data/Centrify/Zones
You can use other containers for zones, if needed.
Chapter 3 • Planning the deployment of Centrify DirectControl 51

This target object Requires these permissions Applied to

Private Groups • Read All Properties This object only
container • Create classStore Objects
• Modify permissions
• Write displayName property This object and all
child objects
Centrify DirectControl requires you to create or select a
parent container object for private groups if you are using
private groups in any zones. By default, this container
objects is:
domain/Program Data/Centrify/Private Groups
By default, all Authenticated Users have permission to
create group objects in the Private Groups container.
Creating Display Specifiers for Centrify DirectControl

To set up the Centrify Profile properties page in the Active
Directory Users and Computers console, you must be an
enterprise administrator or a domain administrator for the forest
root domain because adding the Centrify Profile to Active
Directory Users and Computers requires you to add Display
Specifiers to Active Directory.
If you want to provide access to the Centrify Profile in the Active
Directory Users and Computers console, an enterprise
administrator can manually define the display specifiers (under
domain/Configuration/DisplaySpecifiers/LanguageID/) for
computer, group, and user properties by modifying the
adminPropertyPages attribute with the appropriate GUID.
Note Adding the display specifiers for Centrify DirectControl

properties is an optional step you can perform manually using ADSI
Edit or by running the displayspecifier.vbs script. If you manage
all Centrify DirectControl objects through the Centrify
DirectControl Administrator Console, you do not need to perform
this task.
To use the displayspecifier.vbs script to set up the display
specifiers for Centrify DirectControl:
1 Log on using an enterprise administrator account or a domain
administrator for the forest root domain.
2 Open a Command Prompt window and change to the Centrify
DirectControl directory. For example:
cd C:\Program Files\Centrify\Centrify DirectControl
3 Run the displayspecifier.vbs script.

To manually set up the property pages in the Active Directory
Users and Computers, you need to create the following entries
using ADSI Edit, where n is the next number in the index of values
for the attribute:
For this target object Set this attribute To

computer-Display adminPropertyPages n,{DB5E4BE1-A0F0-4e6c-AD8A
displaySpecifier -B46475D727CB}
group-Display adminPropertyPages n,{0CDC9AD0-E870-483f-8D16

displaySpecifier -17EAB3B7F881}
user-Display adminPropertyPages n,{543DBFE3-317D-4493-8D00

displaySpecifier -84591E4EDCDE}
inetOrgPerson-Display adminPropertyPages n,{543DBFE3-317D-4493-8D00

-84591E4EDCDE}
In most cases, you only need to set up the display specifiers once
for the Active Directory forest. If you support multiple languages,
you can manually add the display specifiers to each language you
support. For example, if your organization supports US-English
(CN=409), Standard French (CN=40C), and Japanese (CN=411), you
would add the display specifiers to these three containers. Once
you have updated Active Directory by running the
displayspecifier.vbs script or by manually adding the display
specifiers, you can access the Centrify Profile properties using
Active Directory Users and Computers.

Registering the administrative notification handler

The administrative notification handler supports the replication
services in Active Directory to ensure data integrity in the Active
Directory forest. You can register the notification handler
automatically through the Centrify DirectControl Setup Wizard
the first time you start the Centrify DirectControl Administrator
Console, but this requires an account that is an Enterprise
Administrator or a Domain Administrator in the forest root
domain rights.
Although this step is optional, registering the administrative
notification handler helps to ensure Unix profile properties are
properly deleted if a user, group, or computer is deleted using
Active Directory Users and Computers.
If you don’t want to perform this step in the Setup Wizard, you can
manually configure the administrative notification handler using
ADSI Edit or you can choose not to register the administrative
notification handler for Centrify DirectControl. If you choose not
to register the administrative notification handler, however, you
should periodically run the Centrify DirectControl Analyze
command to check and maintain data integrity in the Active
Directory forest.
To manually set up the administrative notification handler for
Centrify DirectControl, add the following entry using ADSI Edit
under domain/Configuration/DisplaySpecifiers/LanguageID/
where n is the next number in the index of values for the attribute:
For this target object Set this attribute To

DS-UI-Default-Settings dSUIAdminNotification n,{D0D2C2AE-C143-4C81-A61C
-BE95C3C5EEDF}
Creating containers manually for Centrify DirectControl

Some organizations prefer to create and manage Active Directory
objects manually to ensure tight control over the objects and their
related attributes. For example, you may want to manually create
your own Zone or License containers so that you can manually set
specific permissions and related properties on those containers and
refine who has access to them. You can create the container objects
anywhere in the forest’s directory structure, but you must have at
least one Zone container object and at least one License container
object. If you plan to use private groups for any zone, you also need
to have at least one Private Groups container object.
Normally, you can create these objects when you run the Setup
Wizard, create a new zone, or manage licenses, but you can
manually create them prior to deployment, if desired.
Understanding permissions for the Zone Delegation Wizard

If you use the Zone Delegation Wizard to delegate administrative
tasks to specific users and groups, you are providing those users and
groups specific permissions for working with objects in Active
Directory. The following table summarizes the permissions that can
be assigned through your selections in the Zone Delegation
Wizard.
Selecting this task Grants these rights

All Permissions to perform all of the actions listed in the Zone
Delegation Wizard and described below.
When a user creates a new zone, that user is granted this
permission for the zone he created.
Change zone • List Contents on the ZoneName object container.
properties • Read All Properties on the ZoneName object container.
• Write Description property on the ZoneName object
container.
Add or remove users • List Contents on the ZoneName/Users object container.
• Read All Properties on the ZoneName/Users object
container.
• Create serviceConnectionPoint objects on the
ZoneName/Users object container.
• Delete serviceConnectionPoint objects on the
ZoneName/Users object container.


Add or remove • List Contents on the ZoneName/Groups object container.
groups • Read All Properties on the ZoneName/Groups object
container.
ZoneName/Groups object container.
• Delete serviceConnectionPoint objects on the
ZoneName/Groups object container.
Join computers • List Contents on the ZoneName/Computers object

container.
• Read All Properties on the ZoneName/Computers object
container.
ZoneName/Computers object container.
Modify users • List Contents on the ZoneName/Users object container.

• Read All Properties on the ZoneName/Users object
containers.
• Write name on the serviceConnectionPoint object.
• Write Name on the serviceConnectionPoint object.
For RFC 2307-compliant zones, modifying the user Unix
profile also requires the following rights on the
serviceConnectionPoint object of the Unix user object:
• Write uid.
• Write uidNumber.
• Write loginShell.
• Write gecos.
• Write gidNumber.
• Write unixHomeDirectory.
Modify groups • List Contents on the ZoneName/Groups object container.
• Read All Properties on the object containers.
• Write name on the serviceConnectionPoint object.
• Write Name on the serviceConnectionPoint object.
For RFC 2307-compliant zones, modifying the user Unix
profile also requires the following rights on the
serviceConnectionPoint object of the Unix group object:
• Write gidNumber.
Delete zone • List Contents on the ZoneName object container.
• Read All Properties on the ZoneName object container.
• Allow Delete on the ZoneName object container.
• Allow Delete Subtree on the ZoneName object container.
Note The permissions granted through the Zone Delegation Wizard

are a subset of the complete permissions required to perform some
tasks. For information about the complete permissions required to
perform a specific task, see the section that describes the
permissions for performing that task. For example, for information
about setting permissions for NIS maps, see “Setting rights for
working with NIS maps” on page 78.
Understanding how permissions are set

Built-in Windows groups, such as Domain Admins and Domain
Users, have default permissions, which may be customized for your
organization. In general, the administrators for the forest root
domain have broad authority to set permissions for other users and
groups, including the administrators of other domains. Therefore,
whether you can modify the permissions for specific users and
groups within your Active Directory environment will depend on
the policies of your organization.
If you have the appropriate authority, there are several ways you can
access, verify, and modify the permissions assigned to specific users
and groups. For example, you can:
Use ADSI Edit to directly modify any Active Directory
attributes.
Use Active Directory Users and Computers to set basic
or advanced permissions on any Active Directory object
through the Security tab. To display this tab, you may need to
select View > Advanced Features. For some advanced
permissions to be available in Active Directory Users and

Computers, however, your user account must have Create all

child objects or Write all properties permissions.
Run the Zone Delegation Wizard to set the appropriate
permissions for specific users or groups to perform specific
tasks within a zone.
Click Permissions when viewing Zone Properties in the
Centrify DirectControl Administrator Console to set basic or
advanced permissions on any zone object.
Click Permissions when viewing the Centrify Profile for a
user in the Centrify DirectControl Administrator Console to
set basic or advanced permissions on any user object.
For specific information about how to set permissions on Active
Directory objects and properties and how to view, modify, and
remove permissions, see your Active Directory documentation.
Setting rights to create and modify zones

To create new zones in Centrify DirectControl, your user account
must be set with the following permissions:
Select this target object To apply these permissions

Parent container for the new zone On the Object tab, select Allow to apply the
For example, the default Zones following permission to this object and all child
container or the container you objects:
created or selected in the Setup • Create Container Objects
Wizard:
domain/Program Data/Centrify/
Zones
Note The user who creates a zone by default has full control over
the zone and can delegate administrative tasks to other users and
groups through the Zone Delegation Wizard. In most cases, users
who create zone have domain administrator privileges and only the
zone owner has the appropriate rights to delegate administrative
tasks to other users.
To open an existing zone, your user account must be set with the
following permissions:

Parent container for the zone On the Object tab, select Allow to apply the
object following permission to this object:
For example, the default container • List Contents
object:
Zones
Parent container for the individual Click the Properties tab and select Allow to
zone apply the following properties to this object
For example, a ZoneName container only:
object, such as: • Read allowedAttributes
domain/Program Data/Centrify/ • Read allowedAttributesEffective
Zones/default
• Read canonicalName
• Read Description
• Read displayName
• Read name
• Read objectClass
Parent container for Users in the Click the Properties tab and select Allow to
For example: only:
domain/Program Data/Centrify/ • Read objectClass
Zones/default/Users
Parent container for Groups in the Click the Properties tab and select Allow to
For example,: only:
domain/Program Data/Centrify/ • Read objectClass
Zones/default/Groups

To modify zone properties for a Centrify DirectControl zone, your

user account must be set with the following permissions:

Parent container for an individual Click the Properties tab and select Allow to
object: • Read Name
domain/Program Data/Centrify/ • Read name
Zones/default
• Read Description
• Write Description
Note You can grant these permission to specific
users or groups by selecting the Change zone
properties task in the Zone Delegation Wizard.
To rename a zone, your user account must be set with the following
permissions:

Parent container for an individual Click the Properties tab and select Allow to
object, such as: • Write name property
domain/Program Data/Centrify/ • Write Name property
Zones/default
Note You can grant this permission to specific
users or groups by selecting the Change zone
properties task in the Zone Delegation Wizard.
To delete a Centrify DirectControl zone from Active Directory,
your user account must be set with the following permissions:

Parent container for an individual On the Object tab, select Allow to apply the
zone following properties to this object only:
For example, a ZoneName container • Delete
object, such as: • Delete Subtree
Zones/default
Click the Properties tab and select Allow to
apply the following properties to this object
only:
• Read Name
• Read name
Note You can grant this permission to specific
users or groups by selecting the Delete zone
task in the Zone Delegation Wizard.
Setting rights to join the domain

To join a Unix computer to an Active Directory domain without
predefining a computer account, your Active Directory user
account must be set with the following permissions:

Parent container object for the On the Object tab, select Allow to apply the
computer account in Centrify following permission to this object only:
DirectControl • Create serviceConnectionPoint Objects
For example, the Note You can grant this permission to specific
ZoneName/Computers container users or groups by selecting the Join
object: computers task in the Zone Delegation Wizard.
Zones/default/Computers
To join a Unix computer to an Active Directory domain and place

the computer account in a specific organizational unit (OU), the

Active Directory account used to join the domain must be set with
the following permissions:

For example, the default
ZoneName/Computers container
object:
Parent OU container object for the On the Object tab, select Allow to apply the
computer account following permission to this object only:
For example: • Create Computer Objects
domain/myOU/UnixComputers
To join a Unix computer to an Active Directory domain when you

are using a predefined computer account, your Active Directory
user account must be set with the following permissions:

For example, the default
ZoneName/Computers container
object:
Computer account object in Active On the Object tab, select Allow to apply the
Directory following permission to this object only:
For example, if the computer • Full Control
account is AJAX in the default This permission is required for enabling or
Active Directory Computers disabling a computer account.
container:
domain/Computers/AJAX
To remove a Unix computer from an Active Directory domain,
your Active Directory user account must be set with the following
permissions:

DirectControl • Delete serviceConnectionPoint Objects
For example, the If you are deleting a computer account, you
ZoneName/Computers container also need the Delete Computer Objects
object: permission.
Setting rights to list computers

To list computers, your user account must have the following
permission:

computer account in Active following permission to this object for each of
Directory the computers to be included in the list:
For example: • List Contents
domain/Computers
Parent container object for the Click the Properties tab and select Allow to
computer account in the zone apply the following properties to this object
For example, the default only:
ZoneName/Computers container • Read objectClass
object:


The serviceConnectionPoint Click the Properties tab and select Allow to
object for the computer account apply the following properties to this object for
For example, if the computer each of the computers to be included in the
account name is AJAX, select: list:
domain/Program Data/Centrify/ • Read displayName
Zones/default/Computers/AJAX
• Read keywords
then select:
serviceConnectionPoint objects • Read managedBy
• Read Name
Computer account object in Active Click the Properties tab and select Allow to
Directory apply the following properties to this object for
For example, if the computer each of the computers to be included in the
account name is AJAX: list:
domain/Computers/AJAX • Read objectClass
• Read Operating System
• Read Operating System Version
• Read userAccountControl
Setting rights to modify computer properties

To modify any computer account properties for a Unix computer,
your user account must have the following permission:

computer account in Active following permission to this object only:
Directory • List Contents
For example:
domain/Computers
object for the computer account apply the following properties to this object
For example, if the computer only:
account name is AJAX, select: • Read allowedAttributes
domain/Program Data/Centrify/ • Read allowedAttributesEffective
Zones/default/Computers/AJAX
then select: • Read displayName
serviceConnectionPoint objects • Read keywords
• Read managedBy
• Read Name
• Write keywords
Computer account object in Active Click the Properties tab and select Allow to
Directory apply the following properties to this object
For example, if the computer only:
account is AJAX in the default • Read objectGUID
Active Directory Computers • Read objectSid
container: • Read objectClass
domain/Computers/AJAX
• Read Operating System
• Read Operating System Version
If you need to change the zone for a computer account, your user
account must have the following additional permissions:

All parent container objects for Click the Properties tab and select Allow to
the original and new zones apply the following properties to this object
only:
• Read name
• Read Name
object for the computer account apply the following properties to this object
only:
• Write name
• Write Name
Note The Name property is the container name
(cn) of the serviceConnectionPoint object.


Original parent container for the On the Object tab, select Allow to apply the
computer account in the current following permission to this object only:
zone • Delete serviceConnectionPoint Objects
For example, if you are moving a Click the Properties tab and select Allow to
computer from the Finance zone apply the following properties to this object
to the Corporate zone, and you only:
use the default Computers • Read objectGUID
container, the target object would
be:
Zones/Finance/Computers
New parent container for the On the Object tab, select Allow to apply the
computer account in the new following permission to this object only:
zone • Create serviceConnectionPoint Objects
For example, if you are moving a Click the Properties tab and select Allow to
computer from the Finance zone apply the following properties to this object
to the Corporate zone, and you only:
use the default Computers • Read objectGUID
container, the target object would
be:
Zones/Corporate/Computers
Note You can set the permissions for modifying computer accounts
by clicking the Security tab when you are viewing a computer’s
properties.
Setting rights to work with user accounts

The specific objects and permissions required to work with user
accounts depend on whether the user account is associated with a
standard Active Directory security group or a private group. The
objects and permissions can also vary depending on the type of
zone the user account is associated with and the task to be
performed. In most cases, you can grant the required permissions
to specific users or groups by selecting the appropriate task in the
Zone Delegation Wizard.
Adding a user with a normal Active Directory primary group
In a standard Centrify DirectControl zone when the functional
level of the forest is Windows 2000 Server or Windows Server
2003 or a standard RFC 2307-compliant zone when hen the
functional level of the forest is Windows Server 2003, adding a
user account with a standard Active Directory security group as the
primary group to a zone requires the following permissions:

user account in Centrify following permission to this object only:
For example, if you use the default This permission is required for both standard
Users container in the Finance Centrify DirectControl zones and RFC
zone: 2307-compliant zones.
Zones/Finance/Users
For standard Centrify DirectControl zones, you
need to apply additional permissions. Click the
Properties tab and select
serviceConnectionPoint objects from the
object list, then select Allow to apply the
following properties to this object:
• Read Name
• Read name
User account object in Active Click the Properties tab and select Allow to
For example: only:
domain/Users/user_name • Read objectCategory
• Read objectGUID
• Read objectSid
individual zone apply the following properties to this object
For example, if you are adding a only:
user to the Finance zone: • Read objectGUID
domain/Program Data/Centrify/ • Write Description
Zones/Finance

Adding a user with a private primary group

To add a user account with a private group as the primary group to
a zone, your user account must have the following permissions:

user account in Centrify following permission to this object only:
For example, if you use the default This permission is required for both standard
Users container in the Finance Centrify DirectControl zones and RFC
zone: 2307-compliant zones.
Zones/Finance/Users
For standard Centrify DirectControl zones, you
need to apply additional permissions. Click the
Properties tab and select
serviceConnectionPoint objects from the
object list, then select Allow to apply the
following properties to this object:
• Read Name
• Read name
User account object in Active Click the Properties tab and select Allow to
For example: only:
domain/Users/user_name • Read objectCategory
• Read objectGUID
• Read objectSid
user to the Finance zone: • Read objectGUID
Zones/Finance
Private Group container object On the Object tab, select Allow to apply the
For example, if you use the default following permission to this object if a private
container: group does not already exist for the user:
domain/Program Data/Centrify/ • Create Group Objects
Private Groups
Parent container for groups in On the Object tab, select Allow to apply the
Centrify DirectControl following permission to this object if a private
For example, if you use the default group does not already exist for the user in the
Groups container: current zone:
domain/Program Data/Centrify/ • Create serviceConnectionPoint Objects
Modifying a user with an Active Directory primary group

In a standard Centrify DirectControl zone, modifying user account
properties for a user with a standard Active Directory security
group as the primary group requires the following permissions:

object for the user account apply the following properties to this object
For example, if the Unix user name only:
is chris: • Read allowedAttributesEffective
domain/Program Data/Centrify/ • Read objectGUID
Zones/default/Users/chris
then select • Write keywords
serviceConnectionPoint objects If you are changing the Unix user name for the
user, you need the following additional
permissions applied to this object:
• Read name
• Write name
• Write Name property

In a standard RFC 2307-compliant zone, modifying user account

properties for a user with an Active Directory security group as the
primary group requires the following permissions:

domain/Program Data/Centrify/ • Write keywords
then select • Write uid
serviceConnectionPoint objects • Write uidNumber
• Write gecos
• Write gidNumber
• Write loginShell
• Write unixHomeDirectory
Note You can set the permissions for modifying user accounts by
clicking Permissions when you are viewing the Centrify Profile
for a user.
Modifying user accounts in private groups
In a standard Centrify DirectControl zone, modifying user account
properties for a user with a private group as the primary group
requires the following permission:

then select • Write keywords
serviceConnectionPoint objects If you are changing the Unix user name for the
user, you need the following additional
• Write name
• Write Name
object for the private group apply the following properties to this object
For example, if the private group only to allow the private group name or GID to
for the user is chris: be modified:
Zones/default/Groups/chris
• Read name
then select
servicConnectionPoint objects • Write name
• Write Name
Private groups container object On the Object tab, select Allow to apply the
Private Groups

In a standard RFC 2307-compliant zone, modifying user account

properties for a user with an Active Directory security group as the
primary group requires the following permissions:

then select • Write uid
serviceConnectionPoint objects • Write uidNumber
• Write gecos
• Write gidNumber
• Write loginShell
• Write unixHomeDirectory
object for the private group apply the following properties to this object
For example, if the private group only to allow the private group GID to be
name is chris: changed:
domain/Program Data/Centrify/ • Write gidNumber
Zones/default/Groups/chris
Click the Properties tab and select Allow to
then select
serviceConnectionPoint objects
apply the following properties to this object
only to allow the private group name to be
changed:
• Write name
• Write Name
Private groups container object On the Object tab, select Allow to apply the
Private Groups
Note You can grant the required permissions to specific users or

groups for any zone by selecting the Modify users task in the Zone
Delegation Wizard.
Listing user account information
In a standard Centrify DirectControl zone, listing user account
information requires the following permissions:

object for the user account apply the following properties to this object for
For example, if the Unix user name each user included in the list:
is chris: • Read displayName
domain/Program Data/Centrify/ • Read managedBy
then select • Read objectClass
serviceConnectionPoint objects • Read Name to display the Unix name
• Read keywords to display the other Unix
attributes
In a standard RFC 2307-compliant zone, listing user account


For example, if the Unix user name each user included in the list:
is chris: • Read displayName
domain/Program Data/Centrify/ • Read keywords
then select • Read managedBy
serviceConnectionPoint objects • Read objectClass
• Read uid to display the Unix name
• Read uidNumber to display the Unix UID
• Read gidNumber to display the GID of the
user’s primary group
• Read logonShell to display the default shell
for the user
• Read unixHomeDirectory to display the
user’s home directory
• Read Public Information to display the
userPrincipalName for the user

Removing users from zones

Removing a user account from a standard Centrify DirectControl
zone or RFC 2307-compliant zone requires the following
permission:

The serviceConnectionPoint On the Object tab, select Allow to apply the
object for the user account following permission to this object only:
For example, if the Unix user name • Delete
is chris:
then select
Setting rights to work with group accounts

The specific objects and permissions required to work with group
accounts can vary depending on the type of zone the group is
associated with and the task to be performed. In most cases, you
can grant the required permissions to specific users or groups by
selecting the appropriate task in the Zone Delegation Wizard.
Adding an Active Directory group to a zone

Adding an Active Directory group to a zone requires the following
permissions:

group in Centrify DirectControl following permission to this object only:
For example, if you use the default • Create serviceConnectionPoint objects
ZoneName/Groups container: Click the Properties tab and select Allow to
domain/Program Data/Centrify/ apply the following properties to this object
only:
Note You can grant the required permissions to
specific users or groups by selecting the Add or
remove groups task in the Zone Delegation
Wizard.
Group account object in Active Click the Properties tab and select Allow to
For example: only:
domain/Users/group_name • Read groupType
• Read objectCategory
• Read objectGUID
• Read objectSid
group to the Finance zone: • Read objectGUID
Zones/Finance
Modifying an Active Directory group in a zone

In a standard Centrify DirectControl zone, modifying an Active
Directory group in a zone requires the following permissions:

object for the group account apply the following properties to this object
For example, if the Unix group only:
name is web-qa in the HKLab zone: • Read allowedAttributesEffective
Zones/HKLab/Groups/web-qa
then select • Read Name
serviceConnectionPoint objects If you are changing the Unix group name for a
group, you need the following additional
• Read name
• Write name
• Write Name

In a standard RFC 2307-compliant zone, modifying an Active

Directory group in a zone requires the following permissions:

object for the group account apply the following properties to this object
For example, if the Unix group only:
name is web-qa in the HKLab zone: • Read allowedAttributesEffective
then select • Read Name
serviceConnectionPoint objects If you are changing the Unix group name for a
group, you need the following additional
• Write gidNumber
If you are changing the Unix name for a group,
you need the following additional permissions
applied to this object:
• Read name
• Write name
• Write Name
Listing group account information

In a standard Centrify DirectControl zone, listing group account

object for the group account apply the following properties to this object for
For example, if the Unix group each group included in the list:
name is web-qa in the HKLab zone: • Read displayName
domain/Program Data/Centrify/ • Read managedBy
then select • Read objectClass
serviceConnectionPoint objects • Read Name to display the Unix group name
• Read keywords to display the Unix GID
In a standard RFC 2307-compliant zone, listing group account

For example, if the Unix group each user included in the list:
name is web-qa in the HKLab zone: • Read displayName
domain/Program Data/Centrify/ • Read keywords
then select • Read managedBy
serviceConnectionPoint objects • Read objectClass
• Read objectGUID
• Read Name to display the group name
• Read gidNumber to display the group GID
Removing groups from zones

Removing an Active Directory group from a standard Centrify
DirectControl zone or RFC 2307-compliant zone requires the
following permission:

The serviceConnectionPoint On the Object tab, select Allow to apply the
object for the group account following permission to this object only:
For example, if the Unix group • Delete
name is web-qa:
Zones/default/Groups/web-qa
then select

Setting rights to add and remove license keys

Starting the Centrify DirectControl Administrator Console
requires the following permissions on the container object for
licenses:

The domain root object Click the Properties tab and select Allow to
For example, if the root domain of apply the following properties to this object
the forest is arcade.com: only:
DC=arcade,DC=com • Read objectClass
Parent container for the Licenses On the Object tab, select Allow to apply the
container object following permission to this object only:
For example, if you use the default • List Contents
location in the Setup Wizard:
domain/Program Data/Centrify
Parent container for license keys On the Object tab, select Allow to apply the
For example, the Licenses following permission to this object only:
container object you created or • List Contents
selected in the Setup Wizard:
Licenses
To add and remove license keys in Centrify DirectControl, your

user account must have the following permissions:
For this target object You need these permissions

Parent container for license keys Click the Properties tab and select Allow to
For example, the Licenses apply the following properties to this object
container object you created or and all child objects:
selected in the Setup Wizard: • Write Description
domain/Program Data/Centrify/L
icenses
Setting rights for working with NIS maps

You can delegate administrative permissions for all NIS Maps in a
zone or for any specific NIS map within a zone by selecting either
the NIS Maps parent container object or the specific NIS map
object you want to work with. If you select the NIS Maps parent
container object, the permissions you set apply to all NIS maps you
add to the zone. If you select the individual NIS map object, the
permissions you set only apply to that individual NIS map.
Note Permissions to perform administrative tasks with NIS maps
must be set through ADSI Edit because these tasks are not included
in the Zone Delegation Wizard.
1 Open the ADSI Edit console snap-in and connect to the Active
Directory domain.
2 In the console tree, navigate to the Centrify DirectControl
folder. For example, if you installed Centrify DirectControl in
the default location and are setting permissions for NIS maps in
the default zone, expand Domain > CN=Program Data >
CN=Centrify > CN=Zones > CN=default.
3 Select CN=NisMaps to set permissions for all NIS Maps in a
zone, right-click, then select Properties. If setting permissions
for an individual map, expand CN=NisMaps, then select the
map object, for example, CN=auto_master, right-click and
select Properties.
4 Click the Security tab, then click Advanced.
5 Click Add to search for the user or group to which you want to
give administrative privileges, select the user or group in the
results, then click OK.
6 Scroll to locate the appropriate permissions for the object and its
properties to allow the selected user or group to perform the
administrative task, check Allow, then click OK.

Setting permissions for all NIS maps in a zone

To add NIS maps to the NISMaps parent container in a zone, the
user account must have the following permissions:

Parent container for NIS Maps On the Object tab, select Allow to apply the
For example, if using the default following permissions to this object and all
container location: child objects:
domain/Program Data/Centrify/ • Create Container Objects
Zones/ZoneName/NISMaps
To delete NIS maps in a zone, the user account must have the

Parent container for NIS Maps On the Object tab, select Allow to apply the
For example, if using the default following permissions:
container locations: • Delete Container Objects applied to this
domain/Program Data/Centrify/ object and all child objects.
Zones/ZoneName/NISMaps
On the Object tab, set Apply onto to Container
objects, then select Allow to apply the
• Delete Subtree
To add entries to any NIS map in a zone, the user account must have
the following permissions:

Parent container for NIS Maps On the Object tab, set Apply onto to Container
For example, if using the default objects, then select Allow to apply the
container locations: following permissions:
domain/Program Data/Centrify/ • Create classStore Objects
Zones/ZoneName/NIS Maps
To delete entries from any NIS map in a zone, the user account
must have the following permissions:

Parent container for NIS Maps Click the Properties tab, set Apply onto to
For example, if using the default classStore objects, then select Allow for the
container locations: following properties:
domain/Program Data/Centrify/ • Write name
• Write Name
To modify entries in any NIS map in a zone, the user account must
have the following permissions:

Parent container for NIS Maps Click the Properties tab, set Apply onto to
container locations: following properties:
domain/Program Data/Centrify/ • Write adminDescription
• Write wWWHomePage
To change the map type for any NIS map in a zone, the user account

Parent container for NIS Maps Click the Properties tab, set Apply onto to This
For example, if using the default object and all child objects, then select Allow
container locations: for the following properties:

Setting permissions for a single NIS map in a zone

To add entries to a specific NIS map in a zone, the user account

NIS map On the Object tab, select Allow to apply the
For example, if using the default following permissions to this object and all
container location: child objects:
domain/Program Data/Centrify/ • Create classStore Objects
Zones/ZoneName/NISMaps/map_name
To delete entries from a specific NIS map in a zone, the user

account must have the following permissions:

NIS map Click the Properties tab, set Apply onto to
container location: following properties:
domain/Program Data/Centrify/ • Write name
• Write Name
To modify the entries in a specific NIS map in a zone, the user


NIS map Click the Properties tab, set Apply onto to
container location: following properties:
domain/Program Data/Centrify/ • Write adminDescription
• Write wWWHomePage
To change the map type for a specific NIS map in a zone, the user

NIS map Click the Properties tab, set the Apply onto to
For example, if using the default This object and all child objects, then select
container location: Allow for the following properties:
Setting permissions for password synchronization

If you are using Windows Server 2003 R2 and the Centrify
DirectControl Network Information Service, adnisd, to
authenticate NIS client requests, you must set the following
permissions at the domain level, on the Users container object, or
on another container that applies to all users.

Users object or a container that Click the Object tab, set the Apply onto to User
applies to all users objects and select Allow to apply the following
permission:
• All Extended Rights
You can apply this permission to Domain
Computers or to a specific group of computers
that contains the computer where the Centrify
DirectControl Network Information Service is
running.
Planning changes to the Active Directory structure

Adding new Unix, Linux, or Mac OS X computers to one or more
Active Directory forests often requires upfront planning to
determine whether you will need to create new organizational
units and groups for the objects to be added and how and where in
the Active Directory tree you will apply group policies to the new
objects. In addition, you need to decide where to create the
container objects for Licenses, Zones, and Private Groups and

whether you want to create more than one of each of these

container objects within trusted forests to give you more
granularity for delegating administrative tasks.
Although you typically create the containers using the Centrify
DirectControl Setup Wizard or from the Manage Licenses dialog
box, you can also manually create one or more of any of these
container objects, if needed, provided you have an account with the
appropriate permissions.

In this release, Centrify DirectControl supports cross-forest
authentication for users in Active Directory forests that are
configured with a two-way trust relationship. This cross-forest
support requires Windows Server 2003. External transitive trusts
between forests are not supported.
If your Active Directory environment does not permit two-way
trusts between forests, however, or uses a combination or one-way
and two-way trust relationships between forests, users who
attempt to log on from a remote forest may be denied access if the
forest they are logging on to or the forest they are logging in from
do not share a two-way trust.
As part of your deployment planning you should review your entire
Active Directory infrastructure and determine whether you will be
authenticating users from multiple forests and how trust
relationships are defined for the forests users need access to. You
may want to change the trust relationships you have defined.

In planning a deployment of Centrify DirectControl in a
production environment, you should first evaluate the needs of
your organization, the design of your Active Directory forests, and
the current configuration of the systems where Centrify
DirectControl will be installed and how those systems are used,
and how you will migrate existing user communities and legacy
information to Active Directory. With this information, you can
better plan your deployment strategy before you begin adding Unix
computers to the domain.
To help you get started, you should evaluate your existing
environment to determine how best to use zones to suit the unique
needs of your organization. In evaluating the Unix environment:
Determine whether you are enabling access for computers
that are used as workstations for individual users or small
groups of users or as application servers, or both.
Consider whether you are migrating existing user information
to Active Directory and whether there are overlapping user
and groups IDs or multiple account names for individual
users.
Identify any special system or application accounts that may
have unique requirements and decide whether or not to
manage access to those accounts through Active Directory.
Determining your zone requirements

Like domains, your goal is not to have a large number of zones but
to use zones to organize and group the computers in your
organization most effectively. As an example, consider an
organization where some Unix computers are used to host financial
applications. Those computers are centrally managed by the IT
organization, which follows well-established conventions for
issuing user login names, user IDs, and home directories. The same
organization has a software development group that includes
numerous Unix workstations that are not centrally managed by the
IT organization and computers and accounts are added in an ad hoc
fashion.
Because enterprise-wide conventions are not enforced for the Unix
computers in the software development group, it’s possible that the
local login names and user IDs may conflict with the names and IDs

used on the computers running the financial applications. In

addition, users in the software development group may use a
different convention for their home directories or prefer different
login shells.
Without zones, the IT organization would need to eliminate any
duplicate user IDs and verify each login name was unique across all
of the computers. By placing the computers running the financial
applications in one zone and the computers in the development lab
in another zone, the IT organization can avoid the overhead of
checking and changing existing account information and can set
default zone settings, such as different default home directories or
login shells, that are most appropriate to the users in each zone.
Because zones can greatly simplify deployment, it’s worthwhile to
spend some time planning a strategy for using them. The most
common approaches for grouping any given set of computers into a
zone include:
Computers share the same platform and operating
environment. You can use this strategy, for example, to create
separate zones for Red Hat Linux workstations and Sun Solaris
Unix workstations.
Computers that share the same identity store, such as an
existing NIS domain, or form a natural administrative set.
Computers run specific applications or are accessed by a specific
group of users. You can use this strategy, for example, to create
separate zones for the computers that host financial applications
and computers used by software developers.
Computers located in the same geographical region or line of
business. You can use this strategy, for example, to create
separate zones for the computers in different office locations or
that are used by different business units within the organization.
As these examples suggest, there are many different approaches
you can take to defining the scope of a zone, including organizing
by platform, department, manager, application, geographical
location, or usage pattern. Once you have a basic strategy in place,
you can create new zones whenever you need to.
Using zones to map Unix identities to Active Directory

As an example of how you can use zones, consider the following
example of a user who has access to several different computers:
Active Directory Forest Active Directory Account
User name: Dale Wilson
Administrator Console Logon name: dale.wilson@mycorp.org
Given access to three zones: Marketing,

Finance, Intranet
No access to any other zones
Windows Domain Marketing Zone Finance Zone Intranet Zone

User logon name: User: dale User: wilsond User: dwilson
dale.wilson UID: 9189 UID: 2387 UID: 5381
Shell: /bin/bash Shell: /bin/csh
HomeDir: /home/dale HomeDir: /nfs/wilsond
Windows XP Linux Workstation Solaris Server Linux/Apache Server
As illustrated in the figure above:

In Active Directory, the user account for “Dale Wilson” stores
all of the normal attributes associated with a Windows user,
such as the person’s full name, login name, password, group
membership and associated policies. This user logs in to a
Windows desktop using dale.wilson or
dale.wilson@mycorp.org and his Active Directory password.
The Active Directory account for dale.wilson has been given

permission to log in to three Unix zones. For each zone that he
is allowed to log in to, he has a specific set of Unix account
settings and he can only log in to the computers in zones for

which he has these settings. The Unix account settings must be

unique to each zone but won’t create conflicts if they are not
unique across the enterprise.
The user dale.wilson can log on to any Unix computer in the
three zones he has permission to access, unless you explicitly
deny access to particular computers within any zone. Each zone
might include laptop computers, workstations, or servers, or
be limited to a specific type of computer, depending on how you
have decided to use zones. The user cannot log on to any of the
Unix computers in zones you haven’t given him permission to
access.
Although the Unix account settings are different for the
computers in each zone, the user dale.wilson only needs to
remember his Active Directory account name and password. He
doesn’t need to know the underlying Unix account information
or whether that information conflicts with any other Unix user.
Regardless of which zone the Unix computer is in, he can
simply log in to the Unix system using dale.wilson or
dale.wilson@mycorp.com and his Active Directory password
and the environment is set up correctly.
To ensure there are no conflicts between the Unix UIDs, each
computer is only ever a member of one zone within a domain
forest.
As this example illustrates, zones give you flexibility for assigning
or allowing users with multiple user IDs to be linked to a single
Active Directory account. If a user needs access to multiple
computers, you can use zone to easily provide access to those
computers without having to create any accounts on those
computers. If the user already has multiple Unix UIDs the systems,
you can use zones to map those separate identities to a single Active
Directory set of credentials without having to ensure there are no
conflicts with other user accounts across the enterprise.
Using zones to migrate existing identity stores
In many organizations, it is impractical to attempt to rationalize
user accounts across the enterprise to achieve a single global UID
for each individual user and zones are particularly useful for
migrating multiple existing Unix identity stores to Active
Directory. For example, most organizations have multiple identity
stores already in use on their current Unix platforms. These
identity stores may include LDAP directories, NIS or NIS+
domains, and local account configuration files using /etc/passwd.
Often a single user can be a member of more than one identity
store and may have a different user name, UID, or group
memberships in each. Centrify DirectControl zones allow the
organization to import the information from these legacy identity
stores without consolidating the multiple identities that each user
may have. The result might be a structure with three zones in
Active Directory: one with the pre-existing UNIX LDAP directory
information, one with information imported from an existing NIS
domain, and one with information imported from one or more
/etc/passwd files.
If a user has an account in all three systems, these three identities

can be mapped back to a single Active Directory identity, even if
the user’s profile and attributes were different in each of the legacy
directories, and the user can access all of the same systems as
before the migration using either Active Directory credentials or
the credentials from the legacy identity store, making the transition
from a legacy system to Active Directory more manageable for the
user community.
Using zones for access control and dynamic provisioning

As a practical matter, you may choose to use Centrify
DirectControl zones to ease migration to Active Directory by
creating a separate zone for each legacy identity store. However,
you can also use Centrify DirectControl zones to group computers
by department, by function, or by any other criteria you choose.

Using zones in this way gives you a great deal of flexibility in

controlling who has access to the Unix, Linux, and Mac OS X
computers in your environment and makes it easier to set up
account information for new users based on job function or other
criteria. For example:
If you authorize a user for a particular Centrify DirectControl
zone, that user can log in to any computer in that zone without
requiring you to set up an account there first. This “dynamic
provisioning” of accounts is similar to the behavior in a
Windows environment, where a user can log on to any
computer that is part of the domain where the user’s account
exists.
Although the user by default has access to all of the computers
in each authorized zone, you can still use Active Directory to
block access to any individual computers in the zone the user
should not access.
You can use zones to restrict access to whole groups of
computers. Each user can only log on to the computers in the
specific zones you have authorized for access. The user cannot
log on to any of the Unix, Linux, or Mac OS X computers in
other zones.
For example, all machines in the finance department could be
grouped into a single Centrify DirectControl Zone called “Finance”
and the members of that zone could be restricted to finance
employees and senior managers. This gives the organization better
control over access to systems based on well-defined roles.
Additionally, Centrify DirectControl zones can be used to restrict
access to certain types of applications running on the Unix systems.
For example, if you have a Unix server that hosts an Apache Web
server with internal applications, you may want to restrict access to
that computers and the applications hosted there.
Administrator Console Active Directory Forest
Active Directory Account Active Directory Account

User name: Dana Harrison User name: Marcelino Perez
Logon name: dana.harrison@mycorp.org Logon name: perez@mycorp.org
Access to zones: Linux and WebFarm Access to zone: QALab
Finance Zone WebFarm Zone QALab Zone

User: dana User: harrisond User: perez
UID: 4189 UID: 2200 UID: 2200
Shell: /bin/bash Shell: /bin/ksh Shell: /bin/csh
HomeDir: /home/dana HomeDir: /nfs/webs/dh HomeDir: /home/perez
Linux Workstation Linux/Apache Server Solaris Server
Because setting up and managing accounts for users who have

access to multiple computers is time-consuming and error-prone,
Centrify DirectControl zones make it faster and more reliable for
you to grant users access to the specific computers, and only those
computers, that are appropriate for their job function.
Using zones for policy management

Centrify DirectControl Zones also provide you with more
flexibility to apply Active Directory Group Policy configuration
settings to different groups of computers or users. Although you
cannot apply Group Policy Objects directly to Centrify
DirectControl zones, you can use zones in combination with
organizational units to control how configuration settings are
applied to Unix computers and users through Unix-specific group

policies. Because Centrify DirectControl zones allow you to group

computers within organization units, using multiple zones is more
practical and flexible than combining all of your Unix, Linux, and
Mac OS X computer into a single zone.
Using zones to delegate administration

Zones can also be useful for grouping computers that form a
natural administrative set or that should be managed by different
administrative teams. For example, you may want to group
computers that are managed by a local support organization in one
zone and computers that are managed by a corporate IT
administrative group in another zone.
Using zones, you can then control what different groups of users
can do within the zones they have permission to access. For
example, you can authorize some users to view and modify object
properties for the computers in a specific zone but not delete
objects in that zone while other users may have permission to view
object properties in multiple zones, but without the permissions
necessary to make changes.
Zones provide a convenient way for you to assign maintenance
responsibilities to specific users or groups based on a set criteria,
such as department, geographic location, or functional role.
Using a zone for each computer

In some cases, you may find your existing Unix infrastructure to be
too complex to organize into meaningful groups or too difficult to
rationalize into multiple logical or physical zones. This is often the
case in large organizations where the networked environment has
evolved organically. For this type of environment, you may find it
useful to place each computer in a separate zone. You can still use
the zone to control who accesses individual computers, manage
policies, and delegate administrative tasks, but you don’t need to
rationalize any user or group account information between
computers to deploy.
With this scenario, you can create as many zones of different types
as you need and migrate computers to different zones over time.
Determining the types of zones to use

Within Centrify DirectControl, you can create the following types
of zones:
Standard Centrify DirectControl zones for Windows 2000
Server and Windows Server 2003
Windows Services for UNIX (SFU), version 3.5, zones
Windows Services for UNIX (SFU), version 4.0, zones
Standard RFC 2307-compatible zones
The zone type determines how the Unix profile data and other
attributes are stored in Active Directory. You can use a mix of zone
types within the organization, depending on the domain and forest
functional level you are using and the version of the Services for
UNIX schema version you have installed. You can also convert new
and existing zones to Standard RFC 2307-compatible zones over
time. Centrify DirectControl supports these different types of
zones to give you maximum flexibility in rolling out a deployment
across your organization and migrating your systems as needed over
time. To use Standard RFC 2307-compatible zones or Windows
Services for Unix 4.0 zones, however, your domain controller must
be running Windows Server 2003, R2, and must be running at the
Windows Server 2003 forest functional level.
Note Before you raise the forest functional level to Windows Server
2003 forest functional level, be sure that all of your domain
controllers are running Windows Server 2003. You cannot revert
the functional level after raising it. To raise the forest functional
level and begin using Standard RFC 2307-compatible zones, click
Start > Administrative Tools > Active Directory Domains
and Trusts. In the console tree, select Active Directory
Domains and Trusts, right-click and select Raise Forest
Functional Level then select Windows Server 2003. Creating

RFC 2307-compatible zones can make Centrify DirectControl data

available to other RFC 2307-compliant applications.

In most organizations, new Active Directory user accounts aren’t
necessary because most, if not all, Unix users already have Active
Directory accounts so they can access resources in the Windows
network. Although user accounts are likely to exist, you may
decide you need to create several new Unix-specific groups to
make it easier to control access to Unix resources and apply group
policies. In addition, you may already have account information for
users and groups stored in NIS maps or in individual passwd and
group files.
As part of your planning process, you should determine where

information for existing Unix users is stored and how and when to
import this information to Active Directory. You should also define
a strategy and schedule for migrating users from any legacy
authentication system to Active Directory.
In planning your deployment, you should identify and define your
organization’s policies for allowing or denying local users access,
notifying the user community to begin using Active Directory user
names and passwords, mapping any local user accounts to Active
Directory accounts, and establishing one or more accounts that can
log on without being authenticated through Active Directory.
Planning group membership

In planning the deployment, you should evaluate how you can use
group membership to control access. You should also determine
whether you will create new private Active Directory groups for
Unix users, use existing Active Directory groups, or import
existing Unix group information from legacy identity stores to
create new Active Directory.
Using private groups for Unix users
In the Unix environment, every user account is associated with one
primary Unix group. This primary group defines the user’s file
ownership and permissions on the Unix computer. Because of this
requirement, any time you create a Unix profile for an Active
Directory user, you must specify the primary group for that user.
The primary group you specify for any user can be either a standard
Active Directory group, for example an existing domain or global
security group, or a private group.
A private group is an Active Directory group that can be reserved
for the exclusive use of an individual user within a specific zone. By
using private groups, you can allow users to manage group
membership and file access permissions outside of Active
Directory. For example, users can modify the membership of their
private group to give another user access to their files.
Depending on the zone properties you set, new Unix users are
assigned either a private group or a normal Active Directory group
by default. If you choose to use a private group, the Unix group
profile is created automatically and assigned the same name and
GID as the user account.
Because private groups can be used on a zone-by-zone basis, you
may find it convenient to use them while you plan your Active
Directory group strategy and zones. For example, if you are
importing account information from an existing identity store, you
may want to use private groups to set up accounts in Active
Directory without impacting any of your existing Active Directory
group management infrastructure. You may also want to use
private groups to allow individual users to maintain control over
their files on the Unix computers they log on to within each zone.
If you already have a well-defined Active Directory group
structure, however, you may simply want to add Unix users to the
appropriate groups within that structure. Whether you choose to
use private groups or your existing Active Directory group

Planning group membership
structure, you can change the primary group for any user at any
time by modifying the user’s Unix profile.
Working with Active Directory security groups

In Active Directory, security groups are used to control access to
computers and network resources. When you create a group, you
define the scope of accounts that can be members and the scope of
permissions that can be applied. For example, the members of a
domain local group can only be assigned permissions within their
local domain, while members of a global group can be assigned
permissions for any domain in the forest.
For Centrify DirectControl, you can enable Unix access for domain
local, global, or universal groups and can use nested groups in the
same way you use them for Windows computers.
Any existing Active Directory security group can be enabled for
Unix access in any zone. You can also use any standard Active
Directory security group as the primary group for Unix users in
any zone, if desired.
Note Only Active Directory security groups are supported for
authentication and authorization. Centrify DirectControl does not
support distribution groups for authentication and authorization.
Enabling Unix access for Active Directory groups gives you greater
control, consistency, and visibility for managing user accounts. For
example, you can create a nested group hierarchy in Active
Directory to manage Unix users accounts in the same way you
manage Windows accounts. Whether you create new Unix-specific
groups or use existing Active Directory groups access to Unix
computers depends on the needs of your organization and the
structure of your Active Directory forest.
Running commands that retrieve group information

Because of fundamental differences in how groups are handled in
most Unix operating environments and how groups are handled in
Active Directory, you may notice slow performance when you run
commands that retrieve group information from Active Directory
for the first time.
For example, the id command displays the system identifications,
such as the user’s name, numeric ID, and group membership, for a
specified user. The first time you run this command for any user, it
may take longer than you expect it to because of the time it takes to
determine all of the Active Directory groups the user is a member
of. As an example, if you have nested groups or groups with more
than 1000 members, iterating through a user’s group membership
may take more than one to two minutes. Once the information is
retrieved from Active Directory, however, it is stored in the local
cache and commands that require this information take less time to
execute. Therefore, the first time you run the id command for any
user, it will take longer to execute than subsequent executions
unless you clear the cache or configure objects to expire. The same
is true for other commands that retrieve group information.
In the Unix operating environment, a user’s primary group is
normally defined in the user’s /etc/passwd entry, and, therefore,
does not need to be identified in the /etc/group entry. This is
different from the way groups are defined in Active Directory
where user accounts are defined as members of one or more
groups. By default, when you enable Unix access for an Active
Directory user, Centrify DirectControl adds the Active Directory
user to the Active Directory group associated with the default Unix
group for the zone you are giving the user access to. This
association of the user with an Active Directory group allows for
configuration management using group policies, but the Unix
environment does not require this secondary association.
To avoid a slow-down when retrieving group information using
commands such as id, you can remove Unix-enabled users from
their default group membership list. This will prevent Unix
commands like id from retrieving the complete list of users
associated with the Active Directory group, but allow the

command to retrieve the user’s default group membership from the

/etc/passwd entry.

You may find it useful to migrate information from other NIS maps,
such as the automount and netgroup maps, to Active Directory. If
you import this information into Active Directory, you can use the
Centrify DirectControl Administrator Console to manage the data
and the Centrify DirectControl Network Information Service to
serve this information to a NIS client requests.
If you import information from passwd and group maps, you can
also use the Centrify DirectControl Network Information Service
to respond to NIS client requests for user and group information,
enabling you perform authentication of Active Directory users on
computers where you cannot install the Centrify DirectControl
Agent. For more information about installing and using the
Centrify DirectControl Network Information Service, see Chapter
12, “Using the DirectControl Information Service for NIS
requests.”
Chapter 4
Installing Centrify DirectControl on

Windows
This chapter provides step-by-step instructions for installing
Centrify DirectControl on a Windows computer and configuring
Centrify DirectControl for the first time in an Active Directory
forest. You should complete the steps in this chapter before you
attempt to add any non-Windows computers to the domain.
Preparing for installation on Windows
Installing Centrify DirectControl Management Tools
Starting Centrify DirectControl for the first time
Updating from a previous release
Removing Centrify DirectControl

Before installing Centrify DirectControl, you should verify that the
computers where you are planning to install Centrify
DirectControl components meet all of the system requirements
and prerequisites and that you have all of the information you need
to install and configure Centrify DirectControl.
Checking your Active Directory configuration

Because installing and configuring an Active Directory forest and
sites can be a complex task, requiring a great deal of planning and
preparation, you should be sure Active Directory is fully deployed
and operational before installing Centrify DirectControl.
99
You should verify that you have:

At least one Windows computer acting as a domain controller
for the Active Directory forest to which you want to add Unix
computers.
At least one Windows computer acting as a DNS server. You
should also verify the DNS server allows secure dynamic
updates and your domain controllers are configured to publish
updated service locator (SRV) records.
A user account and password with sufficient rights to create new
container objects in the Active Directory forest. Alternatively,
your Active Directory administrator may choose to manually
preconfigure your environment or modify your account
permissions to enable you to perform setup tasks. For
information about the specific rights required to perform tasks
in the Setup Wizard, see “Planning Active Directory
permissions” on page 49.
If you have a functioning Active Directory deployment, you should
be able to install the Centrify DirectControl on one or more
Windows computers without any modification to your Windows
or Active Directory environment.
Note If you are not using Windows as your DNS server, you may
need to modify your Unix environment or add a new Windows
DNS server role to ensure communication between the Unix
computers and appropriate Active Directory domain controllers.
For more information about the options for configuring the DNS
environment, see “Working with DNS, Active Directory, and
DirectControl” on page 275.
Verifying system requirements

Before installing Centrify DirectControl in the Windows
environment, check the following basic requirements that apply to

both the Centrify DirectControl property extensions for Active
Directory and the Centrify DirectControl Administrator Console:
For this You need this

Operating system One of the supported versions of the Windows operating
environment product families:
• Windows Server 2003 (including R2 and x64 Editions)
• Windows 2000 Professional and Server (SP4 or later)
• Windows XP Professional (including x64 Edition)
• Windows Vista (including x64 Edition)
.NET Framework .NET Framework v1.1 or 2.0
If the .NET Framework is not installed, the Centrify
DirectControl setup program will install it for you.
Active Directory access The computer must be able to connect to Active
Directory.
If you are installing the Centrify DirectControl

Administrator Console, you should check the following
additional requirements:

CPU speed Minimum 550 MHZ
RAM 25MB
Disk space 100MB
Planning your Active Directory structure

The first time you use Centrify DirectControl, you will update the
Active Directory forest with containers for Centrify DirectControl
licenses and zones. Depending on how you have designed your
Active Directory site and how you are using domains and
Organizational Units, you may want to do some planning to
determine how zones and Unix-specific objects fit into your
existing Active Directory structure and where you want to place
the Centrify DirectControl containers.
Chapter 4 • Installing Centrify DirectControl on Windows 101

Note Within the Centrify DirectControl containers, Unix-specific

properties for users, groups, and computers are organized by zone.
This means there are essentially two ways to view this information:
the DirectControl view organized by zone and the Active Directory
view that is typically designed around the structure of your business.
Although you can place the zone container anywhere within the
Active Directory structure as appropriate for your organization,
users will need certain rights to access that container and its child
containers to work with Unix objects. For more information about
permissions and delegating access rights for Centrify DirectControl
actions, see “Setting permissions and rights for Centrify
When you configure Centrify DirectControl for the first time, you
will be able to place Centrify DirectControl containers at any point
within your existing structure or create new containers at any
location in the tree you choose. In addition, as you add Unix
computers to the domain, you will be adding new computer
accounts to Active Directory. You may also be adding new group
and user accounts. Therefore, it is a good practice to determine a
general plan for where in Active Directory you want to place Unix
users, groups, and computers and the Centrify DirectControl
containers for licenses and zones.
Planning when to install on Windows and Unix

Although you can install components in any order, if needed, in
most cases, you should install and configure Centrify
DirectControl on at least one Windows computer first. The first
time you start Centrify DirectControl on Windows, you update
the Active Directory forest with the Centrify DirectControl
property extensions and configure the default zone properties.
After you update the Active Directory forest, you can deploy on
Unix computers over time and install additional Administrator
Consoles on Windows computers when needed.

Before you can add any Unix computers to Active Directory, you
first need to install the Centrify DirectControl Management Tools
on a Windows computer in the Active Directory forest using the
Centrify DirectControl setup program. The setup program simply
copies the necessary Centrify DirectControl files to the local
Windows computer. There are no special permissions required 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 Log on to the Windows computer and locate the Windows folder
on the Centrify DirectControl CD or in the folders extracted
from a Centrify DirectControl download package.
2 Double-click setup.exe to start the setup program.
3 At the Welcome page, click Next.
4 Review the terms of the license agreement. If you accept the
license agreement, select I agree to these terms, then click
Next.
5 Type your name and company, select who should be able to use
this application on the computer, then click Next.

6 Select the components you want to install, then click Next. For
example:
In most cases, the first time you run the setup program you
should accept the default to install all components, but there is
no requirement to do so.
Note For administrative purposes, you should install either the
Centrify DirectControl property extensions for Active
Directory Users and Computers, or the main Centrify
DirectControl Administrator Console on each computer that
needs access to the Unix attributes in the Centrify Profile. If
Active Directory Users and Computers is available on the local
computer, you can choose to install just the property extensions.
If Active Directory Users and Computers is not installed on the
local computer, you can choose to install only the Centrify
DirectControl Administrator Console.
7 Click Next to install components in the default location, or click
Browse to choose a different location, then click Next.
8 Verify your installation settings, then click Next.
9 Click Finish to complete the installation.

When you run the setup program with the default components
selected, the setup program installs all of 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 policies.
The Centrify DirectControl Administrator Console Help and
other documentation.
The Centrify DirectControl API packaged in the dynamic link
library (DLL). The Centrify DirectControl API provides the
COM objects that convert Active Directory application objects
into Centrify-enabled Unix user, group, computer, and zone
objects.

When you start the Centrify DirectControl Administrator Console
for the first time, the Setup Wizard is displayed to help you
configure the Active Directory forest and the default properties for
your first Centrify DirectControl Zone. Zone properties are
important because they allow you to control the default settings for
users and groups in the zone, greatly simplifying the task of adding
new Unix users and groups to Active Directory.
In addition, the Setup Wizard makes it easier for you to control
where Centrify DirectControl container objects should be placed
and who will have permission to modify the objects within those
containers. Because the Centrify DirectControl Zone Setup
Wizard creates container objects, you may need to log on with an
account that has Domain Administrator privileges. This
requirement depends on the specific permissions your organization

has configured for different classes of users. For example, if your

organization permits Domain Admins or other types of accounts to
create parent and child objects in Active Directory, an Enterprise
Admin account is not necessary to configure the environment. For
more information about the permissions required to perform
specific configuration steps or Centrify DirectControl tasks, see
“Setting permissions and rights for Centrify DirectControl” on
page 315.
Note Although you can skip some initial configuration steps,
Centrify recommends you complete all of the configuration steps,
including those that set up the default zone, before you begin
attempting to add computers to the domain. For more information
about managing zone properties and creating new zones after the
initial configuration, see “Managing zones” on page 129. In addition,
the steps in this section describe the initial configuration of a new
Centrify DirectControl installation. If you are updating Centrify
DirectControl from a previous release, see “Updating from a
previous release” on page 113 for information that is specific to an
upgrade.
To start the Setup Wizard and update the Active Directory forest:
1 Log onto the computer where you installed the Centrify
DirectControl Administrator Console and start the Centrify
3 Select Use currently connected user credentials to use
your current log on account or select Specify another user’s
credentials and type a user name and password, then click
Next.
4 Select a location for installing license keys in Active Directory,
then click Next. You can create a new container object for
license keys or select an existing container object.

The default container for license keys is domain_name/Program
Data/Centrify/Licenses.
Note At a minimum, users who work with the Centrify

DirectControl Administrator Console must have Read
permission for the container that holds license keys and all child
objects. If you use the Setup Wizard to create the container, the
new container can be read by all Authenticated Users by default.
If you use an existing container, you should determine which
users need access to the Centrify DirectControl Administrator
Console and verify that those users have read permission for the
object and all child objects on the container you want to use.
You can add other License containers in other locations later
using the Manage Licenses dialog box.
5 Review the permission requirements for the container, then
click Yes to confirm your selection or click No to select a
different container.
6 Select whether to install the evaluation license keys or
permanent license keys.
If you want to install the evaluation license keys, select Install
30 day evaluation license key, then click Next. The
evaluation license gives you unlimited access to all of Centrify
DirectControl features for 30 days, then the license expires.
If you have purchased licenses and want to install those license
keys, select Install the following license keys, type the
24-character license key you received, then click Add. If you
received multiple license keys, add each key to the list of
installed licenses, then click Next.
Note If you received your license keys in a text file, you can click
Import to import the keys directly from the file instead of
adding the keys individually.
If you choose to install the evaluation license, you can install
permanent license keys later using the Centrify DirectControl

Administrator Console. For information about adding and

updating licenses, see “Managing licenses” on page 213.
7 Select Create default zone container, then click Next to
specify a location for the Zones container.
8 Select a location for creating new zones in Active Directory,
then click Next. The “default” zone and any other zones you
create will be created within the container you specify by
default. You can create a new container object or select an
existing container object.
The default container location for zones is
domain_name/Program Data/Centrify/Zones.
Note At a minimum, users who create new zones with the

Centrify DirectControl Administrator Console must have
permission to create container objects for this container object
and all child objects. If you use the Setup Wizard to create the
container, this permission is granted to all Authenticated Users
by default. If you use an existing container, you should
determine which users should be able to create zones and verify
that those users have permission to create container objects for
the selected object and all child objects on the container you
want to use.
9 Select Create default zone, then click Next to configure the
“default” zone.
If you do not want to create a zone named “default” as the first
zone, uncheck Create default zone, then click Next. If you
uncheck this option, the Setup Wizard skips the next steps for
configuring the default zone and displays your configuration
settings for you to confirm your selections. If no changes are
necessary, click Finish. If you choose not to configure the
“default” zone:
You must create at least one zone before any Unix computers
can join the domain. For information about creating zones,
see “Creating a new zone” on page 130.

You must specify the --zone option for every Unix computer
when you run the adjoin command to join the Active
Directory domain. For information about running the adjoin
command and specifying a zone, see “Using adjoin” on
page 285.
If you are not configuring the “default” zone, go to Step 16 on
page 112.
10 Click Next to accept the default location for the “default” zone
or click Browse to specify a different location for the “default”
zone, then click Next. If you use the default container location
for zones, the new zone object is created as
domain_name/Program Data/Centrify/Zones/default.
11 Type the numeric user identifier (UID) you want to start with
for new Unix users in this zone, then click Next.
By default, new Unix users are automatically assigned the next
available UID for the zone. For example, if you set the default
UID for a zone to 500, the first Active Directory account that
you authorize to log on to the Unix shell is assigned a user ID of
500 by default. The next user account that you give this
permission to is assigned a user ID of 501, and so on. You can
override this default value for any user, if desired.
You can also set aside some user IDs to be reserved for special
purposes. For example, if you run an application that requires a
specific user account, you may want to reserve the UID for that
account so no other users can be assigned that ID.
To prevent some UIDs from being assigned, click Add. You can
then specify individual UIDs or a range of UIDs you want to
prevent from being used. To specify both individual values and a
range of range, use a comma to separate the entries. For
example, to reserve the UIDs from 2006 to 2010 and 2025 and
2400, you could click Add, type, 2006-2010,2025,2400, then
click OK.

12 Type the numeric group identifier (GID) you want to start with
for new Unix groups in this zone, then click Next.
By default, new Unix groups are automatically assigned the next
available GID for the zone. For example, if you set the default
GID for a zone to 500, the first Active Directory group that you
authorize to log on to the Unix shell is assigned a group ID of 500
by default. The next group account that you give this permission
to is assigned a group ID of 501, and so on. You can override this
default value for any group, if desired.
You can also set aside some group IDs to be reserved for special
purposes. For example, if you run an application that requires a
specific group account, you may want to reserve the GID for that
account so no other groups can be assigned that ID.
To prevent some GIDs from being assigned, click Add. You can
then specify individual GIDs or a range of GIDs you want to
prevent from being used in the same way you reserve UIDs.
13 Type the default location you want to use when creating new
home directories for new Unix users, then click Next.
The default setting, /home/${user}, uses the special keyword
$user to create a new directory using the user’s Unix login
name. For example, if you are enabling access for the Unix user
account shea, the default home directory created is /home/shea.
You can create a different home directory for any user, if
desired.
Note The ${user} keyword is the only keyword supported. This
keyword substitutes a user’s Unix login name to create the
directory name. Although /home is the typical location of a user’s
home directory in the Unix environment, you can specify a
different directory name, if needed, for example,
/nfshome/${user}. You should be sure, however, that the
parent directory—for example, the /home or/nfshome
directory—already exists in your Unix environment, or the

Centrify DirectControl Agent will be unable create the
individual user’s directory.
14 Select the type of Unix shell you want to use as the default for
users in this zone, click Set as default, then click Next.
If you want to add other Unix shells to the list of Available shells,
click Add, type the path to the shell on the Unix system, then
click OK. You can also remove shells from the list, if there are
shells you do not want to make available for selection. Once you
have set the default shell, you can override the default for any
user by selecting a different shell from the list of available shells
when modifying the Centrify Profile for the user.
15 Select the type of group you want to use as the default primary
group for users in the “default” zone, then click Next.
Select Normal group if you want to identify an existing
Active Directory security group as the default primary group
for users in this zone.
You should select this option if you want to manage all aspects
of group membership through Active Directory for users in
this zone and have already created the appropriate Active
Directory groups for Unix users. If you select this option,
click Browse to select the Active Directory group to use,
type the GID and Unix group name, then click Next.
Select Private group if you want to use a private group as
the default primary group for each Unix user in this zone.
Private groups enable you to automatically create a new
Active Directory group enabled for Unix with a group name
and GID that is the same as the Unix user name and UID
whenever you create a new Unix user. Private groups allow
users to manage group membership and file access outside of
Active Directory. For example, users can modify the
membership of their private group to give another user access
to their files. Although selecting this option creates a new
Active Directory group for each new user by default, these
private Active Directory groups do not need to be managed by

the Active Directory administrator unless your organization

requires them to be.
You should select this option if you want each Unix user to
have a private Active Directory group as the primary group. If
you want to use private groups for Unix users, click Yes to
create a private group container within Active Directory, then
specify a location for the private group container. The default
container for private groups is domain_name/Program
Data/Centrify/Private Groups.
Review the permission requirements for the private groups

container, then click Yes to confirm your selection or click
No to select a different container.
For more information about using private groups or Active
Directory groups, see “Using private groups for Unix users” on
page 162.
16 Select Register administrative notification handler for
Microsoft Active Directory Users and Computers
snap-in if you want to automatically maintain the integrity of
the data stored in Centrify Unix profiles, then click Next.
Registering the administrative notification handler affects the
replication services in Active Directory and requires Enterprise
Admin or Domain Admin rights for the forest root domain. If
you don’t want to perform this step or do not have sufficient
rights to register the handler, you can leave this option
unselected and click Next. If you choose to skip this step, you
should periodically run the Centrify DirectControl Analyze
command to check and maintain data integrity in the Active
Directory forest.
17 Review and confirm your configuration settings, click Next,
then click Finish.
For information about modifying zone properties after configuring
the first zone, see “Changing zone properties” on page 137.

If you are upgrading Centrify DirectControl from a previous
release, you should keep in mind that once you install the new
version of the Centrify DirectControl Management Tools on
Windows, you should also update your Centrify DirectControl
Agents to work with the new Centrify DirectControl
Administrator Console.
If you are updating a large environment or over a period of time,
you should take the following co-existence restrictions into
consideration:
You can work with version 1.0.x, version 2.x.x Centrify
DirectControl Agents using any version of the Centrify
DirectControl Management Tools, but you must use version 3.0
of the Centrify DirectControl Management Tools if you want to
work with zones of different types.
You must use version 3.0 of the Centrify DirectControl
Management Tools if you want to work with Active Directory
Federation Services. You should not install any earlier versions
of the Centrify DirectControl Management Tools on a
computer with Active Directory Federation Services, and you
should not install the Active Directory Federation Services
MMC snap-in on a computer with an older version of the
Centrify DirectControl Management Tools.
You can use different versions of the Centrify DirectControl
Management Tools to work with the same Active Directory
domain controller, but not on the same administrative
computer.


On Windows computers, you can use Add/Remove Programs to
remove Centrify DirectControl components. You may also need to
use ADSI to remove any test or Centrify DirectControl-specific
containers and objects, such as the objects for zones and Unix
computers, from Active Directory.

Chapter 5
Installing the Centrify DirectControl

Agent on Unix
This chapter provides step-by-step instructions for installing the
Centrify DirectControl Agent on a computer and joining a Unix,
Linux, or Mac OS X computer to the Active Directory domain.
Preparing for installation on Unix computers
Installing the Centrify DirectControl Agent
Verifying the DNS configuration on Unix
Joining an Active Directory domain
Preparing for installation on Unix computers

The Centrify DirectControl Agent needs to be installed on each
Unix computer you want to manage through Centrify
DirectControl and Active Directory. Therefore, you should check
that each computer where you plan to install is running a supported
115
version of the Linux, Unix, or Mac OS operating system and meets

the following requirements:

Operating system One of the following supporting environments:
• Apple Mac OS X
• Debian Linux
• Hewlett-Packard HP-UX
• IBM AIX
• Red Hat Linux
• Sun Solaris
• SuSE Linux
• VMWare ESX Server
For information about the specific operating
system versions supported, see the Centrify
DirectControl Release Notes.
CPU speed 300 MHZ
RAM 10MB
Disk space 100MB
Note For the most complete information about supported

platforms and version information, you should check the Centrify
DirectControl Release Notes. In addition, the specific operating
environment you use may require patches, updates, or bundles to
work correctly, and you should check the Centrify DirectControl
Release Notes for any environment-specific requirements before
installing. You should also always check the Web site of your
operating system vendor to identify the most recent patches and
updates available.

The files and directories you need to install on each Linux, Unix,
and Mac OS X computer you want to manage through Active
Directory are bundled together in a platform-specific software
package and installed using a native installation mechanism for each

platform. You can use the Centrify DirectControl installation script
to automatically invoke the proper installation mechanism for a
computer’s local operating system with the appropriate command
line options, or you can manually install any package by running the
appropriate installation command yourself. The following steps
assume you are using the Centrify DirectControl installation script
to install the Centrify DirectControl Agent.
If you want to install the package manually rather than through the
installation script, see “Installing an agent software package
manually” on page 399 for the installation command to use for the
specific version of Linux or Unix you have running on the
computer where you are installing the package.
Note If you are updating the Centrify DirectControl Agent from a
previous release, see “Updating from a previous release” on
page 125.
To install on a Linux, Unix, or Mac OS X computer:

1 Log on or switch to the root user if you are installing on a
computer running Linux or Unix, or log on with a valid user
account if you are installing on a computer with the Mac OS X
operating system.
Note Although you are not required to log on as the root user on
the Macintosh computer, you must know the password for the
Administrator account to complete the installation. In addition,
joining the domain and configuring your environment is slightly
different on Macintosh computers than on other platforms.
Therefore, you should follow the steps in the section “Joining the
domain from Mac OS X computers” on page 122 to join an
Active Directory domain on computers running the Mac OS X
operating system.
2 Mount the cdrom device using the appropriate command for the
local computer’s operating environment, if necessary. For
example on Linux, you can use a command similar to the
following if the CD drive is not mounted automatically:
Chapter 5 • Installing the Centrify DirectControl Agent on Unix 117

mount /mnt/cdrom
To manually mount the CD drive on AIX, run a command

similar to the following:
mount -v cdrfs -o ro /dev/cd0 /cdrom
When you auto-mount the Centrify DirectControl CD on

HP-UX, file names are displayed in the short name (8.3) format.
Therefore, on computers running HP-UX, you should mount
the CD manually using the -o rr (rockridge extensions) flag to
display the complete file names. For example, after you insert
the CD in the drive, run a command similar to the following to
display the long file names:
mount -F cdfs -o rr /dev/dsk/c0t0d0 /mnt/cdrom
Note If you have copied the package to another location or

downloaded the package from an FTP server or Web site and are
not using the CD, verify the location and go on to the next step.
3 Change to the appropriate directory on the CD or to the
directory where you have copied or downloaded the Centrify
DirectControl package. For example, to install on a Linux or
Unix computer from the Centrify DirectControl CD, change to
the Unix directory:
cd Unix
Similarly, if you are installing on a Mac OS X computer, change

to the MacOS directory.
4 Run the install.sh script to start the installation of Centrify
DirectControl on the local computer’s operating environment.
For example:
./install.sh
Follow the prompts displayed to select the services you want to

install and the tasks you want to perform. For example, you can
choose whether you want to join a domain automatically at the
conclusion of the installation.

Depending on your selections, you may need to provide
additional information, such as the user name and password to
use to join the domain.
When you complete the installation, the local computer will be
updated with the following directories and files for Centrify
DirectControl:
This directory Contains

/etc/centrifydc The Centrify DirectControl Agent configuration file
and the Kerberos configuration file.
/usr/share/centrifydc Kerberos-related files and service library files used
by the Centrify DirectControl Agent to enable group
policy and authentication and authorization
services.
/usr/sbin and /usr/bin Command line programs to perform Active
Directory tasks, such as join the domain and change
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 the computer is joined to, the Active
Directory site the computer is part of, and other
details.
Verifying the DNS configuration on Unix

Before you attempt to join the domain, you may want to verify that
DNS is configured correctly on the local Unix computer. Because
Centrify DirectControl uses DNS to locate the domain controllers
for the Active Directory forest, the appropriate DNS nameservers
need to be specific in the local /etc/resolv.conf file on each Unix
computer before the computer can join the domain. If you aren’t
sure whether DNS has been configured correctly, you can run the
adinfo --diag command to attempt to read the DNS records for
the domain you want to join. For example:
adinfo --diag domain_name

If DNS is properly configured, the command should display the

LDAP URLs for the domain controllers in the domain you want to
join. If the command indicates that the information is
<unavailable>, you should check the /etc/resolv.conf file and
edit it, if necessary, to include a domain controller for the domain
you want to join or a DNS server that can forward requests to an
appropriate domain controller.
For more information about troubleshooting the DNS
configuration and forward and reverse lookups of host names, see
“Working with DNS, Active Directory, and DirectControl” on
page 275.

When you install the Centrify DirectControl Agent on a Linux,
Unix, or Mac OS X computer, you can automatically join that
computer to an Active Directory domain by selecting this option in
the Centrify DirectControl installation script, install.sh. If you
choose to join the domain when you run the installation script, you
are prompted to specify the domain and a user name and password
for an Active Directory user with permission to add computers to
the domain.
If you don’t want to join the domain when you run the installation
script, you can manually join a domain after installation using the
adjoin command. Whether you add the computer to the domain
automatically from the install.sh script or manually using the
adjoin command, once the computer is part of the domain, you
can enable any existing Active Directory users to log in to the Unix
system.
Note On the Mac OS, joining the domain and configuring your
environment is slightly different than on other platforms.
domain from Mac OS X computers” on page 122 to join an Active

Directory domain when the Centrify DirectControl Agent is
installed on Mac OS X computers.
To join an Active Directory domain manually after installation with

the Centrify DirectControl Agent on a Linux or Unix computer:
1 On the Unix computer, log in as or switch to the root user.
2 Run adjoin to join an existing Active Directory domain. You
should join the domain using a fully-qualified domain name. For
example, to join the sales.acme.com domain with the user
account dylan:
adjoin --user dylan sales.acme.com
The user account you specify must have permission to add

computers to the specified domain and zone. In some
organizations, this account must be a member of the Domain
Admins group. In other organizations, the account simply needs
to be a valid domain user account. If you don’t specify a user
with the --user option, the Administrator account is used by
default.
Note You can use the Zone Delegation Wizard in the Centrify
DirectControl Administrator Console to specify which users and
groups have permission to join specific zones.
3 Type the password for the specified user account.
If Centrify DirectControl can connect to Active Directory and join
the domain, a confirmation message is displayed. You can now
enable existing Active Directory groups and users to work with this
Unix computer.
For more information about the options you can specify when
joining a domain, see the man page for the adjoin command or
“Using adjoin” on page 285.
To learn more about how to enable existing Active Directory
groups to work with this Unix computer, see “Adding standard
Active Directory groups to zones” on page 163.

To learn more about how to enable existing Active Directory users

to work with this Unix computer, see “Adding Active Directory
users to zones” on page 165.
Joining the domain from Mac OS X computers

When you install the Centrify DirectControl Agent on a computer
running the Mac OS X operating system, the steps for joining an
Active Directory domain are similar to the steps for joining the
domain on Linux or Unix computers but there are a few slight
differences.
After you install the Centrify DirectControl Agent on a computer
with the Mac OS, do the following to join that computer to an
Active Directory domain manually:
1 Go to the Applications > Utilities folder and double-click
Terminal to open a new terminal window.
2 Type the following command:
sudo adjoin --name computer_name domain_name
Note The default Macintosh computer name may be too long to

successfully join the domain. Therefore, in most cases, you
should use the --name option and specify a host name to use in
Active Directory when joining the domain.
3 When prompted for the password, type your Macintosh
Administrator password. For example:
Password: ***
4 When prompted for the Active Directory password, type the

password for the Active Directory Administrator account. For
example:
Active Directory Password: ***
Automounting files shares from Mac OS X computers If you configure NFS,

SMB, or AFP network file sharing for your Mac OS X computers,
you can automatically mount and log on to file shares using Active
Directory credentials.

To enable Mac OS X users to log on to file shares when your
network is configured with NFS, SMB, or AFP network sharing:
1 Open Active Directory Users and Computers or the Centrify
2 Select the user account for which you want to enable
automounting, right-click, then click Properties.
3 Click the Centrify Profile tab and set the Home directory
path to use one of the following formats:
/Users/user_login_name to set the user’s home directory to
the default home directory location for all user home
directories on Mac OS X computers.
/Network/Servers/server_name/path to automount a file
share on the NFS server_name you specify.
/SMB/server_name/share[/path] to automount a file share
on the SMB server_name you specify.
/SMB/unix_username/server_name/share[/path] to
automount a file share when you are using Fast User Switching
on the SMB server_name you specify.
/AFP/server_name/share[/path] to automount a file share
on the Apple server_name you specify.
/AFP/unix_username/server_name/share[/path] to
automount a file share when you are using Fast User Switching
on the Apple server_name you specify.
Note If you plan to use Fast User Switching to switch between
Active Directory users on the same computer, you should use
the /SMB/unix_username/server_name/share[/path] or
/AFP/unix_username/server_name/share[/path] format to
specify the user’s home directory to prevent conflicts between
users logging on using the same share. If you want to automount
a share on an Apple file server using the Apple File Protocol
(AFP), however, you must use Centrify DirectControl 3.0.1 or
later.

Using SMB shares on a Windows server For any Mac OS X users to access
SMB shares on a Windows server, you also need to disable the
Windows group policies that prevent this access.
To check and disable, if necessary, the Windows group policies that
prevent access to SMB shares:
1 Open Active Directory Users and Computers, select the
domain, right-click, then select Properties.
2 Click the Group Policy tab.
If the Default Domain Controller Policy is linked to this
domain, click Edit, then click Computer Configuration >
Windows Settings > Security Settings > Local Policies >
Security Options > Microsoft network server: Digitally
sign communications (always) and disable this policy.
If the Default Domain Policy is linked to this domain, click
Edit, then click Computer Configuration > Windows
Settings > Security Settings > Local Policies > Security
Options > Microsoft network server: Digitally sign
communications (always) and disable this policy.
If these group policies are not currently defined, you can leave
them not configured. If either policy is enabled and linked to the
domain, however, Mac OS X computers will not be able to use
SMB connections to automount the Windows file shares.
3 If you change these policies on the domain controller, run the
gpupdate command to refresh the group policies before logging
on to Mac OS X computers.
Restarting services after installing or joining the domain

You may need to restart some services on Unix computers where
you have installed the Centrify DirectControl Agent so that those
services will reread the name switch configuration file. For
example, if you typically log on to the Unix computer through a
graphical desktop manager such as gdm, you need to either restart
the gdm service or reboot the workstation to force the service to

read the updated configuration before Active Directory users can
log on. The most common services that need to be restarted are
sshd and gdm. If you are using these services, you should restart
them. For example, to restart sshd:
/etc/init.d/sshd restart
As an alternative to restarting individual services, you may want to

reboot the system to restart all services.
Note Because the applications and services on different servers may
vary, Centrify recommends you reboot each system to ensure all of
the applications and services on the system read the Centrify
DirectControl configuration changes at your earliest convenience.

If you are updating the Centrify DirectControl Agent from a
previous release:
1 Upgrade the Centrify DirectControl Management Tools on
Windows, if you have not already done so.
2 Install the Centrify DirectControl Agent using the Centrify
DirectControl install.sh installation script or by using the
upgrade option appropriate for the local operating environment
and package installer you are using.
The computer remains joined to the domain you previously
joined and your existing /etc/centrifydc/centrifydc.conf
file is backed up and any modifications you have made to the file
are migrated to the new version of the file.
If all of your zones were created in Centrify DirectControl 2.x or
later, no further steps are needed. If any agents were still joined to
an unconverted 1.x zone, you should convert or replace those
zones, then do the following:
1 Run the adleave command to leave the old version of the zone.

2 Run the adjoin command to rejoin the updated zone or a new,

if needed. For example:
adjoin --user raj --zone engineering eng.arcade.com
If you do not specify a zone to join, the computer will join the
“default” zone, if it exists. If you did not create the “default” zone
when you ran the Centrify DirectControl Setup Wizard, you
must specify a valid zone name to join the domain.
3 Restart running services, such as login, sshd, or gdm, or reboot
the computer to ensure all services use the updated
configuration. For example, you can run the following
command to stop running sessions:
pkill -1 sshd

On most Centrify DirectControl-managed systems, you can
remove the Centrify DirectControl Agent and related files by
running the uninstall.sh script. The uninstall.sh script is
installed by default in the /usr/share/centrifydc/bin directory
on each Centrify DirectControl-managed system.
To remove Centrify DirectControl on a Linux, Unix, or Mac OS X
computer:
1 Log on to the computer where the Centrify DirectControl
Agent is installed.
2 Run the uninstall.sh script. For example:
/bin/sh /usr/share/centrifydc/bin/uninstall.sh
The uninstall.sh script will detect whether the Centrify

DirectControl Agent is currently installed on the local computer
and will ask you whether you want to uninstall your current
Centrify DirectControl installation.
3 To uninstall Centrify DirectControl, enter Y when prompted.

If you cannot locate or are unable to run the uninstall.sh script,
you can use the appropriate command for the local operating
environment to remove the Centrify DirectControl Agent and
related files. The following table summarizes the commands to use
in different environments:
To remove from Do this

Red Hat Linux Run the following command:
rpm -e centrifydc
VMWare ESX Run the following command:

rpm -e centrifydc
SuSE Linux Run the following command:

rpm -e centrifydc
Debian Linux Run the following command:

dpkg -P centrifydc
Sun Solaris Run the following command:

pkgrm CentrifyDC
HP-UX Run the following command:

swremove CentrifyDC
IBM AIX Run the following command:

installp -u CentrifyDC.core
Mac OS X You must use the uninstall.sh script to remove Centrify

DirectControl files on Macintosh computers.


Chapter 6
Managing zones
This chapter describes how to create and configure zones for

managing access to the Linux, Unix, and Mac OS X computers in
your environment.
Using the Centrify DirectControl Setup Wizard
Creating a new zone
Opening and closing zones
Delegating control of administrative tasks
Changing zone properties
Adding a computer to a zone
Running reports for zones
Using the Centrify DirectControl Setup Wizard

The Centrify DirectControl Setup Wizard starts automatically the
first time you start the Centrify DirectControl Administrator
Console and, in most cases, you only need to run the Setup Wizard
during this initial configuration of the Active Directory forest and
domain. However, you can also use the Setup Wizard after the
initial configuration if you want to create or change the “default”
zone or migrate zone information from one type to another. For
example, if you want to change the location of the default container
object for new zones or convert a Centrify DirectControl zone to
an RFC-2307 compliant zone, you can re-run the Setup Wizard to
make these changes. When you re-run the Setup Wizard, the steps
129
Creating a new zone
you see will depend on the specific steps you took during the initial
configuration of Centrify DirectControl.
Creating a new zone

In most cases, you create the first Centrify DirectControl zone
when you run the Setup Wizard the first time you start the
Centrify DirectControl Administrator Console. If you created this
“default” zone using the Setup Wizard, you configured the zone
with a few basic properties. Zone properties are important because
they allow you to control the default settings for users and groups
in the zone, greatly simplifying the task of adding new Unix users
and groups to Active Directory.
Note If you did not create the “default” zone or did not configure
the zone properties using the Setup Wizard, you should check your
zone settings before you begin adding computers to the zone.
Computers are automatically added to the “default” zone when you
join them to the domain unless you specify a different zone. For
more information about configuring zone properties for an existing
zone, see “Changing zone properties” on page 137.
In addition to the “default” zone, you can create as many zones as

you need either in the default Zones container object or in other
organization units within Active Directory. To create new zones,
you need to be a domain administrator or have the permissions
described in “Setting rights to create and modify zones” on page 58.
Once you create a zone, you can delegate administrative tasks to
other users and groups through the Zone Delegation Wizard. In
most cases, only the user who creates a zone has the appropriate
rights to delegate administrative tasks to other users.
To create a new Centrify DirectControl zone:
1 Open the Centrify DirectControl Administrator Console.

2 If you are not currently connected to the appropriate forest,
click Connect to a Remote Forest and specify the forest
domain or domain controller to which you want to connect.
3 In the console tree, select Zones and right-click, then click
Create New Zone.
4 Type the zone name and description to create the zone in the
default container for new zones, then click Next.
If you want to select a different location for this zone, click
Browse and navigate to the container location you want to use
and click Create to create a new container or OK to use the
selected container. Once you specify the zone name, select a
location, and type a description, click Next.
5 Select the type of zone to create, then click Next. The zone type
identifies the schema definition to use for storing Unix attributes
in Active Directory.
Depending on the version of Windows and the functional level
of your Active Directory forest, you may see different zone
types. In most cases, you can choose one of the following zone
types:
Standard zone which stores Unix properties using the
Centrify DirectControl data model. Within a standard
Centrify DirectControl zone, Unix computers are treated as
Active Directory clients served by the Active Directory
domain controllers.
Microsoft Services for UNIX (SFU) zone which stores
Unix properties using the SFU schema extension. Within a
Microsoft Services for UNIX zone, Unix computers are
treated as NIS clients accessing a Network Information
Services server and domain. If you select this type of zone,
then click Next, you are then prompted to select the
Windows domain and the NIS domain associated with
the Windows Services for Unix (SFU) schema.
Chapter 6 • Managing zones 131

Creating a new zone
If you have raised the functional level of the Active Directory

forest to Windows Server 2003, you can also choose to create
zones that store Unix properties according to the RFC 2307
specification by selecting the Standard RFC-2307 zone type.
These different zone types give you maximum flexibility in
storing Unix properties and migrating Unix information from
one data model to another. For more information about the
Microsoft Services for Unix (SFU) data model, see the
Microsoft Services for Unix documentation. For more
information about RFC 2307, refer to the original Request for
Comments available at http://www.faqs.org/rfcs/rfc2307.
Note By creating a Centrify DirectControl zone for the
computers that rely on the SFU schema, you can use the Centrify
DirectControl Administrator Console to manage access to the
computers placed in the SFU-compliant zone. You can then add
users and groups to the SFU zone in the same way you add users
and groups to a standard Centrify DirectControl zone. For more
information about working with Services for Unix, see your
Microsoft documentation.
6 Type the numeric user identifier (UID) you want to start with
for new Unix users in this zone, then click Next.
For more information about setting and reserving UIDs for a
new zone, see Step 11 in “Starting Centrify DirectControl for
the first time” on page 105.
7 Type the numeric group identifier (GID) you want to start with
for new Unix groups in this zone, then click Next.
For more information about setting and reserving GIDs for a
new zone, see Step 12 in “Starting Centrify DirectControl for
the first time” on page 105.
8 Type the default location you want to use when creating new
home directories for new Unix users, then click Next.

For more information about setting the default home directory
for a new zone, see Step 13 in “Starting Centrify DirectControl
for the first time” on page 105.
9 Select the type of Unix shell you want to use as the default for
users in this zone, click Set as default, then click Next.
For more information about setting the default shell and
available shells for a new zone, see Step 14 in “Starting Centrify
DirectControl for the first time” on page 105.
10 Select the type of group to use as the default primary group for
new users, then click Next.
To use a standard Active Directory security group by default,
select Normal group, then click Next. You are prompted
to identify the Active Directory group you want to make the
default primary group before you can complete the zone
configuration. Click Browse to find the existing Active
Directory group to make the default primary group. Select
the group, click OK and review the Unix profile for the
group, then click Next to finish the zone configuration.
If you want to use private groups by default, select Private
group, then click Next to review your selections and finish
zone configuration. If you select Private group and have not
already created a container object for private groups, you are
prompted to create the container before you can finish the
zone configuration.
For more information about setting the default primary group
for a new zone, see Step 15 in “Starting Centrify DirectControl
for the first time” on page 105.
For more information about deciding whether to use a standard
Active Directory security group or an Active Directory private
groups as the default primary group for new Unix users, see
“Using private groups for Unix users” on page 162.
11 Check the selections you have made, then click Finish to
complete the zone configuration.


Because zone properties and Unix-specific objects are organized
into zones, you must open a zone to work with its contents. You
can have multiple zones open at the same time, but you must
explicit open each zone to work with it. Once you open a zone, it
stays open until you close it. For performance reasons, however,
you should close any zones you aren’t actively working with.
To open a zone:
2 In the console tree, select Zones and right-click, then click
Open Zone.
3 Type all or part of the name of the zone you want to open, then
click Find Now.
4 Select the zone to open from the list of results, then click OK.
You can use the CTRL and SHIFT keys to select multiple zones.
Once you open the zones you want to work with, you should save
your changes when you exit the Centrify DirectControl
Administrator Console, so that the open zones are displayed by
default the next time you start the Centrify DirectControl
Administrator Console. When you save your console settings, the
next time you start the Centrify DirectControl Administrator
Console, the console display will be the same as when you last used
the console.
To close an open zone:
1 In the console tree, select the specific zone name you want to
close and right-click, then click Close.
2 Click Yes to confirm that you want to close the zone.

You can use the Centrify DirectControl Administrator Console to
give specific users and groups permission to perform specific types
of administrative tasks within each zone. For example, assume you
have a zone called Finance and you want to set up different types of
permissions for the different kinds of users who access computers
in this zone. Through the Centrify DirectControl Administrator
Console, you can assign specific permissions to individual users and
groups. For example, you can delegate:
The group FinanceITStaff to perform All administrative tasks
within a zone, so that all members of that group can change
zone properties; add, modify, and remove users in the zone;
add, modify, and remove groups in the zone; and delete the
zone.
The group FinanceManagers to add, modify, and remove users
and groups from the zone.
The group FinanceUsers to change zone properties, but
perform no other tasks.
The users jason.ellison and noah.stone permission to delete
zone.
To delegate which users and groups have control over the objects in
a zone:
2 In the console tree, select Zones, then select and expand the
zone you are interested in, for example, open the default zone.
3 Right-click, then click Delegate Zone Control.
5 Click Add, find the User or Group to which you want to
delegate control, then click OK. When you are finished adding
users and groups, click Next.

6 Select the tasks you want to delegate to the user or group, then
click Next. For example, if you want members of the selected
user or group to be able perform all administrative tasks for a
zone, check the All task.
Note The domain administrator who creates a zone has full

control over the zone’s properties and permission to delegate
administrative tasks to other users. For each zone you create,
you should identify at least one group that can be delegated to
perform all administrative tasks. For example, if you have a
Finance zone, you may want to create a Finance Admins group
in Active Directory and then delegate All tasks to that group so
that members of that group can manage the zone. Although you
are not required to create or use a zone administrator group for
every zone, assigning the management of each zone to a specific
user or group simplifies the delegation of administrative tasks. If
you choose to use a finer grain control, for example, allowing
one group to only join computers to the domain and zone and
another to only add and remove users, you should ensure the
members of those groups know their restricted roles.
7 Review your selections, then click Finish.

As noted in “Creating a new zone” on page 130, zone properties
allow you to control the default settings for users and groups in the
zone. Normally, you set zone properties when you create a zone,
either using the Setup Wizard or when you create a new zone after
setup. You can, however, change the zone properties for an existing
zone, if needed. For example, after creating a zone you may find
you need to change the default starting point for user IDs or group
IDs.
To change the properties for an existing zone:
3 In the console tree, select Zones to display the list of zones.
4 Select a zone and right-click, then click Properties. For
example:

5 Click the appropriate tab to configure the default general, user,

and group properties for the zone, then click OK.
Setting General properties

On the General tab, you view the location of the zone in Active
Directory and the zone type. You can also modify the zone
description and configure specific permissions for the zone.
Setting Default Values properties

On the Default Values tab, you can configure the following zone
properties:
Add or remove Unix shells from the list of available shells for
the zone. The available shells are displayed in a selection list
when you edit the Centrify Profile for a user.
Set the default Unix shell to use for the zone. The default Unix
shell is automatically selected from the list of available shells
when you edit the Centrify Profile for a user.
Define the pattern to use when creating a new home directory
for a new Unix user. Because each home directory should be
uniquely named, you can use the ${user} keyword to create a
directory that includes the user’s Unix login name.
Set the default Active Directory group that users in this zone
should be members of. You can choose to create a private group
for each user or use an existing Active Directory group for each
user by default.
If you select the Private group option, creating a new Unix
user automatically creates a new Unix-enabled group with a
group name and GID that is based on the user name and UID.
Although private groups are maintained as Active Directory
groups, private groups can be used to simplify group
management outside of Active Directory. For example, users
can modify the membership of their private group to give

another user access to their files. For more information about
using private groups or Active Directory groups, see “Using
private groups for Unix users” on page 162.
If you select the Normal group option, you can click Browse
to search for an existing Active Directory group to make the
default primary group for new users.
Set permissions that allow specific users and groups to perform
specific types of administrative tasks within the zone. If you
click Permissions, the standard Windows Permissions dialog
box is displayed, but not all of the permissions you can access
from this dialog box apply to Centrify DirectControl.
Setting UID properties

On the UID Manager tab, you can configure the following zone
properties:
Set the starting value for numeric user IDs in the zone. By
default, new Unix users are automatically assigned the next
available UID for the zone. For example, if you set the default
UID for a zone to 500, the first Active Directory account that
you authorize to log on to the Unix shell is assigned a user ID of
500. The next user account that you give this permission to is
assigned a user ID of 501, and so on.
Add and remove reserved UID values. Reserved UIDs are the
specific user IDs that you want reserved for special purposes
and never assigned by Centrify DirectControl. For example, if
you run an application that requires a specific user account, you
may want to reserve the UID for that account so no other users
can be assigned that ID.

Setting GID properties

On the GID Manager tab, you can configure the following zone
properties:
Set the starting value for numeric group IDs in the zone. By
default, new Unix groups are automatically assigned the next
available GID for the zone. For example, if you set the default
GID for a zone to 500, the first Active Directory group account
that you authorize to log on to the Unix shell is assigned a group
ID of 500. The next group account that you give this permission
to is assigned a group ID of 501, and so on.
Add and remove reserved GID values. Reserved GIDs are the
specific group IDs that you want reserved for special purposes
and never assigned by Centrify DirectControl. For example, if
you run an application that requires a specific group account,
you may want to reserve the GID for that account so no other
groups can be assigned that ID.

There are two ways to add a computer to a zone:
By specifying a zone when you join the domain using adjoin.
By selecting a zone when you create or modify the computer
properties.
If you don’t specify the zone when you join the domain, computers
are added to the “default” zone. Normally, you create the “default”
the first time you start the Centrify DirectControl Administrator
Console. If you did not create the “default” zone using the Setup
Wizard, however, you must specify a zone for each computer to
successfully join an Active Directory domain. For more
information about specifying the zone, joining the domain, and
modifying computer properties, see Chapter 7, “Managing
computers.”

To view detailed information about all of your zones, you can run
the Zones Report.
To run a report:
1 Open Centrify DirectControl Administrator Console.
2 In the console tree, click to expand Centrify DirectControl
and open Reports.
3 Click Zones Report to generate a list of zones and related
details, such as the zone name, next available UID, next available
GID, available shells, the default home directory, and default
primary group.
4 If you want to filter information in the report to only include
zones matching specific criteria, click the Filters tab, select the
filtering criteria, and click Add. You can add multiple filters, if
needed. If you don’t specify a filter, the report includes
information for all zones in the Active Directory forest.
You can filter the report by zone name, default user group,
private group, reserved UID, next available UID, reserved GID,
or next available GID.
5 Click Run to start the report generation. When the report is
generated, it is displayed in a new Centrify Report window. For
example:
Each time you run the Zones Report, you generate a new report
about the zones currently defined. For more information about

generating and working with reports, see “Running reports” on

page 257.

Chapter 7
Managing computers
This chapter describes how to make Unix computers part of the

Active Directory forest, strategies for adding computers to
domains, and how to manage Unix-specific computer properties.
Using zones for Linux, Unix, and Mac OS computers
Understanding how a computer joins a domain
Deciding who can join computers to the domain
Preparing computer accounts before joining
Joining a domain interactively or using a script
Changing computer properties
Allowing password resets for computer accounts
Changing the domain for a computer
Leaving a domain
Running reports for computers
Customizing configuration settings for a computer
Using computer-based group policies

As discussed in “Using the Centrify DirectControl Setup Wizard”
on page 129, each computer is associated with one and only one
zone and there are several ways you can use zones to organize
computers to suit the specific needs of your organization. For
example, you can use zones to simplify the migration of existing,
143
legacy identity stores to Active Directory or as the foundation for

delivering configuration settings through group policies.
If you decide to use multiple zones in your environment, you
should consider the following in planning how best to organize
computers into groups:
How user accounts are currently managed for those Unix
computers. If you use local password and group files, users are
more likely to have multiple or conflicting account information.
If you already centrally manage user account information or
have consistent, enterprise-wide standards for user names and
IDs, home directory locations, and other settings, you are more
likely to be able to use a single zone.
Who uses the computers being accessed. You may find natural
zone boundaries by considering which departments or
functional groups access certain computers. For example, you
might place all of the computers used by software developers in
one zone and all of the computers used by the finance staff in
another.
How you plan to deploy. Zones can make it easier to manage a
staged deployment across the organization. Depending on the
size of the organization, you may find it useful to use multiple
zones to migrate users with multiple or conflicting Unix user
accounts to Active Directory over time, consolidating and
removing legacy accounts in stages.
How you want to delegate administrative tasks to the users and
groups in your organization. For example, if your environment
is widely distributed and managed through numerous, separate
administrative teams, you may want to use zones that mirror
that organizational structure.
If you only use one zone and you configured the “default” zone
using the Setup Wizard, you don’t need to specify the zone when
you add Unix computers to the domain. The join operation will
automatically add the computers to the “default” zone, which is

normally created the first time you start the Centrify
DirectControl Administrator Console. If you did not create the
“default” zone or use more than one zone, however, you should
explicitly set the zone for each computer in one of two ways:
By specifying a zone when you join the domain using adjoin.
By selecting a zone when you create or modify the computer
properties.
For more information about specifying the zone when joining the
domain with adjoin, see “Joining a domain interactively or using a
script” on page 150. For more information about selecting a zone
when modifying computer properties, see “Changing computer
properties” on page 152.

Before you can begin authenticating users and authorizing access to
Unix resources through Active Directory, your Unix computers
must be added to the appropriate Active Directory domains in your
organization’s Active Directory forest using the adjoin command.
When you run adjoin, the program locates the appropriate
domain controller for the domain you specify and contacts Active
Directory to add the computer to the domain. As part of this
process, the adjoin program performs a series of key tasks. For
example, when you join the domain, the program does the
following:
Synchronizes the local computer’s time with Active Directory
to ensure the timestamp of Kerberos tickets are accepted for
authentication.
Checks whether a computer account already exists for the local
computer in Active Directory. It creates a new Active Directory
computer account for the local computer, if needed.
Updates the Kerberos service principal names used by the host
computer, generating new Kerberos configuration and
Chapter 7 • Managing computers 145

krb5.keytab entries, as necessary, and generating new service

keys for the host and http services.
Sets the password on the Active Directory computer account to
a randomly-generated password. The password is encrypted and
stored locally on the Unix host to ensure Centrify
DirectControl alone has control of the account.
Starts the Centrify DirectControl daemon (adclient).
Once a computer joins the domain, you can use the Centrify
DirectControl Administrator Console or Active Directory Users
and Computers to manage its properties. By default, the computer
will function exactly as it did before joining the domain, allowing
local user accounts to log in and existing programs and applications
to work as they did previously, but you will have greater control
and flexibility to manage access through Active Directory. You can
also further customize authentication, for example to allow, ignore,
or deny individual users or groups permission to access to a
computer by setting Centrify DirectControl group policies or by
manually modifying the Centrify DirectControl configuration file,
centrifydc.conf, on any Centrify DirectControl managed
system.
By default, the password on the computer account is updated with
a new, randomly-generated password every seven days to ensure
security. You can customize how frequently the password for the
account is changed through Centrify DirectControl group policies
or by modifying the Centrify DirectControl configuration file,
centrifydc.conf, on any Centrify DirectControl managed
system.
For more information about using group policies to customize
computer settings, see “Managing group policies for Unix users
and computers” on page 181.For more information about
customizing the configuration file, see Appendix B, “Customizing
Centrify DirectControl configuration options.”

Active Directory provides various mechanisms for controlling who
is allowed to join computers to the domain. There are two basic
scenarios:
Any user with a valid domain account can add a computer to the
domain. This is the default configuration for Windows. It
permits any successfully authenticated user to add as many as
ten computers to the domain. Many enterprises leave their
domains set up this way so that administrative access is not
required for a computer to join the domain.
Permission to add a computer to the domain is restricted to a
set of privileged users. When permission to add a computer to
the domain is restricted, a user adding the computer must log in
with an account that has appropriate administrative rights and
provide a password. If your organization restricts who can add
computers to the domain, joining the domain might require
explicit permission. For example, joining the domain might be
restricted to domain administrator accounts or delegated within
Organizational Units to specifically designated users or groups.
Since who can join a domain depends on your organization’s
policies and is enforced through Active Directory, Centrify
DirectControl applies the same rules for Unix computers joining
the domain as have been defined in Active Directory for adding
Windows computers to the domain. For example:
If any user with a valid domain account can add a Windows
computer, adding a Unix computer does not require an
administrative user account and password.
If only administrative or delegated users are allowed to add
computers, the user adding the Unix computer must supply a
valid administrative or delegated user name and password.
If joining the domain is restricted to privileged users, an
administrator can choose to create a Unix computer account before

the computer joins the domain using the Windows NETDOM ADD
command, the dsadd computer command, or Active Directory
Users and Computers. (For information about the syntax for
running the commands, type NETDOM HELP ADD or dsadd computer
/? in a Command Prompt window.)
By preparing the Unix computer account in advance, you can

establish the organizational structure you want to use within Active
Directory even before the Unix computer joins the domain. In
addition, if you use Active Directory Users and Computers to add
the computer account, you can specify that a given user is the only
one authorized to join the domain. This can be useful to ensure that
individual users can add their own workstations to the domain
without any special rights or permissions.
If you create the computer account

before joining, you can identify a specific
user or group with permission to join the
domain
By adhering to Active Directory rules for joining the domain,

Centrify DirectControl provides you with flexibility and control
over how Unix computers are added and who is allowed to add
them. For more information about pre-configuring a computer
account in Active Directory, see “Preparing computer accounts
before joining” on page 149.

Preparing computer accounts before joining
One option for managing the Unix computers that are to be part of
a join is to prepare a computer account before joining the domain.
You can use Active Directory Users and Computers or the
command line interface to add the computer accounts for all or
some of your Unix computers.
If you create the computer account in advance, you can:
Specify a particular user or group with permission to join the
computer to the domain.
Create the organizational structure you want to use for Unix
computers in Active Directory, minimizing the need to move
the computer account after joining the domain.
Set other properties for the computer account, such as the
delegation properties for the computer account, so that when
the computer joins the domain it is configured appropriately
without requiring you to perform additional steps.
To prepare a computer account before the computer joins the
domain:
1 Open Active Directory Users and Computers.
2 In the console tree, right-click Computers, or right-click the
folder in which you want to add the computer.
3 Select New, then click Computer and type the computer
name.
Note Alternatively, you can create the computer account using
the command line interface with the command:
dsadd computer ComputerDN
If you are pre-configuring multiple Unix computer accounts,

you may want to write a script to add the accounts.

4 Click Change to select a specific user or group that you want to

give permission to add the computer to the domain, if desired,
then click Next through the rest of the New Object wizard.
5 Right-click the new computer object, then click Properties.
6 Set any additional properties for this computer account.
NoteAlthough you can set other properties, you cannot set any
Centrify Profile properties for the computer account until the
computer joins the domain.
7 Click OK.
You can now join the domain and enable Active Directory groups
and users to work with this Unix computer.

As described in “Understanding how a computer joins a domain” on
page 145, you join a computer to the domain by running the
adjoin command directly on a Unix host. You run this command
once for each Unix computer you want to add to a domain in the
forest.
In most cases, the administrator or a designated user runs the
command interactively at the command line, but the command can
be included in a script, if needed. In addition, there are several
optional arguments you can specify when you join the domain to
identify a specific user account with permission to join the domain,
the zone the computer should be part of, and the name to use for
the computer in Active Directory.
Whether you join the domain interactively from the command line
or using a script, you use the optional arguments to specify
information such as the zone or Organizational Unit you want to
place the computer in. For example:
adjoin --user shea@acme.com --zone LinuxDev sales.acme.com

In this example, the user shea is a member of the acme.com domain
rather than the sales.acme.com domain this computer is joining.
Therefore, the user account must be specified in the
user_name@domain_name format. In addition, this example
illustrates how to place the local Unix host in a specific Centrify
DirectControl zone, in this case, in a previously-created zone called
LinuxDev. This is most common format for the adjoin command
line. For more information about using the adjoin command line
options, see Appendix A, “Using Centrify DirectControl Unix
commands.”
Note Although you can specify the password as part of the adjoin
command line using the --password option, in most cases, you
should avoid including it for security reasons. If you are using adjoin
in a script, however, you may need to include the --password
option or provide another mechanism for inputting a valid
password.
If the adclient daemon is able to connect to Active Directory and

the join is successful, a confirmation message is displayed. If the
connection to Active Directory fails, a warning message is
displayed and the join operation fails.
If you did not pre-configure a computer account for the local Unix
host, by default, the join operation adds a new computer account to
Active Directory in the Computers container and enables access to
the Unix shell on the computer.


Once a computer joins the domain, one computer-based login
license is activated and the computer is available to any Active
Directory users you authorize to log in. After joining the domain,
you can modify the computer account properties to enable access
to Web applications or change the zone for the computer.
Enabling access to Web applications

The Centrify DirectControl Agent provides authentication services
to Web applications through server-specific, add-on modules. To
use these modules, you need to install the appropriate libraries and
modify the configuration of the Web server or Web application to
use Centrify DirectControl and Active Directory.
You can then update the computer account properties to allow
access to the Web applications hosted on your Unix computers. For
example, click Tomcat on the Centrify Profile tab to enable
access to Tomcat-based applications:
Select the type of

applications hosted on this
computer
For more information about configuring Web authentication

services for Apache, see the Centrify DirectControl Authentication

Guide for Apache. For more information about configuring Web
authentication services for Java applications such as Tomcat, JBoss,
WebLogic, and WebSphere see the Centrify DirectControl
Authentication Guide for Java Applications.
Changing the zone for the computer

If you don’t specify the zone when you join the domain, the
computer is added to the “default” zone created when you start
Centrify DirectControl for the first time. Over time, you may want
to migrate computers account from one zone to another. You can
change the zone information for a computer at any time, if needed.
To change the zone for the computer:
2 In the console tree, click Zones, then open the zone where the
computer account is located.
3 Click Computers to display the list of computers in the details
pane.
4 Select the computer that you want to modify, then click
Properties.
5 Click the Centrify Profile tab.
6 Click Browse and type all or part of the zone name, then click
Find Now.
7 Select the new zone from the list of results, then click OK.
After you change the zone in the Centrify DirectControl

Administrator Console, you must restart the Centrify
DirectControl Agent on the Unix computer. For example, on
the computer where you have changed the zone, run the
following command:
/etc/init.d/centrifydc restart
Alternatively, you can choose to restart the Unix computer,

which restarts all services.

8 Click Yes to acknowledge the need to restart the Centrify

DirectControl Agent on the Unix computer for the zone
information to be updated.

By default, most computer accounts do not have permission to
reset their own account password.This prevents the delegation of
administrative rights for the computer to the local computer
account. If you want to give a computer account administrative
rights in a zone, you need to modify the computer account to allow
password resets.
Checking for the appropriate permissions

To check whether a computer account allows password resets, you
need to view the permission settings for the account.
To check and modify the permissions for a computer account:
1 Open Active Directory Users and Computers, expand the
domain, and select Computers to find the computer account to
which you want to assign administrative rights.
2 Select the computer account, right click, then select
Properties.
3 Click the Security tab, scroll down the list of group or user
names and select SELF.
4 In the list of Permissions for SELF, scroll to the Reset
Password permission, click Allow, then click OK.
5 Select the computer account, right-click and select Reset
Account, then click Yes. When the account is reset, click OK.

Assigning administrative rights to computer accounts
To give administrative rights to the computer account:
2 In the console tree, select Zones, then select and expand the
zone you are interested in, for example, open the default zone.
3 Right-click, then click Delegate Zone Control.
5 Click Add, select Group from the Find list, then click Find
Now.
6 In the results, select Domain Computers, click OK, then
click Next.
7 Click Add Computers to Zone and optionally, Remove
Computers from Zone, then click Next.
Note In most cases, these are the only administrative tasks you
should assign to the computer account. You can, however, give
the account additional rights, if needed. For information about
the permissions associated with each delegated task, see
“Understanding permissions for the Zone Delegation Wizard”
on page 55.
8 Click Finish.
Joining the domain using the computer account

On the computer to which you have given administrative rights,
run the adjoin command and set the user name parameter to the
computer name with a dollar sign ($) appended and the password
to the computer name.
adjoin domain -u computername$ -p computername
For example, if the computer name is valencia and the Active

Directory domain is arcade.com, you would run a command
adjoin arcade.com -u valencia$ -p valencia


Once a computer joins a domain, you must leave that domain using
adleave command before you can join a new domain.
To change the domain for a computer:

1 Log in as or switch to the root user. For example:
su -
2 Run adleave to remove the computer account from the old

domain. This command disables the computer account in Active
Directory but does not delete the computer account. For
example, to leave the current domain using the default
Administrator user account and password:
adleave
3 Type the Active Directory password for the user account you
specified.
If the adclient daemon is able to connect to Active Directory
and the leave operation is successful, a confirmation message is
displayed.
4 Run adjoin to join a different Active Directory domain. For
example:
adjoin --user gharris operations.acme.com
In this example, the user gharris is a member of the

operations.acme.com domain that this computer is joining.
specified.
For more information about using the adjoin and adleave
commands, see Appendix A, “Using Centrify DirectControl Unix
commands.”

Leaving a domain
You can remove a computer from a domain at any time by using the
adleave command. Leaving the domain removes the Unix
computer from its current Active Directory domain and reverts
any computer settings that were changed by the adjoin command
to their pre-adjoin condition. This includes reverting PAM, NSS,
and Kerberos configuration files to their pre-adjoin states and
deleting /etc/krb5.keytab. You must leave the domain before you
can move a computer account to a new domain or remove Centrify
DirectControl from a Unix computer.
Note Although the adleave command removes the Unix computer
from its current domain, it does not delete the computer account
from Active Directory. If you want to completely remove any
record of the computer from Active Directory, you must delete the
computer object in Active Directory Users and Computers.
To remove a computer from its current domain:

1 Log in as or switch to the root user. For example:
su -
2 Run adleave to remove the computer account from the old

domain. For example, to leave the current domain using the user
account and password raj@acme.com:
adleave --user raj@acme.com
specified.
If the adclient daemon is able to connect to Active Directory and
the leave operation is successful, a confirmation message is
displayed and the Centrify DirectControl Agent is stopped.


To view detailed information about all of your Unix computers,
you can run the Computers Report.
To run a report:
and open Reports.
3 Click Computer Report to generate a list of Unix computers
and related details, such as the zone, the computer name, the
DNS name for the computer, the operating system and OS
version.
computers matching specific criteria, click the Filters tab, select
the filtering criteria, and click Add. You can add multiple
filters, if needed. If you don’t specify a filter, the report includes
information for all Unix computers in the Active Directory
forest.
You can filter the report by Active Directory computer name,
operating system, shell access, zone, or application access. For
example, you can filter the report so that in only includes
computers used to access applications by selecting the
Application Access Enabled = true filter.
5 If you want to sort the information in the report using specific
criteria, click the Sort tab and select the sorting criteria and sort
order you want to use for the report. For example, you can sort
computer information by Active Directory computer name in
either ascending or descending order.
6 If you want to group the information in the report using specific
criteria, click the Group tab and select an option from the
Group by list to indicate how you want to group information.

You can group computer information by computer name or
zone.
generated, it is displayed in a new Main Report pane. For
example:
Each time you run the Computers Report, you generate a new
report about the Unix computers currently enabled. For more
information about generating and working with reports, see
“Running reports” on page 257.
Customizing configuration settings for a computer

In addition to settings in Active Directory, you can further
customize settings for individual computers through Centrify
DirectControl group policies or by modifying the computer’s local
Centrify DirectControl configuration file. For example, you can set
policies to bypass Active Directory authentication for specific
accounts on certain computers.
Because these policies can be customized through group policies
and Active Directory or locally using the configuration file, or
through a combination of local and Active Directory settings, you
have a great deal of flexibility in controlling access to each
computer and customizing your environment.


Windows group policies allow you to specify a variety of
configuration options and apply those settings to specific groups of
computers and users based on the site, domain, or organizational
unit where a Group Policy Object is applied. Centrify
DirectControl extends the configuration management capabilities
of Windows Group Policy Objects to allow you to configure
settings for DirectControl-managed Unix computers. The Centrify
DirectControl group policies are defined in a Centrify
DirectControl Administrative Template and can be installed as an
optional component on a Windows computer when you run the
setup program.
Although there are a few Windows group policies that can be
applied to Unix computers, most of the Centrify DirectControl
Computer Configuration policies control settings in the Centrify
DirectControl configuration file,
/etc/centrifydc/centrifydc.conf.
When you apply a Group Policy Object that contains Centrify

DirectControl group policies to an Organizational Unit, domain,
or site that includes Unix computers, your policy settings update
the configuration of the Unix computer each time the computer is
rebooted. Policy settings can also be refreshed at a set interval or
updated on-demand by running the adgpupdate command.
computer settings, see “Managing group policies for Unix users
and computers” on page 181. For details about specific policy
settings, see the Centrify DirectControl Administrator Console
Help. For more information about customizing access control using
the Centrify DirectControl configuration file and configuration
parameters, see “Customizing Centrify DirectControl
configuration options” on page 323.

Chapter 8
Managing users and groups
This chapter describes how to enable access to Linux, Unix, and

Mac OS X computers for Active Directory users and groups and
how to manage user and group properties though Centrify
DirectControl.
Understanding user access
Adding standard Active Directory groups to zones
Adding Active Directory users to zones
Modifying the Unix profile for users or groups
Applying password policies and changing passwords
Working in disconnected mode
Mapping local Unix accounts to Active Directory
Setting a local override account
Importing user and group information
Running reports for users and groups
Customizing configuration settings for users and groups
Using user-based group policies
Understanding user access

With Centrify DirectControl, the Active Directory users for whom
you enable Unix access can type their Active Directory user name
and password at any computer in the zones they have been given
161
permission to access. Therefore, you should do some planning to

evaluate how you can use group membership and zones to control
access. You should also determine whether you will use existing
Active Directory groups and user accounts or create new Active
Directory groups and users and whether you have existing Unix
group and user account information to import from legacy identity
stores. For more information about using zones to manage access,
see “Using the Centrify DirectControl Setup Wizard” on page 129.
Group membership and zones are also key components of
controlling access to Web applications through Centrify
DirectControl. The Centrify DirectControl Agent provides
authentication services for Web applications through
server-specific, add-on modules. To use these modules, you first
need to install the appropriate libraries and modify the
configuration of the Web server or Web application to use Centrify
DirectControl and Active Directory. You can then use Active
Directory groups to control authentication and authorization for
Active Directory users. For more information about configuring
Web authentication services for Apache, see the Centrify
DirectControl Authentication Guide for Apache. For more information
about configuring Web authentication services for J2EE
applications such as Tomcat, JBoss, and WebLogic, see the Centrify
DirectControl Authentication Guide for Java Applications.

In the Unix environment, every user account is associated with one
primary Unix group. This primary group defines the user’s file
ownership and permissions on the Unix computer. Because of this
requirement, any time you create a Unix profile for an Active
Directory user, you must specify the primary group for that user.
The primary group you specify for any user can be either a standard
Active Directory group, for example an existing domain or global
security group, or a private group.

A private group is an Active Directory group that can be reserved
for the exclusive use of an individual user within a specific zone. By
using private groups, you can allow users to manage group
membership and file access permissions outside of Active
Directory. For example, users can modify the membership of their
private group to give another user access to their files.
Depending on the zone properties you set, new Unix users are
assigned either a private group or a normal Active Directory group
by default. If you choose to use a private group, the Unix group
profile is created automatically and assigned the same name and
GID as the user account.
Because private groups can be used on a zone-by-zone basis, you
may find it convenient to use them while you plan your Active
Directory group strategy and zones. For example, if you are
importing account information from an existing identity store, you
may want to use private groups to set up accounts in Active
Directory without impacting any of your existing Active Directory
group management infrastructure. You may also want to use
private groups to allow individual users to maintain control over
their files on the Unix computers they log on to within each zone.
If you already have a well-defined Active Directory group
structure, however, you may simply want to add Unix users to the
appropriate groups within that structure. Whether you choose to
use private groups or your existing Active Directory group
structure, you can change the primary group for any user at any
time by modifying the user’s Unix profile.

In Active Directory, security groups are used to control access to
computers and network resources. When you create a group, you
define the scope of accounts that can be members and the scope of
permissions that can be applied. For example, the members of a
domain local group can only be assigned permissions within their
Chapter 8 • Managing users and groups 163

local domain, while members of a global group can be assigned

permissions for any domain in the forest.
For Centrify DirectControl, you can enable Unix access for domain
local, global, or universal groups and can use nested groups in the
same way you use them for Windows computers.
Any existing Active Directory security group can be enabled for
Unix access in any zone. You can also use any standard Active
Directory security group as the primary group for Unix users in
any zone, if desired.
Note Only Active Directory security groups are supported for
authentication and authorization. Centrify DirectControl does not
support distribution groups for authentication and authorization.
Enabling Unix access for Active Directory groups gives you greater
control, consistency, and visibility for managing user accounts. For
example, you can create a nested group hierarchy in Active
Directory to manage Unix users accounts in the same way you
manage Windows accounts. Whether you create new Unix-specific
groups or use existing Active Directory groups access to Unix
computers depends on the needs of your organization and the
structure of your Active Directory forest.
Once you have identified the Active Directory groups that you
want to use, there are two ways to give an existing Active
Directory group access to Linux, Unix, and Macintosh computers:
You can use Active Directory Users and Computers to open the
Properties for a group, then click the Centrify Profile tab to
specify Unix properties for the group.
You can use the Centrify DirectControl Administrator Console
to add a group to any Centrify DirectControl zone.
For simplicity, the following steps describe how to add groups to a
Centrify DirectControl zone.
To add groups to a Centrify DirectControl zone:

2 In the console tree, click Zones and select the zone name to
which you want to add the Active Directory group.
If the zone is not already open, right-click, then click Open
Zone. For example, select and open the “default” zone.
3 Select Groups, right-click, then click Add Group to Zone.
4 Type a search string to locate the group, then click Find Now.
For example, type “fin” to display the FinanceUsers and
FinanceAdmins groups.
5 Select one or more groups in the results, then click OK.
6 Review the Unix profile settings for the group and make any
changes, then click OK. If you selected more than one group,
review the Unix profile settings for the each group and modify
the default settings, if necessary, then click OK.
Note Adding an Active Directory group to a Centrify
DirectControl zone sets up a Unix profile for the group account,
but it does not create Unix profiles for any members of the group or
automatically give any group members access to the zone. User
accounts must be explicitly enabled for each zone the user has
permission to access.

Any existing Active Directory user can be enabled for Unix access
in any zone. In many organizations, Unix users already have Active
Directory accounts to access resources in the Windows network. If
appropriate user accounts already exist, enabling access to Linux,
Unix, and Macintosh computers is simply a matter of modifying the
properties for the user. There are two ways to give an existing
Active Directory user access to Unix:
Properties for a user, then click the Centrify Profile tab to
specify Unix properties for the user.


to add a user to any Centrify DirectControl zone.
For simplicity, the following steps describe how to add users to a
Centrify DirectControl zone from the Centrify DirectControl
To add users to a Centrify DirectControl zone:
2 On the Centrify DirectControl Administrator Console main
page, click Add User to Zone.
3 Click Add to add an Active Directory user to the currently
selected zone.
If you want to add the user to a different zone, click Browse to
search for and select the zone to which you want to add the
Active Directory user.
4 Type a search string to locate the user account, then click Find
Now. For example, type “tes” to display the testuser and
testadminusers.
5 Select one or more users in the results, then click OK.
6 Review the Unix profile settings for the user and make any
changes necessary, then click OK. If you selected more than one
user, review the Unix profile settings for the each user and
modify the default settings, if necessary, then click OK.
Note By default, setting the primary Active Directory group in
a Unix user’s profile does not affect user’s actual Active
Directory group membership. It simply identifies a primary
group name and GID for the user when accessing Unix
computers. If you want to automatically add users to the Active
Directory group you are using as the default primary group for a
zone, you can do so by selecting the Associate Active
Directory group membership option in the Zone
Properties dialog box. To display this option, however, you

must manually add a new DWORD key to the registry and set
the key to a non-zero value. In the Registry Editor, open
HKEY_LOCAL_MACHINE\Software\Centrify\CIMS, right-click
and select New > DWORD Value, then set the name of this
registry entry to EnableGroupMembershipAssociation
and the value to one. After you modify the registry, the
Associate Active Directory group membership option is
displayed on the General tab in the Zone Properties dialog box.
Adding users from another trusted forest

In most cases, when you add users to a zone to enable access to
Unix computers, those users already have an account in the local
Active Directory forest. If you have established a two-way trust
relationship with another Active Directory forest, you can also add
users from that remote forest to Centrify DirectControl zones. You
add these remote user accounts to the zone in the same way you
add local user accounts except that you must select the remote
forest or domain before searching for the user account.
To add users from another trusted forest to a Centrify
DirectControl zone:
2 Click Add User to Zone.
3 Click Add to add an Active Directory user to the currently
selected zone or click Browse to search for and select a different
zone.
4 Click Browse, then select the trusted forest or a specific
domain in the trusted forest, then click OK. For example, if
there is a two-way forest trust between the local wonder.land
forest and the remote w2k3r2.dev forest, you can select the

remote forest, then click OK to add users from the w2k3r2.dev

forest to a local zone:
Local forest
Trusted forest
Note You can only add users from the remote forest to a local
Centrify DirectControl zone. You cannot add groups from the
remote forest.
5 Type a search string to locate the user in the selected forest or
domain, then click Find Now.
6 Select one or more users in the results, then click OK.
7 Review the Unix profile settings for the user and make any
changes necessary, then click OK.
Users from a remote forest are identified in the Centrify
DirectControl Administrator Console with the following icon:

You can modify the Unix profile for an Active Directory user or
group in one of two ways:
Properties for a user or a group, then click the Centrify Profile
tab to modify the Unix properties for that user or group.

and right-click any user or group in any zone, then click the
Centrify Profile tab to modify the Unix properties associated
with that user or group in the selected zone.

Centrify DirectControl enforces all of the password policies you
have defined in Active Directory for the Unix accounts you enable.
Therefore, if you create a new Unix user account that requires a
password change the next time the user logs on, the user is
prompted to change the password the next time she logs on to
either a Windows or Unix computer.
When the user provides a new password, Centrify DirectControl
checks the new password to make sure it conforms to Active
Directory policies for length and complexity. If the new password
meets all of the criteria, the account is updated with the new
information in Active Directory and the user logs on successfully.
Centrify DirectControl also enforces the password expiration
period, the password reuse policy, account lock out policy,
workstation restrictions, and logon hour restrictions if you have
defined these policies for any user account. In addition, Centrify
DirectControl displays a warning message on the Unix computer if
a user’s password is about to expire.
Administrators can set, reset, or change the password for users
using Active Directory or from the Unix command line. Individual
users can also change their own password at any time using the
adpasswd command.
Changing your own password

Normally, you are prompted to change your password based on the
password policies defined in Active Directory. For example, if you
attempt to log in but your password has expired, you are prompted
to provide your old password, a new password, and to confirm

your new password. However, you can also change your own
password at any time using adpasswd.
To change your own password using adpasswd:
1 At the Unix command line, run the following command:
adpasswd
2 Type your old password. When changing your own password,

you must always provide your old password.
3 Type the new password. The password should conform to
Active Directory password policies.
4 Retype the new password.
For more information about using adpasswd, see “Using adpasswd”
on page 297.
Changing another user’s password

The adpasswd command can be used to change the password of
another Active Directory user if you provide the user name and
password of an administrative account with the authority to change
another user’s password.
To change the password for another user using adpasswd:
1 At the Unix command line, run the adpasswd command and
specify an Active Directory administrative account name with
the authority to change the password for users in the domain. For
example, to use the admin user account to change the password
for the user jane in the sales.acme.com domain:
adpasswd --adminuser admin@acme.com jane@sales.acme.com
2 Type the password for the administrative account. For example:

Administrator password: xxx
3 Type the new password for the user specified. Because you are
changing another user’s password, you are not prompted for an
old password. For example:
New password:

4 Retype the new password.
Repeat password:
For more information about using adpasswd, see “Using adpasswd”

on page 297.
Working in disconnected mode

Once an Active Directory user logs on to a Unix computer
successfully, the authentication is cached by the Centrify
DirectControl daemon. These credentials can then be used to
authenticate the user in subsequent log on attempts if the user is
disconnected from the network or an Active Directory domain
controller is not available.
For security reasons, the cached credentials can be configured to
expire after a set period of time. You can configure the length of
time credentials should be considered valid by modifying the
Centrify DirectControl group policies or the Centrify
DirectControl configuration file. For more information about using
group policies, see “Managing group policies for Unix users and
computers” on page 181. For information about changing settings
in the configuration file, see Appendix B, “Customizing Centrify
DirectControl configuration options.”
If there are changes to an account while the account is running in
disconnected mode, the changes don’t take effect until the user
reconnects to Active Directory to start a new session or access a
new service. For example, if a user account is disabled or has its
password changed in Active Directory while the user is
disconnected from the network, the user can still log on and use
the old password until reconnected to the network. Once the user
reconnects to Active Directory, the changes are taken into account
and the user is denied access or prompted to provide an updated
password.
Note You cannot change your Active Directory password when you
are working in disconnected mode.


By default, local Unix user accounts are still valid on the Unix
computers that join the Active Directory domain. You can then
enable or disable access selectively for individual local users and
groups by modifying Centrify DirectControl group policies or the
Centrify DirectControl configuration file on any computer, as
needed. For some local Unix accounts, however, you may want to
control access by mapping the 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, it is
especially useful for controlling access to accounts that have special
privileges. For example, the local root account on each Unix
system has broad authority. By mapping this account to an Active
Directory account and password:
You control access to the root account because users need to
know the Active Directory password for the account.
You ensure Active Directory password policies are applied to
the root account password, so that each root password is
complex enough or changed frequently enough to be secure.
Although this mapping is especially useful for the root account, it
can be done for any local user account. For example, many
applications have their own superuser type of account with
permission to perform restricted operations. If you want to enforce
Active Directory password policies for any such account or 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

The most likely candidate for account mapping is the root user
because every Unix computer has its own root account. Although
you could leave this account as a locally managed account on every
computer and not use Active Directory authentication for it,

mapping this account to an Active Directory account gives you
greater control over the password policies associated with the
account and a convenient way to manage access to the root
password.
In most cases, however, you would not want to create a single user
in Active Directory for the root account because this would
compromise the security of your network, giving anyone with the
root password root-level access to every Unix computer in the
forest. To prevent this problem, Centrify DirectControl allows you
to map the local root user account to another user name in Active
Directory for password validation.
You can use a separate Active Directory user account for each Unix
computer, so each root user has a unique name and password, or
you can use one Active Directory user account for a group of Unix
computers, so that there are fewer accounts and passwords to
manage. For example, if you have a group of computers you have
organized in a 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, then map that user to the local root user using the
User Map group policy for Unix computers.
When users log in as root, they are authenticated using the
password for the Active Directory account you created. For
example, if the user logs on with root and the password &tiger1,
Centrify DirectControl checks the Active Directory password for
the account root is mapped to, such as root_webfarm. If the
password &tiger1 is valid for the Active Directory account, the
user is authenticated and allowed to log on.
Although by default, Centrify DirectControl maps the local root
account to an Active Directory account of root_zonename, you can
change the Active Directory account you want to map to on any
computer by group policy or by modifying the computer’s Centrify

To map the local root account to the default Active Directory user,
you simply need to create the Active Directory user account using
the root_zonename naming convention.
To map the local root account on a specific computer to an Active
Directory user:
1 Create the Active Directory user account you want to use. For
example, if you want to use a unique Active Directory account
for each root account, you may want use the computer’s host
name in the Active Directory account name.
2 On the Unix computer, open the Centrify DirectControl
configuration file /etc/centrifydc/centrifydc.conf.
3 Modify the local account mapping so that the local root user is
mapped to the Active Directory you created. You can use
environment variables such as $DOMAIN, $ZONE, or $HOSTNAME if
you used the domain, zone, or host name in the Active Directory
account name. For example:
pam.mapuser.root: root_$HOSTNAME
Note If you are mapping the account on a single computer or

don’t want to apply group policies to Unix computers, you
should edit the Centrify DirectControl configuration file
directly. Alternatively, you can use group policies to map local
Unix users and groups to Active Directory accounts for sets of
computers.
For more information about using group policies, see “Managing
group policies for Unix users and computers” on page 181. For
more information about modifying the Centrify DirectControl
configuration file and editing configuration parameters, see
“Customizing Centrify DirectControl configuration options” on
page 323. For details about specific policy settings, see the Centrify
DirectControl Administrator Console Help.

Mapping other local Unix accounts
You can use Centrify DirectControl group policies to map any
local Unix users or local Unix groups to Active Directory accounts,
or you can manually edit the centrifydc.conf configuration file
on any DirectControl-managed computer to map local user or
group accounts to Active Directory.
For example, to map a local Unix user account to an Active
Directory user using the Centrify DirectControl User Map group
policy:
1 Create an Active Directory user account.
2 Create a new Group Policy Object or select an existing Group
Policy Object and add the Centrify DirectControl
Administrative Templates to the object.
3 In the Group Policy Object Editor, open the Computer
Configuration > Administrative Templates >
CentrifyDC Settings policy folder.
4 Select the User Map policy, right-click, then click
Properties.
5 Click Enabled, then click Show.
6 Click Add and type the local Unix user account in the first field
and the Active Directory account to which the local user is
mapped in the second field, then click OK. For example, if the
local user is oracle and the Active Directory account you
created is DBAdmins:

7 Click Add to create other user maps or click OK to save this

configuration.
8 Apply this Group Policy Object to the appropriate
Organizational Unit, domain, or site.
When users attempt to sign on using the local oracle Unix
account, they must provide the password for the DBAdmins Active
Directory account. When you use account mapping in this way, you
can ensure the same password policy used for Active Directory
passwords applies to local user accounts.
For more information about using group policies to map local Unix
accounts to Active Directory accounts, see “Managing group
policies for Unix users and computers” on page 181. For more
information about modifying the Centrify DirectControl
configuration file and editing configuration parameters, see
page 323.

In most cases, every computer should have at least one account that
can be authenticated locally to ensure you can access the system
when Active Directory is not available or the Centrify
DirectControl daemon is not running. By default, the local
override account is set to the 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 group policy or by modifying the computer’s Centrify
For more information about working with group policies, adding

Centrify DirectControl group policies to Group Policy Objects,
and applying Group Policy Objects, see “Managing group policies
for Unix users and computers” on page 181. For more information

about modifying the Centrify DirectControl configuration file and
editing configuration parameters, see “Customizing Centrify
DirectControl configuration options” on page 323. For details
about specific policy settings, see the Centrify DirectControl
Administrator Console Help.
Importing user and group information

In many cases, you may already have Unix account information that
you want to map to Active Directory users and groups. You can do
this by importing the existing account information and specifying
how those existing accounts map to Active Directory users and
groups. Existing account information is typically stored in either a
Network Information Service (NIS) server or in local configuration
files.
If you have existing user and group information stored in either NIS
or in local files, you can selectively import this information into
Active Directory using the Centrify DirectControl Administrator
Console. For information about importing existing information
into Active Directory, see “Importing information from NIS maps
or Unix files” on page 223.

To view detailed information about all of your Unix users or
groups, you can run the Users Report or the Groups Report.
To run a report:
and open Reports.
3 Click the type of report you want to generate. For example,
click Users Report to generate a list of Unix users and related
details, such as the zone, UID, and home directory for each user,

or click Groups Report to generate a list of Unix groups and

related information.
users matching specific criteria, click the Filter tab, select the
filtering criteria, and click Add. You can add multiple filters, if
needed. If you don’t specify a filter, the report includes
information for all Unix users or all Unix groups in the Active
Directory forest.
For the Users Report: You can filter the report by Active
Directory user name, Unix name, Unix UID, or zone.
For the Groups Report: You can filter the report by group
type Active Directory group name, Unix GID, or Unix group
name.
5 If you want to sort the information in the report using specific
criteria, click the Sort tab and select the sorting criteria and sort
order you want to use for the report. For example, you can sort
user information by Active Directory user name in either
ascending or descending order.
For the Users Report: You can sort the report by Active
For the Groups Report: You can sort the report by Active
Directory group name, Unix GID, or Unix group name.
6 If you want to group the information in the report using specific
criteria, click the Group tab and select an option from the
Group by list to indicate how you want to group information.
For the Users Report: You can group user information by
user, primary group, or zone.
For the Groups Report: You can group information by
primary group or zone.

generated, it is displayed in a new Centrify Report window. For
example, the Users Report looks similar to the following:
Each time you run the Users Report or Groups Report, you
generate a new report about the users or group currently defined.
For more information about generating and working with reports,
see “Running reports” on page 257.
Customizing configuration settings for users and

groups
In addition to settings in Active Directory, you can further
customize access control by modifying the group policies applied to
a user or computer or by customizing the settings in any
computer’s local Centrify DirectControl configuration file. For
example, you can set policies to bypass Active Directory
authentication for specific users or groups.
Because these policies can be customized through group policies
and Active Directory or locally using the configuration file, or
through a combination of local and Active Directory settings, you
have a great deal of flexibility in controlling access to each
computer and customizing the access controls for specific users and
groups to suit your environment.
settings for users and groups, see “Managing group policies for
Unix users and computers” on page 181. For more information
about customizing access control using the Centrify DirectControl

configuration file and configuration parameters, see “Customizing

Centrify DirectControl configuration options” on page 323.

You can configure many aspects of the environment for individual
users by setting and applying group policies to Active Directory
sites, domains, and organizational units. Centrify DirectControl
extends the configuration management capabilities of Windows
Group Policy Objects to allow you to configure settings for users
who log on to DirectControl-managed computers. The Centrify
DirectControl group policies are defined in a Centrify
DirectControl Administrative Templates, which can be installed as
an optional component on a Windows computer when you run the
setup program.
When you apply a Group Policy Object that contains Centrify
DirectControl group policies to an Organizational Unit, domain,
or site that includes Unix users, the Centrify DirectControl
user-based policies are applied when any of those Unix users logs
on to a Unix computer. Policy settings can also be refreshed at a set
interval or updated on-demand by running the adgpupdate
command.
For more information about working with group policies, adding
Centrify DirectControl group policies to Group Policy Objects,
and applying Group Policy Objects, see “Managing group policies
for Unix users and computers” on page 181. For details about
specific policy settings, see the Centrify DirectControl
Administrator Console Help.

Chapter 9
Managing group policies for Unix users

and computers
Centrify DirectControl group policies allow administrators to
extend the configuration management capabilities of Windows
Group Policy Objects to managed Unix computers and users. This
chapter provides an overview of what group policies provide, how
they are implemented and applied, and how you can define and link
group policies for Unix computers and users.
Understanding Group Policy Objects
Understanding group policy for Unix
Adding Unix policies to a Group Policy Object
Creating a Centrify DirectControl Group Policy Object
Setting policies for Unix computers and users
Linking a Group Policy Object to a container
Reporting group policy settings
Editing the Centrify DirectControl configuration file
Defining custom group policies
Note This chapter provides an overview of key concepts for
working with group policies and Group Policy Objects in an
environment that includes Unix users and Unix computers. For
more complete information about creating and using group policies
and Group Policy Objects, see your Windows or Active Directory
documentation.
181

Group policies allow you to specify a variety of configuration
options and apply those settings to specific groups of computers
and users. In a standard Windows environment, these
configuration settings control many aspects of computer operation
and the user experience, including the user’s desktop environment,
startup and shutdown scripts, local security enforcement, user-
and computer-based registry settings, and software installation and
maintenance services.
When you define policy settings, they are stored in a Group Policy
Object (GPO). Each Group Policy Object can consist of
configuration information that applies to computers, configuration
information that applies to users, or sections of policy specifically
devoted to each.
There are two default Group Policy Objects installed when you
install or promote a Windows domain controller:
Default Domain Controllers Policy
Default Domain Policy
You can use these default Group Policy Objects to include settings
for Unix computers and users or you can create your own custom
Group Policy Objects, as needed.
Understanding how Group Policy Objects are applied

Depending on your environment, you can link Group Policy
Objects to organizational units, domains, and sites using an Active
Directory MMC snap-in, such as Active Directory Users and
Computers, or using the Group Policy Management Console.
Note To set Group Policy for a selected Active Directory site,
domain, or organizational unit, you must have read and write
permission to access the system volume of the domain controller
and the right to modify the selected directory object.

Once you define and link a Group Policy Object to an
organizational unit, domain, or site, the policies are applied when
computers are rebooted, when users logon, or at the next update
interval if you have specified that you want to periodically refresh
the policies. Because you can apply multiple Group Policy Objects
and can link to them throughout the hierarchical structure of your
organization, policies are applied in the following order unless you
explicitly configure them to behave differently:
Local Group Policy Objects are applied.
Site-level Group Policy Objects are applied in priority order.
Domain-level Group Policy Objects are applied in priority
order.
Organizational Unit-level Group Policy Objects are applied in
priority order down the hierarchical structure of your
organization, so that the last Group Policy Object used in the
one that applies to the Organizational Unit the user or
computer resides in.
As this set of rules suggests, a Group Policy Object linked to a site
applies to all domains at the site. A Group Policy Object applied to
a domain applies directly to all users and computers in the domain
and by inheritance to all users and computers in organizational
units and containers farther down the Active Directory tree. A
Group Policy Object applied to an organizational unit applies
directly to all users and computers in the organizational unit and by
inheritance to all users and computers in organizational units
farther down the Active Directory tree. You can modify the specific
users and computers the GPO is applied to by choosing a different
point in the hierarchy, blocking the default inheritance, using
security groups to create Access Control Lists, or defining WMI
filters.
Note You cannot link a Group Policy Object to a generic Active
Directory container, such as the generic containers for Users,
Computers, and Domain Controllers. However, users and
computers in generic Active Directory containers do receive policy
Chapter 9 • Managing group policies for Unix users and computers 183
by inheritance from Group Policy Objects linked at a higher level of

Active Directory. For example, the Users and Computers
containers you see in Active Directory Users and Computers cannot
have Group Policy Objects linked directly to them, but they do
receive domain-linked Group Policy Objects by means of
inheritance.
Understanding how inheritance impacts policy settings

The order in which Group Policy Objects apply is significant
because, by default, policy applied later overwrites policy applied
earlier for each setting where the later applied policy was either
Enabled or Disabled. Settings that are Not Configured don't
overwrite anything — any Enabled or Disabled setting applied
earlier is allowed to persist. You can modify this default behavior by
forcing or preventing Group Policy Objects from affecting specific
groups of users or computers, but in most cases, you should avoid
doing so.
As an example, consider an organization with a single domain
called arcade.com which is divided into the following top-level
organizational units:
USA
Spain
Korea
Each of these may be divided into lower-level organizational units,
indicating major departmental or functional groupings for the
top-level organizational unit. For example, the USA organizational
unit may be divided into CorporateHQ, Development, and Sales.
Each of these second-tier organizational units may then be divided
into additional organizational units. For example, the Development
OU may include organizational units such as Windows QA and UNIX
QA.
A computer placed in the Windows QA organizational unit may then

have several different Group Policy Objects applied to it. For
example, the arcade.com organization may have a base domain

Group Policy Object that applies to all organizational units in the
domain, and each organizational unit may also have its own Group
Policy Object applied. The following table illustrates the
configuration settings for two computer configuration policies—
Windows Update > Configure Automatic Updates and
Windows Media Player > Prevent Desktop Shortcut
Creation—for the Group Policy Objects applied to the example
organization arcade.com.
GPO name Applied to Sample policy configuration settings

Base Domain arcade.com Configure Automatic Updates: Enabled with Auto
download and notify for install
Prevent Desktop Shortcut Creation: Enabled
USA-Specific USA Configure Automatic Updates: Not Configured
Prevent Desktop Shortcut Creation: Enabled
All Development Development Configure Automatic Updates: Not Configured
Prevent Desktop Shortcut Creation: Disabled
Windows Lab Windows QA Configure Automatic Updates: Enabled with
Notify for download and notify for install
Prevent Desktop Shortcut Creation: Not
Configured
When all of the policies are applied in their default order, the
computer’s resulting set of policies reflect these configuration
settings so that a computer in the Windows QA organizational unit
would be configured with the following policy settings:
Configure Automatic Updates: Enabled with Notify for
download and notify for install
Prevent Desktop Shortcut Creation: Disabled
It is important to consider the impact of these inheritance rules
when you are planning how you will apply Group Policy Objects to
sites, domains, or organizational units that contain Unix users and
computers.
Understanding Administrative templates

Because a Group Policy Object represents a complete collection of
configuration details, each Group Policy Object 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. There
is a default set of administrative templates created with any new
Group Policy Object. These administrative templates are stored as
files with the.adm extension in the system volume on the domain
controller.
The default administrative templates are primarily intended to
provide configuration options for Windows users and computers.
In a few cases, however, you can configure some settings in the
default administrative templates that do apply to Unix users or
Unix 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
can be installed when you run the setup program on a Windows
domain controller. The centrifydc.adm administrative template
primarily controls settings in the Centrify DirectControl
configuration file. Other administrative templates can be added to
control other settings, such as Macintosh system preferences, if
they apply to your environment.
Understanding when Group Policy Objects are refreshed

The computer portion of a Group Policy Object is normally
applied any time you restart a computer that receives group
policies. The user portion of a Group Policy Object is normally
applied any time a user logs on to a computer. Both the computer
and user portions of a Group Policy Object can also be configured
to refresh automatically at a set interval. You can configure the
refresh interval and the conditions for refreshing group policies
through the policies under Administrative Templates >

System > Group Policy in the Computer Configuration and
User Configuration of a Group Policy Object.
If you configure your Group Policy Objects to refresh periodically,
at the interval you specify, the computer contacts Active Directory
to get the Group Policy Objects that apply and configures itself
with the appropriate settings. If policies are refreshed at a set
interval, users can change their configuration settings or their
computers’ configuration settings, but the changes will be
overridden when the group policies are refreshed at the next
interval.
If you configure the refresh policy settings for users or computers,
the refresh policy applies to both Windows and Unix.
Understanding the group policy consoles

With Windows Server 2003, there are two MMC snap-ins for
managing group policies:
The Group Policy Management Console is an optional MMC
snap-in you can download from the Microsoft Web site. You can
use the Group Policy Management Console to create new
Group Policy Objects, link Group Policy Objects to sites,
domains, and organizational units, delegate group policy
permissions to specific users and groups, model and report the
effects of group policy inheritance, and backup, restore,
import, and copy existing Group Policy Objects. The Group
Policy Management Console replaces the Group Policy tab for
Active Directory objects. It is used exclusively for working with
Group Policy Objects and linking Group Policy Objects to sites,
domains, and organizational units. Within the Group Policy
Management Console, you can view all of the Group Policy
Objects defined for a forest and create new Group Policy
Objects. You cannot use the Group Policy Management
Console to edit any of the configuration settings that make up a
Group Policy Object.
The Group Policy Object Editor allows you to enable, disable,

and edit the configuration settings within any single Group
Policy Object. You use the Group Policy Object Editor to set
the configuration options you want to use and to assign values to
configuration settings. For example, you use the Group Policy
Object Editor, and not the Group Policy Management Console,
to define the specific policies for password complexity such as
the Minimum password length and the Maximum
password age.
If you don’t install the Group Policy Management Console, you
must use the Active Directory Sites and Services or the Active
Directory Users and Computers MMC snap-in to link Group
Policy Objects to Active Directory containers.
Understanding computer and user settings

As noted previously, there are two types of group policy settings:
Computer Configuration policies define the startup and
shut down operations and other computer-specific behavior.
These configuration settings apply to the computer regardless of
the user account that logs on to the computer.
User Configuration policies define log-on and log-off
operation and other user-specific behavior. These configuration
settings apply to the user account regardless of the computer
the user logs on to. With these settings, users can move from
computer to computer with a consistent profile.
Because the computer and user group policies contain different
configuration settings, they don’t affect each other directly. In
planning how to implement group policies, however, you need to
keep in mind which policies must be computer-based and which
must be user-based. Where applicable, the policies you set can
affect the operation of Unix computers and the working
environment for Unix users.

In the Windows environment, most of the configuration settings
defined in Group Policy Objects are implemented through entries
in the local Windows registry. For Unix computers, local
configuration details are typically defined using 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 extend
group policies so that they can apply to Unix computers and users,
Centrify DirectControl:
Provides its own administrative templates to define
Unix-specific configuration settings.
Uses the adclient daemon to collect configuration details from
Active Directory based on the Group Policy Objects applied
and to maintain a virtual registry of those configuration
settings on the local Unix computer.
The virtual registry is a collection of files that contain all of the
group policy configuration settings from the group policies applied
to the computer through the group policy hierarchy, including
settings that apply only to Windows computers. Because the files
that make up this virtual registry are not native to the Unix
environment, Centrify DirectControl then uses a set of mapping
programs to read the files, determine the settings that are
applicable to Unix computers, and make the appropriate changes in
the corresponding Unix configuration files to implement the
configuration specified. The mapping programs ignore any
Windows-specific settings that have been applied and only map the
settings that are appropriate to the Unix computer.
Note The virtual registry only supports the group policies that are
implemented through registry settings. Group policies that are
implemented in other ways, for example, by running an executable

script on each computer, aren’t supported.
The following figure provides a simplified view of the process.

DirectControl-managed Virtual Registry: Configuration
computer settings stored in files
Active Directory xxxxxx Mapping programs read the

xxxxxx configuration settings for
xxxxxx settings applicable to Unix
xxxxxx
adclient
xxxxxx
xxxxxx
xxxxxx
xxxxxx
Group Policy Object with runmappers Write changes to

centrifydc.adm, system.adm, /etc/centrifydc/centrifydc.conf
and other default .adm files and other files
As this figure suggests, the Centrify DirectControl daemon,

adclient, retrieves policy settings from the Active Directory
domain controller and starts the program runmappers
(/usr/share/centrifydc/runmappers). The runmappers program
runs the individual mapping programs that are stored in the
/usr/share/centrifydc/mappers/machine and
/usr/share/centrifydc/mappers/user directories. Those
individual mapping programs read settings from the virtual registry
and translate them into the appropriate settings in
application-specific configuration files.
The individual mapping programs also keep track of local changes
that conflict with group policy settings, so those changes can be
restored if the computer is removed from the domain, or if the
configuration setting is removed from a Group Policy Object.

Applying computer configuration policies on Unix
The adclient daemon determines the group policies that apply to
a Unix computer using the same rules for inheritance and hierarchy
that apply to Windows computers.
In most cases, the adclient daemon applies computer
configuration policies on the Unix computer by doing the following
whenever the Unix computer is started or when the computer
policies are refreshed:
Contacts Active Directory.
Checks for the Group Policy Objects that are linked to each
organizational unit of which the local computer is a member.
Determines all of the configuration settings that apply to the
local computer, and retrieves those settings from the System
Volume (SYSVOL).
Writes all of the configuration settings to a virtual registry on
the Unix computer.
Starts the runmappers program to initiate the mapping of
configuration settings using individual mapping programs for
computer policies.
The mapping programs then read the virtual registry for the
appropriate Unix-specific computer configuration settings and the
mapping programs locate the appropriate Unix configuration files
to change and modify those files accordingly.
Applying user configuration policies on Unix

The adclient daemon determines the group policies that apply to
a Unix user using the same rules for inheritance and hierarchy that
apply to Windows users.
When a user logs into a DirectControl-managed Unix computer,
the adclient daemon detects the log-in and does the following:
Contacts Active Directory.
Checks for the Group Policy Objects that are linked to each
organizational unit the user logging in is a member of.
user account, and retrieves those settings from the System
Volume (SYSVOL).
the Unix computer.
user policies.
The mapping programs then read the virtual registry for the
appropriate Unix-specific user configuration settings and the
mapping programs locate the appropriate Unix configuration files
to change and modify those files accordingly.
After the user has logged on, the adclient daemon will
periodically check with Active Directory to determine the current
group policy settings for the user unless you explicitly disable
group policy updates.
Updating configuration policies manually on Unix

As discussed in “Understanding when Group Policy Objects are
refreshed” on page 186, there are standard group policy settings
that control whether group policies should be refreshed in the
background at a set interval. Centrify DirectControl also provides
a command line program to manually refresh group policy settings
at any time. This command line program, adgpupdate, forces the
adclient daemon to contact Active Directory and collect group
policy settings. With the adgpupdate command, you can specify
whether you want to refresh computer configuration policies, user
configuration policies, or both.

When you run the adgpupdate command, the adclient daemon
does the following:
Contacts Active Directory for computer configuration policies,
user configuration policies, or both. By default, the daemon
collects both computer and user configuration policies.
computer, the current user, or both, and retrieves those settings
from the System Volume (SYSVOL).
the Unix computer.
user and computer policies.
Resets the clock for the next refresh interval.
For more information about using the adgpupdate command, see
“Using adgpupdate” on page 301.

Each Group Policy Object 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 Centrify DirectControl
configuration settings for Unix in a Group Policy Object, you need
to manually add the Centrify DirectControl administration
template, centrifydc.adm, to a Group Policy Object. Once you
add the Centrify DirectControl administrative template to a Group
Policy Object, you can then assign values for the settings provided
by the template using the Group Policy Object Editor.
To add Unix policies to an existing Group Policy Object:
1 Open the Group Policy Management Console.
2 In the console tree, select the existing Group Policy Object to

which you want to add Unix policies. For example, you can
select the Default Domain Policy or a Group Policy Object you
have created for your organization.
3 Right-click, then click Edit to open the Group Policy Object
Editor.
4 Open the Computer Configuration and select Administrative
Templates.
5 Right-click, then click Add/Remove Templates.
6 Click Add.
7 Navigate to the directory that contains the Centrify
DirectControl administrative template. By default,
administrative templates are located in the local WINDOWS/inf
directory.
8 Select the centrifydc.adm file, click Open to add this template
to the list of Policy Templates, then click Close.
Note The Centrify DirectControl Administrative Template file
includes both computer and user configuration policies.
Therefore, you only need to add this single Administrative
Template to add computer and user configuration settings that
control Centrify DirectControl operation. Other administrative
templates can be added to control other settings, such as
Macintosh system preferences (macsettings.adm), if they apply
to your environment.
Once you have added the Centrify DirectControl Administrative
Template to the Group Policy Object, you can configure the
computer and user policies you want to use. For information about
the specific configuration settings available, see “Setting policies for
Unix computers and users” on page 196.

Creating a Centrify DirectControl Group Policy Object
Depending on the requirements of your organization and how you
have defined and linked existing Group Policy Objects to the sites,
domains, and organizational units in your Active Directory forest,
you may want to create a separate Group Policy Object for Unix
users and computers. You can create new Group Policy Objects
using Active Directory Users and Computers or the Group Policy
Management Console.
To create a new Group Policy Object for Centrify DirectControl
group policies using the Group Policy Management Console:
1 Open the Group Policy Management Console.
2 In the console tree, select a domain or an organizational unit to
which you want to link the new Group Policy Object.
3 Right-click, then click Create and Link a GPO Here.
4 Type a name for the Group Policy Object, then click OK.
5 Select the new Group Policy Object, right-click, then click Edit
to open the Group Policy Object Editor.
The new Group Policy Object is created with the default Windows
configuration options for computers and users, with all of the
options set to “Not defined” or “Not configured.” The Group Policy
Object does not include the Centrify DirectControl Administrative
Template by default. You can add the Centrify DirectControl
Administrative Template and other Administrative Templates to the
new Group Policy Object as described in “Adding Unix policies to
a Group Policy Object” on page 193 and begin configuring specific
Unix group policies as described in “Setting policies for Unix
computers and users” on page 196.
Note Group Policy Objects that contain Unix settings can be
applied to organizational units that include Windows users and
computers. If the Group Policy Object is linked to an organizational
unit that includes Windows computers, the Windows computers
simply ignore the Unix-specific settings as unrecognized when they
retrieve their configuration settings and the local environment is

configured normally.

Once you have added the Centrify DirectControl administrative
template to a Group Policy Object, you can enable and configure
the settings for Unix computers using the Group Policy Object
Editor.
To enable and configure Unix-specific settings in the Group Policy
Object Editor:
1 View the Group Policy Object that includes the Centrify
DirectControl administrative template using the Group Policy
Object Editor. For example, if you created a new Group Policy
Object for Centrify DirectControl, open that object.
The DirectControl
administrative templates
are listed under
Computer Configuration
and User Configuration
2 Select Computer Configuration > Administrative

Templates > CentrifyDC Settings to view and set the
computer-based configuration options you want to apply.

By default, all of the policies are Not configured. To enable a
policy, double-click the policy description, then select
Enabled. Depending on the specific policy, you may need to
select or assign values or provide other information before you
can complete the configuration.
To see more information about any policy or how to set the
policy, click the Explain tab. For an overview of the policies
available, see “Selecting DirectControl policies for Unix
computers” on page 197.
3 Select User Configuration > Administrative Templates
> CentrifyDC Settings to view and set the user-based
configuration options you want to apply.
By default, all of the policies are Not configured. To enable a
policy, double-click the policy description, then select
Enabled. Depending on the specific policy, you may need to
select or assign values or provide other information before you
can complete the configuration.
To see more information about any policy or how to set the
policy, click the Explain tab. For an overview of the policies
available, see “Selecting DirectControl policies for Unix users”
on page 200. For more detailed information about any policy,
see the Centrify DirectControl Help.
Selecting DirectControl policies for Unix computers

The following table provides a summary of the Centrify
DirectControl policies you can set for Unix computers. All of these
policies are in the Centrify DirectControl administrative template
and accessed from Computer Configuration >

Administrative Templates > CentrifyDC Settings.
Use this policy To do this

PAM Settings Control PAM policy settings. You can use these settings to
customize the behavior of the Centrify DirectControl PAM
modules.
Login Settings Control login and local account access. You can use these
settings to grant or deny access to specific users and
groups or to ignore Active Directory authentication for
some users and groups.
Password Prompts Customize the prompts displayed when Active Directory
users are prompted to provide their password. You can
use these settings to change the text displayed when
Active Directory users log in or change their password.
Timeout Settings Specify the maximum period for client connection
time-outs and object expiration intervals. You can use
these settings to determine how long to wait for a
response when connecting to Active Directory and how
long objects should be kept in the local cache.
Kerberos Settings Manage the Kerberos configuration. You can use these
settings to control updates to the Kerberos configuration
files and credential renewal.
Group Policy Settings Manage the Centrify DirectControl group policy mapping
programs. You can use these settings to control the
execution of the Centrify DirectControl group policy
mapping programs.
NSS Overrides Specify the passwd or group override entries you want
to use in place of the entries in the local /etc/passwd
or /etc/group files. You can use these settings to
provide fine-grain control of the users and groups who
can use the computer and to override the user ID, group
ID, default shell, or home directory for specific login
accounts or groups.
Password Caching Control which users can have a password hash stored in
the local cache when they are authenticated at login. You
can use these settings to allow or prevent which users will
or will not have their password hash stored and how long
passwords can remain in the cache.

LDAP Fetch Count Specify the number of objects to obtain in a single LDAP
request. You can use this setting to optimize performance
and network usage.
User Map Map local Unix user names to Active Directory user
names.
This group policy modifies the
pam.mapuser.username setting in the Centrify
DirectControl configuration file. For more information
about the Centrify DirectControl configuration file and
this configuration setting, see
pam.mapuser.username.
SuDo Permissions Control which users can use the sudo command to run
commands as another user on a selected computers. The
policy also specifies the individual commands that the
user run as the sudo user.
Filesystem mounts Specify the file system mount points to be defined in the
/etc/fstab file.
For information about the specific policies available and how to set
them, see the Centrify DirectControl Help.
Setting Mac OS X computer policies

The following table provides a summary of the group policies you
can set for Mac OS X computers. These group policies are in the
Centrify DirectControl Mac OS X administrative template
(macsettings.adm) and accessed from Computer
Configuration > Administrative Templates > Macintosh

Settings.

Services Control access to various services on Mac OS X computers.
These group policies correspond to settings in the
Services pane of the Sharing system preference.
Firewall Control the firewall configuration on Mac OS X
computers.
Firewall pane of the Sharing system preference.
Security Control security settings on Mac OS X computers.
Security system preferences.
Accounts Control the look and operation of the login window on
Mac OS X computers.
These group policies correspond to Login Options in the
Accounts system preference.
Internet Sharing Manage Internet connections on Mac OS X computers.
Internet pane of the Sharing system preference.
EnergySaver Control sleep and wake-up option on Mac OS X
computers.
These group policies correspond to settings in the Sleep
and Options panes in the Energy Saver system preference.
Selecting DirectControl policies for Unix users

The following table provides a summary of the Centrify
DirectControl policies you can set for Unix users. All of these
policies are in the Centrify DirectControl administrative template

and accessed from User Configuration > Administrative
Templates > CentrifyDC Settings.

SuDo Permissions Control which users can use the sudo
command to run commands as another user
and the commands that can be run as that
user.
Filesystem mounts Specify the file system mount points to be
defined in the /etc/fstab file.
Setting Mac OS X user policies

The following table provides a summary of the group policies you
can set for Mac OS X users. These group policies are in the
Centrify DirectControl Mac OS X administrative template
(macsettings.adm) and accessed from User Configuration >
Administrative Templates > Macintosh Settings.

Software Update Control the options for automatic software updates for
users on Mac OS X computers.
Software Update system preference.
Desktop Control the desktop and screen saver options for users on
Mac OS X computers.
Desktop & Screen Saver system preference.
Security Control the secure login options for users on Mac OS X
computers.
Security system preference.
Applying Windows configuration settings to Unix computers

Every Group Policy Object includes several default administrative
templates for user and computer configuration. Most of the
settings in the default Windows policies and administrative
templates only apply to Windows computers and Windows user
accounts. However, there are a few of these common Windows
configuration settings that can be applied to Unix computers.
These configuration options are not duplicated in the Centrify
DirectControl administrative templates.
You can set the following standard Windows group policy options
for Unix computers and users:
Select this Windows object To set this policy for Unix

Computer Configuration > • Turn off background refresh of Group Policy
Administrative Templates > • Group Policy refresh interval for computers
System > Group Policy
Computer Configuration > • Global Configuration Settings - MaxPollInterval
Administrative Templates >
System > Windows Time Service
> Time Providers
Computer Configuration > • Enable Windows NTP Client
System > Windows Time Service
> Time Providers
Computer Configuration > • Interactive logon: Message text for users
Windows Settings > Security attempting to log on
Settings > Local Policies > • Interactive logon: Prompt user to change
Security Options password before expiration

Select this Windows object To set this policy for Unix
Computer Configuration > • Enforce password history
Windows Settings > Security • Maximum password age
Settings > Account Policies > • Minimum password age
Password Policy
• Minimum password length
• Password must meet complexity requirements
• Store passwords using reversible encryption
User Configuration > • Group Policy refresh interval for users
System > Group Policy
Note Although these Windows configuration settings can be

applied to some Unix computers, none of the Windows
configuration settings apply to Mac OS X computers. If these
settings are enabled for a Group Policy Object applied to a site,
domain, or OU that includes Mac OS X computers, the settings are
ignored.
Linking a Group Policy Object to a container

You can link Group Policy Objects that include the Centrify
DirectControl administrative template to any organizational units,
domains, and sites, including ones that have both Windows and
Unix computers and users, as needed. The Unix-specific policies
are ignored for Windows computers and users, and Windows
policies that are not applicable are ignored for Unix computers and
users.
Depending on your environment, you can link Group Policy
Objects to organizational units, domains, and sites with the Group
Policy tab in an Active Directory MMC snap-in, such as Active
Directory Users and Computers, or using the Group Policy
Management Console. The specific steps involved are different
depending on whether you use Active Directory or the Group
Policy Management Console.
For example, to link a Group Policy Object to an organizational

unit using Active Directory Users and Computers:
1 Start Active Directory Users and Computers and select an
organizational unit, right-click, then select Properties.
2 Click the Group Policy tab.
3 Click New and type a name to create a new Group Policy Object
or click Add to link an existing Group Policy Object to the
organizational unit, then click Edit.
4 In the Group Policy Object Editor, select Administrative
Templates, right-click and add the centrifydc.adm
administrative template and any other administrative templates
to the GPO, as needed.
5 In the Group Policy Object Editor, enable the specific computer
and user group policies you want to use, as needed.
The computers and users in the organizational unit you selected
will receive the policies you enabled when they restart or at the
next group policy refresh interval.
For more information about linking and managing Group Policy
Objects, see the Active Directory documentation.

On Windows computers, you can use the Group Policy
Management Console to see the results of group policy settings for
a specific computer or user, including Unix computers and users.
You can also review the results of group policy settings for a Unix
computer or a specific user by viewing the gp.report file locally on
the computer. This report is automatically updated at each group
policy update interval. By default, the gp.report for computer
configuration is located in the /var/centrify/reg/machine
directory and the gp.report for user configuration is located in the
/var/centrify/reg/users/username directory.

Editing the Centrify DirectControl configuration file
Many of the Centrify DirectControl group policies are used to
modify the parameter values in the Centrify DirectControl
configuration file /etc/centrifydc/centrifydc.conf. When you
make changes to a group policy setting, the change is reflected in
the /etc/centrifydc/centrifydc.conf file:
When the computer is rebooted,
When the computer configuration policies are refreshed at the
next update interval, or
When you run the adgpupdate command.
If you enable Centrify DirectControl group policies, you should
not need to manually edit the configuration parameters in the
/etc/centrifydc/centrifydc.conf file. In some rare cases,
however, you may find it useful to customize these parameters on a
particular computer. For example, you can use configuration
parameters to temporarily disable group policies for users,
computers, or both, on a computer.
For more information about customizing Centrify DirectControl
behavior using the Centrify DirectControl configuration file and
configuration parameters instead of group policies, see
page 323.

You can define your own custom group policies for Unix
computers and users and add these custom group policies to
existing or new Group Policy Objects. Custom group policies
consist of:
A custom Administrative Template (.adm) file that describes
how to set the policy within the Group Policy Object Editor.
For example, the Administrative Template describes the user

interface presented to the administrator on Windows computer.
A program or script that makes the appropriate settings for the
computer or the user logging on. For example, you can create a
Perl script that reads the group policy settings and modifies the
appropriate Unix configuration file to reflect those settings.
Creating a custom Administrative Template

The Administrative Template specifies whether a group policy is a
computer configuration policy, a user configuration policy, or both,
the registry key entries and values being set, the data type for the
key value, and the user interface to present for setting the key
value. Once you create you custom .adm file, you can add it to a
Group Policy Object in the same way you add the standard Centrify
DirectControl Administrative Template as described in “Adding
Unix policies to a Group Policy Object” on page 193.
The following example illustrates the basic file format:
CLASS MACHINE
CATEGORY “Sample Unix Security Settings”
KEYNAME "Software\Policies\Centrify\Sample Unix Security"
POLICY "Sample Text Entry Policy"

EXPLAIN "Use a comma to separate list entries."
PART "Sample Text Entry Policy" EDITTEXT
VALUENAME sample_registry_name1
MAXLEN 60
END PART
END POLICY
POLICY “Check for software updates:”
EXPLAIN “Check for updates Daily, Weekly, or Monthly”
PART “Check for updates” DROPDOWNLIST
ITEMLIST
NAME daily VALUE Daily
NAME weekly VALUE Weekly
NAME monthly VALUE Monthly
END ITEMLIST
END PART
END POLICY
POLICY "Enable port settings”
EXPLAIN "Change the checkbox value to yes or no."
PART “Enable port settings” CHECKBOX
VALUEON "yes"
VALUEOFF "no"
END PART
END POLICY
END CATEGORY

Computer configuration policies should have the CLASS keyword
set to MACHINE. User configuration policies should have the CLASS
keyword set to USER. The CATEGORY specifies the folder name for
group policies together. For the registry KEYNAME, you should
determine whether to use one that already exists or creating a new
custom the registry key. Policies can have multiple PART sections of
different types. The PART type can be any of the following:
For this type You can specify

TEXT Static text descriptions for instructions or clarification.
There are no keywords associated with this type of PART.
EDITTEXT A string. This type of PART requires the VALUENAME
keyword and value. The value should be the name
used in the registry, if applicable. You can also use the
following with this type of PART:
• DEFAULT default_value to display when the
policy is first enabled.
• MAXLEN value maximum length of the string
• REQUIRED to require a value be set.
• FILE_VALUE file_value to specify the name of a
Centrify DirectControl configuration parameter as it
appears in the centrifydc.conf file. If this value is not
present, the VALUENAME is used.

NUMERIC Integers. This type of PART requires the VALUENAME
• MIN value to set the minimum value allowed.
• MAX value to set the maximum value allowed.
• SPIN 0 | 1 to specify whether to use a spin control
or not. Setting this keyword to 0 removes the spin
control.
• TXTCONVERT to write a value as a string instead of a
binary.
CHECKBOX Boolean values. This type of PART requires the
VALUENAME keyword and value. The value should be
the name used in the registry, if applicable. You can also
use the following with this type of PART:
• DEFCHECKED to set the check box to checked when
the policy is first enabled. Without this keyword, the
default is to not checked.
• VALUEON [NUMERIC] value to specify a value to be
written to the registry, for example, to set a value to
“true” or “yes” instead of the default value of 1. If you
set the value to a numeric value, you must indicate this
by using the keyword NUMERIC.
• VALUEOFF [NUMERIC] value to specify a value to be
written to the registry, for example, to set a value to
“false” or “no” instead of the default value of 0. If you
set the value to a numeric value, you must indicate this
by using the keyword NUMERIC.

COMBOBOX A list of suggestions to allow the user to select or type a
value. This type of PART requires the VALUENAME
• MAXLEN value maximum length of the string
• SUGGESTIONS suggestion_list END
SUGGESTIONS to create a list of values to display.
DROPDOWNLIST A list of suggestions to allow the user to select a value.
This type of PART requires the VALUENAME keyword and
value. The value should be the name used in the
registry, if applicable. You can also use the following with
this type of PART:
• ITEMLIST NAME name VALUE [NUMERIC]
value END ITEMLIST to create a list of items to
display where the name is the text displayed and the
value is the value written to the registry. If you want a
numeric value, you much use the keyword NUMERIC.
To specify an item as a default, add the keyword
DEFAULT after the value for that item.
• NOSORT to have the items in the list unsorted.
Note The custom Administrative Template is not strictly required if

you do not need to make the settings visible and available to the
Active Directory or Windows administrator, but in most cases, you
should create one using a standard text editor or the Centrify
DirectControl. For detailed information about creating .adm files,
see your Microsoft documentation.
Adding custom group policy programs to DirectControl

To implement group policies for Unix computers and users, you
need to create the custom scripts or programs that modify the
appropriate Unix configuration files or settings. You can create the
programs or scripts using the programming or scripting language of
your choice. Most of the Centrify DirectControl policies use Perl
scripts and you can use those scripts for models if you choose to use
Perl.
Once you create a program or script to implement a group policy,
you need to:
Place the program or script in the
/usr/share/centrifydc/mappers/machine directory if it is a
computer configuration group policy, or in the
/usr/share/centrifydc/mappers/user/user_name directory
if it is a user configuration group policy.
Make the program or script an executable file.
Use the runmappers command to test that the program or script
works as expected and updates the appropriate configuration
file.
By default, when you use the runmappers command, it executes
all of the programs in both the
/usr/share/centrifydc/mappers/machine and the
/usr/share/centrifydc/mappers/user/user_name
directories. Optionally, you can run the command to only
execute your custom program. For example, if you have created
an executable script called setport.pl as a Unix computer
configuration policy and placed the file in the
/usr/share/centrifydc/mappers/machine directory, you
could use a command similar to the following to execute the
script along with the other computer configuration mapper
programs and test its behavior:
runmappers machine map

Note To run the mapping programs for a user, you must specify
the user’s Unix login name to identify which user’s group
policies should be mapped or unmapped. For example, to run
the mapping programs for the Unix user account jgarcia in the
/usr/share/centrifydc/mappers/user/jgarcia directory,
you could use a command similar to the following:
runmappers user jgarcia map

Chapter 10
Managing licenses
This chapter describes how to update and manage Centrify

DirectControl license keys for servers, workstations, and
supported applications.
Understanding how licensing works
Adding license containers
Viewing the license summary
Adding license keys
Deleting a license key
Running reports for licenses

For Centrify DirectControl, licensing is based on the number of
computers and applications you authorize for access. Licenses apply
across all domains, sites, zones, and organizational units within a
single Active Directory forest and are implemented through the use
of licensing keys. Each license key applies to a specific license
type and indicates the total number computers or application
servers you can enable for access.
Understanding license types

In Centrify DirectControl, licenses are issued based on how a
computer is used. For example, a computer can be licensed as a
213
workstation or a server, and as a standard Unix server or as an

application server. The following types of licenses are available:
Workstation Licenses permit a specific number of Unix
workstations to be enabled for Active Directory users to log on.
These licenses make individual computers available for users to
log on and use standard Unix services such as telnet and ftp.
Workstation login licenses are intended for computers that are
used interactively by one or two concurrent users, but do not
host applications needed by other users.
Server Licenses permit a specific number of Unix servers to
be enabled for Active Directory users to log on interactively or
access for applications. These licenses make individual
computers available for multiple users to log on and use either
standard Unix services such as telnet and ftp or access hosted
applications. Server licenses are for computers that are accessed
by more than two concurrent users and typically host a specific
type of application.
Application Licenses permit a specific number of Unix
servers to be enabled for Active Directory users to access
hosted applications. Application licenses are used in conjunction
with server licenses to enable access to specific applications. For
example, there are separate application licenses for Apache,
Tomcat, and JBoss, so that a Unix server that hosts Apache
applications can be licensed to authenticate Active Directory
users for all Apache applications on that server.
Understanding license keys

Every Centrify DirectControl installation includes an evaluation
license that allows you to use Centrify DirectControl for a specific
number of days. If you purchase Centrify DirectControl, you are
provided with permanent license keys that replace any evaluation
keys and identify the specific Centrify DirectControl licenses you
have purchased.

Your capacity for enabling access for standard Unix services or
applications is defined by the total of all of the licenses you
purchase and install. For example, if you install three valid license
keys that each enable 100 workstations for Unix login access, you
have a total of 300 workstation login licenses available.
Each license you purchase has a 24-character registration key that
specifies:
The type of license granted by the key, which can be any of the
license types described in “Understanding license types” on
page 213.
The total number of computers that may be enabled under this
key’s license. If this is an evaluation key, the number of
computers is unlimited, but the license count is displayed as
zero (0) to indicate no computers are licensed under the
evaluation key.
The time limit for the key. If the license is a permanent license
key, the time limit is not applicable. If the license is an
evaluation key, the time is set to 30 days.
Because each license key specifies a set number of computers, it’s
common to receive multiple license keys. You can provide these
license keys when you install Centrify DirectControl on Windows
or after installation using the Centrify DirectControl Administrator
Console. For information about using the Centrify DirectControl
Administrator Console to add licenses, see “Adding license keys”
on page 218.
Understanding how licenses are checked

Centrify DirectControl checks the licenses you have installed when
new Unix computer accounts are added to Active Directory or
when you enable access to Web application servers. If the number
of licensed servers and workstations is less than the total number of
licenses you have purchased, Centrify DirectControl allows you to
Chapter 10 • Managing licenses 215

enable Unix or Web server access and reduces the total number of
available licenses by one.

When you run the Setup Wizard the first time, you are prompted
to create a Licenses container object because you must have at least
one Licenses container in the forest into which you install license
keys. It is also possible to add License containers to the forest and
use those additional containers to control who can use which
license keys. For example, you may want to create one license
container for application servers and another for workstation
licenses. You can then set permissions on the container objects to
prevent the workstation administrators from installing the
application server license keys and the application server
administrators from installing the workstation license keys in their
respective containers.
To add a new license container object:
2 In the console tree, right-click Centrify DirectControl, then
click Manage Licenses.
3 Click the Update tab, then click Create.

4 Browse to select a location for the new license container, then
click Create.Type a name for the new license container and
click OK, then click OK to close the Browse for container dialog
box.
5 Click Yes to add the license container to Active Directory.
6 Click Permissions to assign Read License and Modify License
permissions to specific users or groups. The users or groups that
you give the Modify License permission to can then add license
keys to the new license container.
Viewing the license summary

As discussed in “Understanding how licensing works” on page 213,
licenses are issued for servers, workstations, and applications to
enable specific activities such as permission to log in to the Unix
shell or permission to use specific applications on a Unix computer.
To see a summary of the licenses you have installed and activated,
including the type of license, the number of computers covered by
the license, and the number of licenses currently being used:

Adding license keys
3 Click the Summary tab.
The Computers section lists the total number of workstation

and server licenses you have installed and activated with
licensing keys. Because the number of licenses includes both
workstations and servers, this represents the maximum
number of computers authorized for access to the Unix shell
as application hosts. The number of Used licenses indicates
the number of computer accounts in Active Directory for
which you have enabled access to a Unix shell or Web
applications.
The Applications section lists the total number of
application licenses you have installed and activated with
licensing keys. The number of Used licenses indicates the
number of computer accounts for which you have enabled
access to applications.
Adding license keys

If you need to add license keys to add computers to the domain or
enable access to Web applications:

3 Click the Update tab.
4 Click Add.
5 Type the new license key, then click OK.

6 Click the Summary tab to view the installed licenses. Note that
license keys are Licensed, that is, available to be used, until you
begin adding computers to the domain.
7 Click OK.

If you want to delete a license key you have previously installed:
3 Click the Update tab.
4 Select the license key you want to remove.
5 Click Delete, then click OK.

To view information about the licenses you have installed and used,
you can run the License Summary Report or the License Detail
Report.
The License Summary Report lists the total number of computer
and application licenses you have installed. For each type of license,
you can see the number of computers covered by the license, the
number of licenses used, and the number of licenses you still have
available.
The License Detail Report lists the specific users, computers, and
applications for which you have enabled access. For each type of
license, you can see the specific computers or applications covered
by the license.
To run a report:
and open Reports.
3 Click the type of license report you want to generate. For
example, click License Summary to generate a summary of
the number of each type of license installed, in use, and available,
or click License Detail to generate a list of the specific
computers or applications for which you have installed licenses.
If you generate the License Summary, you can optionally filter
and sort the information, if needed.
To filter information in the report, click the Filters tab,
select the filtering criteria, and click Add. You can add
multiple filters, if needed.
To sort the information in the report, click the Sort tab and
select the sorting criteria and sort order you want to use for
the report.

4 Click Run to generate the reports. Once the report is

generated, you can view the report in a new Centrify Report
window. For example, the License Details report looks similar
to the following:
Each time you run a license report, you generate a new report
about the licenses currently installed. For more information about
generating and working with reports, see “Running reports” on
page 257.

Chapter 11
Importing information from NIS maps or

Unix files
This chapter describes how to import user and group information
from existing Network Information Service (NIS) databases and
local Unix configuration files into Active Directory.
Understanding the information source
Importing from NIS
Importing from a file
Moving pending information into Active Directory
Making imported information available to NIS clients
Understanding the information source

Before you can import existing Unix information into Active
Directory, you need to understand where that information is stored
in your Unix environment. The two most common sources of
information are the NIS server, and the databases or maps that
store users, groups, and other network-related information for NIS
domains, and local Unix configuration files, such as /etc/passwd
and /etc/group, that store local user and group accounts.
Depending on your environment, you may need to import
information from either or both 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+, or local
Unix configuration files.
You also need to verify that you will be able to access the Unix
information from the Windows computer where the Centrify
223
Importing from NIS
DirectControl Administrator Console is installed. For example, if

you are importing information from local /etc/group and
/etc/passwd files, these files must be accessible on the Windows
network. If you are importing from local configuration files, there
are several ways to accomplish this, including using FTP to transfer
the files, copying the files to a network share, or making your Unix
computers directly visible on the Windows network through
Samba or a similar service. To import information from an NIS
server, the server and domain must be accessible from the
Windows computer where you start the import process.
Before you import, you should also do some planning to determine
how imported information fits into your existing Active Directory
structure, how the imported information should be organized into
zones and groups, and how you will handle any account conflicts.
Importing from NIS

The Network Information Service (NIS) provides centralized
storage for information that needs to be known throughout the
network, and provides this information to all computers on the
network when needed. NIS stores this information, including user
login names and passwords and group names and IDs, in a set of
database maps on one or more host servers.
To import this information into Active Directory, you need to
know the name of one or more of these host servers and the name
of the NIS domain you want to import.
To import information from NIS:
2 In the console tree, open Zones.
3 Select the zone into which you want to import users and groups,
right-click, then click Import from Unix.

4 Select Network Information Service (NIS), type the name
of the NIS domain and NIS server from which you want to
import information, then click Next.
Note The NIS server must be accessible on the Windows
network. For example, you can configure the server to be
accessible over the Windows network using Samba or a similar
program.
5 Select the NIS information to import. For example, check that
both Users and Groups are selected for import, then click
Next.
6 Review the summary of information to be imported, then click
Finish.
When you click Finish, all of the user and group information is
placed in a Pending Import state to allow you to decide how
exactly in should be imported into your existing Active Directory
structure. For example, for each group you need to decide whether
it should be ignored, mapped to an existing Active Directory group
you have already created, or used to create a new Active Directory
group of its own in the Active Directory structure.
Importing from a file

The local configuration files /etc/group and /etc/passwd store
user login information and group information locally on individual
Unix computers. If you have local accounts stored in these
configuration files that you want to import into Active Directory,
you can do so using the same Import from Unix command as
used to import information from NIS.
To import information from local configuration files:
2 In the console tree, open Zones.
Chapter 11 • Importing information from NIS maps or Unix files 225

3 Select the zone into which you want to import users and groups,
right-click, then click Import from Unix.
4 Select Unix configuration files, then click Browse to locate
the passwd and group files on the Windows network.
Note These files must be accessible on the Windows network.
You can make them available using FTP, by copying them to a
network share, or by navigating to them directly if your Unix
computers are configured to be accessible over the Windows
network using Samba or a similar program.
When you have identified both the /etc/passwd and
/etc/group files you want to import, click Next. Although the
files can be imported independently, group information must be
available before you can import user information. Therefore,
Centrify recommends you import both files at the same time.
5 Check that both Users and Groups are selected for import,
then click Next.
6 Review the summary of information to be imported, then click
Finish.
When you click Finish, all of the user and group information is
placed in a Pending Import state to allow you to decide how
exactly in should be imported into your existing Active Directory
structure. For example, for each group you need to decide whether
it should be ignored, mapped to an existing Active Directory group
you have already created, or used to create a new Active Directory
group of its own in the Active Directory structure.

The process of moving information from the Pending Import state
to Active Directory is a manual one. It requires you to review each
group and user object and determine how it should be handled.
The initial import step provides some default mapping of Unix
fields to Active Directory properties, but you must make the final

determination as to whether that default mapping is appropriate or
must be modified.
In most environments, the default mapping simplifies the import
process most significantly if you have done some planning and
structuring of the Active Directory environment in preparation for
the import. Even if you have not done this preparation, however, in
many cases you may be able to accept the default mapping without
making changes. Although Centrify DirectControl attempts to
match Unix user names to corresponding Active Directory logon
names where these matches exist, you should carefully review these
Active Directory candidates before accepting them.
Moving groups into Active Directory

To move pending group information to Active Directory:
1 In the Centrify DirectControl Administrator Console, open
Groups under the zone where you imported user and group
information.
2 Click Pending Import to display the list of groups to be
imported. For each group there is an icon, a Unix group name,
and a Unix GID.
3 Select one or more groups in the list, right-click, then click
Check Status to check Active Directory for a potential Active
Directory group that may be a matching candidate for you to
map the Unix group to, and to display an informational message
indicating whether the group is ready to import or may require
another action.
For best results, you should take action for only a limited
number of groups at any one time. For example, you may want
to select only the groups to ignore in one session and only the
groups that map to existing Active Directory groups in another
session. Working with a subset of groups at a time makes
importing a large number of groups more manageable. FOr
example, once you check the status for a group, the icon

displayed changes and the potential Active Directory group it

matches is displayed:
Tip Typically, group identifiers 0 through 99 are reserved for

system use and not imported into Active Directory. Because the
Pending Import list includes both normal Unix groups and
special system groups, you may want to sort the list by GID to
make it easier to manage. Click the GID column header to sort
the groups by number rather than by name. You can then select
all of the groups you don’t want to import, right-click, then click
Ignore.
4 Select one or more groups, right-click, then click an appropriate
action as follows:
Click Accept to accept the Active Directory group candidate
suggested by Centrify DirectControl. For example, Centrify
DirectControl will suggest an Active Directory group
candidate if it finds an Active Directory group name that
matches one of your Unix group names. You can click Accept
if you want to use the Active Directory group suggested.
Click Ignore if you want to eliminate a group from the
import process. For example, if there are system groups or
empty groups that don’t need to be imported into Active
Directory, you can use Ignore to leave those groups out of
Active Directory. Ignored groups are still valid local groups
on the Unix system.
Click Extend existing AD group if you want to select an
existing Active Directory group account to use for the
selected Unix group. For example, if you have already created
the Active Directory structure you want to use for Unix
groups and users, you may want to use this option to map the

imported groups to the appropriate Active Directory groups
you have created. If you select this action, type the name of
the group to map to or click Advanced Search to find the
Active Directory group to use.
Click Create new AD group to create a new Active
Directory account for the group you are importing. For
example, if you have an existing Unix group called devteam
and you want to create a new Unix-specific Active Directory
group based on that group, you can use this option to create
the new Active Directory devteam group and identify where
it should be placed in the Active Directory hierarchy. If you
select this action, you need to select the container to use for
the group, the group display name, and the scope of the
group.
Click Properties to view the time of the import, the file
location information was imported from, the group name and
GID, and the complete informational message describing the
status of the group you are viewing. To view the message,
click the Message tab. The message indicates whether a
group is ready to import of if there are issues you need to
resolve before you continue with importing the group.
Moving users into Active Directory

To move pending user information to Active Directory:
1 In the Centrify DirectControl Administrator Console, open
Users under the zone where you imported user and group
information.
2 Click Pending Import to display the list of users to be
imported. For each user there is an icon, the Unix user name,
the Unix UID, the contents of GECOS field, a potential Active
Directory user account for you to map the Unix user to, a
primary group assignment for the user, and an informational
message indicating whether the user is ready to import or may
require another action.

Tip Typically, user identifiers 0 through 99 are reserved for

system use and not imported into Active Directory. Because the
Pending Import list includes both normal Unix users and special
system accounts, you may want to sort the list by UID to make
it easier to manage. Click the UID column header to sort the
users by number rather than by name. You can then select all of
the user accounts that you don’t want to import, right-click,
then click Ignore.
3 Select one or more users, right-click, then click an appropriate
action as follows:
Click Accept to accept the Active Directory user candidate
suggested by Centrify DirectControl. For example, Centrify
DirectControl will suggest an Active Directory user candidate
if it finds an Active Directory logon name that matches one of
the Unix user names from the password file. You can click
Accept if you want to use the Active Directory user account
suggested.
Click Ignore if you want to eliminate a user from the import
process. For example, if there are system users that don’t
need to be imported into Active Directory, you can use Ignore
to leave those users out of Active Directory. The user
accounts are still valid local users on the Unix system.
Click Extend existing AD users if you want to select an
existing Active Directory user account to use for the selected
Unix user. For example, if you have already created the
Active Directory structure you want to use for Unix groups
and users, you may want to use this option to map the
imported users to the appropriate Active Directory user
accounts you have created. If you select this action, type the
name of the user to map to or click Advanced Search to find
the Active Directory user to use.
Click Create new AD user to create a new Active Directory
account for the user you are importing. If you select this
action, you need to specify the Distinguished name of the
container for the user, the user’s display name based on the

GECOS field or the Unix user name. You can also specify an
initial password for the user and whether the user is required
to change the password at the next interactive login.
Click Properties to view the Unix user name, UID, primary
group, login name, login shell, home directory, and the
informational message describing the status of the pending
import.

Some computers and applications submit NIS lookup requests
directly to an NIS server listening on the NIS port. To make the
information imported into Active Directory available to these NIS
client requests, you can install the optional Centrify DirectControl
Network Information Service.
The Centrify DirectControl Network Information Service relies on
a separate daemon process, adnisd, to receive and respond to NIS
client requests. Once installed and running, the DirectControl
Network Information Service functions just like a standard NIS
server, but responds to NIS client lookup requests using the
information stored in Active Directory.
If you are using the Centrify DirectControl Network Information
Service to service authentication requests from NIS clients, it is not
necessary for you to import your existing passwd and group maps.
You must, however, have the user and group information for
Unix-enabled users and groups stored in Active Directory.
Importing existing maps simply provides a mechanism for
migrating existing information to the Active Directory identity
store. Once the information is imported into Active Directory, the
original maps are no longer used and the Centrify DirectControl
Network Information Service uses Active Directory to generate the
maps it needs to service authentication requests. For more
information about using the Centrify DirectControl Network
Information Service to service authentication requests, see
“Configuring client authentication through adnisd” on page 246.

Note If you have existing NIS servers that are handling client
requests, those servers can continue to run until you have imported
sufficient data into Active Directory to transfer the client requests
to Centrify DirectControl. Although you can the leave standard NIS
servers in place indefinitely, you should plan to migrate all of your
data and NIS clients to use the DirectControl Network Information
Service if you want you to centralize all directory service in Active
Directory. Once you have imported all of the data you need into
Active Directory and configured your existing NIS clients to use the
appropriate Centrify DirectControl Network Information Service,
you can decommission any legacy NIS servers and stop any related
services.
For more information about deploying and configuring the

Centrify DirectControl Network Information Service and
importing other types of NIS maps, see Chapter 12, “Using the
DirectControl Information Service for NIS requests.”

Chapter 12
Using the DirectControl Information

Service for NIS requests
This chapter describes how to install and configure the
DirectControl Network Information Service to emulate a standard
Network Information Server and respond to client requests on the
NIS port.
Understanding the DirectControl Information Service
Understanding how to deploy the adnisd daemon
Understanding NIS maps in Active Directory
Configuring the DirectControl Information Service
Configuring NIS clients to use Centrify DirectControl
Configuring client authentication through adnisd
Maintaining NIS maps in the Administrator’s Console
Discontinuing use of legacy NIS servers
Note The Centrify DirectControl Network Information Service is
not available for all platforms. For the most up-to-date information
about supported platforms and system requirements, see the
Supported Platforms link on the Centrify web site.

When Centrify DirectControl is installed on a Unix computer, the
Name Service Switch configuration file, nsswitch.conf, is
modified so that account lookup requests are passed to Active
Directory through the adclient daemon. By sending these
requests to Active Directory, Centrify DirectControl bypasses the
standard Network Information Service (NIS).
233
In some organizations, however, bypassing NIS may be problematic.

For example, you may use applications, such as automount, 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
may also have computers or devices, such as Network Attached
Storage devices, on which you cannot install the Centrify
DirectControl Agent, but that need access to network information
normally stored in NIS maps such as the netgroup map.
For computers and applications that submit lookup requests
directly to an NIS server listening on the NIS port, Centrify
DirectControl includes its own Network Information Service. This
Centrify DirectControl Network Information Service relies on its
own daemon process, adnisd, to receive and respond to NIS client
requests. The Centrify DirectControl Network Information
Service is an optional addition to the Centrify DirectControl Agent
and can be installed on one or more DirectControl-managed
computers, as needed.
Once installed and running, the DirectControl Information Service
functions just like a standard NIS server, but responds to NIS client
lookup requests using the information stored in Active Directory,
including information imported from the passwd and group NIS
maps and used for NIS client authentication requests.
If you are using the Centrify DirectControl Network Information
Service to service authentication requests from NIS clients, the
user and group information must be stored in Active Directory.
You can migrate this information from existing passwd and group
maps or you can give existing Active Directory users and groups
access to the zone the Centrify DirectControl Network
Information Service uses as its NIS domain. Importing existing
passwd and group maps simply provides a mechanism for migrating
existing information to the Active Directory. Once the information
is imported into Active Directory, the original maps are no longer
used and the Centrify DirectControl Network Information Service
uses Active Directory to generate the maps it needs to service
authentication requests.

Note To keep passwords synchronized between Active Directory
and the NIS client, you must have the Microsoft Services for UNIX
(SFU) 3.5 or Windows Server 2003 R2 Unix Identity Management
service installed in your Active Directory forest. For more
information about using Centrify DirectControl Network
Information Service to service authentication requests from NIS
clients, see “Configuring client authentication through adnisd” on
page 246.
Although you can leave standard NIS servers in place on the Unix
network, using the DirectControl Network Information Service
allows you to centralize all directory service in Active Directory.
Once you have imported all relevant data into Active Directory and
configured the NIS clients to use the Centrify DirectControl
Network Information Service, you can discontinue using your
legacy NIS servers.
The following figure provides a simplified view of operation.
Computers that are not managed by Centrify DirectControl but
send NIS lookup requests to the NIS port on a Centrify
DirectControl-managed computer
NIS maps stored in Active

Directory
NIS Map
xxxxxx
xxxxxx DirectControl-managed
xxxxxx adnisd
computer
adclient
Finance Zone
Active Directory
As this figure suggests, the computers that are not managed by

Centrify DirectControl but need access to the information stored
in Active Directory can be configured to send their NIS requests to
the Centrify DirectControl managed computer where the
DirectControl Information Service daemon runs. Those requests
Chapter 12 • Using the DirectControl Information Service for NIS requests 235
are passed to the Centrify DirectControl daemon, adclient,

which, 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 the
information is passed back through the DirectControl Information
Service adnisd daemon to the client that made the request.
The NIS maps stored in Active Directory can be maps that were
imported directly from an existing NIS server and domain,
imported from existing text files, or created manually using the
Centrify DirectControl Administrator Console.

The key component of the DirectControl Network Information
Service is the adnisd daemon. The adnisd daemon replaces the
ypserv daemon on a Unix computer and accepts NIS requests from
NIS clients through the NIS port. You can install and deploy the
adnisd daemon on any computer where you install the Centrify
DirectControl Agent.
If you choose to install the adnisd daemon on a computer, the zone
associated with that computer defines the scope of information
available to NIS clients. Each instance of the adnisd daemon
supports one and only one zone, which is equivalent to a single NIS
domain. Once you install and start the adnisd daemon, it can only
look up information for the computers and users that exist in the
same zone as the local computer account. If you have more than
one zone, therefore, you may want to deploy the adnisd daemon
on at least one computer in each zone.
Note All instances of adnisd within the same zone respond to
queries using the same NIS maps stored in Active Directory. If you
deploy the adnisd daemon on multiple computers, whether across
the same zone or across multiple zones, keep in mind that all of
these instances are zone-specific peers. There are no master/slave
instances.

Once you install the adnisd daemon on a computer, you must
manually start the service and configure other computers or
devices to use the DirectControl-managed computer running
adnisd for NIS requests. Optionally, you can configure the adnisd
daemon to start whenever the computer is rebooted by modifying
the startup script on the local computer.
Note The adnisd daemon cannot be used with any legacy NIS
servers in a NIS domain. It can only be used in conjunction with
Active Directory and the Centrify DirectControl Agent.

As discussed in “Importing from NIS” on page 224, you can import
existing NIS maps from existing NIS servers and domains using the
Centrify DirectControl Administrator Console. Through the
Centrify DirectControl Administrator Console you can also create
new maps, edit map content, and delete maps you no longer need.
All of the information you import is stored in Active Directory
without any changes to the Active Directory schema.
Just as the adnisd daemon can only receive information for its own
zone, the NIS maps are stored as zone-specific information. When
the adnisd daemon receives NIS client requests or refreshes its
local data store, it only accesses the NIS maps for its own zone. If
you have multiple zones, Active Directory will store a separate set
of NIS maps for each zone.
Note Although the NIS maps are stored in Active Directory, they
are not maintained by Active Directory. For example, if you add a
new computer to a zone by running adjoin, a new computer
account is automatically created in Active Directory, but that new
computer account is not automatically added to the NIS maps for
that zone. If there are changes that impact the NIS maps for the
zone, you must manually update the appropriate NIS maps with the
information.
Using standard and custom NIS maps

There are several standard NIS maps that you can import or create
for any zone, such as the NIS maps for automount, netgroup, and
autohome. You can also create your own custom map files and store
them in Active Directory. Custom NIS maps allow you to specify a
key and a value for any type of information that you want to publish
and make available to NIS clients. When the adnisd daemon
receives an NIS request, it retrieves all of the maps for its zone,
including any new maps, so the daemon can provide information
from any NIS map to the requesting NIS client.
In addition to the standard or custom NIS maps you import or
create, the DirectControl Information Service can automatically
create two special NIS maps, netgroup.byuser and
netgroup.byhost, from an imported netgroup map.
The netgroup.byuser and netgroup.byhost maps make the

information stored in the netgroup map easier to access in
response to common queries. For example, the netgroup.byuser
map simplifies the process of determining the groups any specific
user is a member of. Because the daemon creates these maps
automatically by retrieving information from the netgroup NIS
map, you don’t need to manually derive the information or create
these maps yourself.
For more information about importing NIS maps from the NIS
server or from files, see Chapter 11, “Importing information from
NIS maps or Unix files.”
Updating the NIS map data on a Unix computer

By default, the adnisd daemon periodically connects to Active
Directory to retrieve updated NIS maps for its zone. At each
interval, the daemon connects to Active Directory and does the
following:
Retrieves the current NIS maps found in Active Directory.

Updates the local netgroup.byuser and netgroup.byhost maps
generated from the netgroup map.
Stores the information from all of NIS maps in a local NIS map
data store on the Unix computer.
In between updates, the adnisd daemon responds to NIS client
requests using the data in its local NIS data store. Because this
information is available in the local data store, the adnisd daemon
can respond to NIS requests even when it is unable to contact
Active Directory for map refreshes.

The first step in using Active Directory and the Centrify
DirectControl Network Information Service to handle NIS client
requests is to store the necessary information in Active Directory
through the Centrify DirectControl Administrator Console. Once
you make the appropriate NIS maps available in Active Directory,
you can install and configure the Centrify DirectControl Agent and
the Centrify DirectControl Network Information Service daemon,
adnisd.
To install the Centrify DirectControl Agent and the DirectControl

Network Information Service:
1 On the Unix computer, log in as or switch to the root user, then
run the following command to start the installation:
./install.sh
Follow the instructions displayed on the screen to install and

configure the Centrify DirectControl Agent for your
environment. The DirectControl Network Information Service
is installed with the Centrify DirectControl Agent by default.
2 Run the adjoin command to join an Active Directory domain.
Because the adnisd services client requests only for its own
zone, you may want to identify the zone in the command line
rather than use the default zone. For example, to join the
troilus.com domain and add the computer to the sales zone:
adjoin --user steph --zone sales troilus.com
3 Locate the Centrify DirectControl Network Information Service

package for your platform, and run the appropriate command
for installing the package based on the local computer’s
operating environment. For example, if you are installing on
Red Hat Linux:
rpm -Uvh centrifydc-nis-3.0.0-rh9-i386.rpm
Specifying trusted NIS client requests

By default, the Centrify DirectControl Network Information
Service only accepts local NIS client requests. To accept requests
from other NIS clients in your network, you must modify the
nisd.securenets configuration parameter in the
/etc/centrifydc/centrifydc.conf file to specify the computer
subnets from which to accept NIS requests. With this parameter,
you can configure adnisd to filter NIS requests by IP address.
When you specify the IP addresses, subnets, and masks from which
to accept NIS requests, the adnisd daemon will only respond to the
requests coming from the IP addresses that meet the criteria you
have specified. All other NIS client requests will be ignored.
For example, if you want to restrict NIS requests to a single trusted
subnet of computers, you can edit the nisd.securenets
configuration parameter in the
/etc/centrifydc/centrifydc.conf file to include a line similar to
the following:
nisd.securenets: 172.68.0.0/255.255.0.0
You can specify multiple subnets by separating the entries with a

comma or a space. For example:
nisd.securenets: 172.68.0.0/255.255.0.0,196.48.0.0/0
To accept NIS client requests from any computer, you can set the
nisd.securenets configuration parameter as follows:
nisd.securenets: 0/0

For more information about restricting the computers sending NIS
client requests using the Centrify DirectControl configuration file
and configuration parameters, see “Customizing Centrify
DirectControl configuration options” on page 323.
Starting the adnisd daemon

Once you have specified the subnets from which to accept NIS
client requests, you can manually start the adnisd daemon at the
command line or you can configure the startup script on the local
computer to start the adnisd daemon whenever the computer is
rebooted.
To start the adnisd daemon at the command line, type the
appropriate start command. For example, on Red Hat Linux,
type:
/sbin/service adnisd start
On Solaris or Debian Linux, you can start the adnisd daemon by

running /etc/init.d/adnisd start.
Note The adnisd daemon requires RPC services. Therefore, before
starting the adnisd daemon, you should verify that RPC services are
running on the local computer. If you restart RPC, you will also
need to restart the adnisd daemon.
When the adnisd daemon starts, it connects to Active Directory

through adclient and does the following:
Retrieves the current NIS maps found in Active Directory for
its zone.
Updates the local netgroup.byuser and netgroup.byhost maps
generated from the netgroup map.
Stores the information from all of NIS maps in a local NIS map
data store on the Unix computer.
After the initial connection, the adnisd daemon then periodically
connects to Active Directory to retrieve updated NIS maps for its
zone. In between updates, the adnisd daemon responds to NIS
client requests using the data in its local NIS data store. Because this
information is available in the local data store, the adnisd daemon
can respond to NIS requests even when it is unable to contact
Active Directory for map refreshes.
NoteKeep in mind that if you don’t add the adnisd daemon to a
computer’s startup script, you must manually restart the adnisd
daemon whenever the computer is rebooted.
Customizing map updates

By default, the interval for connecting to Active Directory and
updating the NIS maps is set to every 5 minutes. This interval can
be customized by modifying the nisd.update.interval
configuration parameter in the Centrify DirectControl
configuration file.
You can also customize the list of maps to retrieve from Active
Directory. To explicitly specify a list of NIS maps you want to
retrieve from Active Directory, you can modify the nisd.maps
configuration parameter in the Centrify DirectControl
configuration file. By default, the adnisd daemon retrieves all
available NIS maps that have been stored in Active Directory each
time it connects to Active Directory.
Note Changes to automount maps typically require you to restart
the automount service or reboot the local computer.Therefore,
when there are updates to an automount map, you may need to
reboot the computer and restart the adnisd daemon to ensure the
updated information is used.
For more information about customizing the interval for updating

NIS maps or the maps supported using these configuration
parameters, see “Customizing Centrify DirectControl
configuration options” on page 323.

Once you install and configure the adnisd daemon on a computer,
you must configure other computers or devices to use the
computer running adnisd for NIS client requests. The steps for
configuring the NIS client are slightly different in client operating
environments. For information about configuring the NIS client in
different operating environments, see the appropriate section:
Configuring NIS clients on Linux
Configuring NIS clients on Solaris
Configuring NIS clients on HP-UX
Configuring NIS clients on Linux

To configure the NIS client on a Linux computer:
1 Set the NIS domain name for the client to the zone name of the
computer where the adnisd daemon is running.
domainname zone_name
For example, if you have installed the Centrify DirectControl

Network Information Service on a computer in the corpHQ zone:
domainname corpHQ
2 Edit the NIS configuration file, /etc/yp.conf, to specify the

Centrify DirectControl zone and the name of the computer
where the Centrify DirectControl Network Information Service
is installed.
domain zonename server hostname
For example, edit the /etc/yp.conf to include a line similar to

the following:
domain corpHQ server localhost
Note If your NIS clients are configured for broadcast discovery,

you can typically skip this step.
3 Start the ypbind service. On Linux, you can start the service by
running the following command:
/sbin/service ypbind start
Configuring NIS clients on Solaris

To configure the NIS client on a Solaris computer:
For example, if you have installed the Centrify DirectControl

Network Information Service on a computer in the corpHQ zone:
domainname corpHQ
2 Run the ypinit -c command and enter the name of the

computer where the Centrify DirectControl Network
Information Service is installed.
Note This step is not required if you want to use the broadcast
option to locate the server when you run the ypbind command.
You must use the ypinit command, however, if your network
topology would prevent a broadcast from reaching the desired
servers. For example, if the router does not transmit broadcasts
across subnets, you can use the ypinit -c command to specify a
server on a different subnet.
3 Start the ypbind service. On most versions of Solaris, you can
start the service by running:
/usr/lib/netsvc/yp/ypbind
If you are using the broadcast option to locate the server, you
must start the service with the broadcast option. For example:
/usr/lib/netsvc/yp/ypbind -broadcast
Note On Solaris 10, run the following command:

svcadm enable network/nis/client

Configuring NIS clients on HP-UX
To configure the NIS client on an HP-UX computer:
1 Edit the NIS configuration file, /etc/rc.config.rc/namesrvs,
to set the NIS_CLIENT to 1and the NIS_DOMAIN to the name for
the Centrify DirectControl zone name. For example:
NIS_CLIENT=1
NIS_DOMAIN="zone-name"
2 Add the -ypset option to the YPBIND_OPTIONS variable and set

the YPSET_ADDR variable to the IP address of the computer where
the Centrify DirectControl Network Information Service is
installed. For example:
YPBIND_OPTIONS="-ypset"
YPSET_ADDR="15.13.115.168"
Note This step is not required if you want to use the broadcast
option to locate the server when you run the ypbind command.
4 Start the ypbind service. On HP-UX, you can start the service
by running:
/sbin/init.d/nis.client start
Verifying the client configuration

To test that the client can connect to the Centrify DirectControl
Network Information Service, run an NIS client request command.
For example, try the following commands:
ypwhich
ypwhich -m
ypcat -k mapname

In most cases, the Centrify DirectControl Agent is installed on
individual computers to handle authentication and authorization
requests. You can, however, use the Centrify DirectControl Agent
and Centrify DirectControl Network Information Service together
on a single computer to respond to authentication requests from
NIS clients that don’t have the Centrify DirectControl Agent
installed.
To handle these “agentless” NIS client requests for authentication,
you need to install the Centrify DirectControl Network
Information Service and Centrify DirectControl Agent on at least
one computer and install and configure the Microsoft password
synchronization service to ensure the passwords served by the
Centrify DirectControl Network Information Service are always
up-to-date.
Preparing authentication service for NIS clients

To configure authentication through the Centrify DirectControl
Network Information Service:
1 Install the Centrify DirectControl Agent and Centrify
DirectControl Network Information Service on at least one
computer and join that computer to an Active Directory
domain.
2 Edit the nisd.securenets parameter in the Centrify
DirectControl configuration file, centrifydc.conf, to include a
list of the network addresses the server will accept requests
from. You can set this parameter to list specific IP addresses,
subnets, or all requests. For example, to accept requests from
computers in the 192.168.111.* subnet:
nisd.securenets: 192.168.111.0/255.255.255.0
By default, the Centrify DirectControl Network Information

Service only accepts requests from the local host, so in most
cases, you need to modify the nisd.securenets parameter to

enable authentication for other clients. You can also modify
other configuration parameters for the Centrify DirectControl
Network Information Service, if needed. For more information
about setting other parameters, see “Customizing NIS
parameters” on page 384.
3 Start the adnisd daemon using the appropriate command for
your local operating environment.
4 Configure your NIS clients to use the appropriate NIS domain.
For information about configuring the NIS client, see the
appropriate section in “Configuring NIS clients to use Centrify
As part of this step, you should verify that the NIS domain name
is the Centrify DirectControl zone for the computer you are
using as the NIS server. For example, you can run the
domainname command to verify the client is configured to use
the appropriate Centrify DirectControl zone:
domainname
default
In addition, you can verify the NIS client is connecting to the

Centrify DirectControl Network Information Service server by
running the ypwhich command.
You should also verify that the /etc/nsswitch.conf on the NIS
client includes the following lines:
passwd: files nis
shadow: files nis
group: files nis
5 Install Microsoft Windows Services for Unix or Microsoft

Windows Server 2003 R2 to add the password synchronization
service to your Active Directory environment.
In most cases, you can choose a standard installation with the
default options, then restart the computer. When you are
prompted to configure local user name mapping info:
Set the Windows domain to the domain you joined after

installing the Centrify DirectControl Agent.
Set the NIS domain name to the zone name you specified when
you joined the domain. For example, if you are using the
“default” zone, set the NIS domain to “default”.
Set the NIS Server name to the host name of the computer
running both the Centrify DirectControl Agent (adclient)
and the Centrify DirectControl Network Information Service
(adnisd).
Setting the NIS domain for password synchronization

After you install Windows Services for Unix and restart the
computer, you need to give user accounts access to the NIS domain
to enable password synchronization between Active Directory and
the NIS client through the Centrify DirectControl NIS server.
To enable password synchronization for users:
1 Start Active Directory Users and Computers, select a user
account, right-click, then select Properties.
2 Click the Unix Attributes tab.
3 Select the zone name you are using as the NIS Domain from the
list of NIS domains.
Note The rest of the fields on the Unix Attributes tab are not
used by Centrify DirectControl, but you are required to enter
information for these fields to enable the NIS domain for the
user. Therefore, you should specify a UID, Login shell, Home
directory, and Primary group for the user account, then click
OK.

Verifying authentication through adnisd
On a computer you have configured as an NIS client, you should
verify that the NIS maps required for authentication are available.
You can do this by running the following command:
ypwhich - m
At a minimum, you should the passwd.* and group.* map names

followed by the name of the computer you are using as the NIS
server. For example, if the computer running the Centrify
DirectControl Agent and Centrify DirectControl Network
Information Service is iceberg-hpux:
passwd.byuid iceberg-hpux
passwd.byname iceberg-hpux
group.byname iceberg-hpux
group.bygid iceberg-hpux
These passwd.* and group.* maps are generated based on the

information stored in Active Directory. If you imported the passwd
and group NIS maps and migrated the account information from
those maps to Active Directory users and groups as described in
“Importing from NIS” on page 224, these generated maps will use
information imported from those original maps. If you did not
import existing passwd and group maps, these maps are still
generated from the information for the Active Directory users and
groups that have access to the zone you are using as an NIS domain.
You can view information from any of these maps using a command
such as:
ypcat passwd.byname
The output displayed should look similar this:

paul:Xq2UvSkNngA:10000:10000:paul:/home/paul:/bin/bash
mlopez:!:10002:10000:Marco Lopez:/home/mlopez:/bin/bash
jsmith:!:10001:10000:John Smith:/home/jsmith:/bin/bash
In this example, the user paul has a password hash, but the users
mlopez and jsmith do not have password hashes.
If a user account is a new account and no password is available, the

Centrify DirectControl NIS server sets the password hash field for
the user’s account to “!” until the user sets a password. If a user’s
Active Directory account is disabled, locked, requires a password
change, or is not enabled for a zone, the Centrify DirectControl

NIS server sets the password hash field for the user’s account to “!!”
until the account is enabled, reset, or updated with a new
password.
Note On some platforms, you may see ABCD!efgh12345$67890 as
the password hash for users who need to set their password.

As discussed in “Using standard and custom NIS maps” on page 238
you can import standard NIS maps such as automount, netgroup,
and autohome for any zone, if these maps exist in your
environment. You can also create your own custom map files for
any information you want to make available to the NIS server and
store those custom maps in Active Directory. Once stored in
Active Directory, you can edit the map information, if needed.
To manage Centrify DirectControl NIS maps in Active Directory,
you need to install the NIS Extensions to the Centrify
DirectControl Administrator Console when you run the setup
program. If you accepted the default to install all components when
you ran the setup program, the extensions are available and simply
need to be added to the Centrify DirectControl Administrator
Console.
Note If you have not already installed the extensions, re-run the
setup program and select the Centrify DirectControl
Administrator Console > NIS Extensions component.
To add the NIS Extensions to the Centrify DirectControl

Administrator Console:
2 In the console tree, select Zones, right-click, then click Open
Zone.

3 Type a search string and click Find Now to find the zone you
want to work with, then click OK.
4 Click File > Add/Remove Snap-in.
5 Click the Extensions tab.
6 Select Centrify DirectControl NIS Map in the list of
available extensions, then click OK.
7 In the console tree, open the zone you selected in Step 3 to
display the new NIS Maps node. For example:
Adding new NIS maps to Active Directory

If you cannot import information from existing NIS maps or want
to publish custom information, you can use the NIS Extensions to
add custom maps to Active Directory. The file format used for an
NIS map depends on the type of map it is. Therefore, before adding
a custom map file, you should know the type of map you want to
create.
In Centrify DirectControl, you can create custom maps of the

following types:
Use this map type For this

autoMaster To create a custom version of the
auto.master NIS map. Because this is
a standard NIS map type, you cannot
modify the map name for this type of
map. The auto.master map is used to
retrieve the names of the autoMount
maps.
The basic format for map entries is:
mount-point map [options]
[comments]
where mount-point is the mount
point used and map indicates the map
name to be consulted for this
mount-point. The additional fields are
optional and can contain options to be
applied to entries in the map or
comments that describe the map.
autoMount To create a custom version of the
automount NIS map.
name network-path [options]
[comments]
where name is the name to use for
mounting a directory, and the
network-path specifies the absolute
path to the directory to be mounted. The
additional fields are optional and can
contain mount options or comments.
Generic To create a generic custom NIS map of
name-value pairs when the name
represents a key for the corresponding
value. Because this is not a standard NIS
map type, you can modify the map
name for this type of map.
key value

Use this map type For this
netgroup To create a custom version of the
netgroup NIS map. Because this is a
standard NIS map type, you cannot
modify the map name for this type of
map.
groupname member
Unless you are creating a custom version of a standard NIS map,

you should create custom maps using the Generic map type.
To add a custom map to Active Directory:
2 In the console tree, select Zones, and open the specific zone you
want to work with.
3 In the console tree, select NIS Maps, right-click, then click
New and select the type of map you want to add.
If you are creating an autoMaster map, you can choose to
name the map auto_master or auto.master, then click OK.
If you are creating an autoMount map, you can type a
custom name for the map, then click OK.
If you are creating a netgroup map, it is automatically added
with the name netgroup.
If you are creating a Generic map, type a name for the map,
then click OK.
4 In the details pane, select the new map, right-click, then click
New > Map Entry.
5 Type the details appropriate for the map type. For example, for
a Generic map, type the Key in the first field and a Value
associated with the key in the second field. You can also type
optional Comments for each key-value pair.
Once you have added map entries, you can edit or remove
information for any entry by selecting the map row to work
with, right-clicking, then selecting Properties to modify the
entry or Delete to remove the entry.
Importing an existing NIS map into Active Directory

You can use the NIS Extensions to import information from
standard NIS maps. If Centrify DirectControl can connect to the
NIS server and domain, you can import the NIS maps directly from
the server. If Centrify DirectControl cannot connect to the NIS
server, you can import NIS map information from text files.
Note For Centrify DirectControl to correctly interpret the map
file, you need to provide information about the file format, such as
the type of separator used between fields. In addition, if you want
to import comments recorded in NIS maps, you must save the map
to a text file and import from the file. Because the NIS server does
not include comments in response to service requests, you cannot
import comments in NIS maps if you import directly from an NIS
server and domain.
To import a standard NIS map into Active Directory:

2 In the console tree, select Zones, and open the specific zone you
want to work with.
3 In the console tree, select NIS Maps, right-click, then click
Import Maps.
4 Select whether you want to connect to the NIS server or import
the information from a map file, then click Next.
If you are importing maps directly from an NIS server, type
the name of the NIS domain and server. You can then s.
If you are importing a map from a text file, click Browse to
navigate to the map file you want to import.

5 Select the NIS maps to import if you are importing directly from
an NIS server, or type a map name and describe the file format if
importing from a file, then click Next. If you importing from a
file, you need to specify:
Map name that describes the type of map being imported
Character used to separate fields in the map file
Column number that defines the start of the key field
Whether to include comments and the character used to
designate comment lines
6 When the import is complete, click Finish.
7 After importing any NIS map, restart the adnisd service.
Editing NIS map entries

Once NIS maps are stored in Active Directory, you can use the
Centrify DirectControl Administrator Console to manually add or
edit individual map records for any map. The specific fields
available in each record depend on the type of map you are editing.
For example, the fields in an auto.master map entry are different
from the fields in a netgroup map entry.
For this type of map You can edit these fields for each record
autoMaster Mountpoint to use. This field is required.
Map file to be consulted for the specified mountpoint.
This field is required.
Options to be applied. This field is optional.
Comments that describe the mountpoint or provide
additional information. This field is optional.
autoMount Name to use. This field is required.
Network path specifies from where the file system is to
be mounted. This field is required.
Options to be applied to the entry. This field is optional.
Comments that describe the mountpoint or provide
For this type of map You can edit these fields for each record
netgroup Name of member groups. This field is required.
Comments that describe the member group or provide
Each group listed in the netgroup map can then have
member entries. Member entries can be selected from
existing netgroup entries or specify an individual
machine name, user name, and domain name.
Generic Key to use in looking up the entry in the map.
Value to be returned when looking up the entry in the
map.
Comments that describe the key-value pair or provide

If you have existing NIS servers running on your network, you can
configure your NIS clients to use the Centrify DirectControl
Network Information Service over time, as needed. Once you have
the Centrify DirectControl Network Information Service running,
you can also incrementally update the NIS data that’s stored in
Active Directory using the Centrify DirectControl Administrator
Console. Any updates you make are then propagated to all of the
adnisd servers automatically.
When you are satisfied that you have all of the appropriate NIS
information stored in Active Directory and have deployed the
adnisd daemon across the enterprise, as needed, you can then stop
any remaining legacy NIS servers and complete the migration to
Active Directory for secure, centralized directory service.

Chapter 13
Running reports
Centrify DirectControl includes several standard reports that

provide summarized and detailed information about your Unix
users, groups, computers, zones, and licenses. This chapter
describes the reports you can produce with Centrify DirectControl
and how to generate and export the report data.
Understanding the importance of reports
Understanding the information each report provides
Generating and viewing reports
Filtering report information
Displaying the group navigation pane
Exporting and saving report information
Printing reports
Understanding the importance of reports

Reports provide you with information about all of the Unix users,
computers, groups, and zones you have defined and the properties
associated with 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 by application license.
Reports can also be used as a way to periodically check the
integrity of zones across the Active Directory forest and to verify
which users have access to specific computers, zones, and
applications. Reports can help simplify accounting and auditing of
257
user access and 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.

The Centrify DirectControl reports you can run provide the
following information:
Run this report To view this information

Users Report All or selected Unix user account information,
including the Active Directory user name, the
Unix user name, the Unix user identifier (UID),
group, shell, home directory and zone.
Groups Report All or selected group information, including
the Active Directory group name, the group
membership, zone information, the Unix group
identifier (GID), and the Unix group name.
Computer Report All or selected computer information,
including the computer name in Active
Directory, DNS computer name, the operating
system, the zone the computer is part of,
whether shell access is enabled for the
computer, whether application access is
enabled for the computer, and the specific
applications enabled on the computer.
Zones Report All or selected zone information, including the
available shells, the default shell, default home
directory path, default primary group, next
available UID, reserved UIDs, next available
GID, and reserved GIDs.

Run this report To view this information
Application Report All or selected application information,
including the Active Directory and DNS
computer name where application access has
been enabled, the operating system on the
computer, whether shell access is enabled for
the computer, and the zone the computer is
part of.
User Account Report All or selected Unix user account information,
including the Active Directory user name, the
Unix user name, the current account status,
whether the account has been given access to
applications, and whether the account has
been given access to the Unix shell.
The account status indicates whether the
account is locked out, disabled, or set to expire,
and the time of the last log on.
License Summary Report The number of user, computer, and
applications licenses you have installed and
activated with licensing keys, including the
total number of licenses available for each type
of license, the number of licenses in use, and
the number of licenses still available.
License Detail Report The specific users and computers that have
been licensed for each type of license you have
installed and activated.
Computer Access Report The computers each user is allowed to access in
each zone.
Delegation Report The permissions delegated users or groups
have been given to perform specific actions in
selected zones.
This report indicates which users or groups
have permission to change zone properties,
add or remove users and groups from a zone,
join computers to the domain, and delete zone
information. The report does not include
information about the users or groups who
have permission to modify user or group
information.
Chapter 13 • Running reports 259


To run a report, perform the following steps:
2 In the console tree, click the Reports object.
3 Click the type of Report you want to generate. For example, to
run the Users Report with the default settings, select the Users
Report object. This displays the report selection options for the
type of report you are generating. For example:
4 If you want to filter user information to only include users

matching specific criteria, select the filtering criteria and click
Add. For example, you can filter the Users Report by Active
Note Although all reports allow you to filter the information
reported, the specific filtering options available vary, depending
on the type of report you are generating.
5 If you want to sort user information using specific criteria, click
the Sort tab, then select the sorting criteria and sort order you
want to use for the report. For example, you can sort user

information by Active Directory user name in either ascending
or descending order.
Note Although all reports allow you to sort the information
reported, the specific sorting options available vary, depending
6 If you want to group user information in the report, click the
Group tab, then select a Group by option to indicate how you
want to group user information. You can group user information
by user, primary group, or zone.
Note Although all reports allow you to group the information
reported, the specific grouping options available vary, depending
7 Click Run to start the report generation. In a few seconds, the
report is displayed in a new Main Report pane.
Note Reports only include information for the zones you have
currently open. For best performance, close the zones you are
not interested in reporting on before generating reports.
You can then print, export, or search the report output.

If you have a large organization or are looking for specific
information, you may want to filter the report to display only the
users, groups, computers, or zones, that meet certain criteria. The
filtering criteria you can select, depends on the type of report you
are generating. For example, for User reports, you can filter the
report by Active Directory user name, Unix user name, Unix UID,
or zone.
To filter a report:

3 Click the type of Report you want to generate. For example,

double-click the Users Report to generate a report about
Centrify DirectControl users.
4 Click the type of filter you want to apply. For example, if you
are only interested in the user accounts in a specific zone, you
can select Zones from the list of filters. The filtering criteria
you can select depends on the type of report you are generating.
For example, you can filter Users Reports by:
Active Directory user name
Unix user name
User identifier (UID)
Zone name
5 Select the criterion to use when matching the filter string. You
can specify that the filter starts with, contains, is, or ends with
the specified string.
6 Type the string you want to match, then click Add. For
example, to filter a report to include only users with a Unix
name that contains the letter “z”, the filter criteria looks similar
to the following:
Click Add to add the specified

criteria to the list of filters to be
applied
7 Specify any additional filters, as needed.

8 Click Run to generate a new filtered report in a new Main
Report window.

Note Reports only include information for the zones you have
currently open. For best performance, close the zones you are
not interested in reporting on before generating reports.
Displaying the group navigation pane

By default, new reports are displayed in a new Main Report pane.
This main report does not display its navigation pane by default.
For reports that span multiple pages, you may want to display this
navigation pane to make it easier to review the information. When
displayed, the navigation pane allows you to move through the
information in the report group by group.
To display the group navigation tree for a report:
3 Click the type of Report you want to generate.
4 When the Main Report is displayed, click the Toggle Group
Tree toolbar button ( ).
You can then navigate by clicking groups in the navigation pane. For
example:
Select a group in the navigation pane

to highlight a section in the report


Once you have generated a report you export the report to a
variety of formats. Since 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:
Adobe Acrobat (.pdf)
Microsoft Excel (.xls)
Microsoft Word (.doc)
Rich Text Format (.rtf)
For example, after generating a report you can export it to
Microsoft Excel (.xls) format, then import the report into an Excel
Worksheet to create a Charge Back report on account usage for
other departments.
To export a report:
4 When the Main Report is displayed, click the Export Report
icon ( ) in the toolbar.
5 In the Export Report dialog, type the name of the file to save,
select a format for the report, then click Save.
Printing reports
You can print reports either directly from the Main Report window
or by exporting to another format, then printing the exported
report.

To print a report from a Main Report window:
4 When the Main Report is displayed, click the Print Report icon
( ) in the toolbar.
5 Select a printer, then click OK.

Printing reports

Chapter 14
Troubleshooting authentication and

authorization
This chapter describes how to use diagnostic tools and log files to
retrieve information about the operation of Centrify DirectControl
and to identify and correct problems within your environment.
Understanding diagnostic tools and log files
Analyzing zone information in Active Directory
Configuring logging for Centrify DirectControl
Collecting diagnostic information
Working with DNS, Active Directory, and DirectControl
Filtering the objects displayed
Understanding diagnostic tools and log files

Centrify DirectControl includes some basic diagnostic tools and a
comprehensive logging mechanism to help you trace the source of
problems if they occur. These diagnostic tools and log files allow
you to periodically check your environment and view information
about Centrify DirectControl operation, your Active Directory
connections, and the configuration settings for individual Unix and
Linux computers.
Although Centrify DirectControl logging is not enabled by default
for performance reasons, log files provide a detailed record of
Centrify DirectControl activity. This information can be used to
analyze the behavior of the adclient daemon and communication
with Active Directory to locate points of failure. However, both log
files and other diagnostic tools provide an internal view of
267
operation and are primarily intended for Centrify DirectControl

experts and technical staff. In most cases, you should only enable
logging when you need to troubleshoot problems with the
adclient daemon or the connection to Active Directory or when
requested to do so by Centrify Technical Support. Other
troubleshooting tools can be used at any time to collect of display
information about your environment.

One important way you can troubleshoot your environment is by
running the Analyze command. The Analyze command enables you
to check the integrity of the zone information stored in Active
Directory. With the Analyzer, you can check zones for a variety of
potential problems, such as duplicate user IDs, duplicate groups,
empty zones, orphaned data objects, or computers that have joined
more than one zone.
Note When you run the Analyze command, only the zones that are
open are checked.
To check for problems with Centrify DirectControl information in

the Active Directory forest:
3 In the console tree, select the Centrify DirectControl root node,
right-click, then click Analyze.

5 Select the types of checks you want to perform, then click Next
to generate the report.
Select this option To do this

All Perform all of the data integrity checks.
Note If you do not register the
administrative notification handler
through the Setup Wizard or manually
using ADSI, you should periodically run
the Analyze command with All or
Orphan Unix data objects selected.
Duplicate groups in zones Check for duplicate Unix group names or
group identifiers (GIDs) in each open
Duplicate users in zones Check for duplicate Unix user names or
user identifiers (UIDs) in each open
Empty zones Check for zones that have no computers,
users, or groups.
Orphan Unix data objects Check for Unix profile objects that have
no parent objects because the parent
object has been deleted. For example, if
you delete a zone but do not delete the
users, groups, or computers that were
part of that zone, some Unix data will be
left in Active Directory. This option
removes any Unix-specific data left in
Active Directory after the parent was
deleted.
Computers joined to multiple Check for computers that have joined
zones the domain using more than one zone.
Each Unix computer should only reside
in one zone, but if you run the join
command more than once, it is possible
to have the same computer in more than
one zone. This option checks for this
problem.
Duplicate private groups container Check for duplicate top-level container
for private groups in the Active Directory
forest.
Chapter 14 • Troubleshooting authentication and authorization 269

Select this option To do this

Duplicate zone default container Check for duplicate top-level container
for zones in the Active Directory forest.
Old version 1 zone data Check for zone information stored in the
Centrify DirectControl version 1 format.
You should use this check if you
upgraded Centrify DirectControl from
version 1 to version 2 after you have
migrated all of your Centrify
DirectControl Agents to 2.0.
Zone created under another zone Check for zone information created in
another zone’s parent container.
Duplicate SFU zones Check for duplicate SFU zones that are
set to manage the same NIS domain.
6 Review the result summary, then click Finish.

7 If the result summary indicates any issues, you can view the
details by selecting Analysis Results in the console tree, then
selecting the date and time of the analysis. For example:

By default, Centrify DirectControl logs errors, warnings and
informational messages in the Unix syslog and
/var/log/messages files along with other kernel and program
messages. Although these files contain valuable information for
tracking system operations and troubleshooting issues, occasionally
you may find it useful to activate Centrify DirectControl-specific

logging and record that information in a Centrify DirectControl
log file.
Enabling logging for the Centrify DirectControl Agent

To enable Centrify DirectControl logging on the Centrify
DirectControl Agent:
1 Log in as or switch to the root user.
2 Run the addebug command:
/usr/share/centrifydc/bin/addebug on
Note You must type the full path to the command because
addebug is not included in the path by default.
Once you run this command, all of the Centrify DirectControl
daemon activity is written to the /var/log/centrifydc.log
file.
For performance and security reasons, you should only enable
Centrify DirectControl logging when necessary, for example,
when requested to do so by Centrify Technical Support, and for
short periods of time to diagnose a problem. Keep in mind that
sensitive information may be written to this file and you should
evaluate the contents of the file before giving others access to it.
When you are ready to stop logging activity, run the addebug off
command.
Setting the logging level

You can define the level of detail written to the log by setting the
log configuration parameter in the Centrify DirectControl
configuration file:
log: level
With this parameter, the log level works as a filter to define the
type of information you are interested in and ensure that only the
messages that meet the criteria are written to the log. For example,
if you want to see warning and error messages but not

informational messages, you can change the log level from INFO to
WARN. By changing the log level, you can reduce the number of
messages included in the log and record only messages that indicate
a problem. Conversely, if you want to see more detail about system
activity, you can change the log level to INFO or DEBUG to log
information about operations that do not generate any warnings or
errors.
You can use the following keywords to specify the type of
information you want to record in the log file:
Specify this level To log this type of information

FATAL Fatal error messages that indicate a system failure or other
severe, critical event. In addition to being recorded in the
system log, this type of message is typically written to the
user’s console. With this setting, only the most severe
problems generate log file messages.
ERROR System error messages for problems that may require
operator intervention or from which system recovery is not
likely. With this setting, both fatal and less-severe error events
generate log file messages.
WARN Warning messages that indicate an undesirable condition or
describe a problem from which system recovery is likely. With
this setting, warnings, errors, and fatal events generate log
file messages.
INFO Informational messages that describe operational status or
provide event notification.
Logging details for a specific component

By default, when you specify a logging level, it applies to all of the
Centrify DirectControl components that log activity. The logging
system, however, provides a hierarchical organization of logical log
names for the components within DirectControl and each of these
logical logs can be configured to provide more targeted analysis of
it specific operations. For example, if you set your base logging
level to only report serious errors but you want to see
informational, warning, and error messages for adclient, you can

add a separate logging level parameter for the log messages
generated by adclient:
# Use the following setting to set the base level of detail
# for logging to record Error messages:
log: ERROR
# Add the name of the adclient logical log and specify the
# logging level to use for it and its children:
log.com.centrify.adclient: INFO
Logging for the Centrify DirectControl Administrator Console

Although most logging activity focuses on the actions of the
Centrify DirectControl daemon, you can also enable or disable
logging for the Centrify DirectControl Administrator Console and
configure the types of messages to record in the log file by selecting
options in the Centrify DirectControl Administrator Console.
To configure logging for operations handled through the Centrify
DirectControl Administrator Console:
2 In the console tree, select Centrify DirectControl,
right-click, then click Options.
3 Click the Log Settings tab, select the type of messages to log,
then click OK.
If you enable logging, the log file is located by default in the
Program Files\Centrify\Centrify DirectControl\log folder
and is updated as you perform different operations in the Centrify

You can use the adinfo command to display or collect detailed
diagnostic and configuration information for a local Unix
computer. Options control the type of information and level of
detail displayed or collected. The options you are most likely to use

to collect diagnostic information are the --config, --diag, or

--support options, which require you to be logged in as root. You
can redirect the output from any adinfo command to a file for
further analysis or to forward information to Centrify Technical
Support.
For more information about the options available and the
information returned with each option, see “Using adinfo” on
page 303.
To display the basic configuration information for the local Unix
computer, you can type:
adinfo
If the computer has joined a domain, this command displays

information similar to the following:
Local host name: redhat-sfo-01
Joined to domain: sfo.acme.com
Joined as: redhat-sfo-01
Preferred site: Default-First-Site-Name
Zone: pzone1
Last password set: 2004-10-07 08:38:38 PDT
Generating diagnostic information when joining a domain

Although the adinfo command can provide many details about the
configuration of the local host and its Active Directory domain
controller, in some cases, you may want to generate diagnostic
information as an operation is in progress to log events as they
occur. To do this, you can use the addiag tool. The addiag tool is
used in conjunction with the join command to generate diagnostic
information when you are attempting to join a computer to the
domain.
To start logging diagnostic for the join command:
addiag join [options] domain_name
Before joining to the domain, this command enables debug-level

logging for the adjoin command and clears the system log. After
running the join command, whether the join is successful or not, all
log messages are redirected to a file named
/tmp/centrify.addiag_process_id.support.

To generate diagnostic information when joining to acme.com, run:
addiag join -z finance acme.com

Centrify DirectControl is designed to perform the same set of DNS
lookups that a typical Windows workstation will perform in order
to find the nearest domain controller for the local site. This DNS
lookup enables the DirectControl agent to find domain controllers
as they become available on the network or as the computer is
relocated to another network location where different domain
controllers are present. DirectControl also uses DNS to find the
Kerberos service providers within Active Directory and Global
Catalog service providers for the Active Directory forest.
In most situations, DNS is dynamically updated to contain the
service locator (SRV) DNS entries for Active Directory’s LDAP,
Kerberos and Global Catalog services. However, there are some
configurations of DNS that may not provide all these SRV records
for the set of domain controllers providing Active Directory
service to the enterprise. The next sections describe how you can
adjust DNS or DirectControl to ensure they work properly
together in your environment.
Checking your DNS configuration

The two most common scenarios are running DNS are:
As a Unix-hosted service using Bind.
As a Windows-hosted service within Active Directory.
If you are already using DNS in Active Directory and dynamically
publishing DNS service records, in many cases, no additional
configuration for Centrify DirectControl should be necessary. If
you are using DNS in Active Directory but have disabled dynamic
updates, you should change the configuration for the server role to
allow dynamic updates.

If your environment is configured to use Unix-based DNS servers

instead of Active Directory-based DNS servers and the Unix
system is configured to use DHCP, the nameserver entry in
/etc/resolv.conf file is set automatically to point to a DNS
server. If this DNS server is aware of the Active Directory domain
you want to join, no further changes are needed. If the DNS server
identified as a nameserver in the /etc/resolv.conf file is not
aware of the domain you are trying to join, for example, because
you are using a test domain or a separate evaluation environment,
you need to either disable DHCP or you need to manually set the
location of the Active Directory domain controller in the Centrify
DirectControl configuration file.
In most cases, you can verify whether a Unix computer can locate
the domain controller and related services by running the ping
command and verifying connectivity to the correct Active
Directory domain controller or by checking the nameserver entry
in the /etc/resolv.conf file. This nameserver entry should be the
IP address of one of the domain controllers in the domain you want
to join.
If the Unix computer cannot find the Active Directory domain
controller, there are several ways you can resolve the issue
depending on your specific situation. For example, you may need
to disable DHCP and manually configure the nameserver entry in
the /etc/resolv.conf file to identify an Active Directory domain
controller. In general, however, there are two basic ways you can
solve the problem:
Set up DNS on the target Active Directory domain controller
and the configure the /etc/resolv.conf file to use that domain
controller as described in “Setting up DNS service on a target
domain controller” on page 277.
Set the Centrify DirectControl configuration file to manually
identify the domain controllers you want to use as described in
“Setting the domain controller in the configuration file” on
page 279.

Setting up DNS service on a target domain controller
One of the simplest ways to ensure that the Unix clients can locate
the Active Directory domain controller and related services is to
use the DNS service on the Active Directory domain controller as a
DNS slave to the enterprise DNS servers. You can do this is by
configuring the DNS server role on the Active Directory domain
controller, then specifying that domain controller in the Unix
computer’s /etc/resolv.conf file. You can then add a forwarder
to the local DNS on the domain controller that will pass on all
lookups that it cannot satisfy to an enterprise DNS server.
This configuration does not require any changes to the enterprise
DNS servers. Any look up request from the domain controller is
simply a query from another computer in the enterprise. However,
the Unix computers configured to use this slave DNS service will
receive the appropriate Service Location (SRV) records and Global
Catalog updates for the Active Directory domain controller. In
addition, the DNS service on the domain controller can be
configured to forward requests to the enterprise DNS servers so
those requests can be answered when the local DNS service cannot
respond.
Note The specific steps for configuring the DNS server vary
depending on whether you are configuring a Windows 2000 Server
or a Windows Sever 2003 computer. The following steps describe
how to configure DNS on Windows Server 2003. If you are
configuring DNS on Windows 2000, you may want to consult your
Windows documentation for differences that are specific to your
environment.
To configure the DNS service on a Windows Server 2003 domain

controller:
1 Open the Start Menu and click Manage Your Server.
2 Click Add or remove a role, review the preliminary steps,
then click Next.

3 Select DNS Server from the list of Server Roles. If the DNS
Server role is not currently configured, click Next.
Note If this server role is already configured on this computer,
you can skip the next steps and go on to “Configuring Unix to use
DNS service on the target domain controller” on page 278.
4 Review the summary of steps, then click Next to display the
Configure a DNS Server Wizard. Click Next to configure
the DNS server lookup zones.
5 Select the Create a forward lookup zone (recommended
for small networks) option, then click Next.
6 Select This server maintains the zone, then click Next.
7 Type the domain name (dn) component of the Active Directory
domain controller’s name, then click Next. In most cases, you
should specify a sub-domain of the top-level domain name. For
example, if the forest root domain for the organization is
acme.com, you might have a sub-domain of labs.acme.com.
8 Select the Allow both nonsecure and secure dynamic

updates option, then click Next.
9 Type the IP address for at least one of the enterprise DNS
servers, then click Next. Setting at lease one valid IP address
ensures that any request the local DNS server cannot answer will
be forwarded to a valid enterprise DNS server.
10 Click Finish to complete the configuration of the DNS server.
Once you have configured DNS on the local computer, the local
computer uses the local DNS server as its primary DNS server.
Configuring Unix to use DNS service on the target domain controller

Once you have configured the DNS service to contain the required
Active Directory entries, you simply need to modify the Unix
computer to send all DNS lookup requests to the newly configured
DNS server.

To configure the Unix computer to use the new DNS server:
1 Open the /etc/resolv.conf file.
2 Set the IP address of the nameserver entry to the IP address of
the DNS server on the Active Directory domain controller you
just configured.
Setting the domain controller in the configuration file

If you are not able to use DNS to locate the Active Directory
domain controllers on your network, you can manually specify one
or more domain controllers in the Centrify DirectControl
configuration file.
To manually specify a domain controller, add the following entry to
the Centrify DirectControl configuration file,
/etc/centrifydc/centrifydc.conf:
dns.dc.domain_name: server_name [server_name ...]
For example, if you want to use Centrify DirectControl in a

domain called mylab.test and the domain controller for this
domain is dc1.mylab.test you would add the following line to the
/etc/centrifydc/centrifydc.conf file:
dns.dc.mylab.test: dc1.mylab.test
Note You must specify the name of the domain controller, not its IP
address. In addition, the domain controller name must be resolvable
using either DNS or in the local /etc/hosts file. Therefore, you
must add entries to the local /etc/hosts for each domain controller
you want to use if you are not using DNS or if the DNS server
cannot locate your domain controllers.
To specify multiple servers for a domain, use a space to separate the

domain controller server names. For example:
dns.dc.mylab.test: dc1.mylab.test dc2.mylab.test
Centrify DirectControl will attempt to connect to the domain

controllers in the order specified. For example, if the domain
controller dc1.mylab.test cannot be reached, Centrify
DirectControl will then attempt to connect to dc2.mylab.test.

If the Global Catalog for a given domain is on a different domain

controller, you can add a separate dns.gc.domain_name entry to
the configuration file to specify the location of the Global Catalog.
For example:
dns.gc.mylab.test: dc3.mylab.test
You can add as many domain and domain controller entries to the
Centrify DirectControl configuration file as you need. Because the
entries manually specified in the configuration file override any site
settings for your domain, you can completely control
DirectControl’s binding to the domains in your forest through this
mechanism.
Note In most cases, you should use DNS whenever possible to
locate your domain controllers. Using DNS ensures that any
changes to the domain topology are handled automatically through
the DNS lookups. The settings in the configuration file provide a
manual alternative to looking up information through DNS for those
cases when using DNS is not possible. If you use the
manually-defined entries in the configuration file and the domain
topology is changed by an Active Directory administrator, you must
manually update the location of the domains in each configuration
file.
Using the fixdns script

Centrify DirectControl includes a fixdns script that you can use to
inspect your environment and make the necessary configuration file
changes for you.
To run this script, you need to specify the domain controller name
and IP address:
fixdns domain_controller_name IP_address
For example if you intend to join the domain mytest.lab and the
domain controller for that domain is dc1.mytest.lab and its
address is 172.27.20.1, you would run the following command:
fixdns dc1.mytest.lab 127.27.20.1
The fixdns script will then make the necessary changes to the
/etc/hosts and the DirectControl configuration file.

Note This script does not update the /etc/resolv.conf file. If the
script cannot locate the domain controller using the existing
/etc/resolv.conf settings, it will assume that you want to use
settings from the configuration file.

For performance or security reasons, you may want to filter or
limit the objects displayed in the Centrify DirectControl
To filter the objects listed in the Centrify DirectControl
Administrator Console:
2 In the console tree, select Centrify DirectControl,
right-click, then click Options.
3 Click the Filter Settings tab.
Select Show disabled Active Directory accounts in
the list to include disabled computer and user accounts in the
Centrify DirectControl Administrator Console. Uncheck this
option to hide disabled objects.
Select Show orphaned user and group profiles to
include users and groups that have Unix profiles without a
corresponding user or group object in the Centrify
DirectControl Administrator Console. Uncheck this option
to hide orphan profiles.
Set the Maximum number of items to be displayed in
the list to limit the number of objects displayed in the
Centrify DirectControl Administrator Console. This setting
applies to all of the objects listed in the Centrify

DirectControl Administrator Console, including zones,

computers, users, groups, pending users and groups, and NIS
maps and entries.
4 Click OK.

Appendix A
Using Centrify DirectControl Unix

commands
This chapter provides an overview of the Unix command line
interface and complete reference information for the Unix
command line programs.
Understanding when to use command line programs
Displaying usage information and man pages
Using adjoin
Using adleave
Using adpasswd
Using adgpupdate
Using adinfo
Using addebug
Using adrmlocal
Using adfinddomain
Using adsmb
Using adclient
Using runmappers
Using OpenLDAP commands
283

All of the Unix command line programs are installed by default in
the /usr/sbin directory when you install the Centrify
DirectControl Agent on a Unix computer.
The Unix command line programs allow you to perform basic
Active Directory administrative tasks directly from a Unix shell or
using a shell script. These commands use the underlying Centrify
DirectControl service library to enable you to add a Unix
computer to an Active Directory domain, leave the Active
Directory domain, and change Active Directory user passwords,
and return detailed Active Directory, network, and diagnostic
information for a host computer.
You should use the Unix command line programs interactively or in
shell scripts when you must take action directly from a Unix
computer, for example to join or leave a domain, or when taking
action from the Unix computer is most convenient, for example
when individual users want to set new Active Directory passwords
from their Unix login shell.
You use these commands to perform specific tasks, as follows:
The most important command is the adjoin command. You
must use adjoin to add a Unix computer to an Active Directory
domain, so it is the command you use first and run on each
Unix computer.
You should use adleave if you want to remove a Unix computer
from its current Active Directory domain or from the Active
Directory forest entirely.
You can use adpasswd to change an Active Directory account
password from a Unix computer.
You can use adgpupdate to update computer-based and
user-based group policies applied to a Unix computer.

You can use adinfo to collect and display detailed diagnostic
and configuration information for a Unix computer and its
Active Directory domain.
Displaying usage information and man pages

You can display a summary of usage information for any of the Unix
command line programs by typing the command and the --help or
-h option. For example, to see usage information for the adleave
command:
adleave --help
The usage information displayed is a summary of the valid

command line options and required arguments and a brief
description of each option.
For more complete information about any command, you can
review the information in the command’s manual page. For
example, to see the manual page for the adleave command:
man adleave
Using adjoin
The adjoin command adds the local host computer to the specified
Active Directory domain. The basic syntax for the adjoin program
is:
adjoin [options] domain
The domain name should be a fully-qualified domain name, for

example, sales.acme.com.
If the computer is already a member of another domain, you must
leave the old domain by running adleave to remove the computer
account from the old domain. Once you have left the old domain,
you can run adjoin to join the new domain.
Note To run adjoin, you must be logged in as root.
Appendix A • Using Centrify DirectControl Unix commands 285

Using adjoin
By default, when you run adjoin, the program performs the

following tasks:
Locates the domain controller for the specified domain and
contacts Active Directory.
Synchronizes the local computer’s time with Active Directory
to ensure the timestamp of Kerberos tickets is within the
acceptable time period to allow for authentication.
Checks whether a computer account already exists for the local
computer in Active Directory, and creates a new Active
Directory computer account for the computer, if needed.
Updates the Kerberos principal service names used by the host
computer, generating new /etc/krb5.conf and krb5.keytab
files and new service keys for the host and http services.
Sets the password on the Active Directory computer account to
a randomly-generated password. The password is encrypted and
stored locally to ensure Centrify DirectControl alone has
control of the account.
Starts the Centrify DirectControl daemon (adclient).

Setting valid options
You can use the following options with this command:
Use this option To do this

-u, --user username[@domain] Specify an Active Directory username
with sufficient rights to add a computer
to the specified domain and create new
computer accounts. For example,
depending on the security delegation
policies in place, you may need to specify
a user account with Domain
Administrator privileges. By default,
however, any authenticated Active
Directory user can join a computer to the
domain.
You must use the username@domain
format to specify the user account if the
username is not a member of the
domain being joined.
Note When specifying
username@domain, you cannot use an
alternative UPN. You must use the
domain defined for your account.
If you do not specify the --user option,
the default is the Administrator user
account. Because this account has
special rights that can represent a
security risk, many organizations disable
or restrict access to it. Therefore, in most
cases, you should specify the --user
option when joining a domain.

Using adjoin

-p, --password userpassword Specify the password for the Active
Directory user account performing the
join operation. If you do not provide the
password at the command line, you are
prompted to enter the password before
the command executes.
Note Specifying a password at the
command line represents a security risk
because the password can be retrieved
while the command is running or from
command history after the command
has completed its execution.
-c, --container containerDN Specify the distinguished name (DN) of
the container or Organizational Unit in
which you want to place this computer
account.
The DN you specify should be a partial
DN. It can refer to any container within
the directory but should not include the
domain suffix. The domain suffix is
appended to the containerDN
programmatically to provide the
complete distinguished name for the
object. For example, if the domain suffix
is acme.com and you want to place this
computer in the
paris.regional.sales.acme.com
organizational unit within the
acme.com domain, you would specify:
“ou=paris, ou=regional, ou=sales”
If you do not specify a container, the
computer account is created in the
domain’s default Computers container.
Note that the container you specify must
already exist in Active Directory or the
join operation will fail. In addition, you
must have permission to add entries to
the specified container.

-n, --name computername Specify the host name you want to use
for this computer in Active Directory.
If you do not specify a computername,
the computer account name in Active
Directory is the same as the local host
name.
-f, --force Overwrite the information stored in
Active Directory for an existing
computer account. This option allows
you to replace the information for a
computer previously joined to the
domain. If there is already a computer
account with the same name stored in
Active DIrectory, you must use this
option if you want to replace the stored
information. You should only use this
option when you know it is safe to force
information from the local computer to
overwrite existing information.
-a, --alias computeralias Specify an alias name you want to use
for this computer in Active Directory.
This option creates a Kerberos service
principal name for the alias and the
computer may be referred to by this
alias. This option would normally be
used if a computer has more than one
ethernet port and each port is known by
a different DNS name. You can specify
more than one alias option if you need
to specify multiple aliases for a single
computer.

Using adjoin

-z, --zone zonename Specify the name of the zone in which to
place this computer account. If you do
not specify a zone, the computer joins
the domain in the default zone (a zone
named “default” is normally created
when you run the Setup Wizard for the
first time).
If you specify a zone name and the
named zone does not exist, then the join
operation fails.
-C, --noconf Indicate that you do not want to update
the local system’s PAM and NSS
configuration. If you set this option, you
will need to modify the PAM and NSS
configuration files manually to work
with the adclient daemon.
-t, --notime Indicate that you do not want to update
the local computer time. Under normal
circumstances, the local computer time
should be updated to be synchronized
with the Kerberos Key Distribution
Center (KDC) in Active Directory. If you
use this option, some ticket
authentications may fail.
-s, --server domaincontroller Specify the name of the domain
controller to which you prefer to
connect. You can use this option to
override the automatic selection of a
domain controller based on the Active
Directory site information.
-T, --trust Set the Trust for delegation option in
Active Directory for the computer
account. Trusting an account for
delegation allows the account to
perform operations on behalf of other
accounts on the network.
-k, --des Set the computer account to use the
Data Encryption Standard (DES) for keys.

-V, --verbose domain Displays information about each step in
the join process as it occurs. This option
can be useful in diagnosing join
problems. This option also writes log
messages to the centrifydc.log file
for troubleshooting purposes.
-v, --version Display version information for the
installed software.
Examples of using adjoin

Joining a domain can be a very simple or fairly sophisticated
operation depending on the design of your Active Directory forest,
how you want to manage your Unix systems, and the policies your
organization follows. The following examples illustrate some of the
options you can use when joining a domain.
To join the acme.com domain using all of the default options and the
Administrator user account, you could type a command line similar
to the following:
adjoin acme.com
You are then prompted for the Active Directory Administrator

password.
If you want to join the sales.acme.com domain using a user
account that is not in that domain, using a specified zone, host
name, and Organizational Unit, you could type a command line
adjoin --user jeff@acme.com --zone LinuxDev --name orlando
--container “ou=UNIX computers” sales.acme.com
You are then prompted to provide the password for the user
jeff@acme.com.
Note When specifying username@domain to join a domain, you

cannot use an alternative UPN. For example, if your organization
uses an alternate UPN to allow you to log in as garcia@mission.org
but your account is actually defined in the sf.mission.org domain,
you must use that domain when specifying the user account:

Using adjoin
adjoin --user garcia@sf.mission.org la.mission.org
The computer account is added to Active Directory using the

computer name “orlando” in the “UNIX computers” Organizational
Unit.
Understanding the files modified by the running adjoin

Running adjoin modifies several key files to complete the join
operation and configure your environment to work with Active
Directory for authentication, authorization, and directory services.
By default, the following files are modified by running adjoin:
Type On File location

Kerberos configuration file Most platforms /etc/krb5.conf
Solaris /etc/krb5/krb5.conf
Kerberos keytab file Most platforms /etc/krb5.keytab
Solaris /etc/krb5/krb5.keytab
NSS configuration file All platforms /etc/nsswitch.conf
PAM configuration file HPUX, Solaris /etc/pam.conf
Red Hat Linux /etc/pam.d/system-auth
All other Linux /etc/pam.d/*
nscd configuration file Solaris, Linux /etc/nscd.conf
Login control file AIX /etc/security/user
In addition, the following files are created in the /var/centrifydc

directory by running adjoin or by starting the Centrify
DirectControl Agent for the first time:
Name Purpose
daemon This is the pipe which clients open to
communicate to the agent.
dc.cache Cache of objects from the Domain
Controller
gc.cache Cache of objects from the Global Catalog

Name Purpose
dcdn.idx Cache index
extmgr.idxCache index
gcdn.idx Cache index

gid.idx Cache index
gname.idx Cache index
search.idx Cache index
uid.idx Cache index
uname.idx Cache index
kset.domain The domain name
kset.domaincontroller The domain controller host name
kset.host The host name used to join
kset.schema The current schema version
kset.site The preferred site
kset.zone The Zone GUID
kset.zonename Readable zone name
reg/*/*/* Group Policy registry files downloaded
from AD
Working in an environment without a global catalog

If you join a Unix computer to a domain where there is no global
catalog available, users from other domains must use their
fully-qualified login name to be authenticated successfully. In
addition, users who are members of groups in other domains will
not have their full group membership information. Only the group
information for the joined domain will be visible.

Using adleave
Using adleave
The adleave command removes the local host computer from its
current Active Directory domain. Once a computer has become a
member of a domain, you must run the adleave command to leave
that domain before you can move a computer to a new domain.
The basic syntax for the adleave program is:
adleave [options]
By default, when you run adleave, the program performs the

following tasks:
Contacts Active Directory and deactivates the computer
account associated with the local Unix host. The program does
not remove the computer account from Active Directory. To
remove the computer account entirely, you must delete it from
Active Directory manually with Active Directory Users and
Computers.
Reverts any computer settings that were changed by the adjoin
command to their pre-adjoin condition. This includes
reverting PAM, NSS, and Kerberos configuration files to their
pre-join states, deleting the /var/centrifydc/* files, and
deleting /etc/krb5.keytab.
When you join a domain, the Kerberos configuration file,
/etc/krb5.conf, and keytab file, /etc/krb5.keytab, are
automatically generated for you. Because the /etc/krb5.conf
file can contain entries used by other applications, it is not
removed automatically when you leave a domain. If you leave
the domain, you should check whether this file is used by any
other applications or if it has been manually edited. If it is not
used by other applications, you can safely delete the file after
leaving the domain.
Stops the Centrify DirectControl daemon (adclient).
Note To run adleave you must be logged in as root.


-u, --user username[@domain] Identify an Active Directory user account
with sufficient rights to remove a
computer from the domain.
You must use the username@domain
format to specify the user account if the
username is not a member of the
computer's current domain. If you do not
specify the --user option, the default
is the Administrator user account.
-p, --password userpassword Specify the password for the Active
Directory user account performing the
leave operation. If you do not provide
the password at the command line, you
are prompted to enter the password
before the command executes.

Using adleave

-C, --noconf Indicate that you do not want to revert
the local system's PAM and NSS
configuration files to their original state.
Normally, if you leave a domain, any
changes that have been made to the
PAM and NSS configuration files to work
with the adclient daemon during the
join operation are removed. If you set
this option to leave the file changes in
place, you should review the PAM and
NSS configuration files for potential
changes.
Note Be sure to review and, if necessary,
edit the PAM and NSS configuration files
before you use this option. If you don't
take precautions before using this
option, the computer may become
inoperable and require a reboot in single
user mode to fix the problem.
-f, --force Indicate that you want to force the local
computer’s settings to their pre-join
conditions even if the adleave
command cannot connect to Active
Directory or is not successful in
deactivating the Active Directory
computer account.
You must use this option if the Active
Directory computer account has been
modified or deleted so that the host
computer can no longer work with it.
installed software.
Examples of using adleave

Leaving a domain is a straightforward process that returns a
computer to its pre-join state. The following examples illustrate
the options you can use when leaving a domain.

To remove a computer from its current domain using the default
options and the Administrator user account, you could type a
command line similar to the following:
adleave
You are then prompted for the Active Directory Administrator

password.
To remove a computer from its current domain using a specific user
account and without reverting the PAM and NSS configuration files
to their pre-join state, you could type a command line similar to
the following:
adleave --user raj@acme.com --noconf
You are then prompted for the password for the user
raj@acme.com.
To revert all computer settings to their pre-join state even if unable

to deactivate the host computer's in Active Directory account, you
could type a command line similar to the following:
adleave --force
Using adpasswd
The adpasswd command changes the password for an Active
Directory user account. It can be used to change the password of
the current user executing the command or to change the password
of another Active Directory user. If you want to change the
password for any Active Directory account other than your own,
you must provide the user name and password of an administrative
account with the authority to change that user’s password.
The basic syntax for the adpasswd program is:
adpasswd [options] [user[@domain]]
If a user@domain is specified in the command line, you must

provide an administrative user name and password for an Active
Directory account with the authority to set passwords for other
Active Directory users. If a user@domain is not specified in the
command line, this command can only be used to change the
password for the current user account.

Using adpasswd
Because adpasswd allows a user to change his or her own password,

you do not need to be logged in as root to run this command.
Note Changing a user’s password with this command updates the
user’s Active Directory account. Once changed, the new password
must be used for all activities that are authenticated through Active
Directory, including logging on to the Unix shell, logging on to
Windows computers, and accessing applications on both Unix and
Windows.


-a, --adminuser Identify an Active Directory user account
adminuser[@domain] with sufficient rights to modify another
Active Directory user account.
You must use the adminuser@domain
format to specify the account if the
administrative user is not a member of
the host computer's current domain.
If you do not specify this option, the
default is the Administrator user
account.
-p, --adminpass adminpassword Specify the password for the Active
Directory administrative account when
changing another user’s Active Directory
password. If you do not provide the
prompted to enter the password before
the command executes.

-o, --oldpass oldpassword Specify the current password for the
Active Directory user account.
This option is only used when the user
executing the command is trying to
change the password for his own
account. This option is ignored if the
administrator is trying to change the
password for another user account.
If you are trying to changing your own
password and do not provide the current
prompted to enter the old password
before the command executes.
-n, --newpass newpassword Specify the new password for the Active
Directory user account. If you do not
provide the password at the command
line, you are prompted to enter the new
password and confirm the new
password by retyping it before the
command executes.
The new password must meet the Active
Directory domain password policy
requirements for length and complexity.

Using adpasswd

user[@domain] Specify the Active Directory user account
for the password change. You must use
this option if you are changing another
Active Directory user’s account
password. You should not use this option
when changing your own account
password. If a user name is not specified,
the default is always the current user’s
account.
You must use the user@domain format
to specify the account if the user is not a
member of the host computer’s current
domain.
installed software.
Examples of using adpasswd

In most cases, you use this command to change the password for
your own account. The following command illustrates how to
change the password for the current user account. It prompts for
the old and new passwords because they aren’t provided in the
command line:
adpasswd
Old password: xxx
New password: xxx
Repeat password: xxx
The following command illustrates changing the password for

another user account, jane@acme.com, which is in a domain outside
the host computer’s own Active Directory domain. Because this
example changes the password for another user, the command
specifies an Active Directory administrative account,
admin@acme.com, with the authority to change the password for
Jane’s account:
adpasswd --adminuser admin@acme.com jane@acme.com

You are then prompted for the administrator password and the
user’s new password because these values aren’t provided in the
command line.
Administrator password: xxx
New password for jane@acme.com: xxx
Repeat password: xxx
Using adgpupdate
The adgpupdate command retrieves group policies from the Active
Directory domain controller and applies the policy settings to the
local computer and current user immediately. Under normal
conditions, without running this command, group policies are
updated automatically every 90 to 120 minutes by default. If you
want a policy change to take effect immediately, however, you can
force the group policy to be refreshed by running the adgpupdate
command. Upon updating the group policy, the adgpupdate
command then resets the timer for the next automatic update to
occur in the next 90 to 120 minutes.
Note Automatic group policy updates occur at a random interval
between 90 and 120 minutes to prevent multiple computers from
connecting to and requesting updates from the Active Directory
domain controllers at the same time. However, both the default
interval of 90 minutes and the default offset period of 30 minutes
can be configured to other values using group policy settings.
Therefore, the automatic group policy update may occur more or
less frequently in your environment. For information about setting
computer and user group policies, see Chapter 9, “Managing group
policies for Unix users and computers.” For information about
customizing the group policy update, see Appendix B,
“Customizing Centrify DirectControl configuration options.”
The basic syntax for the adgpupdate program is:

adgpupdate [options]
By default, the adgpupdate command updates both the

computer-based group policies and the user-based group policies

Using adgpupdate
for the user who is currently logged in and running the adgpupdate
command. With a command line setting, you can restrict the group
policies updated to be only computer group policies or only the
current user’s group policies, if needed.


-T, --target [Computer|User] Restrict the group policy update to
either Computer group policy or User
group policy.
installed software.
Examples of using adgpupdate

In most cases, you use the adgpupdate command to update both
the computer-based group policies and the user-based group
policies after changes have been made or when new policies are set.
To update both the computer and user group policies on the local
computer for the current user account, you can type:
adgpupdate
The command then displays update status similar to the following:

Refreshing Computer Policy...
Computer Policy Refresh has completed.
Refreshing User Policy...
User Policy Refresh has completed.
If you only want to update computer group policy on the local

computer, you can type a command similar to the following:
adgpupdate --target Computer
Note To update user policies on a computer, you must be logged on

as a valid Active Directory user. If you are not logged on as a valid
Active Directory user, running adgpupdate will refresh the
computer-based group policies but no user-based group policies
will be updated.

Using adinfo
The adinfo command displays detailed Active Directory, network,
and diagnostic information for a local Unix computer. Options
control the type of information and level of detail displayed.
The basic syntax for the adinfo program is:
adinfo [option] [--user username[@domain]]
[--password password]
The option argument can be any one of the following:

adinfo [--domain] [--zone] [--site] [--server] [--name]
[--all] [--support [--output filename]] [--diag [domain]]
[-–config] [--mode] [--version]
The --domain, --zone, --site, --server, and --name options are

intended for use in scripts to return the current Active Directory
domain, zone, site, domain controller, and computer account
name, respectively. The other options provide more detailed
information.
You can use the --user and --password options in conjunction
with the --all, --support, or --diag option to specify the user
name and password of an Active Directory account with permission
to read the computer account information in the Active Directory
domain controller you are accessing. If you run adinfo while
logged in as root, you do not need to specify the --user or
--password option because the command uses the Active
Directory account associated with the local host. If you run the
adinfo command with a user account that doesn’t have permission
to read the computer account information in Active Directory,
some information may not be available in the command output.
Note To run the adinfo --support command, you must be logged
in as root. You are not required to log in as root for any of the other
adinfo options.
If you do not specify an option, adinfo returns the basic set of

configuration details for the local computer, which is equivalent to
specifying adinfo --all.

Using adinfo


-d, --domain Return the name of the local computer’s Active
Directory domain.
If the computer isn’t currently joined to an Active
Directory domain, then the command exits and
returns an exit status of 2.
-z, --zone Return the name of the local computer’s Active
Directory zone.
-s, --site Return the name of the local computer’s Active
Directory site.
-r, --server Return the fully-qualified name of the local
computer’s Active Directory domain controller.
-n, --name Return the fully-qualified name of the local
computer’s computer account name in Active
Directory.

-a, --all Return the following information:
• Local host name
• Domain the computer is joined to
• Computer account name in Active Directory
• Local preferred site
• Centrify DirectControl zone
• The date and time that the password was last
reset for the computer’s Active Directory
computer account
• Current operational mode indicating whether
the computer is connected to Active Directory or
running in disconnected mode
Note If you use this option but the user account
doesn’t have permission to read the computer
account information in Active Directory, the
command output does not indicate whether shell
access has been enabled or information about the
last password set.

Using adinfo

-t, --support Return all of the information supplied by the
[--output filename] --all option and the following additional
information:
• The current configuration parameters set in
/etc/centrifydc/centrifydc.conf
• The settings from /etc/krb5.conf
• The contents of the log file
/var/log/centrifydc.log
• The key list from /etc/krb5.keytab
This option is typically used to send complete
diagnostic information to a file, which can then be
sent to Centrify Technical Support for analysis.
By default, the output for the command is written
to the file /tmp/adinfo_support.txt. You can
save the output in a different location or using a
different file name by using the optional
--output argument, redirection (>) or the pipe
(|) command.
Note The root account is required if you want to
retrieve the Kerberos key version stored in Active
Directory for comparison with the local Kerberos
key.

-g, --diag [domain] Return the diagnostic information for the host
computer and a specific Active Directory domain. If
you don’t specify the domain, the command
returns information for the computer's current
domain.
Specifying a domain is useful when an attempt to
join the computer to an Active Directory domain
fails. By specifying adinfo --diag and the
domain you tried to join, you can better diagnose
why an attempt to join failed.
This option returns the following information:
• Local host name.
• Local IP address.
• List of the DNS servers for the specified domain.
• Host name of the DNS server supplied by the
domain controller.
• Whether the domain controller has up-to-date
global catalog data so that it can become the
global catalog, if necessary.
• Functional level of the specified Active Directory
domain.
• Functional level of the domain's Active Directory
forest.
• Functional level of the domain controller.
• Name of the Active Directory forest to which the
specified domain belongs.
• Name of the computer account in Active
Directory for this computer.
• Kerberos key version for this computer.
• List of Kerberos service principal names this
computer has registered with Active Directory.
Note You should use the root user account when
you use this option. If you don’t use the root
account, the command will not be able to bind to
domain controller or locate the computer account.
The root account is also required to compare the
local key version with the key version stored in
Active Directory.

Using adinfo

-c, --config Return the parsed contents of the Centrify
DirectControl configuration file.
-m, --mode Display whether the computer is currently
connected to Active Directory or running in
disconnected mode.
-v, --version Display version information for the installed
software.
-u, --user Identify an Active Directory user account with
username[@domain] sufficient rights to read the computer account
information.
You must use the username@domain format to
specify the user account if the username is not a
member of the computer's current domain. If you
do not specify the --user option, the default is
the Administrator user account.
-p, --password Specify the password for the Active Directory user
userpassword account. If you do not provide the password at the
command line, you are prompted to enter the
password before the command executes.
Note Specifying a password at the command line
represents a security risk because the password can
be retrieved while the command is running or from
command history after the command has
completed its execution.
Examples of using adinfo

In most cases, you use the adinfo command to provide information
that will help you diagnose and resolve problems Centrify
DirectControl or Active Directory environments.
To display the basic configuration information for the local Unix
computer, you can type:
adinfo
If the computer has joined a domain, this command displays

information similar to the following:
Local host name: mission-sf-04
Joined to domain: arcade.com
Joined as: mission-sf-04.arcade.com

Preferred site: Default-First-Site-Name
Zone: arcade.com/Program Data/Centrify/Zones/default
Last password set: 2006-02-22 13:20:31 PST
CentrifyDC mode: connected
You can also use adinfo in shell scripts to return specific

information, such as the domain a computer has joined. For
example, the following command returns the host computer’s
current domain and no other information:
adinfo --domain
For example:
arcade.com
The adinfo --diag command can also be useful in diagnosing

Active Directory configuration issues and Kerberos problems. For
example, in addition to other information, the --diag option
returns the Kerberos key version for the Unix computer. The key
version is stored both locally and in the computer’s Active
Directory account. It is incremented when a service principal’s
password key changes. If the local key differs from the Active
Directory account key version, it indicates that the local key is no
longer in sync with the Active Directory key and this may cause
authentication to fail.
By running adinfo --diag and checking the Key Version: field
you can determine whether the key versions are the same or out of
sync. If the versions are different, the Key Version field shows both
keys and indicates which is local and which comes from Active
Directory. If the computer isn’t joined to a domain, it has no local
key and the following is displayed:
Key Version: local key version unavailable
If the computer is joined to a domain other than the specified

domain, the Active Directory key is shown as:
<unavailable>
If the computer has joined a domain, the adinfo --diag command

displays information similar to the following truncated example:
Host Diagnostics
uname: Linux mission-sf-04 2.4.21-15.EL #1 Thu Apr 22 00:27:41 EDT
2004 i686
OS: Red Hat Enterprise Linux ES
Version: 3 (Taroon Update 2)

Using adinfo
IP Diagnostics
Local host name: mission-sf-04
Full local host name: localhost.localdomain
Local IP Address: 192.168.147.134
Domain Diagnostics:
Domain: arcade.com
DNS query for: _gc._tcp.arcade.com
DNS query for: _ldap._tcp.arcade.com
Locating global catalogs for arcade.com from DNS
Found SRV records:
fire.arcade.com:3268
Locating domain controllers for arcade.com from DNS
Found SRV records:
fire.arcade.com:389
Testing Active Directory TCP connectivity:
Global Catalog: fire.arcade.com
gc: 3268 - good
Domain Controller: fire.arcade.com
ldap: 389 - good
smb: 445 - good
kdc: 88 - good
kpasswd: 464 - good
Anonymous LDAP bind to fire.arcade.com:3268
Retrieve DC root object
Domain Controller: fire.arcade.com:3268
Domain controller type: Windows 2003
Domain Name: ARCADE.COM
isGlobalCatalogReady: TRUE
domainFunctionality: 0 = (DS_BEHAVIOR_WIN2000)
forestFunctionality: 0 = (DS_BEHAVIOR_WIN2000)
domainControllerFunctionality: 2 = (DS_BEHAVIOR_WIN2003)
Anonymous LDAP bind to fire.arcade.com:389
Retrieve DC root object
Domain Controller: fire.arcade.com:389
Domain controller type: Windows 2003
Domain Name: ARCADE.COM
isGlobalCatalogReady: TRUE
domainFunctionality: 0 = (DS_BEHAVIOR_WIN2000)
forestFunctionality: 0 = (DS_BEHAVIOR_WIN2000)
domainControllerFunctionality: 2 = (DS_BEHAVIOR_WIN2003)
Forest Name: ARCADE.COM
Retrieving site data from arcade.com
Using machine credentials
Using principal name 'mission-sf-04$@ARCADE.COM'
Binding to arcade.com, cache=MEMORY:0x862e5e0
Retrieving subnet objects from
CN=Subnets,CN=Sites,CN=Configuration,DC=arcade,DC=com
Retrieving zone data from arcade.com
Centrify DirectControl 2.x zones:
default - arcade.com/Program Data/Centrify/Zones/default
Computer Account Diagnostics
Joined as: mission-sf-04
Searching for
(&(samAccountName=mission-sf-04$)(objectClass=computer))
in dc=ARCADE,dc=COM
Found computer account:
CN=mission-sf-04,CN=Computers,DC=arcade,DC=com
Kerberos key number from computer account: 2
Examining local keys
Keys in /etc/krb5.keytab for arcade.com
version - timestamp - principal - encryption
2 02/22/06 09:20:31 cifs/mission-sf-04@ARCADE.COM ...
2 02/22/06 09:20:31 ftp/mission-sf-04@ARCADE.COM ...
2 02/22/06 09:20:31 HTTP/mission-sf-04@ARCADE.COM ...

2 02/22/06 09:20:31 host/mission-sf-04@ARCADE.COM ...
2 02/22/06 09:20:31 mission-sf-04$@ARCADE.COM ...
...
Most recent local key version: 2
Key Version: 2
Retrieving servicePrincipalName from computer object
Service Principal Names: cifs/mission-sf-04.arcade.com
cifs/mission-sf-04
ftp/mission-sf-04.arcade.com
ftp/mission-sf-04
HTTP/mission-sf-04
HTTP/mission-sf-04.arcade.com
host/mission-sf-04
host/mission-sf-04.arcade.com
Centrify DirectControl Status
Running in connected mode
Using addebug
The addebug command is used to start or stop detailed logging
activity for the Centrify DirectControl daemon on a local Unix
computer.
The basic syntax for the addebug program is:
addebug [on | off]
If you do not specify either option, addebug displays its current

status, indicating whether logging is active or disabled.


on Start logging all Centrify DirectControl daemon
activity.
off Stop logging Centrify DirectControl daemon
activity.
Examples of using addebug

You use the addebug command to start and stop detailed Centrify
DirectControl-specific logging to help you trace and resolve
problems.

Using adrmlocal
To display the current status of logging, type:

/usr/share/centrifydc/bin/addebug
Note You must type the full path to the command because addebug
is not included in the path by default.
This command displays information similar to the following:

Centrify DirectControl debug logging is off
To turn on logging, type:

/usr/share/centrifydc/bin/addebug on
This command records information in the

/var/log/centrifydc.log file similar to the following:
...
Dec 14 00:31:59 jon adjoin[11198]: com.centrify.join: Joining domain
garfield.com
Dec 14 00:31:59 jon adjoin[11198]: com.centrify.base: Getting the KDC
List for garfield.com
Dec 14 00:31:59 jon adjoin[11198]: com.centrify.base: Updating config
file with domain garfield.com
Dec 14 00:31:59 jon adjoin[11198]: com.centrify.join: Created user
LDAP connection
Dec 14 00:31:59 jon adjoin[11198]: com.centrify.daemon.ADBinding:
Destroying binding to 'garfield.com'
Attempting connection to server
Connecting to odie.garfield.com:389
Connected
...
For performance and security reasons, you should only enable

Centrify DirectControl logging when necessary, for example,
when requested to do so by Centrify Technical Support, and for
short periods of time.
To discontinue logging, type:
addebug off
Using adrmlocal
The adrmlocal command reports and removes local user names
that duplicate Active Directory user names.
The basic syntax for the adrmlocal program is:
adrmlocal [--interactive] [--commit] [--force] [--version]

The adrmlocal command displays a report of users who are in both
a local user database, for example, the local user accounts defined
in the /etc/passwd file, and in Active Directory to allow you to
check for duplicate user names. You can remove selected duplicate
local user names interactively or remove all duplicate local users
without prompting.
If you run this command with the --interactive option, the
command prompts you to remove the local user account or skip
each duplicate user, regardless of whether the user’s UID or GID in
/etc/passwd matches the information for the user name in Active
Directory. If you run this command with the --commit option, the
command removes duplicate users if there are not UID or GID
conflicts but prompts you to remove or skip local users that have
UID or GID conflicts. If you run this command with the --force
option, the command removes all duplicate local users whether
without prompting.
To delete local user accounts in a NIS domain, you should run the
adrmlocal command on the NIS master server. After running the
command, you must update the NIS passwd maps to make the
updated information available to your NIS servers.


-i, --interactive Be prompted interactively for confirmation that
you want to remove the duplicate local user
account before performing the delete operation.
-c, --commit Remove duplicate local users if the UID and GID is
the same in the local database and Active
Directory. If the UID or GID for a local user conflicts
with the information stored in Active directory, this
option prompts you to determine whether a local
user account should be deleted or not.
-f, --force Remove all duplicate local user names without
prompting even if there are UID or GID conflicts.

Using adfinddomain

software.
Examples of using adrmlocal

You use the adrmlocal command to view and remove duplicate
local user accounts that conflict with Active Directory user
accounts.
To report duplicate user names that exist in both the local user
database and Active Directory and respond to each duplicate
interactively, you would type:
adrmlocal --interactive
This command displays a summary of the conflicts found, then

prompts you to decide whether each duplicate user should be
deleted. For example:
3 local user(s) that are duplicated with AD users:
adam:uid(505):gid(503):ADuid(10001):ADgid(10000) Conflicted with AD
chin:uid(506):gid(504):ADuid(10009):ADgid(10000) Conflicted with AD
liz:uid(507):gid(505):ADuid(10005):ADgid(10000) Conflicted with AD
Delete local user adam ? (Yes/No)
Using adfinddomain
The adfinddomain command displays the domain controller
associated with the Active Directory domain you specify.
The basic syntax for the adfinddomain program is:
adfinddomain [--format name|ldap|ip] [--verify] [--version]
[domain]
If you don’t specify a domain, the command returns information

for the domain the local computer is joined to.


-f, --format Control the format of the information displayed for
name|ldap|ip the domain controller. For example, if you set the
format to name, the command displays the host
name of the domain controller. Similarly, you can
specify the format to be the format used for LDAP
requests or to be the IP address of the domain
controller.
adfinddomain -f ldap
ldap:://fire.arcade.org:389
-V, --verify Check whether the specified domain controller is

currently operational.
software.
Examples of using adfinddomain

You can use the adfinddomain command to display the host name,
LDAP URL, or IP address of the domain controller for a specified
domain. For example, to display the full host name for the domain
controller in the arcade.org domain, you would type:
adfinddomain --format name arcade.org
fire.arcade.org:389
Using adsmb
The adsmb command allows you to perform various file operations,
such as get a file, write a file, or display the contents of a directory
using the Centrify DirectControl smb stack. You can run this
command using your log-on credentials or using the credentials for
the local computer account. To use the local computer’s credential,
you must have root-level permission. You can specify the domain
controller to use or use the nearest domain controller for the
joined domain.

Using adsmb
Note You can use this command in conjunction with group policies
to copy files and directories to and from Windows file shares.
The basic syntax for the adsmb program is:

adsmb file_operation -s share [-m] [-t] [-h [hostname]]
[-r remote_file] [-l local_file]
The valid file_operations are get, getnew, put, putnew, dir,

delete, mkdir, and rmdir.


get Get one or more files from a specified share.
getnew Get one or more files if the copy of the file on the
specified share is newer than the local copy of the
file.
put Put one or more files into the specified share.
putnew Put one or more files if the local copy of the file is
newer than the copy of the file on the specified
share.
dir List the contents of a directory.
delete Delete one or more files.
mkdir Create a new directory.
rmdir Remove a directory.
-s share Specify the share name.
-m Use the local computer’s credentials.
-t Convert timestamp information to a
human-readable format.
-h [hostname] Specify the host name of an Active Directory
domain controller. If you don’t specify a host name
with this option, the command uses the nearest
domain controller for the joined domain.

-r remote_file Specify the remote file or directory to work with.
You can use forward slashes in remote file names.
-l local_file Specify the local file or directory to work with.
Examples of using adsmb

You can use the adsmb command to get file or directory
information or perform file or directory operation.
For example, to display details about the contents of the platforms
directory on the lab file share with human-readable timestamps for
when a file or subdirectory was created, last modified, and last
read, you would type a command similar to the following:
adsmb dir -h sierra -s lab -r "platforms/*" -t
To get the file autorun.bat from the system volume (sysvol) of

the nearest domain controller using the computer credentials and
place it in the local /tmp directory, you would type a command
sudo adsmb get -s sysvol -m -r arcade.com/lab/autorun.bat
-l /tmp/autorun.bat
Using adclient
Most Centrify DirectControl operations are managed by the
central daemon process adclient. This daemon is automatically
started when the system is first booted. The daemon generally
remains running as long as the computer is powered up so that it
can handle all of the authentication and authorization interaction
between Active Directory and the Unix shell programs or Web
applications that need this information.
Although you typically start and stop adclient from a startup
script, you can run adclient directly from the command line to
control the operation of the Centrify DirectControl Agent on a
local computer.
The basic syntax for running adclient at the command line is:
adclient [-x] [-c] [-d] [-F]

Using adclient

You can use the following options with adclient:

-x Stop the Centrify DirectControl Agent if it is
currently running.
-c Prevent the Centrify DirectControl Agent from
generating a core dump.
-d Set the Centrify DirectControl Agent to run in
debug mode.
-F Flush the Active Directory cache when the Centrify
DirectControl Agent is restarted.
For example, to flush the cache when the Centrify DirectControl

Agent starts:
adclient -F
Using the startup script

Although adclient normally runs as long as a computer is powered
up, periodically you may want to manually stop or restart adclient
without rebooting the computer. You do this by running a startup
script called centrifydc and specifying whether you want to start,
stop, or restart the daemon. The location of the startup scripts that
run when a computer is started can vary depending on the
platform. For example, on Linux and Solaris the startup script is in
the directory /etc/init.d, but on HP-UX, startup scripts are
located in the /sbin/init.d directory. For convenience, a copy of
the Centrify DirectControl startup script is installed in the
/usr/share/centrifydc/bin directory, and you can use the copy
in that directory when you want to manually start, stop, or restart
the Centrify DirectControl daemon.
For more information about how daemons are started and stopped
in a specific operating environment, including the normal location
for startup scripts, see the documentation for the operating
environment.

Starting the daemon
To manually start the daemon when the startup script is located in
the /usr/share/centrifydc/bin directory, you run this
command:
/usr/share/centrifydc/bin/centrifydc start
Stopping the daemon

To manually stop the daemon when the startup script is located in
the /usr/share/centrifydc/bin directory, you run this
command:
/usr/share/centrifydc/bin/centrifydc stop
Restarting the daemon

To manually stop then restart the daemon when the startup script is
located in the /usr/share/centrifydc/bin directory, you run this
command:
/usr/share/centrifydc/bin/centrifydc restart
Checking the status of the daemon

You can also check whether the daemon is currently running or
stopped. To view the current status of the daemon when the
startup script is located in the /usr/share/centrifydc/bin
directory, you run this command:
/usr/share/centrifydc/bin/centrifydc status
Using runmappers
The runmappers command allows you to manually run the mapper
programs that configure group policies for Unix users or
computers. As discussed in “Understanding group policy for Unix”
on page 189, individual mapper programs located in the
/usr/share/centrifydc/mappers/user/user_name directories
read settings from the Unix “virtual registry” and translate them
into the appropriate settings in application-specific configuration
files. By default, the Centrify DirectControl Agent is normally

Using runmappers
used to start the runmappers program and the runmappers

program runs all of the executable files it finds in the
/usr/share/centrifydc/mappers/user/user_name directories.
However, you can also run this program manually and specify the
type of mapper programs to run and whether you want to map or
unmap settings.
Note Individual mapper programs can be written in any compiled
or interpreted language that is supported on the target system.
The basic syntax for the runmappers program is:

runmappers [map|unmap] [machine|user user_name]

You can use the following options with the runmappers command:

map Run the mapper programs to update
application-specific configuration files to reflect
group policy settings.
unmap Remove the group policy settings from
application-specific configuration files to restore the
files to their previous state.
machine Run only the computer configuration mapper
programs located in the
/usr/share/centrifydc/mappers/machine
directory.
user user_name Run only the user configuration mapper programs
located in the specified user_name directory in the
/usr/share/centrifydc/mappers/user
directory. If you specify the user option, you must
also specify the Unix user name to identify which
user’s group policies should be mapped or
unmapped.
Note For this command, you cannot use the user’s
Active Directory name. You must use the user’s Unix
profile log on name.

Examples of using runmappers
You can use the runmappers command to execute only the Unix
computer configuration policies or only a specific Unix user’s
group policies. For example, to run all of the executable files
placed in the /usr/share/centrifydc/mappers/machine
directory, you could use a command similar to the following:
runmappers machine map
To remove the mapping of computer-based group policies and

restore the affected Unix configuration files to their previous state,
you could use a command similar to the following:
runmappers machine unmap
To run all of the executable files placed in the

/usr/share/centrifydc/mappers/user directory for the Unix
user account jgarcia, you could use a command similar to the
following:
runmappers user map jgarcia

Centrify DirectControl includes a set of OpenLDAP commands
that have been modified to better support the Active Directory
environment. The Centrify DirectControl distribution of
OpenLDAP supports all of the standard options and syntax for
performing LDAP operations, but the ldap commands in the
Centrify DirectControl distribution of OpenLDAP also support the
following options that are not supported in a standard OpenLDAP
distribution:

-m Use the local machine credentials from the
/etc/krb5.keytab file. This option requires
root user access.
-r Disable line wrapping when printing out LDIF

entries.

The Centrify DirectControl distribution of OpenLDAP also

provides extended URL support for Active Directory. With
Centrify DirectControl LDAP commands, you can use the
following URLs to connect to Active Directory computers:
Use this To do this

ldap://domain_name Connect to the appropriate domain controller for
the specified domain within the Active Directory
site.
ldap:// Connect to the joined domain.
gc://[domain_name] Connect to the Global Catalog domain controller
for the joined domain. You can use the optional
domain_name parameter to specify a domain in a
different forest.
The Centrify DirectControl distribution of OpenLDAP includes

the following commands:
ldapsearch
ldapadd
ldapmodify
ldapmodrdn
ldapcompare
ldapdelete
Note The ldappasswd and ldapwhoami commands do not work
with Active Directory. For more information about using the
OpenLDAP commands or the standard options available, see the
man page for each command.

Appendix B
Customizing Centrify DirectControl

configuration options
This chapter describes the Centrify DirectControl configuration
file, centrifydc.conf. The configuration file controls may aspects
of Centrify DirectControl operation on its local Unix host. This
chapter describes how the configuration file is used, what it
controls, the parameters that can be specified, and the operations
you can customize through the configuration file.
Understanding how the configuration file is used
Understanding the syntax in the configuration file
Customizing daemon parameters
Customizing Kerberos parameters
Customizing PAM parameters
Customizing NSS parameters
Customizing NIS parameters
Customizing group policy parameters
Understanding how the configuration file is used

The Centrify DirectControl configuration file,
/etc/centrifydc/centrifydc.conf, is a local file on each
Centrify DirectControl-managed Unix system. This file contains a
set of configuration parameters that specify different aspects of
Centrify DirectControl operation for the local computer.
All of the Centrify DirectControl components rely on settings in
the configuration file to determine appropriate operation in
different situations. Many of these settings can be controlled
323
through Centrify DirectControl group policies for users and

computers. For details about setting specific group policies, see the
Centrify DirectControl Administrator Console Help.
Note In most cases, there is no need to modify the settings in this
file unless you want to customize specific behavior of an individual
computer in your environment. If you do make changes to any of
the configuration parameters, in most cases, you need to restart the
Centrify DirectControl Agent (adclient) for the changes to take
effect. Similarly, if you make changes to the configuration
parameters used by the Centrify DirectControl Network
Information Service (adnisd), you may need to restart that service.

The Centrify DirectControl configuration file contains a set of
configuration parameter entries, each a name/value pair that
identifies a Centrify DirectControl configuration parameter and
assigns a value to that parameter. If a configuration parameter is not
present in the configuration file, Centrify DirectControl assume a
default value for that parameter.
A name/value pair in the configuration file takes the following
form:
parameter_name: value
where the parameter_name is the name of a Centrify DirectControl
configuration parameter name that describes the component the
setting applies to or the purpose of the parameter and value is the
value assigned to that parameter.
Understanding parameter names

In some cases, the configuration parameter name itself must be
customized to enable a setting. For example, the configuration
parameter pam.mapuser.localuser must include the specific local
user name the map applies to, so that pam.mapuser.joan7 specifies

mapping for the local user joan7 while pam.mapuser.arthur
specifies mapping for the local user arthur.
Understanding parameter values

The value can be a string, a numeric value, or a Boolean value
appropriate for the configuration parameter. User names and
groups found in Active Directory are strings specified using their
Active Directory form user[@domain]. If the domain is not
specified, it’s assumed to be the host computer’s domain. A string
value may also use environment variables in some cases.
In general, you can specify user names in the configuration file with
any of the following valid formats:
Standard Windows format: domain\user_name
Universal Principal Name (UPN): user_name@domain
Alternate UPN: alt_user_name@alt_domain
Unix user name: user
However, you must include the domain name in the format if the
user account is not in the local computer’s current Active
Directory domain.
Centrify DirectControl configuration values recognize the special
characters used in Unix scripts. These include:
The dollar sign ($) signifies an environment variable that can be
resolved to an appropriate value if recognized by the Centrify
DirectControl Agent. Valid environment variable names can
consist of alphanumeric characters and underscores.
A backslash (\) signifies that the next character is a literal, and is
used, among other things, to specify a trailing space (\ ) or a
single backslash (\\).
Boolean values are case-insensitive. The permissible values are
true, yes, false, and no.
Appendix B • Customizing Centrify DirectControl configuration options 325

If a parameter can take multiple values, those values are separated

from each other by a comma or a space. Spaces preceding or
trailing each value are ignored.
Using environment variables

The values in name/value pairs can include standard shell
environment variables. The variables are resolved to their current
value when a process such as the Centrify DirectControl daemon
reads the configuration file. For example, you can use the
environment variable $HOSTNAME to include the local computer’s
host name in any parameter value setting:
example_parameter: test_$HOSTNAME
If the name of the current managed system is host1, then the

configuration parameter example_parameter to the value
test_host1.
Centrify DirectControl defines several additional environment
variables for use in the configuration file:
$ZONE is the name of the host computer’s Centrify
DirectControl zone.
$JOINNAME is the name of the host computer’s account name in
Active Directory.
$DOMAIN is the name of the Active Directory domain to which
the host computer is joined.
$SITEis the name of the Active Directory site for the host
computer.

The following configuration parameters affect the operation of the
Centrify DirectControl daemon on the host computer:
adclient.autoedit
adclient.binding.refresh.interval

adclient.cache.cleanup.interval
adclient.cache.encrypt
adclient.cache.encryption.type
adclient.cache.expires
adclient.cache.expires.computer
adclient.cache.expires.extension
adclient.cache.expires.gc
adclient.cache.expires.group
adclient.cache.expires.search
adclient.cache.expires.user
adclient.cache.negative.lifetime
adclient.cache.object.lifetime
adclient.client.idle.timeout
adclient.clients.socket
adclient.clients.threads
adclient.clients.threads.poll
adclient.fetch.object.count
adclient.hash.allow
adclient.hash.deny
adclient.hash.expires
adclient.ldap.packet.encrypt
adclient.ldap.socket.timeout
adclient.ldap.timeout
adclient.paged.search.max
adclient.sntp.enabled
adclient.sntp.poll
log

lrpc.connect.timeout
lrpc.session.timeout
lrpc.timeout
adclient.autoedit
This configuration parameter specifies whether or not the Centrify
DirectControl daemon is allowed to automatically edit the NSS and
PAM configuration files on the local computer.
The parameter value is set to true to allow the files to be edited, or
false to prevent the files from being edited. The following
example allows the NSS and PAM configuration files to be edited:
adclient.autoedit: true
In most cases, this parameter should be set to true to allow

Centrify DirectControl to maintain the configuration files
automatically. If you set this parameter to false, you need to
manually edit the configuration files or you may disable some or all
Centrify DirectControl operation. For example, if you set this
parameter to false, you should manually edit the nsswitch.conf
and /etc/pam.d/system-auth or /etc/pam.d files to include
Centrify DirectControl information or authentication through
Active Directory will fail and you may disable login access entirely.
If you want to manually edit the configuration files, you should first
make a backup copy of the existing files. After you make a backup
copy of the files, you can use the following examples to manually
update the files with the configuration information for Centrify
DirectControl.
Note If the adclient.autoedit parameter is not defined in the
configuration file, its default value is false.
Editing the NSS configuration

To manually edit the NSS configuration, modify the
/etc/nsswitch.conf file to include centrifydc as the first entry

for the password and group lines as appropriate for your
environment. For example:
passwd: centrifydc files
shadow: centrifydc files
group: centrifydc files
By placing centrifydc at the beginning of each line, you ensure

that Active Directory authentication takes precedence over other
forms of authentication.
Editing the PAM configuration

To manually edit the PAM configuration, you need to add the
Centrify DirectControl information to the top of the appropriate
PAM configuration file.
For example, on Linux you need to add the following lines to the
top of the /etc/pam.d/system-auth file:
auth sufficient pam_centrifydc.so debug
auth requisite pam_centrifydc.so deny debug
account sufficient pam_centrifydc.so debug
session sufficient pam_centrifydc.so homedir
password sufficient pam_centrifydc.so try_first_pass
password requisite pam_centrifydc.so deny
On Solaris, you need to add the following lines to the top of the
/etc/pam.conf file:
rlogin auth sufficient pam_centrifydc.so debug
rlogin auth requisite pam_centrifydc.so deny debug
login auth sufficient pam_centrifydc.so debug
login auth requisite pam_centrifydc.so deny debug
passwd auth sufficient pam_centrifydc.so try_first_pass debug
passwd auth requisite pam_centrifydc.so deny debug
other auth sufficient pam_centrifydc.so debug
other auth requisite pam_centrifydc.so deny debug
cron account sufficient pam_centrifydc.so debug
other account sufficient pam_centrifydc.so debug
other password sufficient pam_centrifydc.so debug
other session sufficient pam_centrifydc.so debug
Note In most operating environments, when new users log on

successfully, Centrify DirectControl will automatically create the
user’s home directory. On Solaris, however, the home directory is
typically automounted over NFS, so the option to automatically
create a new home directory for new users is off by default. If you
do not use NFS to automount home directories, you can turn on this
feature by adding the homedir flag to the existing session line in the
/etc/pam.conf file. For example, after editing the line, it should
look like this:

other session sufficient pam_centrifydc.so debug homedir
By adding the appropriate lines to the beginning of PAM

configuration file, you ensure that Active Directory authentication
takes precedence over other forms of authentication.
adclient.binding.refresh.interval
This configuration parameter specifies how often to refresh the
LDAP bindings to the preferred Active Directory site if a computer
is connected to a domain controller in another site.
If the Centrify DirectControl daemon is unable to communicate
with a local domain controller, it automatically connects to an
available domain controller in another site until a domain
controller in its preferred site becomes available. To determine
when a domain controller in the preferred site is available, the
daemon periodically attempts to re-connect to domain controllers
in its preferred site whenever it is connected to a backup domain
controller in another site. This parameter controls how frequently
the daemon performs the attempt to re-connect to the preferred
site.
The parameter value specifies the number of seconds between
refresh attempts. It must be an integer greater than zero. The
following example sets the interval time to 60 minutes:
adclient.binding.refresh.interval: 60
If this parameter is not defined in the configuration file, its default

value is 30 minutes.
In changing this parameter, you should consider your network and
site topology and the reliability of your servers. If you have highly
reliable network links and very good connections between sites,
you may find it safe to increase this value, but if communication
between sites is slow you should keep this interval short to ensure
the daemon communicates with domain controllers in its preferred
site as soon as possible.

adclient.cache.cleanup.interval
This configuration parameter specifies how often the Centrify
DirectControl daemon should clean up the local cache. At each
cleanup interval, the Centrify DirectControl daemon checks the
cache for objects to be removed or expired, and at every 10th
interval, the Centrify DirectControl daemon rebuilds local
indexes. The default cleanup interval is 60 minutes.
For example:
adclient.cache.cleanup.interval: 60
adclient.cache.encrypt
This configuration parameter specifies whether you want to
encrypt the local cache of Active Directory data. If you set this
parameter to true, all of the Active Directory data stored in the
cache is encrypted and the cache is flushed each time the Centrify
DirectControl daemon starts up. If you set this parameter to false,
the cache is not encrypted and is not flushed when the Centrify
DirectControl daemon starts up.
For example, to encrypt all data in the cache:
adclient.cache.encrypt: true

value is false.
adclient.cache.encryption.type
This configuration parameter specifies the type of encryption to use
when encrypting the local cache. The encryption type you specify
must be a type supported in the Kerberos environment. For
example, Windows Server 2003 Kerberos supports the following
cryptographic algorithms: RC4-HMAC, DES-CBC-CRC and
DES-CBC-MD5.
For example:
adclient.cache.encryption.type: des-cbc-md5

This configuration parameter is only used if

adclient.cache.encrypt is set to true. If the
adclient.cache.encrypt parameter is set to false, this
configuration parameter is ignored.
adclient.cache.expires
This configuration parameter specifies the number of seconds
before an object in the Centrify DirectControl domain controller
cache expires.
Every object retrieved from Active Directory is stamped with the
system time when it enters the domain controller cache. The
object can then be retrieved from the local cache until it expires.
Once an object expires, if it is needed again, the Centrify
DirectControl daemon will contact Active Directory to determine
whether to retrieve an updated object (because the object has
changed) or renew the expired object (because no changes have
been made). To make this determination, the Centrify
DirectControl daemon checks the highestUSN for the expired
object. If the value has changed, the daemon retrieves the updated
object. If the highestUSN has not changed, the daemon resets the
object’s timestamp to the new system time and retrieves the object
from the cache.
Note This configuration parameter applies to generic objects in the
domain controller cache and becomes the default expiration period
for all object types. You can set separate expiration periods for
specific objects types using the object-specific configuration
parameters. For example, you can set different expiration times for
computer objects and user objects using the
adclient.cache.expires.computer, and
adclient.cache.expires.user configuration parameters. This
generic object expiration setting applies to any object for which you
do not set an object-specific expiration period.
In most cases, you set this configuration parameter using the

Computer Configuration > Administrative Templates >

CentrifyDC > Timeout Settings > Object Expiration Time
group policy by selecting Enabled and specifying the maximum
number of seconds for an object to be kept in the local cache. You
can, however, set it manually in the configuration file if you aren’t
using group policy or want to temporarily override group policy.
If you are manually setting this parameter, the parameter value
must be a positive integer. The following example sets the cache
expiration time to 1800 seconds (30 minutes):
adclient.cache.expires: 1800

adclient.cache.expires.computer
before a computer object in the Centrify DirectControl domain
controller cache expires. If this parameter is not specified, the
generic object cache expiration value is used.
Every computer object retrieved from Active Directory is stamped
with the system time when it enters the domain controller cache.
The object can then be retrieved from the local cache until it
expires.
from the cache.
CentrifyDC > Timeout Settings > Computer Object

Expiration Time group policy by selecting Enabled and

specifying the maximum number of seconds for a computer object
to be kept in the local cache. You can, however, set it manually in
the configuration file if you aren’t using group policy or want to
temporarily override group policy.
expiration time for computer objects to 1800 seconds (30
minutes):
adclient.cache.expires.computer: 1800

adclient.cache.expires.extension
before an extension object in the Centrify DirectControl domain
Every object retrieved from Active Directory is stamped with the
system time when it enters the domain controller cache. The
from the cache.
CentrifyDC > Timeout Settings > Extension Object

expiration time for extension objects to 1800 seconds (30
minutes):
adclient.cache.expires.extension: 1800

adclient.cache.expires.gc
before information in the Centrify DirectControl Global Catalog
cache expires. The Global Catalog cache contains the distinguished
name (DN) for each object that has been looked up in Active
Directory. The primary purpose of the Global Catalog cache is to
store the results from paged object searches. Object attributes are
stored in the Centrify DirectControl domain controller cache.
CentrifyDC > Timeout Settings > Global Catalog Object
expiration time for Global Catalog objects to 1800 seconds (30
minutes):
adclient.cache.expires.gc: 1800


adclient.cache.expires.group
before a group object in the Centrify DirectControl domain
Every group object retrieved from Active Directory is stamped
with the system time when it enters the domain controller cache.
The object can then be retrieved from the local cache until it
expires.
from the cache.
CentrifyDC > Timeout Settings > Group Object
specifying the maximum number of seconds for a group object to
be kept in the local cache. You can, however, set it manually in the
configuration file if you aren’t using group policy or want to
expiration time for group objects to 1800 seconds (30 minutes):
adclient.cache.expires.group: 1800

adclient.cache.expires.search
before the results of an Active Directory search expire.
Search expiration is handled separately from object expiration
because a search result may include objects that have been deleted
or be missing objects that have been added that meet the search
criteria.
CentrifyDC > Timeout Settings > Search Expiration Time
number of seconds for a search result to be kept in the local cache.
You can, however, set it manually in the configuration file if you
aren’t using group policy or want to temporarily override group
policy.
expiration time for search to 1800 seconds (30 minutes):
adclient.cache.expires.search: 1800

adclient.cache.expires.user
before a user object in the Centrify DirectControl domain
Every user object retrieved from Active Directory is stamped with
the system time when it enters the domain controller cache. The


from the cache.
CentrifyDC > Timeout Settings > User Object Expiration
Time group policy by selecting Enabled and specifying the
maximum number of seconds for a user object to be kept in the
local cache. You can, however, set it manually in the configuration
file if you aren’t using group policy or want to temporarily override
group policy.
expiration time for user objects to 1800 seconds (30 minutes):
adclient.cache.expires.user: 1800

adclient.cache.negative.lifetime
This configuration parameter specifies how long, in minutes, a
negative object should remain in the cache. A negative object is
returned when an object is not found in a search result. This
configuration parameter determines how long that negative result
should remain in the cache, regardless of the object type or object
expiration time. By storing this negative result in the cache, the
Centrify DirectControl daemon does not need to connect to Active
Directory to look for an object that was previously not found.

The default period of time for keeping negative results is 60
minutes. Setting the parameter value to 0 keeps negative objects in
the cache indefinitely.
The following example sets the lifetime for negative objects to 40
minutes:
adclient.cache.negative.lifetime: 40
adclient.cache.object.lifetime
This configuration parameter specifies how long, in hours, an
Active Directory object should remain in the local cache. Setting
the parameter value to 0 keeps objects in the cache indefinitely.
When you set this parameter to 0, objects remain in the cache until
they are deleted from Active Directory or the cache is manually
flushed with the adflush command. If you don’t want objects to
remain in the cache indefinitely, you can use this parameter to set
the maximum amount of time an object should be available in the
cache.
For example, if you want to set the maximum time for an object to
be held in the cache to 12 hours, you can set this configuration
parameters as follows:
adclient.cache.object.lifetime: 12
With this setting, object values can be retrieved from the local
domain controller cache for 12 hours. At the end of the 12 hour
period, however, the object is removed from the local cache and
must be retrieved from Active Directory if it is needed again.
value is 0.
adclient.client.idle.timeout
before the Centrify DirectControl daemon will drop a socket
connection to an inactive client.

CentrifyDC > Timeout Settings > Client Idle Timeout

number of seconds to keep open a connection when a client is idle.
policy.
must be an integer greater than zero. The following example sets
the inactive client timeout to 5 minutes:
adclient.client.idle.timeout: 300
If you set this parameter to zero, the Centrify DirectControl

daemon will never drop the socket connection. Therefore, you
should always specify a value greater than zero.
value is 300 seconds.
adclient.clients.socket
This configuration parameter specifies the named socket through
which clients communicate with the Centrify DirectControl
daemon.
The parameter value must be the name of the socket. For example:
adclient.clients.socket: /var/centrifydc/daemon

value is daemon.
adclient.clients.threads
This configuration parameter specifies the number of threads the
Centrify DirectControl daemon pre-allocates for processing client
requests.
The parameter value must be an integer zero or greater. If you set
this parameter to zero, the Centrify DirectControl daemon
processes requests sequentially. For example:
adclient.clients.threads: 4

value is 4 threads.
adclient.clients.threads.poll
This configuration parameter specifies the number of milliseconds
the Centrify DirectControl daemon waits between checks to see if
a client's request has been completed.
Request completion polling is necessary to eliminate race
conditions in operating environments such as Linux that don't have
pselect implemented in the kernel. This polling mechanism
should be disabled if the operating system has an atomic pselect.
The parameter value must be an integer zero or greater. A value of
zero turns off polling. For example:
adclient.clients.threads.poll: 100

value is 100 milliseconds.
This configuration parameter specifies the maximum number of
seconds to wait for a DNS response. If there is no response from
DNS within this period of time, the DNS server is considered
unavailable. If you have slow or unstable network connections
between the local computer and its DNS servers, you may need to
increase the value for this parameter to allow more time to receive
a response.
The parameter value should be a positive integer. For example:
adclient.dns.response.maxtime: 30
adclient.fetch.object.count
This configuration parameter specifies the number of objects to
obtain in a single LDAP request. You can use this parameter to
optimize the number of objects to suit your environment.
The parameter value must be a positive integer. For example:
adclient.fetch.object.count: 5

With this parameter, there is a trade-off here between speed and

memory usage as well as bandwidth and latency. As you increase
the number of objects included in an LDAP request, you may
improve the overall performance by decreasing the number of
connections to Active Directory and reducing the overall demand
on the server, but you increase the RAM used by the Centrify
DirectControl daemon. If you decrease the number of objects
included in an LDAP request, you may reduce overall performance
because of the additional network traffic, but decrease the memory
used by the Centrify DirectControl daemon.
On faster networks, you can safely retrieve a small number of
objects. On slower networks or when retrieving information for
large groups (for example, groups with more than 1000 users), you
may want to increase the value for this parameter.
adclient.hash.allow
This configuration parameter specifies the list of users you want to
allow to have their password hash stored. By default, Centrify
DirectControl stores a Unix-style MD5 hash of each user’s
password in the cache when the user is authenticated during login.
Storing the password hash allows previously authenticated users to
log on when the computer is disconnected from the network or
Active Directory is unavailable.
Although the default behavior is to store the password hash for all
users, you can use this parameter to explicitly list the users whose
hashed passwords are stored in the cache. If you use this parameter,
only the users you specify can log on when the computer is
disconnected from the network or Active Directory is unavailable.
The parameter value can be one or more user names. If more than
one name, the names can be separated by commas or spaces. For
example:
adclient.hash.allow: jdoe bsmith
If no user names are specified or the parameter is not defined in the

configuration file, the password hash is stored for all users.

adclient.hash.deny
This configuration parameter specifies the list of users you want to
prevent from having their password hash stored. By default,
Centrify DirectControl stores a Unix-style MD5 hash of each user’s
password in the cache when the user is authenticated during login.
Storing the password hash allows previously authenticated users to
log on when the computer is disconnected from the network or
Active Directory is unavailable.
Although the default behavior is to store the password hash for all
users, you can use this parameter to explicitly list the users whose
hashed passwords must not be stored in the cache. If you use this
parameter, the users you specify cannot log on when the computer
is disconnected from the network or Active Directory is
unavailable. All other users are permitted to have their password
hash stored and allowed to log on when the computer is
disconnected from the network or Active Directory is unavailable.
The parameter value can be one or more user names. If more than
one name, the names can be separated by commas or spaces. For
example:
adclient.hash.deny: jdoe bsmith
If no user names are specified or the parameter is not defined in the

configuration file, the password hash is stored for all users.
adclient.hash.expires
This configuration parameter specifies the number of days the
password hash for any user can be stored in the cache before it
expires.
The parameter value must be a positive integer. A value of zero (0)
specifies that the password hash should never expire. For example,
to set this parameter so that the password hash expires after 7 days:
adclient.hash.expires: 7

value is 0.

adclient.ldap.packet.encrypt
This configuration parameter specifies the LDAP encryption policy
you use. This configuration parameter is equivalent to the
encryption policy setting on the Windows Server 2003. For
example, if your organization has a security policy that does not
allow unencrypted LDAP traffic, you can use this parameter to
specify that all connections to Active Directory are encrypted. If
your organization isn’t concerned with the encryption of LDAP
data and you want better performance, you can force all
connections to be unencrypted.
The parameter value must be one of the following valid options:
Allowed to allow both encrypted and unencrypted LDAP
traffic.
Disabled to prevent encrypted LDAP traffic.
Required to require all LDAP traffic to be encrypted.
For example:
adclient.ldap.packet.encrypt: Allowed

value is Allowed.
adclient.ldap.socket.timeout
This configuration parameter specifies the time, in seconds, the
Centrify DirectControl daemon will wait for a socket connection
timeout during LDAP binding.
CentrifyDC > Timeout Settings > LDAP Connect Timeout
number of seconds to wait for a connection. You can, however, set
it manually in the configuration file if you aren’t using group policy
or want to temporarily override group policy.
must be a positive integer greater than zero. For example:

adclient.ldap.socket.timeout: 30

adclient.ldap.timeout
This configuration parameter specifies the time, in seconds, the
Centrify DirectControl daemon will wait for a response from
Active Directory before it gives up on the LDAP connection.
CentrifyDC > Timeout Settings > LDAP Response
Timeout group policy by selecting Enabled and specifying the
maximum number of seconds to wait for a response from the
LDAP server. You can, however, set it manually in the
must be a positive integer. For example:
adclient.ldap.timeout: 60

adclient.paged.search.max
items included in each page of a paged LDAP search.
adclient.paged.search.max: 100

value is 100 items.
Before changing this parameter setting, you should consider its
impact on your environment. As you decrease the number of items
included in each LDAP page, you increase the number of
connections made to Active Directory and the added demand that

increased traffic places on the server, but you decrease the RAM
used by the Centrify DirectControl daemon. If you increase the
number of items included in each LDAP page, you decrease the
number of connections to Active Directory and reduce the overall
demand on the server, but you increase the RAM used by the
Centrify DirectControl daemon.
adclient.sntp.enabled
This configuration parameter specifies whether you want to use the
Windows Time Service to keep the local system clock in sync with
the domain the computer has joined.
System > Windows Time Service > Time Providers >
Enable Windows NTP Client group policy by selecting
Enabled. You can, however, set it manually in the configuration
file if you aren’t using group policy or want to temporarily override
group policy.
must be true or false. For example:
adclient.sntp.enabled: true
adclient.sntp.poll
This configuration parameter specifies whether the interval, in
seconds, between SNTP clock updates when you are using the
Windows Time Service to keep the local system clock in sync with
the domain the computer has joined.
For example, to set the interval to every 300 seconds:
adclient.sntp.poll: 300
adjoin.adclient.wait.seconds
This configuration parameter specifies the number of seconds the
adjoin command should wait before exiting to ensure the Centrify
DirectControl Agent is available to complete the join operation.

For example, to configure the adjoin command to wait 10 seconds:
adjoin.adclient.wait.seconds: 10
dns.dc.domain_name
This configuration parameter can be used to specify the domain
controller host names if your DNS is not configured to use Active
Directory. In most cases, you should not use this configuration
parameter in a production environment because Active Directory
automatically updates DNS with failover and replica servers
optimized for the Active Directory site configuration. This
configuration parameter is used primarily for configuring an
evaluation environment when the DNS server is on a Unix
computer and can’t provide the _ldap service records.
To set this parameter, the Active Directory domain name must be
specified as the last portion of the configuration parameter name,
and the parameter value is the host name of the domain controller.
For example, if the Active Directory domain is acme.com and the
domain controller for that domain is coyote.acme.com:
dns.dc.acme.com: coyote.acme.com

dns.dc.lab.test: dc1.lab.test dc2.lab.test
dns.forcetcp
This configuration parameter can be used to force all DNS queries
to use TCP rather than UDP. The parameter value can be true or
false. For example:
dns.forcetcp: false

dns.gc.domain_name
This configuration parameter can be used to specify the domain
controller used as the global catalog if your DNS is not configured
to use Active Directory. In most cases, you do not use this
configuration parameter in a production environment. This
configuration parameter is used primarily for configuring an
evaluation environment when the DNS server is on a Unix
computer and can’t provide the _gc service records.
To set this parameter, the Active Directory domain name must be
specified as the last portion of the configuration parameter name,
and the parameter value is the host name of the domain controller.
For example, if the Active Directory domain is arcade.com and the
domain controller for that domain is fire.arcade.com:
dns.gc.arcade.com: fire.arcade.com

dns.dc.lab.test: dc1.lab.test dc2.lab.test
log
This configuration parameter defines the level of detail written to
the Centrify DirectControl log file. The log level works as a filter
to define the type of information you are interested in and ensure
that only the messages that meet the criteria are written to the log.
For example, if you want to see warning and error messages but
not informational messages, you can change the log level from INFO
to WARN.

The parameter value can be FATAL, ERROR, WARN, INFO, DEBUG, or
TRACE. For example:
log: level
For more information about logging and setting the log level, see
“Configuring logging for Centrify DirectControl” on page 270.
lrpc.connect.timeout
Centrify DirectControl NSS or PAM service should wait for a
response from the Centrify DirectControl daemon during an initial
connection attempt. If the initial connection to adclient takes
longer than specified by this parameter, the service will time out
and terminate the attempt to connect. In most cases, there’s no
need to modify this parameter.
lrpc.connect.timeout: 5

value is 5 seconds.
lrpc.session.timeout
seconds to keep the adclient connection open to respond to
context-dependent requests, such as pwgetent or lsgroup
requests. Lowering this value reduces the chance of a
multi-threaded program being affected by an adclient restart, but
may cause slow context-dependent commands to fail to return
results because the session times out before the command
completes its operation. Increasing the value of this parameter
reduces the overhead of re-establishing a connection for multiple
requests.
For example:
ldap.session.timeout: 30

lrpc.timeout
local client should wait for a response from the Centrify
DirectControl daemon before ending a requested operation.
CentrifyDC > Timeout Settings > LRPC Response
Timeout group policy by selecting Enabled and specifying the
maximum number of seconds to wait for a response. You can,
however, set it manually in the configuration file if you aren’t using
group policy or want to temporarily override group policy.
must be an integer greater than zero. The following example sets
the inactive client timeout to 5 minutes:
lrpc.timeout: 300

value is 5 minutes.
Although in some environments increasing or decreasing the value
of this parameter may be beneficial to optimize Centrify
DirectControl and Active Directory for your network topology,
you should take care in changing this setting. For example, in most
cases, you should not decrease this value because of the potential
problems it may cause when transferring data. If you set this value
too low and have a slow connection or a large amount of data to be
transferred, the local client may end the operation prematurely and
prevent the data transfer from completing successfully.

The following configuration parameters affect the operation of
Centrify DirectControl Kerberos-related activity on the host
computer.
adclient.krb5.autoedit

adclient.krb5.conf.file
adclient.krb5.keytab
adclient.krb5.keytab.entries
adclient.krb5.password.change.interval
adclient.krb5.passwd_check_s_address
adclient.krb5.permitted.encryption.types
adclient.krb5.service.principals
adclient.krb5.tkt.encryption.types
adjoin.krb5.conf.file
krb5.cache.clean
krb5.cache.clean.interval
krb5.cache.renew.interval
krb5.config.update
krb5.forwardable.user.tickets
krb5.permit.dns.spn.lookups
adclient.krb5.autoedit
This configuration parameter specifies whether or not the Centrify
DirectControl daemon should automatically update the Kerberos
configuration file with new information, such as domains and IP
addresses, as the daemon discovers this information.
CentrifyDC > Kerberos Settings > Manage Kerberos
Configuration group policy by selecting Enabled and selecting
the Manage Kerberos Configuration option. You can,
must be true or false. In most cases, this parameter should be set

to true to allow Centrify DirectControl to maintain the

configuration files automatically. For example:
adclient.krb5.autoedit: true

value is true.
adclient.krb5.conf.file
This configuration parameter specifies the location and file name of
the Kerberos configuration file on the local computer.
The parameter value must be an absolute path to a file. For
example:
adclient.krb5.conf.file: /etc/krb5/krb5.conf

value is /etc/krb5.conf.
adclient.krb5.keytab
This configuration parameter specifies the location and file name of
the Kerberos key table file.
The parameter value must be a path name. For example:
adclient.krb5.keytab: /etc/krb5/krb5.keytab

value is /etc/krb5.keytab.
adclient.krb5.keytab.entries
This configuration parameter specifies the number of entries that
the Centrify DirectControl daemon maintains in the Kerberos key
table for a service principal.
This value determines the number of key versions that are kept per
service principal. Its value must be a positive integer. For example:
adclient.krb5.keytab.entries: 3

value is 3 entries.

adclient.krb5.password.change.interval
This configuration parameter specifies the number of days in the
interval between the last Active Directory password change for the
computer account and the next password change for the account.
At the interval, Active Directory prompts for a new account
password. The Centrify DirectControl daemon then automatically
generates a new password for the computer account and issues the
new password to Active Directory.
CentrifyDC > Kerberos Settings > Password Change
Interval group policy by selecting Enabled and setting the
interval for updating the randomly-generated password for the
computer account. You can, however, set it manually in the
must be an integer equal to or greater than zero. If the value is zero,
then the change interval is turned off and the account is not
prompted for password change. For example:
adclient.krb5.password.change.interval: 7

value is 7 days.
adclient.krb5.passwd_check_s_address
This configuration parameter specifies whether Kerberos should
ignore the source address on private messages. This setting is useful
when Active Directory uses NAT.
The parameter value can be true or false. The default value for
this parameter is true. For example:
adclient.krb5.passwd_check_s_address: false

adclient.krb5.permitted.encryption.types
This configuration parameter specifies the types of encryption that
can be used in Kerberos client credentials.
The parameter value must be one or more encryption types,
separated by a space. For example:
adclient.krb5.permitted.encryption.types: rc4-hmac
des-cbc-md5
If this parameter is not defined in the configuration file, the default

encryption types permitted are rc4-hmac, des-cbc-md5,
des-cbc-crc, and rc4-hmac-exp.
adclient.krb5.service.principals
This configuration parameter specifies additional service principals
for entries in the Kerberos key table. The key table is populated by
default with the service principals host and http.
CentrifyDC > Kerberos Settings > Service Principals
group policy by selecting Enabled and listing the service
principals to add. You can, however, set it manually in the
This parameter’s value must be one or more principal service
names, separated by a space or by a comma. For example:
adclient.krb5.service.principals: ldap nfs
If this parameter is not defined in the configuration file, no

additional principal names are added to the Kerberos key table.
adclient.krb5.tkt.encryption.types
This configuration parameter specifies the types of encryption that
can be presented to the server in the TGT when the computer is
requesting service tickets.

CentrifyDC > Kerberos Settings > Encryption Types group
policy by selecting Enabled and listing the encryption types to
add. You can, however, set it manually in the configuration file if
you aren’t using group policy or want to temporarily override
group policy.
The parameter value must be one or more encryption types,
separated by a space. For example:
adclient.krb5.tkt.encryption.types: rc4-hmac des-cbc-md5

supported encryption types are rc4-hmac, des-cbc-md5, and
des-cbc-crc.
adjoin.krb5.conf.file
This configuration parameter specifies the path to a customized
Kerberos configuration file you want to use to join a domain.
adjoin.krb5.conf.file: /etc/centrifydc/krb5_join.conf
krb5.cache.clean
This configuration parameter specifies whether Kerberos
credentials in the cache should be deleted when a user logs out. By
default, credentials stored in the Kerberos cache that belong to
users who are not logged in are periodically deleted. This
configuration parameter allows you to control this operation
specifically for Centrify DirectControl users or for all users.
The parameter value must be one of the following valid settings:
off to turn off the deletion of the credentials cache for all users.
cdc to delete only credential caches that belong to Active

Directory users.
all to delete credentials caches that belong to anyone, including
the credentials for users that cannot be resolved.

For example, to remove the credentials cache for all users when
they log out:
krb5.cache.clean: all
The default value for this parameter is cdc.
krb5.cache.clean.interval
This configuration parameter specifies how frequently in minutes
to check the Kerberos cache for credentials that belong to users
who are not logged on that need to be deleted.
The parameter value should be a positive integer. Setting this
parameter to zero disables periodic clean-up of the cache. For
example, to set the clean-up interval to 5 minutes:
krb5.cache.clean.interval: 5
The default value for this parameter deletes the credential cache for
users who have logged off every one minute.
krb5.cache.renew.interval
This configuration parameter specifies, in hours, how often to
renew the Kerberos credentials stored in the cache for users who
have logged on successfully. Because Kerberos tickets expire after a
set period of time, you can use this configuration parameter to
periodically renew the existing Kerberos ticket to keep existing
credentials valid.
CentrifyDC > Kerberos Settings > Credential Renewal
interval for renewing Kerberos credentials. You can, however, set it
manually in the configuration file if you aren’t using group policy or
want to temporarily override group policy.
must be a positive integer. A value of zero disables renewal. For
example, to set the renewal interval to 8 hours:

krb5.cache.renew.interval = 8

value is 8 hours.
krb5.config.update
This configuration parameter specifies, in hours, how frequently
the Centrify DirectControl daemon updates the Kerberos
configuration file.
CentrifyDC > Kerberos Settings > Configuration Update
interval for automatically updating the Kerberos configuration file.
policy.
If adclient.krb5.autoedit is set to false, this parameter has no
effect. If adclient.krb5.autoedit is set to true, this parameter
value must be a positive integer. For example, to set the update
interval to 8 hours:
krb5.config.update: 8

value is 8 hours.
krb5.forwardable.user.tickets
This configuration parameter specifies whether you want Centrify
DirectControl to create forwardable Kerberos user tickets.
Creating a forwardable ticket allows a user’s logon ticket to be sent
to another computer and used to access to additional systems and
resources. For example, if a user logs on and is authenticated on
one computer, then uses a Kerberized telnet session to connect to
a second computer, a forwarded ticket allows the user to access to
additional Kerberized resources from that second computer
without separate authentication.

In most environments, forwarding user tickets is a safe practice.

However, if you do not want tickets to be forwarded, you can use
this parameter to prevent Centrify DirectControl from creating
forwardable tickets.
The parameter value should be 1 is you want to allow ticket
forwarding or 0 is you want to prevent ticket forwarding. For
example, if you want Centrify DirectControl to create forwardable
user tickets:
krb5.forwardable.user.tickets: 1

value is 1 (yes).
krb5.permit.dns.spn.lookups
This configuration parameter specifies whether you want to permit
Centrify DirectControl to look up service principal names (SPN)
using DNS. In most cases, you should set this parameter to false
to ensure the security of the system. You should only set this
configuration parameter to true if you can safely rely on DNS for
security and want to use programs that use the Centrify
DirectControl Kerberos libraries to access a computer using an IP
address or localhost.
For example:
krb5.permit.dns.spn.lookups: false

value is false.

Centrify DirectControl PAM-related activity on the host computer.
pam.account.locked.mesg
pam.allow.groups
pam.allow.override

pam.allow.password.change
pam.allow.password.change.mesg
pam.allow.password.expired.access
pam.allow.password.expired.access.mesg
pam.allow.users
pam.create.k5login
pam.deny.groups
pam.deny.users
pam.homedir.perms
pam.homeskel.dir
pam.ignore.user
pam.mapuser.username
pam.password.change.mesg
pam.password.confirm.mesg
pam.password.enter.mesg
pam.password.expiry.warn
pam.password.new.mesg
pam.password.old.mesg
pam.uid.conflict
lam.max.user.count
Note On AIX, the PAM configuration parameters described in this
section apply to interfaces in the AIX Loadable Authentication
Module (LAM). For consistency across platforms, the parameter
names are the same and retain reference to the PAM settings they
configure, but PAM is not used on AIX.

pam.account.locked.mesg
This configuration parameter specifies the message displayed if a
user account is locked because of too many failed login attempts.
For example:
pam.account.locked.mesg: Account locked
pam.allow.groups
This configuration parameter specifies the groups allowed to access
PAM-enabled applications. When this parameter is defined, only
the listed groups are allowed access. All other groups are denied
access.
If you want to use this parameter to control which users can log in
based on group membership, the groups you specify should be valid
Active Directory groups, but the groups you specify do not have to
be enabled for Unix. Local group membership and invalid Active
Directory group names are ignored.
CentrifyDC > Login Settings > Login Controls group policy
by selecting the allow option and specifying one or more group
names. You can, however, set it manually in the configuration file if
group policy.
If you use this parameter to control access by group name, Centrify
DirectControl checks the Active Directory group membership for
every user who attempts to use PAM-enabled applications on the
host computer.
When a user attempts to log on or access a PAM-enabled service,
the pam_centrifydc module checks with Active Directory to see
what groups the user belongs to. If the user is a member of any
Active Directory group specified by this parameter, the user is
accepted and authentication proceeds. If the user is not a member

of any group specified by this parameter, authentication fails and
the user is rejected.
The parameter’s value can be one or more group names, separated
by commas or spaces, or the file: keyword and a file location. For
example, to allow only members of the administrators, sales,
and engineering groups in Active Directory to log in:
pam.allow.groups: administrators,sales,engineering
Note If you are specifying an Active Directory group that has been
Unix-enabled, you can use the short format of the group name as in
the previous example. If you are specifying an Active Directory
group that has not been enabled for Unix access, you must use the
full canonical name of the group. For example, if the domain is
arcade.com and the group is HelpDesk:
pam.allow.groups: arcade.com/Users/HelpDesk
To specify a file that contains a list of the groups allowed access,

type the path to the file:
pam.allow.groups: file:/etc/centrifydc/groups.allow
If no group names are specified, no group filtering is performed.
pam.allow.override
This configuration parameter is used to override authentication
through Active Directory to ensure the root user or another local
account has permission to log on when authentication through
Active Directory is not possible, when there are problems running
the Centrify DirectControl daemon, or when there are network
communication issues.
When you specify a user account for this parameter, authentication
is passed on to a legacy authentication mechanism, such as
/etc/passwd. You can use this parameter to specify an account that
you want to ensure always has access, even if communication with
Active Directory or the Centrify DirectControl daemon fails. For
example, to ensure the local root user always has access to a system
even in an environment where you have enabled root mapping, you
can specify:

pam.allow.override: root
To log in locally with the override account, you must specify the
local user name and password. However, because the account is
mapped to an Active Directory account, you must append
@localhost to the user name. For example, if you have specified
root as the override account and are using root mapping, you
would type root@localhost when prompted for the user name.
You can then type the local password for the root account and log
in without being authenticated through Active Directory.
Note If you are mapping the root user to an Active Directory
account and password, you should set this parameter to root or to
a local user account with root-level permissions (UID 0), so that you
always have at least one local account with permission to access
system files and perform privileged tasks on the computer even if
there are problems with the network connection, Active Directory,
or the Centrify DirectControl daemon.

CentrifyDC > Login Settings > Local-only Users group
policy by selecting Enabled and typing the local user names that
you want to permit to log on. You can, however, set it manually in
pam.allow.password.change
This configuration parameter specifies whether users who log in
with an expired password should be allowed to change their
password. You can set this parameter to true or false and use it in
conjunction with the pam.allow.password.expired.access
parameter to control access for users who attempt to log on with
an expired password.
If both this parameter and pam.allow.password.expired.access
are set to true, users logging on with an expired password are
allowed to log on and are prompted to change their password.

If the pam.allow.password.expired.access parameter is set to
true, but this parameter is set to false, users logging on with an
expired password are allowed to log on but are not prompted to
change their password and the message defined for the
pam.allow.password.change.mesg parameter is displayed.
If both this parameter and pam.allow.password.expired.access

are set to false, users who attempt to log on with an expired
password are not allowed to log on or change their password and
the message defined for the pam.allow.password.change.mesg
parameter is displayed.
For example, to allow users with expired passwords to change their
password:
pam.allow.password.change: true
pam.allow.password.change.mesg
This configuration parameter specifies the message displayed when
users are not permitted to change their expired password because
the pam.allow.password.change parameter is set to false.
For example:
pam.allow.password.change.mesg: Password change not
permitted
pam.allow.password.expired.access
This configuration parameter specifies whether users who log in
with an expired password should be allowed access. You can set this
parameter to true or false and use it in conjunction with the
pam.allow.password.change parameter to control access for users
who attempt to log on with an expired password.
If this parameter is set to true, users logging on with an expired
password are allowed to log on, and either prompted to change
their password if the pam.allow.password.change parameter is set
to true, or notified that they are not allowed to change their
expired password if the pam.allow.password.change parameter is
set to false.

If this parameter is set to false, users logging on with an expired

password are not allowed to log on and the message defined for the
pam.allow.password.expired.access.mesg parameter is
displayed.
For example, to allow users with expired passwords to log on:
pam.allow.password.expired.access: true
pam.allow.password.expired.access.mesg
This configuration parameter specifies the message displayed when
users are not permitted to log on with an expired password because
the pam.allow.password.expired.access parameter is set to
false.
For example:
pam.allow.password.expired.access.mesg: Password expired -
access denied
pam.allow.users
This configuration parameter specifies the users who are allowed to
access PAM-enabled applications. When this parameter is defined,
only the listed users are allowed access. All other users are denied
access.
If you want to use this parameter to control which users can log in,
the users you specify should be valid Active Directory users that
have a valid Unix profile for the local computer’s zone. If you
specify local user accounts or invalid Active Directory user names,
these entries are ignored.
by selecting the allow option and specifying one or more user
group policy.

If you specify one or more users with this parameter, user filtering
is performed for all PAM-enabled applications on the host
computer.
the pam_centrifydc module checks the users specified by this
parameter to see if the user is listed there. If the user is included in
the list, the user is accepted and authentication proceeds. If the user
is not listed, the user is rejected.
The parameter value can be one or more user names, separated by
commas or spaces, or the file: keyword and a file location. For
example:
pam.allow.users: root,joan7,bbenton
To specify a file that contains a list of the users allowed access, type
the path to the file:
pam.allow.users: file:/etc/centrifydc/users.allow
If no user names are specified, then no user filtering is performed.
pam.create.k5login
This configuration parameter specifies whether the .k5login file
should be created automatically in the user’s home directory. This
file is used to enable Kerberos authentication and single sign-on in
PAM-aware applications.
CentrifyDC > PAM Settings > Create .5login group policy
by selecting Enabled. You can, however, set it manually in the
The parameter value can be true or false. If set to true, Centrify
DirectControl will create the .k5login file in the user’s home
directory.
For example:
pam.create.k5login: true

pam.deny.groups
This configuration parameter specifies the groups that should be
denied access to PAM-enabled applications. When this parameter is
defined, only the listed groups are denied access. All other groups
are allowed access.
If you want to use this parameter to control which users can log in
based on group membership, the groups you specify should be valid
Active Directory groups, but the groups you specify do not need to
be enabled for Unix. Local group membership and invalid Active
Directory group names are ignored.
by selecting the deny option and specifying one or more group
group policy.
the pam_centrifydc module checks with Active Directory to see
which groups the user belongs to. If the user is a member of any
Active Directory group specified by this parameter, the user is
denied access and authentication fails. If the user is not a member of
any group specified by this parameter, authentication succeeds and
the user is logged on.
The parameter’s value can be one or more group names, separated
by commas or spaces, or the file: keyword and a file location. For
example, to prevent all members of the vendors and azul groups
in Active Directory from logging on:
pam.deny.groups: vendors,azul
Note If you are specifying an Active Directory group that has been
Unix-enabled, you can use the short format of the group name as in
the previous example. If you are specifying an Active Directory
group that has not been enabled for Unix access, however, you must

use the full canonical name of the group. For example, if the domain
is arcade.com and the group is HelpDesk:
pam.deny.groups: arcade.com/Users/HelpDesk
To specify a file that contains a list of the groups that should be

denied access:
pam.deny.groups: file:/etc/centrifydc/groups.deny
If this parameter is not defined in the configuration file, no group

filtering is performed.
pam.deny.users
This configuration parameter specifies the users that should be
denied access to PAM-enabled applications. When this parameter is
defined, only the listed users are denied access. All other users are
allowed access.
If you want to use this parameter to control which users can log in,
the users you specify should be valid Active Directory users that
have been enabled for Unix. If you specify local user accounts or
invalid Active Directory user names, these entries are ignored.
by selecting the deny option and specifying one or more user
group policy.
the pam_centrifydc module checks the users specified by this
parameter to see if the user is listed there. If the user is included in
the list, the user is rejected and authentication fails. If the user is
not listed, the user is accepted and authentication proceeds.
The parameter value can be one or more user names, separated by
commas or spaces, or the file: keyword and a file location. For

example, to prevent the user accounts starr and guestuser from

logging on:
pam.deny.users: starr,guestuser
To specify a file that contains a list of the users that should be

denied access:
pam.deny.users: file:/etc/centrifydc/users.deny
If this parameter is not defined in the configuration file, no user

filtering is performed.
pam.homedir.perms
This configuration parameter specifies the permissions for a user’s
home directory if a new home directory is created for the user on
the local computer.
CentrifyDC > PAM Settings > Home Directory
Permissions group policy by selecting Enabled and typing the
permission value.
For example, to give read, write, and execute permissions on the
directory to the user and no other permissions:
pam.homedir.perms: 0700
pam.homeskel.dir
This configuration parameter specifies where the PAM skeleton
directory is located. The skeleton directory to used to
automatically create a new home directory and Unix profile for a
new user, if needed.
pam.homeskel.dir: /etc/skel
If this parameter is not defined in the configuration file, no files are

copied when a new user directory is created.

pam.ignore.user
This configuration parameter specifies one or more users that
Centrify DirectControl will ignore for lookup in Active Directory.
Because this parameter allows you to intentionally skip looking up
an account in Active Directory, it allows faster lookup for system
accounts such as tty, root, and bin and local login accounts.
Note This configuration parameter ignores listed users for
authentication and NSS lookups.

CentrifyDC > Login Settings > Users to Ignore group
policy by selecting Enabled and typing the list of local user names
not stored in Active Directory. This list is then stored in the
/etc/centrifydc/user.ignore file and used to disable lookups in
Active Directory for the users specified.You can, however, set it
should be one or more user names, separated by a space, or the
file: keyword and a file location. For example, to specify a list of
users to authenticate locally:
pam.ignore.users: root sys tty
To specify a file that contains a list of the users to ignore:

pam.ignore.users: file:/etc/centrifydc/users.ignore
If this parameter is not defined in the configuration file, no users

are specified.
pam.mapuser.username
This configuration parameter maps a local Unix user account to an
Active Directory account. Local user mapping allows you to set
password policies in Active Directory even when a local Unix
account is used to log in. This parameter is most commonly used to
map the root user on each computer or in each zone to a different

Active Directory account and password, but it can be used for any
local user account. For more information about mapping local
Unix accounts to Active Directory accounts, see “Mapping local
Unix accounts to Active Directory” on page 172.
CentrifyDC > User Map group policy. You can, however, set it
If you are manually setting this parameter, you should note that the
local account name you want to map to Active Directory is
specified as the last portion of the configuration parameter name.
The parameter value is the Active Directory account name for the
specified local user. For example, the following maps the local Unix
account root to the Active Directory account
root_storm@acme.com if the host computer’s name is storm:
pam.mapuser.root: root_$HOSTNAME@acme.com
You can specify the user name in the configuration file with any of
the following valid formats:
Standard Windows format: domain\user_name
Universal Principal Name (UPN): user_name@domain
Alternate UPN: alt_user_name@alt_domain
Unix user name: user
You must include the domain name in the format if the user
account is not in the local computer’s current Active Directory
domain.
If this parameter is not defined in the configuration file, no local
Unix user accounts are mapped to Active Directory accounts.
pam.password.change.mesg
This configuration parameter specifies the text displayed by a
PAM-enabled application when it requests a user to change a
password.

CentrifyDC >Password Prompts > Change Password
Notification Text group policy by selecting Enabled and typing
the text you want displayed for Active Directory users. You can,
The parameter value must be an ASCII string. Unix special
characters and environment variables are allowed. For example:
pam.password.change.mesg: Changing Active Directory
password for\
If this parameter is not present, its default value is “Change

password for”.
pam.password.confirm.mesg
PAM-enabled application when it requests a user to confirm his
new password by entering it again.
Prompt to Confirm New Password group policy by selecting
Enabled and typing the text you want displayed for Active
Directory users. You can, however, set it manually in the
pam.password.confirm.mesg: Confirm new Active Directory
password:\
If this parameter is not present, its default value is “Confirm new

password:”.

pam.password.enter.mesg
PAM-enabled application when it requests a user to enter his
password.
CentrifyDC >Password Prompts > Login Password
Prompt group policy by selecting Enabled and typing the text
you want displayed for Active Directory users. You can, however,
set it manually in the configuration file if you aren’t using group
policy or want to temporarily override group policy.
pam.password.enter.mesg: Active Directory password:\
If this parameter is not present, its default value is “Password:”.
pam.password.expiry.warn
This configuration parameter specifies how many days before a
password is due to expire PAM-enabled applications should issue a
warning to the user.
The parameter value must be a positive integer. For example, to
issue a password expiration warning 10 days before a password is
set to expire:
pam.password.expiry.warn: 10
If this parameter is not present, its default value is 14 days.
pam.password.new.mesg
PAM-enabled application when it requests a user to enter his new
password during a password change.

Prompt for New Password group policy by selecting Enabled
and typing the text you want displayed for Active Directory users.
policy.
pam.password.new.mesg: Enter new Active Directory
password:\
If this parameter is not present, its default value is “Enter new

password:”.
pam.password.old.mesg
PAM-enabled application when it requests a user to enter his old
password during a password change.
Prompt for Old Password group policy by selecting Enabled
and typing the text you want displayed for Active Directory users.
policy.
pam.password.old.mesg: (current) Active Directory
password:\
If this parameter is not present, its default value is “(current)

password:”.
pam.uid.conflict
This configuration parameter specifies how you want Centrify
DirectControl to respond if a user logs on with an Active Directory

account and either the Active Directory user name or Active

Directory UID conflicts with a local user account. The purpose of
detecting a duplicate user name or duplicate UID is to prevent an
Active Directory user from signing on and receiving privileges to
modify files created by a different local user.
The pam.uid.conflict configuration parameter determines what
happens when this type of conflict is found. The parameter value
must be set to one of the following valid options:
Use this value To do this

ignore Do not report duplicate user names or UID conflicts. If
detected, log the conflict at the info level if logging is
enabled.
warn Warn the user of the user name or UID conflict after s
successful login. Log the conflict at warning level if logging
is enabled. This is the default value.
error Report UID conflict to user after user name is entered. Don't
accept password. Don't allow log in. Log conflict at error
level.
For example:
pam.uid.conflict: warn
Note If both the Active Directory user name and Active Directory
UID are the same as a local user name and UID, the accounts do not
conflict and the user can log on regardless of how you set this
parameter. Although this situation is rare, you should avoid using
Active Directory user names and UIDs that duplicate local user
names and UIDs but apply to different individual users.
If this parameter is not present, its default value is warn.
lam.max.group.count
This configuration parameter applies to the AIX Loadable
Authentication Module (LAM) and specifies the maximum number
of Active Directory groups that the lsgroup ALL command will
return.

The parameter value must be an integer. The default value for this
parameter is 1000 groups. If you specify 0 or a negative value (for
example, -1), there is no limit on the number of groups returned.
For example:
lam.max.group.count: 100
Before changing this parameter setting or using a value of 0, you

should consider its impact on your environment. Increasing the
value of this parameter may provide more complete information
about the number of Active Directory Unix groups, but may result
in slower performance if there are more Active Directory Unix
groups in the zone than the maximum you specify. Similarly, if you
do not set a limit, you may experience performance problems if
you have a large number of Active Directory groups. Decreasing
the value of this parameter may provide better response time if
there are more Active Directory Unix groups in the zone than the
maximum you specify, but further limits how much information is
returned.
value is 1000 groups.
lam.max.user.count
This configuration parameter applies to the AIX Loadable
Authentication Module (LAM) and specifies the maximum number
of Active Directory users that the lsuser ALL command will
return. This value also limit the results returned by the getpwent()
and nextuser() functions.
The parameter value must be an integer. The default value for this
parameter is 1000 users. If you specify 0 or a negative value (for
example, -1), there is no limit on the number of users returned.
For example:
lam.max.user.count: 100
Before changing this parameter setting or using a value of 0, you

should consider its impact on your environment. Increasing the
value of this parameter may provide more complete information
about the number of Active Directory Unix users, but may result in

slower performance if there are more Active Directory Unix users

in the zone than the maximum you specify. Similarly, if you do not
set a limit, you may experience performance problems if you have a
large number of Active Directory users. Decreasing the value of
this parameter may provide better response time if there are more
Active Directory Unix users in the zone than the maximum you
specify, but further limits how much information is returned.
value is 1000 users.

Centrify DirectControl NSS module on the host computer.
nss.group.ignore
nss.group.override
nss.mingid
nss.minuid
nss.passwd.override
nss.program.ignore
nss.shell.login
nss.user.ignore
Note On AIX, the NSS configuration parameters described in this
section apply to interfaces in the AIX Loadable Authentication
Module (LAM). For consistency across platforms, the parameter
names are the same and retain the reference to NSS settings they
configure, but NSS is not used on AIX.

nss.group.ignore
This configuration parameter specifies a set of one or more groups
that the Centrify DirectControl NSS module will ignore for lookup
in Active Directory.
CentrifyDC > Login Settings > Groups to Ignore group
policy by selecting Enabled and typing the list of local group
names not stored in Active Directory. This list is then stored in the
/etc/centrifydc/group.ignore file and used to disable lookups in
Active Directory for the groups specified.You can, however, set it
should be one or more group names, separated by a space, or the
file: keyword and a file location. For example:
nss.group.ignore: maintenance apps
nss.group.ignore=file:/etc/centrifydc/group.ignore
If this parameter is not defined in the configuration file, no groups

are specified.
nss.group.override
This configuration parameter allows you to override entries in the
/etc/group file. By defining override filters, you can use this
parameter to give you fine-grain control over the groups that can
access a local computer. You can also use the override controls to
modify the information for specific fields in each group entry on
the local computer. For example, you can override the group ID or
member list for a specific group on the local computer without
modifying the group entry itself.
CentrifyDC > Login Settings > NSS Group Overrides
group policy by selecting Enabled and typing the appropriate

group override entries. These entries are then stored in the

/etc/centrifydc/group.ovr file and used to filter group access to
a local computer.You can, however, set it manually in the
The syntax for overriding group entries is similar to the syntax
used for overriding NIS. You use + and – entries to allow or deny
access for specific groups on the local system. Additional fields
correspond to the standard /etc/group fields separated by colons
(:).
In most cases, the nss.group.override parameter is used to
identify a file location of an override file that contains all of group
override entries you want to use on the local computer. For
example:
nss.group.override: file:/etc/centrifydc/group.ovr
Within the override file, you use the following format:

+zone_group_name:group_name:group_password:group_id:member_list
-zone_group_name:group_name:group_password:group_id:member_list
For example:
+users::::
+admins::::jdoe,bsmith,frank
+ftpusers:ftp::300:
-webusers
+::::
Note Changes to the group password field are ignored. In

overriding group entries, the groups be enabled for Unix.
For more information about overriding group entries, see the

sample group override file /etc/centrifydc/group.ovr.
nss.mingid
This configuration parameter specifies the minimum group ID
(GID) that the Centrify DirectControl NSS module will look up in
Active Directory. By setting this parameter, you allow the NSS
module to ignore the GIDs for special system or application
accounts that are not stored in Active Directory. Because this
parameter allows you to intentionally skip looking up account

information in Active Directory, it results in faster name lookup
service for system group accounts such as tty and disk.
CentrifyDC > Login Settings > Minimum Group ID group
policy by selecting Enabled and setting the minimum group ID
value. You can, however, set it manually in the configuration file if
group policy.
must be a positive integer. For example:
nss.mingid: 3

value is 0, which disables this feature.
nss.minuid
This configuration parameter specifies the minimum user ID (UID)
value that the Centrify DirectControl NSS module will look up in
Active Directory. By setting this parameter, you can allow the NSS
module to ignore the UIDs for special system or application
accounts that are not stored in Active Directory. Because this
parameter allows you to intentionally skip looking up account
information in Active Directory, it results in faster name lookup
service for system accounts such as tty, root, and bin.
CentrifyDC > Login Settings > Minimum User ID group
policy by selecting Enabled and setting the minimum user ID
value. You can, however, set it manually in the configuration file if
group policy.
The parameter value must be a positive integer. For example, to
only check Active Directory for account information when the
UID for an account is more than 200:

nss.minuid: 200
Setting this parameter value to 0 disables the feature and may cause
delays in responding to lookup service requests. If this parameter is
not defined in the configuration file, its default value is 100.
nss.passwd.override
This configuration parameter allows you to override entries in the
/etc/passwd file. By defining override filters, you can use this
parameter to give you fine-grain control over the user accounts that
can access a local computer. You can also use the override controls
to modify the information for specific fields in each /etc/passwd
entry on the local computer. For example, you can override the
user ID, primary group ID, default shell, or home directory for
specific login accounts on the local computer without modifying
the account entry itself.
CentrifyDC > Login Settings > NSS User Overrides group
policy by selecting Enabled and typing the appropriate passwd file
override entries. These entries are then stored in the
/etc/centrifydc/passwd.ovr file and used to filter user access to
a local computer.You can, however, set it manually in the
The syntax for overriding passwd entries is similar to the syntax
used for overriding NIS. You use + and – entries to allow or deny
access for specific users on the local system. Additional fields
correspond to the standard /etc/passwd fields separated by colons
(:).
In most cases, the nss.passwd.override parameter is used to
identify a file location of an override file that contains all of passwd
override entries you want to use on the local computer. For
example:
nss.group.override: file:/etc/centrifydc/passwd.ovr

Note Although the passwd.ovr file is generated from the list of
override entries you specify in the Computer Configuration >
Administrative Templates > CentrifyDC > NSS User
Overrides Group Policy applied to a computer, you can also
manually create or update the override file on any local computer,
if needed. A sample illustrating the syntax is provided in the
/etc/centrifydc/passwd.ovr.sample file.
Within the override file, you use the following format for entries:
+zone_username:username:password:uid:gid:GECOS:home_directory:shell
For example:
+mike:::::::/usr/local/ultrabash
+kris:kdavis:x:6:6:Kris Davis:/home/kdavis:/bin/bash
+janedoe@centrify.test:jdoe::300:300:::
+@sysadmins:::::::
-ftp
+@staff:::::::
+@rejected-users:::32767:32767:::/bin/false
+:::::::/sbin/nologin
+:::::::
Note Overriding the password hash field is ignored. Changing this

field in the override file does not affect Centrify DirectControl user
passwords. In overriding passwd entries, users accounts must be
enabled for Unix in the zone, but the groups do not need to be
Unix-enabled.
In the example above, the @ symbol denotes an Active Directory
name. It may be an Active Directory group name, a Centrify
DirectControl zone name, or some other container name. You may
also specify an Active Directory user principal name instead of the
zone name.
Entries in the override file are evaluated in order from first to last
with the first match taking precedence. This means the system will
only use the first entry that matches a particular user. For example,
if the user cruz is a member of both the staff group and the
rejected-users group and you have defined the override entries as
listed in the example above, the cruz user account is allowed to log
on to the computer because the staff entry is evaluated and
matched before the rejected-users entry. If the order were

reversed in the override file, the cruz account would be flagged as a

rejected-users account and denied access.
Note If you manually create the passwd.ovr file, you must include
the following as the last line in the file:
+:::::::
For more information about overriding group entries, see the

sample passwd override file /etc/centrifydc/passwd.ovr. For
information about using the NSS Overrides group policy to
generate and maintain the passwd.ovr file, see the Centrify
DirectControl Help.
nss.program.ignore
This configuration parameter specifies one or more programs that
should not look up account information in Active Directory. The
programs you specify for this parameter do not use the Centrify
DirectControl daemon to contact Active Directory.
Setting this parameter helps 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. For
example, you can specify programs such as adduser and addgroup
to ensure those programs can still be used to create and update
local accounts independent of Active Directory:
nss.program.ignore: addgroup,adduser
The specific programs you should include in the list vary by

platform and the specific operating environment you are using. he
default setting for this configuration parameter includes the most
common program names that shouldn’t make calls to Active
Directory through the Centrify DirectControl daemon.
nss.shell.login
This configuration parameter specifies the default login shell to use
when a user or group attempting to access the computer is not
allowed to log on. The default no-login shell and its location is

typically platform-specific. For example, on Red Hat Linux the
default shell for users who are denied access is /sbin/nologin.
nss.user.ignore
This configuration parameter specifies one or more users that the
Centrify DirectControl NSS module will ignore for lookup in
Active Directory. Because this parameter allows you to
intentionally skip looking up specific accounts in Active Directory,
it allows faster lookup for system accounts such as tty, root, and
bin.
Note This configuration parameter only ignores the listed users for
NSS lookups. To ignore users for authentication and NSS lookups,
use the pam.ignore.user configuration parameter.

CentrifyDC > Login Settings > Users to Ignore group
policy by selecting Enabled and typing the list of local user names
not stored in Active Directory. This list is then stored in the
/etc/centrifydc/user.ignore file and used to disable lookups in
Active Directory for the users specified. You can, however, set it
should be one or more user names, separated by a space, or the
file: keyword and a file location. For example:
nss.user.ignore: root sys tty
nss.user.ignore=file:/etc/centrifydc/user.ignore
If this parameter is not defined in the configuration file, no users

are specified.
Skipping Active Directory authentication for local users on AIX

By default, Centrify DirectControl modifies the AIX Loadable
Authentication Module (LAM) for the SYSTEM user attribute to
look like this:

SYSTEM=CENTRIFYDC OR CENTRIFYDC[NOTFOUND] AND compat
This setting specifies that the first attempt to authenticate a user

should be passed to Active Directory through DirectControl. In
some cases, however, you may have local user accounts that you
only want to authenticate locally. Although there are parameters in
the Centrify DirectControl configuration file that enable you to
ignore Active Directory authentication for specific local users,
these parameters are not completely applicable on computers
running AIX. To exclude any local user account from Active
Directory authentication on AIX, you can run the following
command for the user:
chuser SYSTEM=compat username
Alternatively, you can edit the /etc/security/user file and change

the stanza for a particular user’s SYSTEM attribute to:
SYSTEM=compat
If you later decide you want to migrate the local user account to use
Active Directory, you can run the following command for the user
to reset the default authentication:
chuser SYSTEM= username
Note To reset the user account to be authenticated through Active

Directory, there must be a space after the equal sign (=) in the
command line.

Centrify DirectControl Network Information Service on the host
computer. The DirectControl Information Service provides a
mechanism for DirectControl to respond to NIS client requests
from other computers not managed by Centrify DirectControl.
nisd.maps
nisd.securenetss
nisd.server.switch.delay
nisd.threads

nisd.update.interval
nisd.maps.max
log.adnisd
nisd.maps
This configuration parameter specifies the name of the NIS maps
currently available for NIS service. When the adnisd daemon
connects to Active Directory, it retrieves the list of NIS maps
available for the local computer’s zone, creates a local map data
store, and updates this configuration parameter, if necessary, to
indicate the maps retrieved. If any NIS client requests a map that is
not in the list specified by this parameter, the daemon refuses the
request.
The parameter value must be a list of NIS map names. If the
parameter is included in the configuration file but no value is set,
no maps are retrieved from Active Directory or available for
service. For example, to specify that you want to make the
netgroup maps available but no other maps, you can set this
parameter as follows:
nisd.maps: netgroup,netgroup.byhost,netgroup.byuser
If this parameter is not defined in the configuration file, all NIS

maps found in Active Directory are retrieved and available for
service.
nisd.securenets
This configuration parameter specifies a list of one or more subnets
from which the daemon will accept NIS requests. You use this
parameter to restrict access to the Centrify DirectControl
Network Information Service by IP address. NIS requests that do
not come from the IP addresses specified in this configuration
parameters are refused by the asnisd daemon.

Note You do not need to specify the local IP address for this
parameter. The Centrify DirectControl Network Information
Service will always accept local NIS client requests.
The parameter value must include both the specific IP address or

subnet and the subnet mask, separated by a forward slash. For
example:
nisd.securenets: 192.168.111.0/255.255.255.0
You can specify multiple IP addresses by separating each IP

address-subnet mask pair with a comma or a space. For example:
nisd.securenets: 192.68.11.0/255.255.255.0,192.147.10.0/255.255.255.0
If this parameter is not defined in the configuration file, only local

NIS client requests are accepted by the asnisd daemon.
nisd.server.switch.delay
This configuration parameter specifies how long, in seconds, to
wait before loading maps from a backup domain controller when
the connection to the primary domain controller is lost. If the
Centrify DirectControl Network Information Service is unable to
connect to its primary Active Directory domain controller, it will
respond to NIS client requests using information in the local cache
until the switch to the backup domain controller is complete.
The parameter value must be an integer equal to or greater than
zero. If the value is zero, then the delay is disabled. For example, to
delay period to 2 hours:
nisd.server.switch.delay: 7200

delay for switching to the backup domain controller is one hour
(3600 seconds).
nisd.threads
This configuration parameter specifies the number of threads to use
for processing NIS requests.

The parameter value must be an integer greater than zero. The
default is 4 threads. For example:
nisd.threads: 4
nisd.update.interval
This configuration parameter specifies the interval, in seconds, that
the adnisd daemon waits between connections to Active
Directory. At each interval, the adnisd daemon connects to Active
Directory, gets the latest NIS maps for the local computer’s zone,
and updates its local NIS map data store.
zero. If the value is zero, then the update interval is disabled and the
local NIS map data store is not updated. For example, to set the
interval for getting NIS maps to 1 hour:
nisd.update.rate: 3600

interval is 5 minutes (300 seconds).
nisd.maps.max
This configuration parameter specifies the number of alternate sets
of NIS maps to retain. A new set of NIS maps is normally created
when adnisd switches to an alternate domain controller. Keeping
these alternate sets of maps allows Centrify DirectControl
Network Information Service to more efficiently switch between
domain controllers.
The parameter value must be an integer greater than zero. The
default is 2 map sets. For example:
nisd.maps.max: 2
log.adnisd
This configuration parameter specifies the logging level for the
Centrify DirectControl Network Information Service. The default
logging level is the logging level set for the log configuration
parameter or INFO if neither parameter is defined in the

configuration file. For example, to diagnose problems with the

Centrify DirectControl Network Information Service without
changing the logging level for other component:
log.adnisd: DEBUG

The following configuration parameters affect Group Policy
support on the host computer:
gp.disable.all
gp.disable.machine
gp.disable.user
gp.mappers.directory.machine
gp.mappers.directory.user
gp.mappers.machine
gp.mappers.runmappers
gp.mappers.timeout
gp.mappers.user
gp.refresh.disable
gp.refresh.frequency.machine
gp.refresh.offset.machine
gp.refresh.frequency.user
gp.refresh.offset.user
gp.reg.directory.machine
gp.reg.directory.user
gp.disable.all
This configuration parameter can be used to disable both computer
and user group policies on a local computer. If set to true, all

group policy settings are ignored. If this parameter is not defined in
the configuration file, its default value is false.
gp.disable.machine
This configuration parameter can be used to disable
computer-based group policies on a local computer. If set to true,
all computer-based group policy settings are ignored. If this
parameter is not defined in the configuration file, its default value is
false.
gp.disable.user
This configuration parameter can be used to disable user-based
group policies on a local computer. If set to true, all user-based
group policy settings are ignored. If this parameter is not defined in
the configuration file, its default value is false.
gp.mappers.directory.machine
This configuration parameter specifies the root directory that
contains the all of the mapping programs for computer-based
group policy settings. Individual mapping programs translate
entries from the virtual registry into configuration settings in the
appropriate files on the local computer.
gp.mappers.directory.machine: /usr/share/centrifydc/mappers/machine

value is /usr/share/centrifydc/mappers/machine.
gp.mappers.directory.user
This configuration parameter specifies the root directory that
contains the all of the mapping programs for user-based group
policy settings. Individual mapping programs translate entries from
the virtual registry into configuration settings in the appropriate
files on the local computer.


gp.mappers.directory.machine: /usr/share/centrifydc/mappers/user

value is /usr/share/centrifydc/mappers/user.
gp.mappers.machine
This configuration parameter specifies the list of mapping programs
to run to configure computer-based policies. The mapping
programs are executed in the order in which they are specified.
CentrifyDC > Group Policy Settings > Group Policy
Machine Mapper List group policy by selecting Enabled and
specifying the list of mapping programs to run. You can, however,
set it manually in the configuration file if you want to temporarily
override group policy.
In defining the list of mapping programs to run, you can use an
asterisk (*) as a wild card to match a set of program names. For
example, you can specify a* to match all programs with names that
start with the letter a. You can use square brackets ([ ]) to match
any character within the brackets. For example, you can specify
mapprogram[123] to match the program names of mapprogram1,
mapprogram2, and mapprogram3. You can also use an exclamation
point (!) with a program name to prevent a mapping program from
running. For example, you can specify !mysample to prevent the
mapping program mysample from running. These rules can be
combined to give you precise control over which mapping
programs run.
To run all of the mapping programs for computer-based policy
settings, you can specify:
gp.mappers.machine: *
To run a subset of the mapping program, you can explicitly define

the order and which programs to run. For example, to run the
program mapgp1, followed by mapgp4 and mapgp3, but skipping the
execution of mapgp2:

gp.mappers.machine: mapgp1 !mapgp2 mapgp4 mapgp3
gp.mappers.runmappers
This configuration parameter specifies the location of the
runmappers program. The runmappers program is started by the
Centrify DirectControl daemon and invokes individual mapping
programs for computers, users or both.
gp.mappers.runmappers: /usr/share/centrifydc/mappers/runmappers

value is /usr/share/centrifydc/mappers/runmappers.
gp.mappers.timeout
This configuration parameter specifies the maximum time, in
seconds, to allow for a mapping program to complete execution. If
a mapping program takes longer than this period to successfully
complete its execution, the process is stopped and the next
mapping program is started.
CentrifyDC > Group Policy Settings > Group Policy
Mapper Execution Timeout group policy by selecting
Enabled and specifying the maximum amount of time to allow for
a group policy mapper program to run before the process is
stopped. You can, however, set it manually in the configuration file
if you want to temporarily override group policy.
must be a positive integer. For example, to set the timeout interval
to 60 seconds:
gp.mappers.timeout: 60

gp.mappers.user
This configuration parameter specifies the mapping programs that
map user-based policy settings to run. The mapping programs are
executed in the order in which they are specified.
CentrifyDC > Group Policy Settings > Group Policy User
Mapper List group policy by selecting Enabled and specifying
the list of mapping programs to run. You can, however, set it
manually in the configuration file if you want to temporarily
override group policy.
In defining the list of mapping programs to run, you can use an
asterisk (*) as a wild card to match a set of program names. For
example, you can specify a* to match all programs with names that
start with the letter a. You can use square brackets ([ ]) to match
any character within the brackets. For example, you can specify
mapprogram[123] to match the program names of mapprogram1,
mapprogram2, and mapprogram3. You can also use an exclamation
point (!) with a program name to exclude a program from the list.
For example, you can specify !mysample to prevent the mapping
program mysample from running.
To run all of the mapping programs for user-based policy settings,
you can specify:
gp.mappers.user: *
To run a subset of the mapping program, you can explicitly define

the order and which programs to run. For example, to run the
program mapgp1, followed by mapgp4 and mapgp3, but skipping the
execution of mapgp2:
gp.mappers.user: mapgp1 !mapgp2 mapgp4 mapgp3
gp.refresh.disable
This configuration parameter specifies whether to disable the
background processing of group policy updates. This configuration
parameter applies to both computer- and user-based policies.

System > Group Policy > Turn off background refresh of
Group Policy in a Group Policy Object. You can, however, set it
manually in the configuration file if you want to temporarily
override group policy. For example:
gp.refresh.disable: false
gp.refresh.frequency.machine
This configuration parameter specifies the base refresh interval, in
minutes, between updates for computer-based group policies on
the local computer. At each update interval, the Centrify
DirectControl daemon adclient connects to Active Directory to
get the computer group policies that apply to the local computer.
The base refresh interval is supplemented by an offset value so that
group policy updates occur at a random interval to prevent
multiple computers from connecting to and requesting updates
from the Active Directory domain controllers at the same time.
The offset value specifies the maximum number of minutes to add
to the base interval, and thereby defines the maximum period of
time between group policy updates. For example, if the
gp.refresh.frequency.machine parameter is set to 90 minutes
and the offset value specified for the gp.refresh.offset.machine
configuration parameter is 30 minutes, computer group policies
are updated at a random interval between 90 and 120 minutes.
zero. For example, to set the base interval for updating computer
group policies to 20 minutes:
gp.refresh.frequency.machine: 20

impact on your environment. If you set this parameter to update
group policies more frequently, you increase the number of
connections made to Active Directory and the demand that

increased traffic places on the server, but you ensure that policy
changes are implemented more quickly and you decrease the RAM
used by the Centrify DirectControl daemon. If you set this
parameter to update group policies less frequently, you decrease
the number of connections to Active Directory and reduce the
overall demand on the server, but policy changes take longer to
take effect and you increase the RAM used by the Centrify
DirectControl daemon.
If your computer group policies rarely change, you may want to
have the policies updated less frequently. If you have a large number
of computers or a widely distributed network, you may want to
increase the offset period to allow for a longer period of time for
updates to be completed.
gp.refresh.offset.machine
minutes that are added to the base refresh interval specified by the
gp.refresh.frequency.machine configuration parameter. This
offset value defines a period of time during which group policy
updates can occur at random. Using a random rather than a fixed
interval prevents multiple computers from connecting to and
requesting updates from the Active Directory domain controllers
at the same time. For example, if you boot up several computers at
the same time and they all attempt to get policy updates
simultaneously, the demand might overload the domain controller.
To prevent this, the offset value specifies the maximum number of
minutes to add to the base refresh interval—thereby defining the
maximum period of time between group policy updates—but the
actual policy update can occur at any point within the offset period.
If the gp.refresh.frequency.machine parameter is set to 90
minutes and the offset value specified for the
gp.refresh.offset.machine configuration parameter is 30
minutes, computer group policies are updated at a random interval
between 90 and 120 minutes.

zero. For example, to set the offset value for updating computer
group policies to 20 minutes:
gp.refresh.offset.machine: 20

gp.refresh.frequency.user
This configuration parameter specifies the base refresh interval, in
minutes, between updates for user-based group policies on the
local computer. At each update interval, the Centrify
DirectControl daemon adclient connects to Active Directory to
get the user group policies that apply to the currently logged-in
user.
The base refresh interval is supplemented by an offset value so that
group policy updates occur at a random interval to prevent
multiple computers from connecting to and requesting updates
from the Active Directory domain controllers at the same time.
The offset value specifies the maximum number of minutes to add
to the base interval, and thereby defines the maximum period of
time between group policy updates. For example, if the
gp.refresh.frequency.user parameter is set to 90 minutes and
the offset value specified for the gp.refresh.offset.user
configuration parameter is 30 minutes, user group policies are
updated at a random interval between 90 and 120 minutes.
zero. For example, to set the base interval for updating user group
policies to 20 minutes:
gp.refresh.frequency.user: 20

impact on your environment. If you set this parameter to update
group policies more frequently, you increase the number of

connections made to Active Directory and the demand that

increased traffic places on the server, but you ensure that policy
changes are implemented more quickly and you decrease the RAM
used by the Centrify DirectControl daemon. If you set this
parameter to update group policies less frequently, you decrease
the number of connections to Active Directory and reduce the
overall demand on the server, but policy changes take longer to
take effect and you increase the RAM used by the Centrify
DirectControl daemon.
If your user-based group policies rarely change, you may want to
have the policies updated less frequently. If you have a large number
of users or a widely distributed network, you may want to increase
the offset period to allow for a longer period of time for updates to
be completed.
gp.refresh.offset.user
minutes that are added to the base refresh interval specified by the
gp.refresh.frequency.user configuration parameter. This offset
value defines a period of time during which group policy updates
can occur at random. Using a random rather than a fixed interval
prevents multiple computers from connecting to and requesting
updates from the Active Directory domain controllers at the same
time. For example, if multiple users log on and attempt to get
policy updates simultaneously, the demand might overload the
domain controller. To prevent this, the offset value specifies the
maximum number of minutes to add to the base refresh interval—
thereby defining the maximum period of time between group
policy updates—but the actual policy update can occur at any point
within the offset period. If the gp.refresh.frequency.user
parameter is set to 90 minutes and the offset value specified for the
gp.refresh.offset.user parameter is 30 minutes, user group
policies are updated at a random interval between 90 and 120
minutes.

zero. For example, to set the offset value for updating user group
policies to 20 minutes:
gp.refresh.offset.machine: 20

gp.reg.directory.machine
This configuration parameter specifies the root directory of the
virtual registry for computer-based group policies. The parameter
value must be a path name. For example:
gp.reg.directory.machine: /var/centrifydc/reg/machine

value is/var/centrifydc/reg/machine.
gp.reg.directory.user
This configuration parameter specifies the root directory of the
virtual registry for user-based group policies.
gp.reg.directory.user: /var/centrifydc/reg/users

value is /var/centrifydc/reg/users.


Appendix C
Installing an agent software package

manually
Although the Centrify DirectControl installation script to
automatically invoke the proper installation mechanism for a
computer’s local operating system, you can manually install any
package by running the appropriate platform-specific application or
installation command for installing software on the local operating
system. This appendix describes how to install the Centrify
DirectControl Agent using a native installation mechanism for
Linux, Unix, or Mac OS X operating environment.
Installing DirectControl on Red Hat, SuSE, or VMware
Installing DirectControl on Debian
Installing DirectControl on Solaris
Installing DirectControl on HP-UX
Installing DirectControl on AIX
Installing DirectControl on Mac OS X
Note The instructions in this appendix are provided for your
convenience. You are not required to use the specific installation
instructions described here to install a package manually. For
example, if your operating environment supports another native
mechanism for installing and managing software packages, such as
the SMIT or YAST programs, you can use those programs to install
the Centrify DirectControl package.
399

To install the Centrify DirectControl RPM package, follow these
steps:
1 On the computer, log in as or switch to the root user.
2 Mount the cdrom device, if necessary. For example, on Red Hat
or SuSE, use the following command:
mount /mnt/cdrom
3 Use the RPM command to install the appropriate package for

your operating environment, replacing release with the version
of the Centrify DirectControl package you are installing.
For Red Hat Linux, use:
rpm –Uvh /mnt/cdrom/Unix/centrifydc-release-rh9-i386.rpm
For SuSE Linux, use:

rpm –Uvh /mnt/cdrom/Unix/centrifydc-release-suse8-i386.rpm
For VMware ESX, use:

rpm –Uvh /mnt/cdrom/Unix/centrifydc-release-esx2-i386.rpm
If you aren’t sure which file to use for your operating

environment, see the readme.txt file in the Unix directory of
the CD or the Centrify DirectControl Release Notes.
Installing DirectControl on Debian

To install the Debian package, follow these steps:
1 On the computer, log in as or switch to the root user.
2 Mount the cdrom device, if necessary. For example:
mount /mnt/cdrom
3 Use dpkg to install DirectControl for Debian with the following

command, replacing release with the version of the Centrify
DirectControl package you are installing:
dpkg –i /mnt/cdrom/Unix/centrifydc-release-deb3-i386.deb

Installing DirectControl on Solaris
To install the package on Solaris, follow these steps:
1 On the Solaris computer, log in as or switch to the root user.
2 Copy the package from the CD to a local directory, replacing
release with the version of the Centrify DirectControl package
you are installing. For example, if your operating environment
is Solaris 9 on SPARC:
cp /cdrom/cdrom0/Unix/centrifydc-release-sol8-sparc-local.tgz .
If you aren’t sure which installation package to use for your

operating environment, see the readme.txt file in the Unix
directory of the CD or the Centrify DirectControl Release Notes.
3 Unzip the compressed installation package, replacing release
with the version of the Centrify DirectControl package you are
installing. For example:
gunzip -d centrifydc-release-sol8-local.tgz
4 Extract the installation files from the archive file, replacing

you are installing. For example:
tar –xvf centrifydc-release-sol8-local.tar
5 Run the pkgadd command to install DirectControl for Solaris.

For example:
pkgadd –d CentrifyDC -a admin
Installing DirectControl on HP-UX

When you auto-mount the Centrify DirectControl CD-ROM on
HP-UX, file names are displayed in the short name (8.3) format
which makes the platform-specific file names for the different agent
packages indistinguishable.
Before you can manually install agent packages, you need to mount
the CD-ROM manually using the -o rr (rockridge extensions) flag
to display the complete file names.
Appendix C • Installing an agent software package manually 401

After you insert the CD in the drive, run a command similar to the
following to display the long file names:
mount -F cdfs -o rr /dev/dsk/c0t0d0 /mnt/cdrom
You can then change to the Unix directory and determine the
proper agent package to install for the local HP-UX operating
environment.
To install the package on HP-UX, follow these steps:
1 On the HP-UX computer, log in as or switch to the root user.
2 Copy the package from the CD to a local directory, replacing
you are installing. For example, if your operating environment
is HP-UX B.11.11:
cp /cdrom/Unix/centrifydc-release-hp11.11-pa.depot.gz .

directory on the CD or the Centrify DirectControl Release Notes.
3 Unzip the compressed installation package, replacing release
with the version of the Centrify DirectControl package you are
gunzip –d ./centrifydc-release-hp11.11-pa.depot.gz
4 Run swinstall to install the appropriate DirectControl

package. For example:
swinstall –s $full_path/centrifydc-release-hp11.11-pa.depot –x
allow_incompatible=true
You need to mark the Centrify files for installation, select Actions
and Install, then click OK to complete the installation.

To install the package on IBM AIX, follow these steps:
1 On the AIX computer, log in as or switch to the root user.

2 Copy the package from the CD to the current working
directory, replacing release with the version of the Centrify
DirectControl package you are installing:
cp /cdrom/Unix/centrifydc-release-aix5.2-ppc-bff.gz .
3 Unzip the compressed software package, replacing release with

the version of the Centrify DirectControl package you are
gunzip centrifydc-release-aix5.2-ppc-bff.gz
4 Once you have unzipped the file, create the .toc file by running
the following command:
inutoc .
5 You can then install the software by running the following

command:
installp -a -d . CentrifyDC.core

To install the package on a computer with the Mac OS X, follow
these steps:
1 Log on with a valid user account. Although you are not required
to log on as the root user, you must know the password the
Administrator account to complete the installation.
2 Copy the appropriate Centrify DirectControl software package
to the Macintosh computer. For example, if you are installing on
a server running Mac OS X 10.3, copy the file
centrifydc-release-mac10.3.pkg.tar.gz to the computer,
replacing release with the version of the Centrify DirectControl
package you are installing.
directory on the CD or the Centrify DirectControl Release Notes.
3 Go to the Applications > Utilities folder and double-click
Terminal to open a new terminal window.
Appendix C • Installing an agent software package manually 403

4 Change to the directory where you placed the Centrify

DirectControl software package.
5 Type the command to extract the contents of the package to the
local disk, replacing release with the version of the Centrify
DirectControl package you are installing. For example, if you
are installing the package for Mac OS X 10.3:
sudo tar –C / -zxvf centrifydc-release-mac10.3.tgz
6 Type the password for the Administrator account if you are

prompted for it.
On the Mac OS, joining the domain and configuring your
environment is slightly different than on other platforms.
domain from Mac OS X computers” on page 122 to join an Active
Directory domain.

Appendix D
Setting the ports for Centrify

DirectControl
This appendix summarizes the ports that need to be opened in a
firewall for Centrify DirectControl operations.
The following ports must be open for a Unix computer to join the
Active Directory domain through a firewall:
For these operations Port Protocol

LDAP 389 TCP/UDP
LDAP Global Catalog Updates 3268 TCP
Kerberos Authentication 88 UDP
Kerberos Password Changes 464 TCP/UDP
DNS 53 TCP/UDP
Centrify DirectControl uses UDP for DNS
lookups by default. You can, however,
use TCP for DNS lookups on any
computer by changing the
dns.forcetcp configuration
parameter in the /etc/centrifydc/
centrifydc.conf file from false to
true.
Samba (SMB) 445 TCP/UDP
You may also need to open the following ports depending on the
requirements of your organization:
If you want to allow non-administrative users to join the Active
Directory domain, you should open port 135 for TCP
connections to handle RPC communication. The traffic on this
port is initiated by the Unix computer attempting to contact the
Active Directory server.
405
To maintain time synchronization between the local computer
and the domain controller, you should open port 123 for UDP
connections to handle Simple Network Time Protocol (SNTP)
operations. You can close this port if your external servers can
get accurate time updates and stay synchronized with the Active
Directory domain controller.

Index
A adclient
account mapping configuration parameters 326 to 350
configuration setting 369 log file 267
default behavior 173 NSS operation 41
groups pending import 228 operations performed 37 to 38
other local users 175, 176 PAM operation 39
purpose of 172 starting and stopping 317
strategies for root 173 web modules 42
users pending import 230 adclient.autoedit 328
Active Directory adclient.binding.refresh.interval 330
DNS configuration 100 adclient.cache.expires 332
domain controller selection 37 adclient.cache.expires.group 333, 334,
enabling existing users 165 335, 336
forest integrity for zones 268 adclient.cache.expires.user 337
group definition 138 adclient.client.idle.timeout 339
importing Unix information 223 adclient.clients.socket 340
joining the domain 121 adclient.clients.threads 340
local file import 225 adclient.clients.threads.poll 341
mapping Unix fields 226 adclient.fetch.object.count 341
migrating user accounts 33 adclient.hash.allow 342
NIS import 224 adclient.hash.deny 343
planning deployment 85 adclient.hash.expires 343
planning the structure 101 adclient.krb5.autoedit 351
preferred site connection 330 adclient.krb5.conf.file 352
updating first 102 adclient.krb5.encryption.types 354
users pending import 229 to 231 adclient.krb5.keytab 352
Windows infrastructure 18 adclient.krb5.keytab.entries 352
Active Directory Users and Computers adclient.krb5.password.change.interval
creating computer accounts 148, 149 353
managing computer properties 146 adclient.krb5.service.principals 354
setting permissions 57 adclient.ldap.packet.encrypt 344
Unix properties 32 adclient.ldap.socket.timeout 344
407
adclient.ldap.timeout 345 adpasswd
adclient.paged.search.max 345 command reference 297
addebug displaying help 285
command reference 311 examples 300
examples 311, 314 options 298, 302
options 311, 313, 315, 316 when to use 284
adgpupdate applications
examples 302 authentication issues 18
adinfo licenses 214
command reference 303 reporting 259
displaying help 285 authentication
examples 308 mechanisms available 17
introduction 274
options 304 C
when to use 285 Centrify DirectControl
adjoin access control summary 24, 25
command reference 285 Administrator Console 30
displaying help 285 architectural components 47
examples 291 cached information 38
operations performed 145 command line programs 284
options 287 configuration file 323
running after installation 121 daemon 317
when to use 284 diagnostic information 273
adleave documentation 14
changing a computer’s domain 156 evaluation license 107
command reference 294 joining the domain 121
displaying help 285 log files 270
examples 296 managed system 24
options 295 Management Tools 29
when to use 284 Name Service Switch (NSS) 40
Administrator Console password enforcement 169
installation requirements 101 platform-dependent components 27
introduction 30 Pluggable Authentication Module 39
key tasks 31 prerequisites 99
updating license keys 215 release information 10
viewing users 32 removing 114

Centrify DirectControl continued computer accounts
removing the software 126 changing the zone 153
service library 38 domain changes 156
solution overview 19 to 24 password interval 146, 353
support for UNIX services 35 pre-join creation 147, 149
system requirements reporting 258
Windows 100 running adjoin 145
technical support 16 secured by password 146
troubleshooting issues 267 using zones 143
Unix installation 116 configuration file (centrifydc.conf)
UNIX requirements 115 adclient daemon parameters 326 to
updating 113 350
Windows interface 29 environment variables 326
Centrify DirectControl Administrator group policy 388 to 397
Console Kerberos parameters 350 to 357
installation requirements 101 NIS 384 to 387
minimum permissions 107 NSS parameters 376 to 383
primary tasks 30 PAM parameters 358 to 374
starting the first time 105 purpose 323
Centrify DirectControl Agent special parameter names 324
architecture 35 syntax 324
key tasks 34 valid values 325
Centrify DirectControl Management conventions, documentation 13
Tools
components 29 D
default components installed 105 daemon
Centrify web site 16 configuration parameters 326 to 350
command line programs enabling logging 267
basic usage 284 introduction 317
displaying help 285 key tasks performed 37
introduction 47 local timeout 349, 350
location 284 Debian Linux
man pages 285 installing DirectControl manually 400
removing DirectControl 127
system requirements 116
deployment
staged in phases 144
Index 409
diagnostic information 273, 309 groups
disconnected operation available GIDs 140
account changes 171 customizing access 360, 366, 377
credential storage 37, 171 default GID setting 110, 132
display specifiers 52 defining scope 96, 163
documentation ignoring for import 228
additional 14 importing 177, 223
audience 9 local file import 225 to 226
conventions 13 NIS import 224 to 225
latest information 10 pending import 227 to 229
online help 14 planning access 162
summary of contents 10 to 12 planning to import 223
domain controller private by default 138
selection of 37 reporting 177, 258
domain local groups 96, 163 reserved GID values 140
Domain Name Server (DNS) using private 95, 162
forwarding requests 120
Unix configuration 119 H
Windows requirement 100 heterogeneous environments
duplicate Unix users 269 challenges 17
dynamic provisioning 90 HP-UX
installing DirectControl manually 402
E removing DirectControl 127
Evaluation Guide 14 system requirements 116
evaluation license key 107, 214
I
G IBM AIX
GID installing DirectControl manually 402
new zone creation 132 removing DirectControl 127
next available 140 system requirements 116
reserved values 110, 140 identity management
starting value 110 importance 17
global groups 96, 164 integrated solution 48
group policy multiple mechanisms 18
configuration parameters 388 to 397 simplifying 19

importing from Unix K
accessibility from Windows 224 Kerberos
default mapping 226 automatic configuration 351
groups pending 227 to 229 configuration parameters 350 to 357
local configuration files 225 to 226 credential renewal 356
NIS maps 224 to 225 encryption types 354
pending state 226 key table file location 352
sources of information 223 location of configuration file 352
users pending 229 to 231 overview of operation 41
installation password change interval 353
files and directories 119 service principal entries 352, 354
functional Active Directory 99 timestamp 38
license keys 107 update interval 357
order 102 krb5.cache.renew.interval 356
prerequisites krb5.config.update 357
Active Directory 99
Administrator Console 101 L
Unix platforms 116 licensing
Windows components 100 adding keys 218
restarting services 124 container permissions 51
running setup on Windows 103 to 104 deleting keys 220
Unix components 116 during installation 107
evaluation key 214
J introduction 213
Java authentication multiple keys 215
standard package 42 permanent keys 214
join operation reports 221 to 222, 259
key tasks performed 145 types 213 to 214
optional arguments 150 updating keys 215
user restrictions 147 viewing a summary 217
Linux
joining the domain 121
naming convention 13
PAM configuration file 329
system requirements 116
Index 411
log files NSS configuration
adinfo output 274 automatic editing 328
enabling 270 groups ignored 377
location 271 introduction 40
performance impact 271 manual editing 328
purpose 267 minimum group identifier 378
lrpc.timeout 350 minimum user identifier 379
parameter settings 376 to 383
M reverting to pre-join state 157
Mac OS X users ignored 369, 382, 383
installing DirectControl manually 403 nss.group.ignore 377
joining the domain 122 nss.mingid 378
removing DirectControl 127 nss.minuid 379
system requirements 116 nss.user.ignore 369, 383
Macintosh
configuring WINS 122 O
man pages online help 14
displaying 285
source of information 15 P
managed system 24 PAM configuration
Microsoft Management Console (MMC) account mapping 369
DirectControl snap-in 30 automatic editing 328
Microsoft Services for Unix (SFU) group filtering 360, 366
zone creation 131 home directory skeleton 368
ignore authentication 361
N local computer policies 159
Name Service Switch (NSS) manual editing 329
DirectControl module 40 messages displayed 370 to 372
nested groups 96, 164 parameter settings 358 to 374
Network Information Service (NIS) reverting to pre-join state 157
configuration parameters 384 to 387 user filtering 364, 367
default mapping 226 user identifier conflicts 374
described 224 pam.allow.groups 360, 366
groups pending import 227 to 229 pam.allow.users 364, 367
importing maps 224 to 225 pam.homeskel.dir 368
planning to import 223 pam.mapuser.username 369
server accessibility 224 pam.password.change.mesg 370
users pending import 229 to 231 pam.password.confirm.mesg 371
pam.password.enter.mesg 372

pam.password.expiry.warn 372 Q
pam.password.new.mesg 372 Quick Start 14
pam.password.old.mesg 373
pam.uid.conflict 373 R
password management Red Hat Linux
changing your own 169 to 170 installing DirectControl manually 400
computer accounts 38, 353 removing DirectControl 127
disconnected mode 171 system requirements 116
hash storage 342 Release Notes 10
messaged displayed 370 to 372 reporting
PAM-enabled services 39 account status information 259
policy definition 169 application information 259
policy enforcement 25 default content 258
resetting for other users 170 to 171 export formats 264
pending import filtering information 261 to 262
group information 227 forest analysis 268
local users and groups 226 generating reports 260 to 261
manual process 226 group information 177, 258
NIS information 225 license information 259
user information 229 navigation pane 263
permissions printing 265
assigned by delegation 55 purpose of 257
displaying the Centrify Profile 52 saving 264
methods for setting 57 Unix computers 158, 258
Setup Wizard 50 user information 177, 258
Pluggable Authentication Module (PAM) web applications 259
DirectControl module 39 zone information 141, 258
primary groups root user
selecting the default type 111 installation requirement 117
private groups mapping 172, 370
advantages 95, 163
container permissions 52
default option 138
defined 95, 162
selecting as primary 111
Index 413
S Unix
Setup Wizard authentication mechanisms 18
creating the Licenses container 107 available shells 111, 138
creating the Zones container 108 clock maintenance 38
permission requirements 50 credentials for basic services 35, 317
starting after install 105 DNS configuration 119
Single Sign-On domain controller selection 37
web applications 42 files and directories 119
Sun Solaris groups pending import 227 to 229
installing DirectControl manually 401 importing from common sources 223
removing DirectControl 127 installing DirectControl 116
system requirements 116 knowledge of 9
SuSE Linux local configuration files 225
installing DirectControl manually 400 man pages 285
removing DirectControl 127 managing from Windows 30
system requirements 116 manually importing accounts 226
naming convention 13
T new users 40
technical support 16 NIS servers and domains 224
troubleshooting restarting services 124
daemon operation 267 server licenses 214
enabling logging 270 system requirements 115
forest integrity 268 users pending import 229 to 231
using adinfo 273 Unix command line programs 284
Unix computers
U changing the zone 153
UID domain changes 156
minimum setting 379 joining a domain 145
new zone creation 109, 132 local configuration 159
next available 139 organizing in zones 144
preventing conflicts 88 reporting 158, 258
reserved values 109, 139 restricting who can join 147
response to conflicts 374 server and workstation licenses 214
starting value 109 web application access 152
universal groups 96, 164 web application hosting 214
Unix groups
duplicate information 269

Unix users W
duplicate information 269 Web applications
enabling in Active Directory 165 licensing 214
local account mapping 172 native authentication 42
migrating using zones 33 to 88 Windows
users checking system requirements 100
account mapping 172 integrating Unix computers 28
account status report 259 knowledge of 9
customizing access 364, 367, 379 reliance on Active Directory 19
default UID setting 109, 132 updating first 102
disconnected logins 171 workstation licenses 214
dynamic provisioning 90
group requirements 95, 162 Z
ignoring for import 230 zones
importing 177, 223 adding computers 140
local file import 225 to 226 available shells 111, 138
migrating using zones 33 to 88 changing default properties 137
NIS import 224 to 225 changing for a computer 153
password policies 169 checking integrity 268
pending import 229 to 231 closing 134
planning access 162 configuring the “default” zone 108
planning to import 223 container permissions 51
reporting 177, 258 controlling access with 34, 89 to 91
reserved UID values 139 creating additional 130 to 133
skeleton files 40 default GID setting 110, 132
default UID setting 109, 132
V delegated administration 92
VMware ESX delegating control 135
installing DirectControl manually 400 dynamic provisioning 90
removing DirectControl 127 home directory setting 110, 132
system requirements 116 importance of properties 130
managing properties 30
mapping multiple identities 87 to 88
migrating users 33 to 34, 89
Index 415
zones continued
opening 134
organizing principles 33
parent container 108
permission requirements 58
permissions assigned by delegation 55
policy management by 91 to 92
private groups 138
reports 141, 258
strategies for 85 to 92
understanding the use of 33

Centrify DC Admin Guide v3

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Centrify DC Admin Guide v3

Hochgeladen von

Copyright:

Verfügbare Formate

Centrify DirectControl

About this guide 9

Chapter 2 About the Centrify DirectControl architecture and operation 27

Chapter 3 Planning the deployment of Centrify DirectControl 49

Chapter 4 Installing Centrify DirectControl on Windows 99

Chapter 5 Installing the Centrify DirectControl Agent on Unix 115

Chapter 6 Managing zones 129

Chapter 8 Managing users and groups 161

Chapter 10 Managing licenses 213

Chapter 11 Importing information from NIS maps or Unix files 223

Chapter 13 Running reports 257

Chapter 14 Troubleshooting authentication and authorization 267

Appendix A Using Centrify DirectControl Unix commands 283

Appendix B Customizing Centrify DirectControl configuration options 323

Appendix C Installing an agent software package manually 399

Appendix D Setting the ports for Centrify DirectControl 405

CentrifyTM DirectControlTM delivers secure access control and

you may be able simplify or automate some tasks described in this

Getting a preview of what’s in this release

Using this guide

About this guide 11

an NIS domain or Unix configuration files into Active

specific release of the Centrify DirectControl Agent for Solaris

About this guide 13

Using online help

Where to go for more information

About this guide 15

This chapter provides an introduction to identity, access, and

Understanding identity and access management

Windows computers Active Directory forests

Users who have access to more than one application or computer

Why integrate with Active Directory?

What is the Centrify DirectControl solution?

With the Centrify DirectControl suite, organizations with diverse

Moving to a central directory

Streamline operations by standardizing on a single set of Active

Using Centrify DirectControl Zones for granular control

Extending single sign-on for web applications

Simplify compliance with regulatory requirements

Deploying without changes to existing infrastructure

to this base agent to provide services such as SSO for Web

What can you do after you deploy DirectControl?

About the Centrify DirectControl

Understanding the integration of Windows and Unix

On each server or workstation to be integrated into Active

Windows servers and workstations

Active Directory user Centrify DirectControl Agent

UNIX and Linux servers and workstations

Before you can centrally manage access across different platforms

Understanding DirectControl Management Tools

Chapter 2 • About the Centrify DirectControl architecture and operation 29

The documentation, release notes, and online help for

The Centrify DirectControl Administrative Templates

DirectControl DirectControl Property

Active Directory Domain Controller

About the Centrify DirectControl Administrator Console

You can use the Centrify DirectControl Administrator Console to:

Chapter 2 • About the Centrify DirectControl architecture and operation 31

Generate and view reports describing Unix users, groups,

About the Centrify Profile

Chapter 2 • About the Centrify DirectControl architecture and operation 33

with minimal advance planning or impact to your existing