Centrify Server Suite 2014

Transcription

1 Centrify Server Suite 2014 Administrator s Guide for Linux and UNIX June 2014 Centrify Corporation

2 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 Centrify Corporation. All rights reserved. Portions of Centrify software 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 (for Department of Defense (DOD) acquisitions) and 48 C.F.R and (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, DirectAudit, DirectControl and DirectSecure are registered trademarks and Centrify Server Suite, Centrify User Suite, DirectAuthorize and DirectManage are trademarks of Centrify Corporation in the United States and 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 other countries. Centrify software is protected by U.S. Patents 7,591,005, 8,024,360, and 8,321,523. 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.

3 Contents About this guide 9 Intended audience Conventions used in this guide Finding information about Centrify products Contacting Centrify Getting customer support Chapter 1 Introduction 11 Understanding identity and access management Why integrate with Active Directory? What is the Centrify solution? What does authorization provide? What can you do after you deploy? Chapter 2 Architecture and operation 19 Understanding the integration of Windows and UNIX Understanding what s installed on Windows Understanding Centrify UNIX agents Understanding the log-on process Understanding agentless authentication Chapter 3 Installing and starting Access Manager 29 Preparing for installation Installing Centrify software on Windows Starting DirectManage for the first time Installing the Centrify UNIX agent Chapter 4 Managing zones 34 Understanding Centrify zones Using the Access Manager Setup Wizard Creating a new parent zone Creating a child zone

4 Opening and closing zones Delegating control of administrative tasks Setting zone properties Renaming a zone Changing the master domain controller Adding a computer to a zone Changing the location of a zone in Active Directory Provisioning user and group profiles automatically Running reports for zones Searching for profiles in a domain Connect to a domain using Auto Zone Chapter 5 Migrating from classic to hierarchical zones 62 Planning migration from classic zones to hierarchical zones Upgrading to a 5.x version of Access Manager Creating a parent zone Delegating zone permissions Verifying that UNIX agents are running version 5.0 or newer Migrating users and groups, roles and rights, and NIS maps Moving joined computers to new hierarchical zones Deleting the old classic zones Cleaning up after migration Chapter 6 Managing computers 74 Understanding the join operation Deciding who can join computers to the domain Preparing computer accounts Joining a domain interactively or using a script Allowing password resets for computer accounts Designating a computer as a NIS server Changing the zone for the computer Changing the domain for a computer Leaving a domain Renaming a server Customizing configuration settings for a computer Administrator s Guide for Linux and UNIX 4

5 Running reports for computers Chapter 7 Importing existing users and groups 87 Determining the source for existing user information Preparing to import users and groups Using the Import from UNIX wizard Checking for conflicts and matching candidates Mapping UNIX profiles to Active Directory accounts Resolving conflicts for pending users and groups Resolving other issues for pending users and groups Making imported information available to NIS clients Chapter 8 Managing group profiles 100 Creating group profiles for Active Directory groups Managing Active Directory group membership Using Zone Provisioning Agent to provision zones Marking a group profile as required Adding groups from another trusted forest Modifying zone-specific settings for a group profile Modifying a group object s properties Customizing additional settings for groups Assigning groups to roles Running reports for groups Chapter 9 Managing user profiles 107 Understanding user profiles Adding Active Directory users to zones Using Zone Provisioning Agent to provision zones Adding users from another trusted forest Adding multiple profiles for a user to a zone Modifying zone-specific settings for a user profile Modifying the user profile and object properties Working with read-only domain controllers Applying password policies and changing passwords Working in disconnected mode Mapping local UNIX accounts to Active Directory Contents 5

6 Setting a local override account Customizing other settings for users Assigning users to roles Setting runtime variables Running reports for users Chapter 10 Authorizing users 132 Understanding authorization Defining specific rights Creating roles for job functions in a zone Creating a computer role Assigning users and groups to a role Working within assigned roles Exporting and importing rights and roles Modifying rights, roles, and role assignments Viewing rights and roles Migrating from sudo to dzdo Running reports for roles and rights Chapter 11 Managing license containers and keys 180 Understanding how licensing works Adding license containers Assigning a specific license container to a zone Viewing the license summary Adding license keys Removing a license key Running a report for licenses Chapter 12 Generating predefined and custom reports 188 Understanding the importance of reports Understanding the default report definitions Understanding current and snapshot results Generating a report from current or saved results Creating and modifying report definitions Exporting and importing report definitions Configuring SMTP for ing reports Administrator s Guide for Linux and UNIX 6

7 Using Centrify Deployment report Using the database loader and report command line utilities Chapter 13 Troubleshooting authentication and authorization 206 Understanding diagnostic tools and log files Analyzing information in Active Directory Configuring logging for agent Collecting diagnostic information Working with DNS, Active Directory, and Centrify software Understanding the Centrify DNS client Filtering the objects displayed Appendix A Using Centrify UNIX commands 228 Understanding when to use command-line programs Displaying usage information and man pages Understanding common result codes Using adjoin Using adleave Using adcheck Using adchzone Using adlicense Using adpasswd Using adupdate Using adquery Using adgpupdate Using adinfo Using addebug Using admigrate Using adobfuscate Using adrmlocal Using adfinddomain Using adfixid Using adflush Using adid Using adkeytab Contents 7

8 Using adsmb Using adsendaudittrailevent Using adsetgroups Using adclient Using adcache Using adreport Using adreload Using addbloader Using addns Using dzdo Using dzedit Using dzinfo Using dzsh Using nisflush Using OpenLDAP commands Appendix B Running managed computers in FIPS mode 379 Introduction to Centrify FIPS compliance Setting up the Windows environment Configuring the agent for FIPS mode Recovering from a FIPS-mode error Index 386 Administrator s Guide for Linux and UNIX 8

9 About this guide The Centrify Server Suite Administrator s Guide for Linux and UNIX describes how to use Centrify software to manage user and group profiles, role-based access rights, and delegated administrative activity for Linux and UNIX computers. This guide focuses exclusively on the management of identity attributes, rights, roles, role assignments, and privileges that apply to Linux and UNIX computers. If you manage a heterogeneous environment that includes Linux, UNIX, Mac OS X, and Windows computers, you should check for additional information in the other guides that make up the Centrify documentation set. Intended audience The Administrator s Guide for Linux and UNIX is intended for administrators who are responsible for managing user access to servers, workstations, enterprise applications, and network resources. This guide focuses on using the Centrify DirectManage Access software components to administer Centrify-managed UNIX and Linux computers, and on deploying the same authentication and policy services deployed you use for Windows computers. You can perform the same administrative tasks described in this guide using a variety of other tools, but you should know how to perform common administrative tasks on the operating systems you support. You should note that this guide does not cover deployment planning or installation details. For complete information about planning and installing Centrify software, see the Planning and Deployment Guide. 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 and Linux operating systems unless otherwise noted. 9

10 Finding information about Centrify products Finding information about Centrify products Centrify includes extensive documentation targeted for specific audiences, functional roles, or topics of interest. However, most of the information in the documentation set is intended for administrators, application developers, or security architects after you have purchased the software or licensed specific features. If you want to learn more about Centrify and Centrify products and features, start by visiting the Centrify website. From the Centrify website, you can download data sheets and evaluation software, view video demonstrations and technical presentations about Centrify products, and get the latest news about upcoming events and webinars. Contacting Centrify You can contact Centrify by visiting our website, On the website, you can find information about Centrify office locations worldwide, and phone numbers for contacting Centrify sales, and links for following Centrify on social media. If you have questions or comments, we look forward to hearing from you. Getting customer support If you have a Centrify account, click Support on the Centrify website to log on and access the Centrify Customer Support Portal. From the support portal, you can to search knowledge base articles, open and view support cases, connect with other Centrify users on customer forums, and access additional resources such as online training, how-to videos, and diagnostic tools. Administrator s Guide for Linux and UNIX 10

11 Chapter 1 Introduction This chapter provides an introduction to identity, access control, and configuration management and to the main components of Centrify Server Suite, including a brief overview of the ways Centrify software can help organizations leverage their investment in Active Directory. The following topics are covered: Understanding identity and access management Why integrate with Active Directory? What is the Centrify solution? What does authorization provide? What can you do after you deploy? 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 11

12 Why integrate with Active Directory? following figure suggests, there are many authentication mechanisms available for UNIX and Linux systems, but they are typically isolated from each other and managed separately. UNIX and Linux computers Local accounts stored in local files on individual UNIX servers and workstations NIS and NIS+ servers and account maps provide a central repository for UNIX accounts Kerberos realms and Key Distribution Center provide authentication for some users and services LDAP authentication for LDAP transactions 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 provides a way to centralize and simplify the management of user accounts and access to computers and applications through Active Directory. Why integrate with 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 workstations and servers, 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, UNIX, and Mac OS X computers, Centrify software provides administrators with a comprehensive identity and access management solution while reducing administrative complexity and overhead. Administrator s Guide for Linux and UNIX 12

13 What is the Centrify solution? What is the Centrify solution? As the previous section suggests, Centrify delivers secure access control and centralized identity management by integrating UNIX, Linux, and Mac OS X servers and workstations, and SAP, J2EE, and Web platforms with Microsoft Active Directory. Through the Centrify UNIX 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 UNIX agent to provide services such as single sign-on for Web applications and SAP, and Samba integration. The Centrify tools provide an Access Manager console, extensions for Active Directory Users and Computers, out-of-the-box reporting, and account migration tools. With Centrify software, 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 zones to provide secure, granular access control and delegated administration. Extend 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 Centrify software enables an organization 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 to simplify administrative training and in-house processes for account provisioning, maintenance, and other tasks. Chapter 1 Introduction 13

14 What is the Centrify solution? 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 group policy templates for computerand 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 make fewer Help Desk calls to reset passwords or update their account information. Using Centrify zones for granular control Centrify s patented zone technology delivers the granular access control that real-world enterprises need to securely manage heterogeneous environments. With Centrify zones, IT managers can: Segregate logical collections of UNIX, Linux, or Mac OS X computers into Centrify zones within Active Directory. Computers can be organized by any grouping that makes sense for a particular organization, including department, geography, function, and system type. 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. Use Centrify authorization features to grant users roles with the exact rights they need to access specific computers and accomplish the tasks associated with their job function. 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. A specific, powerful feature of zones is the ability to create a hierarchical structure of parent and child zones that enables rapid and dynamic provisioning of identify and access control. For example, you can define profile and access data at a higher level of the tree that is inherited by child zones at a lower level in the tree. At any level, including an individual computer, you are able to override profile data to fine-tune the identity of users on a joined computer. And at any level you can add access controls specific to that zone or computer that do not apply to computers joined to a zone at a higher level of the tree. Creating a zone hierarchy provides powerful features, such as the ability to: Rapidly provision a domain by adding users in a high level zone, then assigning access in a lower-level zone. Administrator s Guide for Linux and UNIX 14

15 What is the Centrify solution? Provide users with different identities for different computers by overriding their profiles in a child zone or at the computer level for example, by defining different shells or home directories for different types of computers to which they have access. Create roles in a global zone that can be used by multiple child zones. Extending single sign-on for web applications and SAP Centrify software provides Active Directory-based single sign-on for intranet and extranet applications running on SAP, Apache, and popular J2EE servers. These add-on modules for SAP, Apache, or J2EE provide: 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 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 software 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 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 enduser access to sensitive systems, and the Access Manager console and Centrify utilities and tools make 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 software enables IT managers to enforce consistent, enterprise-wide security policies in a manner that can be verified by auditors. By ensuring activity on UNIX, Linux, and Mac OS servers and workstations is written to the proper Active Directory logs, Centrify enables you to verify who has access to computers. Chapter 1 Introduction 15

16 What does authorization provide? Deploying without changes to existing infrastructure Centrify products support open standards and rely on a unified architecture that makes Centrify software easy to deploy without making any changes to your existing Active Directory or network infrastructure. Centrify Server Suite offers the following benefits: You do not need to install any software on any domain controllers, or make any changes to the Active Directory schema to store UNIX identity data. You can use any native or custom Active Directory schema, including the Microsoft Services for UNIX (SFU) schema extension, and the RFC 2307 Active Directory schema. You can map multiple UNIX identities to a given Active Directory account, and access this UNIX data in Active Directory using the tools of your choice, including ADSI or LDAP commands. You can rely on the core Centrify UNIX agent to deliver a single comprehensive solution for identity management, access control, and policy enforcement, with add-on modules to provide single sign-on services and integration. Centrify accelerates an organization s productivity by offering free downloads of open source tools such as OpenSSH and PuTTY, which have been modified to work seamlessly with Active Directory. What does authorization provide? The built-in authorization facility, also known as DirectAuthorize, centrally manages and enforces role-based entitlements for fine-grained control of user access and privileges on UNIX and Linux systems. By controlling how users access systems and what they can do on those computers, DirectAuthorize enables organizations to lock down sensitive systems and eliminate uncontrolled use of root accounts and passwords. With DirectAuthorize you can: Meet regulatory compliance requirements with a centralized, role-based model for finegrained delegation of administrative rights on UNIX and Linux systems. Secure your UNIX and Linux infrastructure by eliminating the need to share the passwords of root or super-user accounts with privileged access. Implement integrated authentication, authorization, and auditing, leveraging the same underlying architecture at a fraction of the cost of alternative solutions. Leverage your existing Active Directory infrastructure for role-based entitlement management without the need to deploy additional servers or infrastructure. Replace sudo or other complex, script-driven products with a modern, role-based solution that extends beyond controlling privileged commands. Administrator s Guide for Linux and UNIX 16

17 What can you do after you deploy? Deploy a highly available solution for privilege management that works well in a networked environment and does not require changes to your UNIX systems. Managed through the Access Manager console, and as part of an integrated suite of tools, DirectAuthorize provides a simple, scalable solution for managing the cross-platform environment. What can you do after you deploy? Once the Centrify UNIX agent is deployed on a server or workstation, that computer is considered a managed system. When a computer is managed by Centrify, an administrator with the proper permissions can perform the following common tasks: Discover the computers in your UNIX environment, then rapidly migrate existing accounts and access rights into Active Directory. Specify which Active Directory users and groups can log on to a specific UNIX computer or group of computers, and define the commands that each user is allowed to execute on those computers. Identify groups of dedicated servers and create computer roles that to define a set of roles that apply to these computers and the user group that executes tasks on them; for example, create a computer role for servers that host a database and apply roles for the DBA group that manages those servers. Control user access to UNIX computers across 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 service accounts or 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, authorized users can perform the following common tasks: Log on to the UNIX shell or desktop program and use standard 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. Chapter 1 Introduction 17

18 What can you do after you deploy? Manage their Active Directory passwords directly from the UNIX command line, provided they can connect to Active Directory. Administrator s Guide for Linux and UNIX 18

19 Chapter 2 Architecture and operation This chapter provides an overview of the Centrify software architecture and the basic flow of operation for a typical log-on session. For more detailed information about the architecture and the operations handled by different software components, see the Planning and Deployment Guide. The following topics are covered: Understanding the integration of Windows and UNIX Understanding what s installed on Windows Understanding Centrify UNIX agents Understanding the log-on process Understanding agentless authentication Understanding the integration of Windows and UNIX Because Centrify Server Suite provides an integration layer between Windows and other operating environments, it consists of the following primary components: On Windows, the Centrify DirectManage Access Manager console and property extensions enable you to add and manage UNIX-specific properties in Active Directory. On Windows, the DirectManage tools enable you to discover the computers in your UNIX environment that are available to be managed by Centrify software, and to rapidly migrate existing accounts and access rights from these computers into Active Directory. On non-windows computers, the Centrify UNIX agent enables the local host computer to join an Active Directory domain. Once the Centrify UNIX agent is deployed on a server or workstation, that computer is considered a managed system and it can join any Active Directory domain you choose. When a managed system joins an Active Directory domain, it essentially becomes an Active Directory client and relies on Active Directory to provide authentication, authorization, policy management, and directory services. The interaction between the Centrify UNIX agent on the local computer and Active Directory is similar to the interaction between a Windows client computer and its Active Directory domain controller, including failover to a backup domain controller if the UNIX computer is unable to connect to its primary domain controller. 19

20 Understanding what s installed on Windows The following figure provides a simplified view of the integration between Active Directory and UNIX through Centrify software. Centrify Utilities and Tools ADUC property extensions Centrify DirectManage Access Manager console Windows servers and workstations Active Directory user Centrify UNIX agent Package Account: chris UNIX, Linux, and Mac OS X servers and workstations To centrally manage access across different platforms using Microsoft Active Directory, you need to: Prepare the Active Directory environment by installing the Centrify DirectManage Access Manager console and utilities and tools on at least one Windows computer to update the Active Directory forest with Centrify properties. Ensure each UNIX, Linux, or Mac OS X computer can communicate with an Active Directory domain controller to present valid credentials for authentication. For successful communication, the managed computer should be able to resolve the address of its Active Directory domain controller through DNS. Install the Centrify UNIX agent (adclient) on the UNIX, Linux, or Mac OS X computers that will be joining an Active Directory domain. Run the join command and specify the Active Directory domain to join on each UNIX, Linux, or Mac OS X computers to be managed. Use Active Directory Users and Computers or the Access Manager console to authorize access to the UNIX, Linux, and Mac OS X computers for specific users and groups. Now that you are familiar with the basics, the next sections provide a closer look at what s included with Centrify Server Suite, including the Centrify utilities and tools installed on Windows, and the Centrify UNIX agent installed on other platforms. Understanding what s installed on Windows When you install Centrify DirectManage on a Windows computer, you can choose which components you want to install. After you start the setup program, the Setup Wizard lists Administrator s Guide for Linux and UNIX 20

21 Understanding what s installed on Windows the components available. Most of the components are optional and can be installed either together or separately. Choosing a console for managing Centrify properties From the main Centrify DirectManage Access setup program, you can choose the method you want to use for managing Centrify properties. You do this by selecting one or both of the following components: The ADUC property page extension for Active Directory can be installed on any computer that is joined to an Active Directory domain and has Active Directory Users and Computers installed. The property extension allows you to use Active Directory Users and Computers to store UNIX-specific attributes. You are not required to install the property extension if you do not intend to use Active Directory Users and Computers to view or manage UNIX-specific attributes. The Access Manager console must be installed on at least one computer that can access domains in Active Directory. The Access Manager 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 Access Manager console includes a Setup Wizard that updates the Active Directory forest to include Centrify properties the first time you start the console. The update to the Active Directory forest does not make any changes to the underlying Active Directory schema you have installed. Note Some optional components require the Access Manager console to be installed on the same computer. For example, the Extension for NIS Maps can only be installed on a computer where you install the Access Manager console. For more information about installing optional components, see Choosing optional DirectManage Access components on page 21. The Access Manager console is a Microsoft Management Console (MMC) snap-in and is the primary tool for managing Centrify-specific information stored in Active Directory. It provides access to a full spectrum of management activities including the ability to manage UNIX, Linux, Mac OS X, and Windows computers, set and modify user and group properties, create and manage zones, and add Active Directory users and groups to zones. In addition, you can install the DirectManage DeploymentManager console, which enables you to find computers in your UNIX environment, evaluate their readiness for management by Centrify, install the Centrify UNIX agent, and rapidly import user accounts into Active Directory. Choosing optional DirectManage Access components From the setup program, you can also choose to install the following optional components: Chapter 2 Architecture and operation 21

22 Understanding what s installed on Windows The NIS Map extension can be installed on any computer where you install the Access Manager console if you want to import and manage NIS maps for network information, such as netgroup and auto.master, in Active Directory. The extension is not required for importing users and groups. The Documentation and DirectManage Help for the Access Manager console can be installed on any Windows computer and are installed by default on the computer where you install the Access Manager console. The Group Policy Management Editor Extension can be installed on any computer where the Group Policy Object Editor is available if you want to apply Centrify group policies to a site, domain, or organizational unit that includes Centrifymanaged computers or users. The DirectManage Access Utilities include the following: DirectManage DeploymentManager console enables you to find computers in your UNIX environment, evaluate their readiness for management, install the Centrify UNIX agent, and rapidly import user accounts into Active Directory. Centrify Zone Provisioning Agent can be installed on any computer where you install the Direct Manage Access Console. The Zone Provisioning Agent automates the process of adding users to new zones by linking AD groups to Centrify zones. Password Synchronization extension installs the Password Synchronization service. Centrify (Kerberized) PuTTY installs Centrify PuTTy, a terminal emulator that is optimized to work with Centrify software and Active Directory. The following figure provides a simplified view of the architecture. Windows environment UNIX environment Centrify Utilities and Tools DirectManage Access Manager console DirectManage Access Property Extensions Centrify UNIX agents adclient Active Directory Users and Computers adclient Active Directory Domain Controller adclient Administrator s Guide for Linux and UNIX 22

23 Understanding Centrify UNIX agents Understanding Centrify UNIX agents The Centrify UNIX agent makes a UNIX, Linux, or Mac OS X computer look and behave like a Windows client computer to Active Directory. The Centrify UNIX agent performs the following key tasks: Joins the UNIX, Linux, or Mac OS X computer to an Active Directory domain. Communicates with Active Directory to authenticate users when they log on and caches credentials for offline access. Enforces Active Directory authentication and password policies. Extends Active Directory group policies to manage configuration settings for UNIX users and computers. Provides a Kerberos environment so that existing Kerberos applications work transparently with Active Directory. Although the individual agents you install are platform-specific, the Centrify UNIX agent is a tightly integrated suite of services that work together to ensure seamless operation between existing UNIX programs and applications and Active Directory authentication, authorization, and directory service. The following figure provides a closer look at the services provided through the Centrify UNIX agent: Core services for UNIX shell programs and applications PAM module NSS module Kerberos-enabled applications Kerberos environment Other addon modules: Apache JAAS realm SPNEGO NIS Centrify adclient Service Library Centrify adclient Command line programs Active Directory Domain Controller Centrify UNIX agent Cached credentials and search results As this figure suggests, the Centrify UNIX agent includes the following core components: The core Centrify UNIX agent is the adclient process that handles all of the direct communication with Active Directory. The agent contacts Active Directory when there are requests for authentication, authorization, directory assistance, or policy updates then passes valid credentials or other requested information along to the programs or applications that need this information. Chapter 2 Architecture and operation 23

24 Understanding the log-on process The Centrify Pluggable Authentication Module (PAM), pam_centrifydc, enables any PAM-enabled program, such as ftpd, telnetd, login, and sshd, to authenticate using Active Directory. The Centrify NSS module is added to the nsswitch.conf so that system look-up requests use the Centrify UNIX agent to look up and validate information using Active Directory through LDAP. The Centrify command line programs (CLI) enable you to perform common administrative tasks, such as join and leave the Active Directory domain or change user passwords for Active Directory accounts from the UNIX command prompt. These command line programs can be used interactively or in scripts to automate tasks. The Centrify Kerberos environment generates a Kerberos configuration file (etc/ krb5.conf) and a default key table (krb5.keytab) to enable your Kerberos-enabled applications to authenticate through Active Directory. These files are maintained by the Centrify UNIX agent and are updated to reflect any changes in the Active Directory forest configuration. The Centrify local cache stores user credentials and other information for offline access and network efficiency. In addition to these core components, the Centrify UNIX agent can also be extended with the following add-on modules: The Centrify libraries for Apache, Tomcat, JBoss, WebLogic, or WebSphere 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 libraries for SAP plug in to the native authentication mechanisms for each SAP server to enable you to configure SAP applications to use Active Directory for authentication. The Centrify Network Information Service (adnisd) is a separate service that works in conjunction with the Centrify UNIX agent to enable you to store NIS maps in Active Directory and publish that information to NIS clients through the Centrify agent. Optional utilities and programs, such as updated Kerberos, OpenSSH, Samba, or PuTTY utilities, that have been optimized to work with Centrify software and Active Directory. Understanding the log-on process The core Centrify UNIX 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 for UNIX commands that need to get information about the current user or group. Administrator s Guide for Linux and UNIX 24

25 Understanding the log-on process Note The following steps focus on the operation of the Centrify UNIX agent rather than the interaction between the Centrify UNIX agent and Active Directory. In addition, these steps are intended to provide a general understanding of the operations performed through the Centrify UNIX agent and do not provide a detailed analysis of a typical log-on session. When a user starts the UNIX computer, the following takes place: 1 A login process starts and prompts the user to supply a user name. 2 The user responds by entering a valid local or Active Directory user name. 3 The login process, which is a PAM-enabled program, then reads the PAM configuration file, /etc/pam.conf, and determines that it should use the Centrify PAM service, pam_centrifydc, for identification. The UNIX login process then passes the log-in request and the user name to the Centrify Pluggable Authentication Module (PAM) service for processing. 4 The PAM service checks parameters in the centrifydc.conf 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 service passes the log-in request to the next PAM module in the PAM configuration file, for example, to the local configuration file /etc/passwd. If the user is not set to be authenticated locally, the PAM service checks to see if the Centrify UNIX agent process, adclient, is running. If it is, the PAM service passes the log-in request and user name to adclient for processing. 5 The adclient process connects to Active Directory and queries the Active Directory domain controller to determine whether the user name included in the request is a Centrify user who has access to computers in the current computer s zone. If adclient is unable to connect to Active Directory, it queries the local cache to determine whether the user name has been successfully authenticated before. If adclient can connect to Active Directory but the user account does not have access to computers in the current zone or if the user can t be found in Active Directory or the local cache, adclient checks the centrifydc.conf configuration file to see if the user name is mapped to a different Active Directory user account. If the user name is mapped to another Active Directory account in the configuration file, adclient 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, adclient 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. Chapter 2 Architecture and operation 25

26 Understanding the log-on process 7 The adclient process checks the Centrify zone s authorization store to determine whether the system right for password login is enabled. If so, adclient goes to the next step to query NSS. 8 The adclient process queries through the NSS service to determine whether there are any users logged in with same UID. If there are no conflicts, the log-in request continues and adclient passes the request to the PAM service to have the UNIX login process prompt for a password. 9 The UNIX login process prompts the user to provide a password and returns the password to the PAM service. 10 The PAM service checks the Centrify authorization store to verify that the user has access to the PAM login application. 11 If the current user account is not prevented from logging on by lack of a PAM-access right, the PAM service queries adclient to see if the user is authorized to log on. 12 The adclient process 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 process receives the results of its authorization request from Active Directory and passes the reply to the PAM service. If the user is not authorized to use the current computer or to log in at the current time, the PAM service denies the user s request to log on through the UNIX login process. If the user s password has expired, the PAM 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 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 the agent, the PAM service creates a new home directory on the computer in the location specified in the centrifydc.conf configuration file by the parameter pam.homeskel.dir. Administrator s Guide for Linux and UNIX 26

27 Understanding agentless authentication The following figure provides a simplified view of a typical log-on process when using Centrify software. PAM-enabled services Check /etc/pam.conf pam_centrifydc Check /etc/centrifydc.conf settings for override, allow, deny, password expiration xxxxx xxxxx xxxxx Active Directory Domain Controller User starts a UNIX log on process using a command such as login, telnet, ssh Kerberos applications UNIX look-up requests nss_centrifydc Check /etc/nsswitch.conf adclient Cached credentials and search results Centrify Agent Kerberos keytab and configuration file Understanding agentless authentication The previous section described a typical log-on session for a Centrify-managed computer where the Centrify UNIX agent is installed. For computers and devices where you cannot install a Centrify UNIX agent, you may still be able to provide Active Directory authentication by using the Centrify Network Information Service (adnisd). The Centrify Network Information Service provides agentless authentication from Active Directory for computers that have older or unsupported operating systems but that can be, or already are, configured as NIS clients. The following figure provides a simplified view of this environment. Computers with older, unsupported operating systems ( agentless systems) NIS client request submitted to the NIS listening port adnisd adclient Active Directory Domain Controller Zone: ConsumerDivision Centrify-managed system Local cache xxxxx xxxxx xxxxx NIS maps generated from information in Active Directory and served by adnisd in response to NIS client requests Chapter 2 Architecture and operation 27

28 Understanding agentless authentication In this scenario, the Centrify zone acts as the NIS domain for a group of computers or devices that are configured as NIS clients. Those clients submit requests to the Centrify Network Information Service, adnisd, listening on the NIS port. The Centrify Network Information Service periodically contacts the Centrify UNIX agent, adclient, to get updated information from Active Directory and generates a set of maps that it stores locally. The Centrify Network Information Service can then use the information in these maps to respond to NIS client requests for authentication or other services. Administrator s Guide for Linux and UNIX 28

29 Chapter 3 Installing and starting Access Manager This chapter provides a brief summary of the steps for installing Centrify software on Windows and UNIX computers and starting Access Manager for the first time. For more information about preparing for deployment and installing Centrify software, see the Planning and Deployment Guide. The following topics are covered: Preparing for installation Installing Centrify software on Windows Starting DirectManage for the first time Installing the Centrify UNIX agent Preparing for installation Before installing Centrify software: 1 Verify that you have Active Directory installed and have access to at least one Windows computer acting as a domain controller. 2 Verify that the domain controller or another computer you can access is the primary DNS server. 3 Check whether the Windows computer where you intend to install Access Manager has Active Directory Users and Computers installed. You can perform many administrative tasks for Linux and UNIX computers and users using Active Directory Users and Computers instead of Access Manager, if you choose to do so. 4 Verify that you have root level access for installing the Centrify UNIX agent on non-windows computers. 5 Verify that you have an Active Directory account with sufficient rights to add containers and objects to the Active Directory domain. 6 Verify that all of the computers where you are planning to install Centrify software meet the basic system requirements. For more information about using this program, see the Planning and Deployment Guide. 29

30 Installing Centrify software on Windows Installing Centrify software on Windows To install the Centrify Server Suite on Windows: 1 Log in to the Windows computer and locate the Centrify software package for the Windows 32-bit or Windows 64-bit architecture. 2 Open the autorun.exe file to display the suite installer Getting Started page if it is not displayed automatically. 3 On the Getting Started page, click Access to start the setup program for DirectManage Access components. If any programs must be updated before installing, the setup program displays the updates required and allows you to install them. After updates are complete, you can restart the setup program. 4 At the Welcome page, click Next. 5 Review the terms of the license agreement, click I agree to these terms, then click Next. 6 Type your name and organization, then click Next. 7 Expand and select the DirectManage Access - Administration components you want to install, then click Next. You can choose to install components separately on different computers or at a later time, if needed. At a minimum, you should install ADUC property page extensions and Access Manager. 8 Accept the default location for installing DirectManage Access components, or click Browse to select a different location, then click Next. 9 Specify whether you want to disable the publisher verification, then click Next. Selecting this option skips the verification to provide better startup performance. Deselect this option to force verification when applications are started. 10 Review the components you have selected, then click Next. 11 When setup is complete, click Finish to close the setup program. Starting DirectManage for the first time When you start the Access Manager console for the first time, the Setup Wizard is displayed to configure the Active Directory forest and set the default properties for your first Centrify Zone. To start the Setup Wizard and update the Active Directory forest: Administrator s Guide for Linux and UNIX 30

31 Starting DirectManage for the first time 1 Log onto the computer where you installed the Access Manager console and click Start > All Programs > Centrify Server Suite version > Access > Access Manager. 2 Verify the name of the domain controller displayed is a member of the Active Directory forest you want to update or type the name of a different domain controller if you want to connect to a different forest, then click OK. 3 At the Welcome page, click Next. 4 Select Use currently connected user credentials to use your current log on account or select Specify alternate user credentials and type a user name and password, then click Next. 5 Select a location for installing license keys in Active Directory, then click Next. The default container for license keys is domain_name/program Data/Centrify/ Licenses. To create or select a container object in a different location, select Change default zone container and click Browse. You can also add other License containers in other locations later using the Manage Licenses dialog box. 6 Review the permission requirements for the container, then click Yes to confirm your selection. 7 Type the license key you received, then click Add or click Import to import the keys directly from a file, then click Next. 8 Select Create default zone container and specify a location for the Zones container, then click Next. The default container location for zones is domain_name/program Data/Centrify/ Zones. Any zones you create are placed in this container location by default. You can create a new container object or select an existing container object. 9 Check the Grant computer accounts in the Computers container permission to update their own account information option to give each UNIX computer account permission to manage its own account password, then click Next. 10 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. 11 Select Activate Centrify Corporation profile property pages if you want to be able to display the properties in Centrify profiles in any Active Directory context, then click Next. This setting is not required to display the Centrify property pages when using Active Directory Users and Computers or the Access Manager console. If you only need to access Centrify properties from Active Directory Users and Computers or the Access Manager console, leave this option unchecked and click Next. Chapter 3 Installing and starting Access Manager 31

32 Installing the Centrify UNIX agent 12 Review and confirm your configuration settings, click Next, then click Finish. For information about modifying zone properties after configuring the first zone, see Setting zone properties on page 44. Installing the Centrify UNIX agent Depending on your environment, you may have several options for installing the Centrify UNIX agent. The instructions summarized here assume you are using the standard agent installation script, install.sh. For information about the other options available or more detailed information about any step, see the Planning and Deployment Guide. To install the Centrify UNIX agent on a computer 1 Download the Centrify software package for your target platform from the Centrify Customer Support Portal Customer Download Center. 2 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 You are not required to log on as the root user on Mac OS X computers, but you must know the password for the Administrator account to complete the installation. 3 Copy the tgz (or dmg) file to a directory on your UNIX computer and unzip the file and then unpack the archive file. 4 Run the install.sh script to install the Centrify agent package on the computer. For example, on a Red Hat Enterprise Linux computer you would enter the following /bin/sh./install.sh The script runs the Centrify adcheck command and then prompts you to select the following tasks: Run adcheck: At this point in the procedure, adcheck has already run. Run it again if you select to join a domain (see next prompt) to see if your join was successful. Join an Active Directory domain: Join the domain if you have the organizational unit, containers, and zone already set up on the domain controller for this computer. Otherwise, do not join at this time. The script then prompts you to select the services you want to install. In the enterprise edition, the follow services are installed by default: CentrifyDC: the agent, tools (adinfo, adquery, etc.) and configuration files (for example, centrifydc.conf) CentrifyDC-openssh: a Centrify-compiled version of the openssh program. Centrify DirectAudit If you are installing the standard edition, DirectAudit is not an option. Administrator s Guide for Linux and UNIX 32

33 Installing the Centrify UNIX agent Optionally, you can select the CentrifyDC-nis. If you want a different configuration, respond N to the prompt Do you want to continue (Y) or re-enter information? (Q Y N) Note These instructions describe use of the install.sh script in interactive mode. The script also offers command line options that let you run it in non-interactive mode. In addition, there are other options available only in non-interactive mode. Enter /bin/sh./install.sh -h to display the options. Joining an Active Directory domain If you do not join the domain when you run the installation script, you can do so manually using the adjoin command on any computer where the Centrify UNIX agent is installed or by selecting Applications > Utilities > Directory Access and configuring the adclient service on Mac OS X computers. For more information about running adjoin, see Using adjoin on page 233 or the adjoin man page. For information about configuring the adclient service on Mac OS X computers, see the Mac-specific information in the Administrator s Guide for Mac OS X. Restarting UNIX services after joining the domain You may need to restart some services on UNIX computers where you have installed the Centrify UNIX agent so that those services will reread the name switch configuration file. 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 Corporation recommends you reboot each system to ensure all of the applications and services on the system read the Centrify configuration changes at your earliest convenience. Chapter 3 Installing and starting Access Manager 33

34 Chapter 4 Managing zones Zones are the key component for organizing identity attributes, access rights and role assignments, and delegated administrative activity for Linux and UNIX computers. This chapter describes how to use Access Manager to create zones and manage zone properties and explains the advantages of using hierarchical zones. It also shows how to manage without zones by using Auto Zone. The following topics are covered: Understanding Centrify zones Using the Access Manager Setup Wizard Creating a new parent zone Creating a child zone Opening and closing zones Delegating control of administrative tasks Setting zone properties Renaming a zone Changing the master domain controller Adding a computer to a zone Changing the location of a zone in Active Directory Provisioning user and group profiles automatically Running reports for zones Searching for profiles in a domain Connect to a domain using Auto Zone For more detailed information about zone types, different strategies for using zones, and planning the migration of existing users and groups to zones, see the Planning and Deployment Guide. Understanding Centrify zones A Centrify zone is similar to an Active Directory organizational unit (OU) or Network Information Service (NIS) domain. Zones allow you to organize the computers in your organization in meaningful ways to simplify account and access management and the migration of information from existing sources to Active Directory. 34

35 Understanding Centrify zones How you use zones, depends primarily on the needs of your organization. In some organizations, a single zone is sufficient. In other organizations, using multiple zones might be a necessity. Although using multiple zones can provide flexibility for managing user accounts and computer access, you are not required to do so. Creating a single zone, or for that matter, multiple zones, can be done simply through the Administrator s Console or by using ADEdit. You only need to be concerned with planning and populating additional zones if multiple zones would be useful for your organization. You can then create the additional Centrify zones as you need them. On the other hand, you may choose to define no zones at all by connecting to a domain through Auto Zone. With Auto Zone, every Active Directory user and group defined in the forest, as well as any users defined in a two-way trusted forest are valid users or groups for the joined computer. Understanding identity and access in hierarchical zones Centrify supports the creation of a hierarchical zone structure of parent and child zones that allows for the inheritance of data from the top to the bottom of the tree. This section explains how you can use this hierarchical structure to maintain identity and control access to a UNIX environment through Active Directory, but it begins from the perspective of a single, self-contained zone, then expands to include how user management works in a hierarchical structure. After you create a zone you can add any of your AD users to it and define their identity in UNIX for any computer that joins the zone. To define an AD user s UNIX identity, you create an NSS profile that contains the same data as the /etc/passwd file on a UNIX computer: login name, UID, primary group, etc. In addition, you can control access to computers in a zone by assigning roles to AD users, either individually or through AD groups. In fact, you must assign roles to users for them to have access to Centrify-managed computers. A user with an identity, and a role assignment in a zone, is considered an effective user for that zone. Users with an identity but without a role, have no access to a managed computer. The ability to define identity separately from access is one of the key features provided by hierarchical zones. Its utility is not immediately obvious in a flat zone structure, but as you will see, it is a powerful feature in a tree structure. Hierarchical zones In a hierarchical-zone structure, identity and access are determined in much the same way as for a single zone, except the zone tree determines who users are and what access they have. When a computer joins a domain, the profile and access settings (role assignments) in effect for the zone determine who can access the computer and their identities on the computer. In a zone hierarchy, the profiles and access definitions may be defined in the Chapter 4 Managing zones 35

36 Understanding Centrify zones zone, inherited from a parent zone, or defined specifically for the joined computer, and it is all of these together that determine a user s profile and access. Note In a zone hierarchy, in addition to parent zones and child zones, you have to take into account the actual joined computers. If you think in terms of nodes, a parent node can have child nodes, a child node has a parent and may have a child node or may be a leaf node (at the bottom of the tree), while a computer node is always a leaf node. Inheritance of identity information Of course, the most prominent feature of a hierarchical zone structure is inheritance. Both identity and access control flow down the hierarchy, from parent to child to leaf nodes though how inheritance works is different for identity and access. For identity, the salient points are: Profile data can be defined at any level, parent, child, or computer. It is possible to define a partial profile at any level, that is leave one or more of the NSS fields blank. A complete profile is required to have access to a computer, but a profile in a child zone can complete the missing fields from the parent zone. Profiles are inherited down the tree but profile definitions in a child zone override the definition in the parent zone, and computer-level definitions override both the joined zone and any parent definitions. Computer-level profile definitions are also known as computer-level overrides. From this viewpoint, when considering which users have an identity for a particular zone or joined computer, it makes sense to talk about the profile tree, rather than about the users or profiles defined in the zone.` Practically, this scheme solves some of the classic problems of managing a heterogenous UNIX environment, such as creating a unified name space. For example, in a typical UNIX environment, the same user may have different UIDs on different computers. You can address this problem by defining a user profile for a zone while overriding just the UID field in the profile for that user on one or more specific computers that have joined the zone. Another practical application is to override home directory and shell defaults on specific computers, for example, on a Mac OS X computer, you can specify the home directory as / User rather than /home, or you could specify a shell such as /bin/bash for a zone, but override it with /usr/bin/ksh on an AIX computer that joins the zone. Inheritance of access Access data is also inherited, and role assignments can be made at each level of the hierarchy. However, role assignments do not override each other. Rather they accumulate, such that a user s potential rights include all the rights granted by all the role assignments in the access tree. The reason these are potential rights is that rights granted to a user by a role assignment are only effective if the user has a complete profile defined for a zone. Administrator s Guide for Linux and UNIX 36

37 Using the Access Manager Setup Wizard In other words, when a computer joins a zone, the profile tree determines a pool of potential users, and the access tree determines a different set of users with rights, and where the two intersect is the set of effective users. In practice, defining access and inheritance separately allows quick and easy provisioning of a UNIX environment. For example, one approach is to add your entire store of AD users to a parent zone. Then, in child zones, make role assignments to specific users. The parent zone functions as a pool of users and the child zones define the functions that users. On the other hand, you can identify the user accounts you want to assign to particular roles and actually make the role assignments, for example by assigning a role to an AD group. However, until you create profiles for users in the group, the role assignments confer potential rights only. How to use zones Although it is recommended that you use zones in a hierarchical structure (see the Planning and Deployment Guide for detailed instructions about creating a hierarchical zone structure for your UNIX environment) creating one or more hierarchical zones does not mean that you must create a hierarchical structure, it simply means that you may do so if it makes sense for your organization. You are still free to create a single zone, or multiple zones in a flat structure. On the other hand, for new zones, it is recommended that you always create a hierarchical zone, not a classic zone, unless you are trying to maintain compatibility with an environment that contains zones created by a previous version of Centrify software. For example, if you are running a previous version of the Centrify UNIX agent that does not support hierarchical zones, you would need to create classic zones. Otherwise, even if you do not intend to create a zone hierarchy, hierarchical zones are the best choice because they provide many features not available in a classic zone. This chapter explains how to create and manage zones but keep in mind that most of the impact of using hierarchical zones occurs in user identity (see Chapter 9, Managing user profiles) and user access (see Chapter 10, Authorizing users). Those chapters explain in great detail how to manage user identities and access in a multi-layered zone structure. Note Centrify Server Suite provides other ways of modeling the functioning of your UNIX environment. For example, computer roles allow you to link a group of users and role assignments to a dedicated group of computers, such as those hosting a database. Using the Access Manager Setup Wizard The DirectManage Access Manager Setup Wizard starts automatically the first time you start the Access Manager console. In most cases, the only time you need to run the Setup Wizard is to perform this initial configuration of the Active Directory forest. You can, however, use the Setup Wizard after the initial configuration if you want to change your Chapter 4 Managing zones 37

38 Creating a new parent zone configuration. For example, if you want to change the location of the default container object for new zones, you can re-run the Setup Wizard to make this change. When you re-run the Setup Wizard, the steps you see depend on the specific steps you took during the initial configuration of Direct Manage Access Manager. Follow the instructions displayed to make changes to the Access Manager environment. Creating a new parent zone You can use the Create New Zone wizard to create as many zones as you need. You can create the zones in the default Zones container object or in other containers or organizational units within Active Directory. To create new zones, however, you must be a domain administrator or have the permissions described in the Planning and Deployment Guide. 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. Unless you join to the domain through Auto Zone (see Connect to a domain using Auto Zone on page 56), you must create at least one new zone before you begin adding computers to the Active Directory domain. For more information about configuring zone properties for an existing zone, see Setting zone properties on page 44. To create a new Centrify zone: 1 Open Access Manager. 2 Select Zones and right-click, then click Create New Zone. 3 Type the zone name and, optionally, a longer description of the zone. In most cases, you can use the default parent container and container type, and the default zone type, which creates the new zone as a hierarchical zone, then click Next. Administrator s Guide for Linux and UNIX 38

39 Creating a new parent zone For additional details about any of the zone fields, press F1 to view context-sensitive help. For this Zone name Container Object type Description Use default zone type Do this Type a name for the zone. The zone name can start with any alphanumeric character or an underscore character (_), followed by any combination of alphabetic, numeric, underscore (_), hyphen (-), or period (.) characters up to a maximum length of 64 characters. For example: paris1.france-tgv.org Specify the parent container for this zone. By default, the parent location is the container you specified in the Setup Wizard. If you want to select a different location for this zone, click Browse and navigate to the container or organizational unit you want to use as the parent for this zone. If you are not using the default parent container, you can click Create to create a new container or organizational unit or select an existing container or organizational unit, then click OK. Note In selecting a location for a zone, you can use any Active Directory parent container or organizational unit. However, you should never put any Active Directory objects, such as user or computer objects into zone containers. For more information about planning how to add Centrify objects to Active Directory, see the Planning and Deployment Guide. Select Container or Organizational Unit to specify whether the zone should be created as a container object or an organizational unit object. If the parent container for the zone is a generic container object, the zone must be created as a container object. If the parent container is an organizational unit, the zone must be created as organizational unit. You cannot apply Group Policy Objects to generic container objects. Type a description of the zone. You can use the description to provide more detailed information about how computers are grouped. For example, if you are grouping computers by location, you might want to use the location in the zone description. If you are organizing computers by department, you may want to specify the department in the description. Select this option to create the new zone as a standard Centrify hierarchical zone. You should only deselect this option if you want to create a classic zone for backwards compatibility or are using the Microsoft Services for UNIX (SFU) schema. 4 Review the information about the zone you are creating, then click Finish. When you click Finish, the zone is created in the specified location with a set of default values for adding new users and groups to the zone. After creating a zone, and before adding any users, you should review the default zone properties and modify them as needed to suit your environment. For more information about modifying zone properties, see Setting zone properties on page 44. Chapter 4 Managing zones 39

40 Creating a child zone Creating a child zone Most zone properties are not inherited from a parent zone. When you create a new child zone, its properties are set to the same default values as a new global zone. The reason for this is that when users are added to a parent zone, they automatically inherit the identical profile in any of the zone s child zones. Therefore, since the main reason to add a user who is already defined in a parent zone, to a child zone, is to change the profile by overriding one of the profile fields, it makes sense to define separate user and group defaults for parent and child zones. To create a child zone 1 Open Access Manager. 2 Expand Zones, expand the zone hierarchy as far as necessary to select the zone that will be the parent of the new zone. 3 Right-click, then click Create Child Zone. 4 Type the zone name and, optionally, a longer description of the zone, then click Next. Because you are creating a child zone, you should leave the default parent container and container type, and the default zone type. For additional details about any of the zone fields, press F1 to view context-sensitive help. 5 Review the information about the zone you are creating, then click Finish. After creating a child zone, you can change its properties at any time. For more information about modifying zone properties, see Setting zone properties on page 44. Moving a child zone In the Console, you can make an existing zone a child of another zone by dragging and dropping or by changing the Parent zone field on the zone s Properties > General tab. When you use the Console to make an existing zone a child of another zone, the zone is not moved automatically to the new parent container object in Active Directory. Instead, at the end of the move operation you are prompted to specify whether to move the zone to a new Active Directory container or leave it in its original location. If you choose to move the zone to a new container, you are prompted to select the destination container (typically the parent container). If you choose to leave the child zone in its original location in Active Directory, you can move it later using ADSI Edit as described in Changing the location of a zone in Active Directory on page 50. Notes If you move zones in the Console but not in Active Directory, use extreme caution if you use the Console to delete a zone at a later time. When you delete a zone in the Console, Administrator s Guide for Linux and UNIX 40

41 Creating a child zone its Active Directory zone container and all of its child zone containers are deleted. If the depiction of zones in the Console does not match the zone container structure, it might not be obvious that the zone you deleting in the Console is actually a parent zone. It is important to thoroughly plan your zone structure early in the design process so you will not need to make major structural changes later on. However, during the planning and prototype phase of a deployment, you might want to move or nest zones. This feature provides the ability to do so. If a child zone inherits role assignments from its parent zone, the Console will display a warning message and prevent you from moving the zone until you have removed the role assignments. If moving the zone creates a circular hierarchy, the Console will prevent you from moving the zone. To move a child zone to a new parent by dragging and dropping 1 Open the Access Manager Console. 2 In the console tree, select Zones and expand the hierarchy to see the zone you want to move. 3 Select the zone, then drag it to the new parent zone and drop it. 4 In the Move Zone dialog, specify whether to move the zone to a new location (that is, to a different zone container object) in Active Directory. To move the zone to a different zone container object, select Yes, move to: location. The parent zone container object is specified by default. Accept the default location, or browse to a different location. Click OK. To keep the zone container in its original location, select No and click OK. To move a child zone to a new parent by changing properties 1 Open the Access Manager Console. 2 In the console tree, select Zones and expand the hierarchy to see the zone you want to move. Select the zone, right-click and select Properties. 3 On the General tab, in the Parent zone field click Browse to find and select the zone to use as the parent. 4 Click OK, and OK again to save the new zone properties. 5 In the Move Zone dialog, specify whether to move the zone to a new location (that is, to a different zone container object) in Active Directory. To move the zone to a different zone container object, select Yes, move to: location. The parent zone container object is specified by default. Accept the default location, or browse to a different location. Click OK. To keep the zone container in its original location, select No and click OK. Chapter 4 Managing zones 41

42 Opening and closing zones Opening and closing zones 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 explicitly 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: 1 Open the Access Manager Console. 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 Access Manager Console, so that the open zones are displayed by default the next time you start the console. When you save your console settings, the next time you start the Access Manager 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. Delegating control of administrative tasks You can 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. 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 user and group profiles in the zone; join and remove computers from the zone; and delete the zone. The group FinanceManagers to add, modify, and remove user and group profiles from the zone. The group FinanceUsers to change zone properties, but perform no other tasks. Administrator s Guide for Linux and UNIX 42

43 Delegating control of administrative tasks The users jason.ellison and noah.stone permission to delete the zone. You can delegate zone permissions by using ADEdit or the Access Manager console. The following procedure shows how to do so by using Access Manager. To delegate which users and groups have control over the objects in a zone: 1 Open the Access Manager Console. 2 In the console tree, select Zones, then select and expand the zone you are interested in. 3 Right-click, then click Delegate Zone Control. 4 Click Add to find the users, groups, or computer accounts to which you want to delegate specific tasks. 5 Select the type of account User, Group, or Computer to search for, type all or part of the account name, then click Find Now. 6 Select one or more accounts from the list of results, then click OK. 7 When you are finished adding users and groups to which you want to assign administrative tasks, click Next. 8 Select the tasks you want to delegate to the user or group, then click Next. For example, if you want all of the members of the group you selected in the previous step to be able perform all administrative tasks for a zone, check the All task. To restrict the administrative tasks a user or group can perform, select those specific tasks. The domain administrator who creates a zone has full control over the zone s properties and permission to delegate administrative tasks to other users. The user who creates a zone is also the only user who can add NIS maps to the zone. The right to create NIS maps is exclusive to the creator of a zone because it requires permission to create containers in Chapter 4 Managing zones 43

44 Setting zone properties Active Directory. The zone creator can, however, grant other users permission to add, remove, or modify NIS map entries. For each zone you create, you should identify at least one user or 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. In addition, any user or group assigned the Add users or Add groups task should also be assigned the Change zone properties task to enable the next UID and next GID properties to be updated each time a user or group is added to a zone. If you don t assign the Change zone properties task, you must manually increment the next UID and GID values. Note For information about the permissions set when you select administrative tasks in the Zone Delegation Wizard, see the Planning and Deployment Guide. 9 Review your selections, then click Finish. Note If you delegate administrative tasks to one or more groups that have members logged on, you should inform the group members that they may need to log out and log back on before they can perform the administrative tasks assigned to the group. Setting zone properties At any time, you can set or change zone properties. The zone creation wizard sets blank values for many of the zone properties, including those that allow you to control the default profile settings for users and groups in the zone. Setting values for these properties, allows you to much more rapidly provision a zone with users and groups. To set or change the properties for a zone: 1 Open the Access Manager Console. 2 In the console tree, select Zones to display the list of zones, and if you are interested in a child zone, expand the appropriate Child Zones node until you see the zone you want. Administrator s Guide for Linux and UNIX 44

45 Setting zone properties 3 Select a zone and right-click, then click Properties. For example: 4 Click the appropriate tab to configure the default properties for the current zone, then click OK. You can set properties on the following tabs: Click this tab To do this General This tab allows you to view general zone properties and change the value in certain fields, as follows: User Defaults View the location of the zone in Active Directory and the zone type. Modify the zone description. View whether a master domain controller has been defined for the zone. Select a specific Licenses container for the zone to use. Add or remove support for agentless authentication in the current zone. Configure the access control list of permissions for the zone. This tab allows you to set default values for any of the profile fields for users who are added to the zone. When an administrator adds a user to a zone, they can accept the default values defined here or override any of the defaults as desired. Select this tab and click F1 to see information specific to setting user defaults. Chapter 4 Managing zones 45

46 Renaming a zone Click this tab Group Defaults Variables Provisioning To do this This tab allows you to set default values for any of the profile fields for groups that are added to the zone. When an administrator adds a group, they can accept the default values defined here or override any of the defaults as desired. Select this tab and click F1 to see information specific to setting group defaults. This tab allows you to add or edit user-defined variables and override the values of predefined variables. Select this tab and click F1 to see information specific to adding and editing variables. This tab is displayed if the Zone Provisioning Agent was selected during installation or through a separate installation. It allows you to enable and configure auto-provisioning for user and group profiles. Select this tab and click F1 to see information specific to autoprovisioning of user and group profiles. Renaming a zone You can rename a zone at any time. For example, if your organization changes how business units are aligned, moves to a new location, or merges with another organization, you might want to update zone names and descriptions to reflect these changes. You might also want to rename zones if your initial deployment did not use a naming convention for new zones, and you want to implement one after you have agents deployed. What to do before renaming a zone Before you rename zones, you might want to define and document a naming convention to use for future zones or the reasons for changing the zone name. You should also identify the computers in the zone to be renamed. You must restart the agent on those computers for the new zone name to be recognized. There are no other prerequisites for performing this task. Administrator s Guide for Linux and UNIX 46

47 Renaming a zone Rights required for this task To rename a zone, your user account must be set with the following permissions: Select this target object Parent container for an individual zone For example, a ZoneName container object, such as: domain/zones/arcade To apply these permissions Write Description Write name Write Name These are the minimum permissions required to rename a zone and not allow a user or group to modify any other zone properties. You can set permissions manually, or automatically grant these and other permissions to specific users or groups by selecting the Change zone properties task in the Zone Delegation Wizard. Who should perform this task A Windows administrator performs this task, depending on your organization s policies. The user who creates the zone is responsible for delegating administrative tasks to other users or groups, if necessary. In most organizations, this task is done using an account with domain administrator privileges. How often you should perform this task After you are deployed, you rename zones only when you need to address organizational changes or to implement or improve the naming conventions you use. Steps for completing this task The following instructions illustrate how to rename a zone using Access Manager. To rename a zone using Access Manager: 1 Open DirectManage Access Manager. 2 Expand Zones to display the list of zones, then expand any child zones in the zone hierarchy until you see the specific zone you want to modify. 3 Select the zone to change, right-click, then click Rename. 4 Type the new name and, if needed, any changes to the zone description. 5 Restart all of the Centrify UNIX agents on the computers in the zone you have renamed. You do not have to leave and rejoin after changing a zone name. However, you must restart the agent for the name change to take effect on a managed computer. In a terminal window on each managed computer, run the following command: [user@computer]# /usr/share/centrifydc/bin/centrifydc restart Chapter 4 Managing zones 47

48 Changing the master domain controller 6 You can verify the updated zone name on a local computer by using the adinfo command, which returns output similar to the following: [user@computer]# adinfo... Zone: acme.com/unix/zones/global/finance Changing the master domain controller When you create new zones, you have the option to specify a master domain controller that you want to use for the zone. Setting a master domain controller helps to ensure data integrity because it prevents other domain controllers from adding and removing users and groups in a zone and introducing duplicate UIDs or GIDs. If you choose to not set the master domain controller or the master domain controller is unavailable, it is possible for administrators to add users to the zone with the same UID because they are connecting to different domain controllers. Using a master domain controller ensures that the administrators cannot add new users with duplicate UIDs. If you choose to use a master domain controller for a zone, you should avoid changing it. If you do need to change the master domain controller, however, you should keep the following in mind: The zone information is only updated in the new master domain controller when replication is complete. If you connect to the old domain controller and view zone information, the zone will display the old domain controller as its master domain controller until replication is complete for all domain controllers. Reports and forest analysis will not report the correct master domain controller for the zone until replication is complete between the new master domain controller and the previous master domain controller. You cannot refresh the information displayed in Access Manager until replication is complete between the new master domain controller and the previously connected domain controller. You should wait for zone information to be replicated to all domain controllers before you add any new users or groups to the zone you are modifying to prevent duplicated UIDs. After changing the master domain controller for one or more zones, you should run the Analyze command to check the Active Directory forest and verify that no duplicate UIDs or GIDs have been introduced. Changing the master domain controller for one zone This section explains how to change the master domain controller for a single zone. See the next section for information about changing the master controller for multiple zones. Administrator s Guide for Linux and UNIX 48

49 Changing the master domain controller To change the master domain controller for a zone: 1 Open Access Manager. 2 In the console tree, select Zones to display the list of zones. 3 Select the zone name for which you want to set a new master domain controller. 4 Right-click, then click Change Master Domain Controller. 5 Type the fully-qualified domain name for the new domain controller, then click OK. If there are other administrators managing this zone, you should notify them before changing the master domain controller and make this change while they are logged out. Depending how long it takes for replication to complete for all of the domain controllers in the Active Directory forest, you might want to schedule this change for a time when no administrators need access to zone information. 6 Click Yes to confirm that you want to change the master domain controller for the zone. Changing the master domain controller for multiple zones If you are using the same master domain controller for multiple zones, you may need to change the domain controller for all of the zones at once. For example, if several zones use the server ginger.ajax.org as their master domain controller and the server has a hardware failure or other problem requiring it to be taken down, all of the zones using that domain controller need to connect to a new master domain controller. To change the master domain controller for multiple zone: 1 Open the Access Manager Console. 2 In the console tree, select Zones to display the list of zones in the details pane. 3 Use SHIFT-CLICK and CTRL-CLICK to select the zone names for which you want to set a new master domain controller. 4 Right-click, then click Change Master Domain Controller. 5 Type the fully-qualified domain name for the new domain controller, then click OK. You should notify all Centrify administrators before changing the master domain controller for multiple zones and, if possible, make this change while they are logged out. Depending how long it takes for replication to complete across the domain controllers in the Active Directory forest, you may want to schedule this change for a time when no administrators need access to zone information. 6 Click Yes to confirm that you want to change the master domain controller for all of the selected zones. Chapter 4 Managing zones 49

50 Adding a computer to a zone Adding a computer to a zone There are three ways to add a computer to a zone: By specifying the zone when you join the domain using adjoin. By selecting a zone when you create or modify the computer account properties. By connecting to Auto Zone when you join the domain using adjoin. You cannot join a domain without either specifying a zone or connecting through Auto Zone. For more information about specifying the zone, joining the domain, and modifying computer properties, see Chapter 6, Managing computers.. Changing the location of a zone in Active Directory If you want to move a zone from one container object to another in Active Directory, you can do so manually using ADSI Edit to edit the zone container s object properties. If you change the location for a zone, you must then restart the Centrify UNIX agent on the computers in that zone so that they recognize the new zone location. After you move the ZoneName object to a new parent container or organizational unit, run the following command to restart the Centrify UNIX agent on the computers in the zone: /usr/share/centrifydc/bin/centrifydc restart Provisioning user and group profiles automatically The Centrify Zone Provisioning Agent is a separate tool that enables automated provisioning of user and group accounts into Centrify zones. You configure the Zone Provisioning Agent to monitor specific Active Directory groups that are linked to a zone. When you add or remove Active Directory users or groups in the monitored groups, the Zone Provisioning Agent adds or removes corresponding user or group profiles in the zone. You can configure the business rules for adding and removing groups and how the attributes associated with a user profile or a group profile are generated. For more detailed information about automated provisioning and using the Zone Provisioning Agent, see the Planning and Deployment Guide. Modifying settings for the Zone Provisioning Agent The Centrify Zone Provisioning Agent is a DirectManage Access - Utilities component that includes a Configuration Panel, a Windows service, and a command-line utility. You can install it on a computer with other DirectManage Access components or as a separate component from its own setup program. For information about preparing a service account, installing, and performing the initial configuration of the Zone Provisioning Agent, see the Planning and Deployment Guide. Administrator s Guide for Linux and UNIX 50

51 Provisioning user and group profiles automatically After the initial configuration, you can modify settings for the Zone Provisioning Agent using the Zone Provisioning Agent Configuration Panel. To modify configuration settings for the Zone Provisioning Agent: 1 Click Start > All Programs > Centrify Server Suite 2014 > Centrify Utilities and Tools > Zone Provisioning Agent > Zone Provisioning Agent Configuration Panel. 2 Modify the list of monitored containers, if needed. By default, Zone Provisioning Agent monitors all domains in the entire forest. Click Add if you want to select a specific organizational unit to monitor. For information about creating and using a specific OU for provisioning, see the Planning and Deployment Guide. To connect to a specific domain controller for a monitored container, select the container, then click Change.To remove a monitored container, select it, then click Remove. 3 Modify the polling interval, if needed. The polling interval controls how often (in minutes) that the Zone Provisioning Agent checks monitored containers for changes and provisions users and groups into zones.the default value is 60 minutes. 4 Modify the event log settings, if needed. By default, the Zone Provisioning Agent writes the name of the users and groups added or removed for a zone and any fatal errors for the Zone Provisioning Agent service to the Windows Event Log. You can click Open Event Viewer to see the Event Log. 5 Modify the troubleshooting settings to enable logging and generate a log file that can help to diagnose problems with Zone Provisioning Agent operation. 6 Modify the Active Directory user name and password for the Zone Provisioning Agent to use, if needed. In most cases, you should use a dedicated user account to run the service rather than using an existing user account. For information about the rights required for the service account, see the Planning and Deployment Guide. 7 Click Apply to save any changes, then click Start or Restart to start or restart the Zone Provisioning Agent service. Configuring automated provisioning of group profiles You can configure the business rules for automated provisioning of group profiles on a zone-by-zone basis. When you use hierarchical zones, however, you typically want to configure the business rules in the parent zone so that the profile can be inherited in all child zones. The profile, on its own, does not provide any access to any computers in any of the Chapter 4 Managing zones 51

52 Provisioning user and group profiles automatically child zones. In addition, you can override any inherited attributes in any child zone or on individual computers, if needed. Note The business rules you define only affect new UNIX user and group profiles. The imported legacy data remains unchanged, and the Zone Provisioning Agent will not modify any attributes on the existing user and group profiles. To configure the business rules for groups in the parent zone: 1 Open Access Manager. 2 Expand the Zones node. 3 Select the top-level parent zone, right-click, then click Properties. 4 Click the Provisioning tab. This tab is only displayed if you have installed the Zone Provisioning Agent on a computer with Access Manager. 5 Click Enable auto-provisioning for group profiles. 6 Click the Find icon to search for and select the provisioning group you created to use as the Source Group for new groups. 7 Select a method for assigning a new GID to new UNIX group profiles: Generate from group SID is the default option because it automatically generates new GIDs that are guaranteed to be unique based on the Active Directory security identifier (SID) of the group. Selecting this option ensures groups defined in the parent zone have a unique GID across all zones in the Active Directory forest. RFC 2307 attribute can be used if you have added the gidnumber attribute from the RFC 2307 schema to all the Active Directory groups that you want to add to the parent zone. This option also ensures GID uniqueness, but it requires you to add the RFC 2307 attribute to Active Directory group principals. Zone default value selects the next available GID in the parent zone. In most cases, you should avoid using this option because it does not guarantee unique GIDs when you have an existing GID space. Generate using Apple scheme generates group GIDs based on the Apple algorithm for generating numeric identifiers from the Active Directory group s objectguid. This option automatically generates new GIDs that are guaranteed to be unique using the Apple scheme rather than the Centrify scheme. Using the Apple scheme creates GIDs that are compatible with the Apple Active Directory plug-in and with other Mac OS X tools such as ExtremeZ-IP. 8 Select a method for assigning a new group name to new UNIX group profiles: SamAccountName attribute generates the group name for the new UNIX group profile based on the pre-windows 2000 or samaccountname value. Administrator s Guide for Linux and UNIX 52

53 Provisioning user and group profiles automatically CN attribute can be used if you verify the common name does not contain spaces or special characters. Otherwise, you should not use this option. RFC 2307 attribute can be used if you have added the RFC 2307 groupname attribute to Active Directory group principals. Otherwise, you should not use this option. Zone default value uses the samaccountname attribute. By default, all UNIX group names are lowercase and invalid characters are replaced with underscores. 9 Click OK to save your changes. Configuring automated provisioning of user profiles In addition to the business rules for group profiles, you can configure similar rules for new UNIX user profiles. When you use hierarchical zones, you typically want to configure these business rules for the parent zone so that the profile can be inherited in all child zones. The profile, on its own, does not provide any access to any computers in any of the child zones. In addition, you can override any inherited attributes in any child zone or on individual computers, if needed. To configure the business rules for user profiles in a parent zone: 1 Open Access Manager console. 2 Expand the Zones node. 3 Select the top-level parent zone, right-click, then click Properties. 4 Click the Provisioning tab. 5 Click Enable auto-provisioning for user profiles. This tab is only displayed if you have installed the Zone Provisioning Agent on a computer with Access Manager. 6 Click the Find icon to search for and select the provisioning group you created as the Source Group for new users. 7 Select a method for assigning a new UID to new UNIX user profiles by selecting one of the following options from the UID drop down menu: Generate from user SID is the default option because it automatically generates new UIDs that are guaranteed to be unique based on the Active Directory security identifier (SID) of the user. Selecting this option ensures users defined in the parent zone have a unique UID across all zones in the Active Directory forest. RFC 2307 attribute requires you to have added the RFC 2307 uidnumber attribute to the Active Directory users. Chapter 4 Managing zones 53

54 Provisioning user and group profiles automatically Zone default value uses the next available UID in the parent zone. In most cases, you should avoid using this option because it can create UID conflicts with users in other zones. Use custom ID enables you to use the EmployeeId, EmployeeNumber, or uidnumber attribute as the UID for new users. After selecting this option, click the gear icon to select one of these attributes. You should only select the EmployeeId or EmployeeNumber attribute if your organization already populates the EmployeeId or EmployeeNumber attribute with a unique value for each user account. Generate using Apple scheme generates UIDs based on the Apple algorithm for generating numeric identifiers from the Active Directory user s objectguid. This option automatically generates new UIDs that are guaranteed to be unique using the Apple scheme rather than the Centrify scheme. Using the Apple scheme creates UIDs that are compatible with the Apple Active Directory plug-in and with other Mac OS X tools such as ExtremeZ-IP. 8 Select a method for assigning a new UNIX user login name to new UNIX user profiles: SamAccountName attribute generates the user login name for new UNIX users based on the pre-windows 2000 or samaccountname value. CN attribute can be used if you verify the common name does not contain spaces or special characters. Otherwise, you should not use this option. RFC 2307 attribute can be used if you have added the RFC 2307 uid attribute to Active Directory user principals. Otherwise, you should not use this option. Zone default value uses the samaccountname attribute. 9 Select a method for assigning a new shell and home directory to new UNIX user profiles. You can use RFC 2307 attribute if you are using the RFC 2307 schema for user objects. In most cases, however, you should select Zone default value for the shell and home directory. Selecting Zone default value enables you to use the values you define on the User Defaults tab, which can include runtime variables for the shell and home directory. Runtime variables are populated with platform-specific values when a user tries to log on to a UNIX computer. For example, if a user logs on to a Linux computer with a profile that uses the runtime variable for the home directory, the home directory is /home/ username. If the user logs on to a Solaris computer, the runtime variable becomes / export/home/username. 10 Select a method for assigning a primary group to new UNIX user profiles. RFC 2307 attribute is only applicable if you are using the RFC 2307 schema for user objects. In most cases, however, you should select Zone default value for the shell and home directory. Zone default value uses the values you define on the User Defaults tab. This setting enables you to use Domain Users, or any other group profile, as the primary group for Administrator s Guide for Linux and UNIX 54

55 Running reports for zones all UNIX users. If you don t change the default value for the primary group on the User Defaults tab, primary group is a private group. Private group uses the user s UID as the primary GID. Active Directory group membership selects an Active Directory group with the highest priority as the primary UNIX group. With this option, the Zone Provisioning Agent checks which groups a user belongs to and a prioritized list of groups you have defined. If you select this option, click the Configure icon to search for and select the Active Directory groups to include in the prioritized list. This option allows different users to have different primary GIDs in the same zone. Generate using Apple scheme generates primary group GIDs based on the Apple algorithm for generating numeric identifiers from the Active Directory user s objectguid. This option automatically generates primary GIDs that are guaranteed to be unique using the Apple scheme rather than the Centrify scheme. Using the Apple scheme creates GIDs that are compatible with the Apple Active Directory plug-in and with other Mac OS X tools such as ExtremeZ-IP. If you select the Active Directory group membership option and a user isn t a member of any of the groups in the list of prioritized groups, the Zone Provisioning Agent will not create a UNIX user profile for the user, because it won t be able to determine their primary group. As noted in the Planning and Deployment Guide, the most common approach is to have all users assigned the same primary GID in a zone. 11 Select a method for assigning a value to the GECOS field in new UNIX user profiles. RFC 2307 attribute is only applicable if you are using the RFC 2307 schema for user objects. Zone default value uses the values you define on the User Defaults tab. This setting enables you to use Active Directory displayname attribute for the user in the GECOS field. Running reports for zones To view information about zones, you can run the following default report definitions or create your own custom reports: The Zone Delegation Report lists the administrative tasks for each zone and the users or groups have been delegated to perform each task. The Zones Report lists zone properties for each zone. For more information about generating and working with reports, see Generating predefined and custom reports on page 188. Chapter 4 Managing zones 55

56 Searching for profiles in a domain Searching for profiles in a domain You can search for the UNIX profiles for computers, groups, or users within a domain, or for the zones that have been created in the domain. To search for profiles in a domain: 1 Open Access Manager. 2 Select the DirectManage Access Manager node. 3 Right-click and click Find Objects. 4 In Find, select the type of profile you want to find, such as Computer. 5 Type all or part of the name of the profile you want to find, then click Find Now. 6 Select the profile from the list of results and double-click to see the Active Directory properties for the object. 7 Click the Centrify Profile tab to see the Centrify profile for the object. Note If the object has multiple profiles, you will need to select the one you want to see. For example, if a user has a profile in two or more zones, double-click the one whose profile you want to view. Connect to a domain using Auto Zone Ordinarily, when you join a UNIX computer to a domain, you must perform a certain amount of configuration, such as defining a zone, adding Active Directory users and groups to the zone, and enabling group policies. The Auto Zone option greatly simplifies the process of joining a domain. Auto Zone essentially is one super zone for the forest. With Auto Zone, UNIX attributes that are normally defined in the zone to which the computer is joined, are derived from user attributes in Active Directory, or from agent configuration parameters. By default, when a computer is joined to a domain through Auto Zone, all users and groups defined in Active Directory for the forest automatically become valid users and groups on the joined computer. In addition, all Active Directory users defined in a forest with a twoway, cross-forest trust relationship to the forest of the joined domain, are also valid users for the joined computer. Note Auto Zone does not support one-way trusts. That is, if a computer is joined to a domain through Auto Zone, and the domain has a one-way trust relationship with another domain, users and groups in the trusted domain do not become valid users and groups on the computer. Administrator s Guide for Linux and UNIX 56

57 Connect to a domain using Auto Zone Although certain group policies and configuration settings are provided to simplify Auto Zone configuration, using Auto Zone does not require enabling any group policies, or changing any of the default configuration settings. In fact, you can join a domain by connecting to Auto Zone without installing Access Manager on any computers in the forest. However, any group policies that are defined in the domain, are enforced on computers joined to Auto Zone. Auto Zone is intended primarily for smaller installations. For performance reasons, Centrify recommends using Auto Zone with default settings, only in installations with 1500 users or less. Note that other factors, such as the number and size of groups, and their nesting levels, also affect how well computers in your environment will perform when connected to Auto Zone. However, even in larger installations, if you have a discrete sub group of Active Directory users who need access to UNIX or Mac OS X computers, and a larger group of Windowsonly users, you can still use Auto Zone by setting configuration parameters (or group policies) to specify the subset of valid Auto Zone users. When joined to Auto Zone, no zone features, including the ability to assign roles, require auditing, provide different identities on different computers, and so on are enabled. Steps for configuring Auto Zone To use Auto Zone, do one of the following. If you have an installation with 1500 or fewer Active Directory users, simply join a domain through Auto Zone without setting any configuration parameters or group policies. See Joining a domain by connecting to Auto Zone on page 57. If you have an installation with more than 1500 Active Directory users, first specify the Active Directory users and groups who will have access to the computers joined to Auto Zone, then join the domain through Auto Zone. See Limiting users and groups in the Auto Zone on page 59. Although all users and groups have default access to all computers joined to Auto Zone, you can control access to computers and other Auto Zone related operations by setting parameters in the agent configuration file. For more information about setting configuration parameters, see the Configuration and Tuning Reference Guide. Joining a domain by connecting to Auto Zone To join a domain by connecting to Auto Zone, you can use the adjoin command line tool on a UNIX computer with the --workstation option. When joining a computer to Auto Zone, be certain that the following are true: Active Directory identities are unique for the forest and any two-way trusted forest. Chapter 4 Managing zones 57

58 Connect to a domain using Auto Zone The Active Directory users and groups require a single set of properties for all computers that join the domain through Auto Zone and do not need to be segregated into zones for any reason. All domains in the forest and any trusted external forest must be unique or the join will fail. In this case, you must manually configure a unique prefix for each trusted domain using configuration parameters. Who should perform this task A Linux or UNIX administrator with root permission on the computers you want to join to an Active Directory domain. The administrator must also know the password for an Active Directory domain administrator account. How often you should perform this task In most cases, you only do this once for each Linux or UNIX computer that needs to join an Active Directory domain. Steps for completing this task The following instructions illustrate how to join Auto Zone using the adjoin command. You can also use Deployment Manager to join a discovered Linux or UNIX computer to an Active Directory domain through the Auto Zone. To join a computer to a domain through Auto Zone 1 Log on the computer with the Centrify agent using an account with root privilege. 2 Open a terminal and execute the following command; when prompted, type the Active Directory administrator s password: adjoin domainname --workstation For example: [root@rhe5]#adjoin acme.com --workstation [email protected] s password: Using domain controller: win-f7d27u7kl6m.acme.com writeable=true Join to domain:acme.com, zone: Auto Zone succesful 3 Run the adinfo command to verify the connection to Auto Zone: [root@rhe5]# adinfo Local host name: rhe5 Joined to domain: acme.com Joined as: rhe5.acme.com Pre-win2K name: rhe5 Current DC: win-f72d7u7kl6m.acme.com Preferred site: Default-First-Site Zone: Auto Zone Last password set: :08:34 PDT CentrifyDC mode: connected Administrator s Guide for Linux and UNIX 58

59 Connect to a domain using Auto Zone Licensed Features: Enabled You can also view the connected computers in Access Manager by expanding Zones then the Auto Zones node. Limiting users and groups in the Auto Zone By default, all users in an Active Directory forest and any two-way trusted forest are valid users for computers in the Auto Zone. You can use configuration parameters or group policies to fine-tune the Active Directory users you want as valid users on a UNIX computer. To specify subsets of Active Directory users and groups as valid Linux and UNIX users in the Auto Zone, you can configure the following settings: The auto.schema.allow.users configuration parameter or the Specify AD users allowed in Auto Zone group policy. The auto.schema.allow.groups configuration parameter or the Specify groups of AD users allowed in Auto Zone group policy. The auto.schema.groups configuration parameter or the Specify AD groups allowed in Auto Zone group policy. Rights required for this task You must have an account with root permission to modify agent configuration files on managed computers or an administrative account with write permission to enable group policies on a Group Policy Object linked to a domain or organizational unit. Who should perform this task A Windows or UNIX administrator performs this task, depending on your organization s policies. Steps for completing this task The following instructions illustrate how to limit the valid users and groups in the Auto Zone using group policy settings. To specify users and groups to include in Auto Zone by using group policy settings 1 Identify or create an Active Directory group that includes all of the users that you want to give access to UNIX computers. The group can be a domain local, global, or universal group. The group can include sub groups members of these sub groups will also be included in Auto Zone. Chapter 4 Managing zones 59

60 Connect to a domain using Auto Zone 2 Open Group Policy Management to create or select a Group Policy Object that is linked to a site, domain, or organizational unit that includes the UNIX computers to join to Auto Zone. 3 Right-click the Group Policy Object, then select Edit. 4 In the Group Policy Management Editor, expand Computer Configuration > Policies > Centrify Settings > DirectControl Settings, click Adclient Settings, then double-click Specify groups of AD users allowed in Auto Zone. 5 Select Enabled, then click List to browse for the groups to specify. 6 Click Add, enter search criteria and click Find Now. 7 Select one or more groups from the list and click OK. 8 If necessary, add individual Active Directory users by completing Steps Double-click Specify AD users allowed in Auto Zone. 10 Select Enabled, then click List to browse for the users to specify. 11 Click Add, enter search criteria and click Find Now. 12 Select one or more users from the list and click OK. 13 Double-click Specify AD groups allowed in Auto Zone. 14 Select Enabled, then click List to browse for the groups to specify. 15 Click Add, enter search criteria and click Find Now. 16 Select one or more groups from the list and click OK. To specify users and groups to add to Auto Zone by using configuration parameters 1 On a Windows computer, in Active Directory Users and Computers, identify or create a group or group that includes all the users who you want to have access to your UNIX computers. 2 On each computer to add to Auto Zone, open the CentrifyDC configuration file (/etc/ centrifydc/centrifydc.conf). 3 Find auto.schema.allow.groups and remove the comment (#). 4 Enter the names of groups (identified in Step 1) to add separated by commas. The configuration file contains comments that list the valid formats for group names. You can also see the Configuration and Tuning Reference Guide for more information. 5 If necessary, add individual Active Directory users by completing Steps 5 and 6. 6 Find auto.schema.allow.users and remove the comment (#). 7 Enter the names of users to add separated by commas. Administrator s Guide for Linux and UNIX 60

61 Connect to a domain using Auto Zone The configuration file contains comments that list the valid formats for user names. You can also see the Configuration and Tuning Reference Guide for more information. 8 Find auto.schema.groups and remove the comment (#). 9 Enter the names of groups to add, separated by commas. The configuration file contains comments that list the valid formats for group names. You can also see the Configuration and Tuning Reference Guide for more information. 10 Save and close the file. Chapter 4 Managing zones 61

62 Chapter 5 Migrating from classic to hierarchical zones Zones are the key structure for organizing computers in an organization in meaningful ways for account and access management. This chapter describes how to migrate your existing legacy, or classic zones, to hierarchical zones to take advantage of inheritance, separation of identity and access information, and more robust roles and rights management to the features available through zones. This chapter assumes you have existing classic zones that you want to migrate to hierarchical zones. If you do not have existing classic zones, you can skip this chapter. If you are unsure of the zone type, you can look at the properties page for a zone to see its type. For detailed information about zone types, strategies for using zones, or planning the migration of existing users and groups to zones for the first time, see Chapter 4, Managing zones and the Planning and Deployment Guide. The following topics are covered: Planning migration from classic zones to hierarchical zones Upgrading to a 5.x version of Access Manager Creating a parent zone Delegating zone permissions Verifying that UNIX agents are running version 5.0 or newer Migrating users and groups, roles and rights, and NIS maps Moving joined computers to new hierarchical zones Deleting the old classic zones Cleaning up after migration 62

63 Planning migration from classic zones to hierarchical zones Planning migration from classic zones to hierarchical zones Migrating from classic zones to hierarchical zones requires some effort but should cause no disruption to your current implementation. The migration process copies the zone information from a classic zone to a new hierarchical zone without changing anything about the existing zone, including the computer accounts that are joined to it. Once you are certain that the new zone is properly set up, you can move the joined computers from the old zone to the new zone. The first step is to analyze your current implementation and to understand how it will fit into a hierarchical framework. Before you begin, you should have a basic understanding of how hierarchical zones differ from classic zones (see Understanding identity and access in hierarchical zones on page 35) and the benefits of using them. In summary, hierarchical zones provide the following: Separation of identity and access information. Ability to share (inherit) or override profile information, rights and role definitions, and user and group role assignments at any point in the hierarchy. Robust roles and rights management that enables consistent application of roles across zones and computers, including the use of computer roles, which allow you to assign specific roles to groups of users on a set of computers, such as database servers or test computers, that perform a dedicated job function (see Creating a computer role on page 156). The recommended approach to using hierarchical zones is to create a parent zone that serves as a consistent name space and a point of delegation for zone permissions. You can then create child zones that inherit data and delegation information from the parent zone, with the ability to override this information on a zone-by-zone basis, or on an individual computer as necessary. Before creating any parent zones, you should analyze your current environment to determine how many parent zones to create. For example, if you have two teams with different, non-intersecting policies and procedures for adding users or granting privileges, you should probably create two parent zones. On the other hand, if you have a single account fulfillment desk that handles all user fulfillment and a dedicated security team that manages privilege, you only need to create a single parent zone, because there s only one way to manage the data. Upgrading to a 5.x version of Access Manager Hierarchical zones require a 5.x version of the Access Manager console; if you are not already running version 5.x, upgrade the console now. To migrate to hierarchical zones you need only one console that is at version 5.x or newer; however, at some point you need to update all your consoles to 5.x in order to view and manage hierarchical zones. Chapter 5 Migrating from classic to hierarchical zones 63

64 Creating a parent zone Note Versions 5.0 and 5.1 of the console can manage classic zones if you choose not to migrate any existing classic zones to hierarchical zones. Creating a parent zone The recommended migration strategy is to create a parent zone, then migrate all the existing classic zones as child zones of this parent zone. The migration tool copies the profile data from all the classic zones to the parent zone. If one or more identical profiles exist in multiple classic zones, the migration tool copies each identical profile to a single profile in the parent zone. The migration tool copies everything else from each classic zone (roles, rights, role assignments, groups, NIS maps) to a new, corresponding child zone. If a user account (or group) has profiles in multiple zones with different attribute values (for example, UID in one zone, but in another zone), the migration creates a single profile for the user in the parent zone, and creates a profile override with the distinct attribute values in the child zones. Each child zone inherits the base profile for the user from the parent zone but applies any distinct attribute values. Note It is possible to keep the exact structure you have now by migrating each existing zone to a new peer zone and not create a parent zone at all. Although this configuration gives you access to some of the features that are available only in hierarchical zones, such as the separation of access and identity information, the flat structure does not provide inheritance, one of the key features of hierarchical zones, and is not a recommended configuration. To start the migration process, create a parent zone as described in Creating a new parent zone on page 38. Delegating zone permissions If your current process requires you to run the Zone Delegation Wizard to set up permissions when creating a zone, you can do the same now. On the other hand, if your zones inherit permissions through standard Active Directory inheritance, you can skip the following procedure. Note Permissions that you delegate to the parent zone are not automatically inherited by the child zones that you are about to create from your migrated classic zones. In addition, the migration tool does not copy delegated permissions from the existing classic zones to the new child zones. After migrating the zones, you can delegate the necessary permissions; see Cleaning up after migration on page 72. For now, you need permissions to manage the parent zone after creating it. Administrator s Guide for Linux and UNIX 64

65 Verifying that UNIX agents are running version 5.0 or newer To delegate permissions for the parent zone 1 On a Windows computer, open the Access Manager console and navigate to and select the new zone you created. 2 Right-click and select Delegate Zone Control. 3 Click Add and select User, Group, or Computer in the Find list. 4 Enter search criteria in Name and click Find Now to find Active Directory users, groups or computers that match your criteria. 5 Select one or more users, groups, or computers and click OK. 6 Click Next. 7 Assign the permissions you want to delegate; you can select All to delegate all permissions. Verifying that UNIX agents are running version 5.0 or newer The migration tools are contained in the Centrify UNIX agent, version 5.1 or later, so you must install version 5.1 or later on at least one UNIX computer in order to do the migration. Note At some point you must update the UNIX agents of all computers you intend to move to 5.1 because the adchzone command, which is used to move a joined computer from a classic zone to a hierarchical zone, is contained in Centrify software version 5.1 or later. You can use Deployment Manger to report on the version of the agent on each UNIX computer, and to update it if necessary; or use the following procedure. To verify and upgrade agent version to version 5.0 or newer 1 On each managed UNIX computer, open a terminal and run adinfo to see the adclient version: [user@rhe5]adinfo -v adinfo (CentrifyDC ] 2 Update to the latest version of the agent for any computers that do not show CentrifyDC 5.1 or later. See Installing the Centrify UNIX agent on page 32 for details. Migrating users and groups, roles and rights, and NIS maps Centrify provides a command line utility, admigrate, to automate the process of migrating users, groups, roles, rights, and NIS maps from a classic zone to a new hierarchical zone. The admigrate command line utility is installed by default in the following directory: Chapter 5 Migrating from classic to hierarchical zones 65

66 Migrating users and groups, roles and rights, and NIS maps /usr/share/centrifydc/adedit/admigrate The basic syntax for admigrate is: admigrate -in classiczone -z targetzone -hz parentzone -config configfile -f -v where: -in classiczone Note There are additional options for admigrate to limit the data to be migrated, for example, -users to migrate only user profiles, or -privileges to migrate only roles and rights, however, it is generally recommended to migrate all data, which is what the example in this section shows. To migrate zone data from a classic to hierarchical zone: Distinguished name of the classic zone to migrate. For example: cn=finance,cn=zones,ou=unix,dc=acme,dc=com -z targetzone Distinguished name of the new zone. It can be the same as the existing classic zone name, however the new zone will be a child zone of the specified parent zone, so the distinguished name is different. For example: cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com -hz parentzone -config configfile A parent zone for the migration. The specified zone must be an existing zone. The target zone becomes a child zone of this zone. You can run admigrate multiple times and specify the same parent zone and different source and target zones each time to migrate multiple zones to different child zones of this parent. For example: cn=global,cn=zones,ou=unix,dc=acme,dc=com A configuration file to use with the migration. The configuration file is primarily useful to specify bind information if you are migrating zones from domains that are different from the target zone s domain. The file is a simple text file, for example: -config admigrate.txt In the file, specify one bind command per line with credentials for the domain. For example: bind fin.acme.com administrator {myp@$swd} bind -write eng.acme.com administrator {@lt!pas$} -f Overwrites the target zone if it already exists. -v Print verbose information while the command runs. Pipe this to a text file to save the information. The sample setup is provided to make it easy to understand the admigrate syntax. Your setup may be different in terms of the containers in which you store zones, and of course with regard to zone names. Note As explained earlier, the first zone you migrate will be the primary source of UID and GID mappings. If your current Centrify configuration uses a legacy NIS domain or you are Administrator s Guide for Linux and UNIX 66

67 Migrating users and groups, roles and rights, and NIS maps using the Centrify global zone best practice, start with that zone because it contains the most consistent UIDs and GIDs. Assume the following sample setup for using admigrate: Table 1. Sample domain and zone names for migration Domain First classic zone name Second classic zone name First target zone name Second target zone name Parent zone name Path to zones in Active Directory acme.com finance engineering finance engineering global DC=acme,DC=com OU=UNIX CN=Zones CN=zoneName Distinguished name (first classic zone) cn=finance,cn=zones,ou=unix,dc=acme,dc=com Distinguished name (first target zone) cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com 1 Log in to a UNIX computer running adclient version 5.1 or later and open a terminal window. 2 Open a text editor and enter bind information for each domain to which admigrate must connect. Specify credentials on one line per domain in the format: bind domain account password For example: bind finance.acme.com administrator {myp@$swd} bind eng.acme.com administrator {@lt!pas$} The specified Active Directory account must have permissions in the parent zone to create child zones, roles, rights, user profiles and group profiles (see Delegating zone permissions on page 64). These permissions correspond to those of the Zone Administrators group, which is created as a best practice in the Planning and Deployment Guide. 3 Save and close the file. 4 Run a command similar to the following; for the distinguished names, this example assumes the domain, zones, and containers shown in Table 1. on page 67. Your names, of course, will be different, as may be the types of Active Directory objects (ou or cn) that comprise the distinguished name. /usr/share/centrifydc/adedit/admigrate \ -in cn=finance,cn=zones,ou=unix,dc=acme,dc=com \ -z cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com \ -hz cn=global,cn=zones,ou=unix,dc=acme,dc=com \ Chapter 5 Migrating from classic to hierarchical zones 67

68 Migrating users and groups, roles and rights, and NIS maps -config ~/admigrate.txt \ -f -v >migrate_finance.txt The target zone name is the same as that of the input classic zone, except its distinguished name is different because it is a child zone of the global zone. The -config ~/admigrate.txt option specifies the configuration file (with bind information) that you created in Steps 2 and 3. The first time you run admigrate, it does the following: Copies all users to the parent zone. Copies everything else (groups, role definitions, right definitions, role assignments, NIS maps) to the target child zone. If you specified the verbose output option (-v) and piped the result to a text file as recommended in the example, look at this text file after the command finishes execution to see if the command executed successfully or if it generated any error messages. If you want to see the results of the migration, on a Windows machine, open the Access Manager console, navigate to and expand the new parent zone, then expand Child Zones >newchildzone > UNIX Data > Users. You won t see any users because the migration tool put them all in the parent zone. Expand UNIX Data > Users in the parent zone to see the users who were copied from the classic zone to the new parent, hierarchical zone. 5 Run admigrate for the next zone to migrate. Specify the same parent zone but a different target zone. For example: /usr/share/centrifydc/adedit/admigrate \ -in cn=engineering,cn=zones,ou=unix,dc=acme,dc=com \ -z cn=engineering,cn=global,cn=zones,ou=unix,dc=acme,dc=com \ -hz cn=global,cn=zones,ou=unix,dc=acme,dc=com \ -config ~/admigrate.txt \ -f -v >migrate_finance.txt Each subsequent time you run admigrate with the same parent zone and a different source and target zone, admigrate does the following: If a user from the source zone does not exist in the parent zone, it creates a profile for the user in the parent zone. If a user exists in the parent zone and matches the user from the source zone, it doesn t do anything. The new child zone will inherit the user profile from the parent zone. See Understanding user profiles on page 108 for information about how inheritance works in hierarchical zones. If a user already exists in the parent zone and has attribute values that differ from those for the user from the source zone, it creates the user in the child zone with overrides for the differing attribute values. Copies everything else (groups, role definitions, right definitions, role assignments, NIS maps) to the target, child zone. After the migration, Administrator s Guide for Linux and UNIX 68

69 Migrating users and groups, roles and rights, and NIS maps you may want to move some role and right definitions and groups to the parent zone. See Cleaning up after migration on page Repeat Step 5 for each existing zone to migrate as a child of the new parent zone. To simplify the migration process for multiple zones, you could put admigrate in a shell script and specify the source zone as an input variable or read it from a file with a listing of all your zones. User profiles are migrated to the parent zone and overrides to the child zone The first time you run admigrate, the migration tool copies all user and group profiles to the parent zone. Each subsequent time that you run admigrate with the same parent zone and a different child zone, admigrate does one of the following: If admigrate finds a user or group in the classic zone without a profile in the hierarchical parent zone, it copies the profile from the classic zone to the parent zone. If admigrate finds a user or group in the classic zone with an identical profile in the parent zone, it does nothing. Each new child zone will inherit all user and group profiles from the parent zone. If admigrate finds a user or group in the classic zone that already has a profile in the parent zone, but some of the attributes are different, it doesn t change the profile in the parent zone, but copies the attributes that are different to the child zone. The child zone inherits the base profiles from the parent zone and overrides the profile attributes that are different. Roles and rights are upgraded to Suite 2012 and later definitions To understand how roles and rights (including role assignments) are migrated, you need to understand the differences, both in philosophy and implementation, between roles and rights management in Suite 2011 (agent version 4.x) and Centrify Suite 2012 and later (agent version 5.x and DirectManage Access 5.x). Roles and rights are optional in version 4.x. By default, all users with a profile in a zone are automatically allowed to log in to any UNIX machine joined to the zone. In version 4.x, you need roles only if you want to restrict access or to provide enhanced access. Before you can create or assign roles, you must first enable DirectAuthorize, which is not enabled by default. By contrast, roles and rights are required in version 5.x. By default, users with a profile in a zone are not automatically allowed to log in to a UNIX machine joined to the zone. They must be assigned system login rights (new in 5.0) and PAM access rights in addition to having a profile before they can log in. To support this model, version 5.x provides the following built-in roles: UNIX Login grants a user UNIX system rights for Password login, non-password login, and login with a restricted shell, and access to all (*) PAM applications. Chapter 5 Migrating from classic to hierarchical zones 69

70 Migrating users and groups, roles and rights, and NIS maps listed makes a user visible in a zone but does not grant any UNIX system rights, PAM rights, or command rights. Two new roles have been added for migration: login_at_roles assigns the UNIX system rights Password login... and Nonpassword login. It does not assign Login with non-restricted Shell because the user may be assigned to a restricted shell. login_all_apps assigns the login-all PAM right, which grants access to all PAM applications. It does not assign any UNIX system rights. All users are added to the login_all_apps role so if they are granted login rights, they have access to all PAM applications, which is the default for users in classic zones. If PAM access rights are restricted by another role assignment, the restricted role assignment will override the rights granted by login_all_apps. DirectManage Access uses the following role-assignment rules when migrating roles and rights from a classic zone to a hierarchical zone: Role assignment in classic zone Enabled or disabled Role assignment in hierarchical child zone User assigned to role Enabled Assign to the following roles: login_at_roles, which grants Password login and Non-password login UNIX system rights. login_all_apps, which grants access to all PAM applications. Corresponding user-created roles, which are migrated. User assigned to role Disabled Assign to corresponding user-created roles, which are migrated. No login roles are assigned because the user is disabled in the classic zone. User not assigned to role Enabled Assign to the default UNIX Login role, which grants all UNIX system login rights and access to all PAM applications. User not assigned to role Disabled Assign to the default listed role, which makes the user visible in the zone but does not assign any UNIX system rights or PAM access rights. In classic zones, users who are added to a zone is enabled for login access by default. As an administrator, you can leave a user profile defined in a zone but disable login access. All the roles and rights you defined in the source zone, as well as any role assignments to user-created roles, are added, as-is, to the child zone each time you run admigrate. For example, if you defined a privileged mount command in 20 classic zones, admigrate will copy that mount command to 20 new hierarchical zones. Therefore, after migration you should analyze your roles and rights to see if some of them can be moved up to the parent zone to take advantage of inheritance. Administrator s Guide for Linux and UNIX 70

71 Moving joined computers to new hierarchical zones Assigning audit rights when migrating Audit rights are a type of system right available in hierarchical zones but not in classic zones. Audit rights come in three levels: Select this Do not audit Audit if possible Audit required To do this Auditing is not requested nor required for a user in the role. Audit a user in the role if DirectAudit is installed and set up. If DirectAudit is not available, allow the user to log in without being audited. This option is selected by default for new roles. Always audit the user. If auditing is not available, a user in this role is not allowed to log in. During migration, the default right, Audit if possible, is assigned to all migrated roles. To change the audit right for a role, or for more information, see Configuring audit levels on page 148. Moving joined computers to new hierarchical zones Once you have migrated data from all your classic zones to new hierarchical zones, you can move the computers themselves to the new zones. Use the command-line utility, adchzone to move a computer in a classic zone to a hierarchical zone. Note The adchzone command is part of the Centrify software package, so you must upgrade adclient to version 5.1 on each UNIX computer that you want to move. The syntax for adchzone is: /usr/share/centrifydc/adedit/adchzone -z zonename [-u user] [-p passwd] [-v] where: -z zonename Distinguished name of the zone to join. This is one of the child zones you just created. For example: cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com -u user Active Directory User Principal Name or Samaccountname of a user account with permission to delete the computer account in the classic zone and add a profile for the computer in the new zone. -p passwd Password for this user account. You will be prompted if you omit this parameter. For example, to join the finance zone that you created in Migrating users and groups, roles and rights, and NIS maps on page 65, open a terminal window on a computer joined Chapter 5 Migrating from classic to hierarchical zones 71

72 Deleting the old classic zones to a classic zone that was migrated to a new zone and run a command similar to the following: /usr/share/centrifydc/adedit/adchzone \ -z cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com \ -u administrator You will be prompted to supply a password for the specified user. After changing the zone, you can open the Access Manager console to see the computer in the Computers node of the new zone, or you can run adinfo on the computer: [root]# adinfo Local host name: rhe5 Joined to domain: acme.com Joined as: rhe5.acme.com Pre-win2K name: rhe5 Current DC: win-f72d7u7kl6m.acme.com Preferred site: Default-First-Site Zone: acme.com/unix/zones/global/finance Last password set: :08:34 PDT CentrifyDC mode: connected Licensed Features: Enabled When adchzone runs, it copies the UNIX profile from the old zone to the new zone, deletes it from the old zone, then stops and restarts adclient to flush the cache and update the zone information. The advantage of this approach over leaving the old zone (adleave) and then joining (adjoin) the new zone is that it is very quick and preserves all the join information without you having to specify join options. Deleting the old classic zones After migrating all your zones to new hierarchical zones and moving all joined computers to the new zones, you can delete the old classical zones. You can delete zones by using adedit or in the Console, which is shown in the following procedure. To delete a zone 1 On a Windows computer, open the Access Manager console and expand Zones. 2 Select the zone to delete, then right-click and select Delete. 3 At the confirmation message click OK. Cleaning up after migration Although admigrate automates the migration of most zone data, it can t do everything necessary to upgrade classical zones to hierarchical zones. The following is a checklist of tasks you might need to perform: Administrator s Guide for Linux and UNIX 72

73 Cleaning up after migration Clean up roles and rights management. The admigrate command copies all roles, rights, and role assignments to child zones. You should analyze your roles and rights and see how many of them have been copied into multiple zones. Roles and rights that are defined in the parent zone are available for assignment in all child zones. By moving role and right definitions to the parent zone you simplify your zone structure making it easier to understand the roles and rights that are a available for your organization. Set up new provisioning information. Delegate permissions on a zone-by-zone basis. For now, all zones are inheriting identical permissions from the parent zone. You can fine-tune permissions, if necessary, for some or all of the child zones. Chapter 5 Migrating from classic to hierarchical zones 73

74 Chapter 6 Managing computers This chapter describes how to add UNIX computers to Active Directory domains, manage computer account properties, and leave the domain. The following topics are covered: Understanding the join operation Deciding who can join computers to the domain Preparing computer accounts Joining a domain interactively or using a script Allowing password resets for computer accounts Designating a computer as a NIS server Changing the zone for the computer Changing the domain for a computer Leaving a domain Renaming a server Customizing configuration settings for a computer Running reports for computers Understanding the join operation To begin authenticating users and authorizing access to UNIX resources through Active Directory, UNIX computers must be added to the appropriate Active Directory domains in the Active Directory forest. You do this by 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. By default, the domain controller to contact is determined by the Active Directory site topology or the master domain controller specified for the zone you are joining. If the preferred domain controller is not available, the UNIX agent attempts to connect to the next domain controller. If no domain controller can be contacted or the connection takes too long to complete, the join operation fails. If the adjoin program can successfully contact Active Directory, it 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. 74

75 Deciding who can join computers to the domain 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 a Kerberos configuration file and krb5.keytab entries, 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 that only the Centrify agent has control of the account. Starts the Centrify UNIX agent adclient. Once a computer joins the domain, you can use the Access Manager 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 complete control and flexibility to manage access through Active Directory by adding AD users to the zone the computer joined, and defining and assigning roles that determine the access these users have on the UNIX computer. By default, the password on the computer account is updated with a new, randomlygenerated password every seven days to ensure security. You can customize how frequently the password for the account is changed through the Password change interval group policy or by modifying the configuration file, centrifydc.conf, on any managed system. For more information about defining access to a managed computer, see Chapter 9, Managing user profiles, and Chapter 10, Authorizing users. Deciding who can join computers to the domain 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. Chapter 6 Managing computers 75

76 Preparing computer accounts Since who can join a domain depends on your organization s policies and is enforced through Active Directory, Access Manager 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. Preparing computer accounts If joining the domain is restricted to privileged users, or if you want to specify computerlevel overrides in advance, you may want to prepare (precreate) computer accounts for your UNIX computers before they join the domain. By preparing the computer account before joining the domain, you can: Specify a particular user or group with permission to join the computer to the domain, so that users can add their own workstations to the domain without any special rights or permissions. 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. Specify a particular user or group with permission to manage computer overrides for the computer, which allows the specified user or group to add user profiles or make role assignments for the computer, ahead of time, that will take effect when the computer joins the domain. You can use Active Directory Users and Computers, the Access Manager console, or ADEdit to prepare and create computer accounts. If you use Active Directory Users and Computers to create the account, however, you need to modify the permissions for the account as described in Allowing password resets for computer accounts on page 80 before joining the domain. When you prepare a computer account by using the Access Manager console, you are presented options (in Step 3) to specify the following: Whether to prepare for joining the domain Whether to delegate permissions for managing machine-level overrides In general, it makes sense to select both options as it allows administrators, besides the administrator creating the computer account, to manage these two aspects of the computer Administrator s Guide for Linux and UNIX 76

77 Preparing computer accounts account. Depending on how you delegate permissions in your organization, you may assign different users or groups to each of these functions. However, it is possible to create a computer account and not delegate permission for machine overrides. In this case, the administrator who created the computer account is the only one who can make machine-level overrides, that is, add users and make role assignments for the computer. The console will show User and Role Assignment nodes for the computer, but no one other than the computer account creator can add users or make role assignments. Likewise, it is possible to delegate permissions for machine overrides without preparing the computer to join the domain. In this case, the computer icon appears in the zone, but an AD object and service connection point are not created. The designated administrator may add users and make role assignments for the computer. Who can add this computer to the domain depends on how permissions are set up for your domain (as described in the previous section, Deciding who can join computers to the domain). If any user with a valid domain account can add computers to the domain, then any user can, otherwise, only the administrator who created the computer may join it to Active Directory. To prepare a computer account using the Access Manager console: 1 In the console tree, select Zones and if necessary, Child Zones, to display the list of zones, then select the specific zone to which you want to add the computer account. 2 Select Computers, right-click, then click Prepare UNIX Computer. 3 Select one or both of the following options to specify the type of preparation to do: Prepare computer for adjoin to create or select a computer account to add to the selected zone. On a later screen, you may delegate permission to join a zone to a specific user or group. Delegate permission for machine overrides to delegate permission to manage machine overrides to a different user or group. The specified user or members of the specified group will be able to create user profiles and make role assignments that are specific to this computer. Click Next. 4 Choose whether to create a new computer object or select an existing one, by selecting one of the following objects: Create new computer object to create a new computer account in the domain, then click Next. Select existing computer object if the computer account already exists in the same domain or a different domain, but you want to add a zone profile and delegate permission to join the a domain and manage computer overrides. Click Browse to search for the existing computer object. After selecting an existing computer account, click Next to continue to Step 7 to select the user or group that should be allowed to join the computer to the domain. Chapter 6 Managing computers 77

78 Preparing computer accounts 5 If you are creating a new computer object, type the computer name to use for the new computer account and specify a location for the computer account object in Active Directory, then click Next. For example: For this Computer name Domain DNS name Create the computer object in the container Do this Type the host name to use for the computer account in Active Directory. Verify the domain name displayed is the appropriate domain for the computer account to join. Click Browse to navigate to a different Active Directory domain. Verify the DNS name for the computer account. You can modify the DNS name for the computer, if needed. For example, if computer names in DNS use a different suffix than the Active Directory domain, you may need to modify the default value displayed. Specify the parent container for the new computer account in Active Directory. In most cases, you should use the default parent container object: domain_name/computers Click Change to navigate to a different container object for the computer account. 6 Define service principal names for the specified computer. You can click Next to accept the list of default service principal names, or do one of the following (Press F1 to get help with any of the procedures for adding, removing, or modifying service principal names): Click Add to add a service type or add a new service name to an existing service type. Select a service principal name and click Edit to change the name. Select a service principal name and click Remove to delete the name. Click Default SPN to return the list to the default names. Clicking this button restores any service principal names that you removed and removes any service principal names that you added. 7 Select whether to allow a specific user or group to join the computer to the domain or use the precreated computer account and password to join the domain, then click Next. Select Allow this user, group, or computer to join the computer to the zone to delegate the permission to join the domain to a specific user, group, or computer account. If you select this option, you can click Next to give the permission to the default Domain Admins group, or click Browse to search for another user or group that you want to give permission to join the computer to the domain. Select Allow the computer to join itself to the zone to generate an automatic password reset on the computer account that allows the precreated computer s account and password to be used to perform a self-service join. This option is selected by default because it allows you to automate the join operation so that a user name and password are not required to join the domain. Administrator s Guide for Linux and UNIX 78

79 Joining a domain interactively or using a script 8 You can click Next to give permission to manage computer-level overrides to the default Domain Admins group, or click Browse to search for another user or group. Note This page only appears if you selected Delegate permission for machine overrides in Step 3. 9 Review your configuration settings, then click Next. 10 Review the confirmation of the operation performed, then click Finish. The computer account is created in Active Directory and a zone profile for the computer is added to the Access Manager console in the zone s Computers container. The user or group you have designated as the trustee can now join this computer to the domain using the adjoin --selfserve command line option, and the group you designated for machinelevel overrides can add users and role assignments to the computer. Joining a domain interactively or using a script As described in Understanding the join operation on page 74, you join a computer to the domain by running the adjoin command directly on a computer. 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 to automate joining a domain. Whether you join the domain interactively from the command line or using a script, you must specify the zone the computer should be part of (--zone zonename) unless you are using the self service option (--selfserve), in which case the computer is made a member of the zone where the precreated object was created. There are several additional arguments that you can use when joining a domain to specify information such as a user name and password for an account with permission to join the domain, or the Organizational Unit you want to place the computer in. For example, the following command connects to Active Directory as the user [email protected] to add the local computer to the LinuxDev zone and the sales.acme.com domain: adjoin --user [email protected] --zone LinuxDev sales.acme.com The adjoin program then prompts for the Active Directory password for the [email protected] account: Active Directory password: xxx 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 places the local UNIX computer account in a specific, previously-created zone called LinuxDev. This is most common format for the adjoin command line. Although you can specify the password for an account as part of the adjoin command line using the --password option, in most cases, you should avoid including it for security Chapter 6 Managing computers 79

80 Allowing password resets for computer accounts 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. For more information about using the adjoin command line options, see Appendix A, Using Centrify UNIX commands. If the adclient process 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 computer in another container, the join operation adds a new computer account to Active Directory in the domain_name/computers container. If the computer has a precreated computer account in Active Directory, you can run a command similar to the following to join the domain: adjoin --selfserve domain For example: adjoin --selfserve cendura.org Note that you must specify the domain to join but not the zone the computer is automatically joined to the domain in which the computer object was pre-created. See Preparing computer accounts on page 76 for information about preparing computer accounts. Allowing password resets for computer accounts 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. In addition, allowing a computer account to update its own properties enables DirectManage Access to display the agent version and maintain operating system information for the computer account. Note You should use the Prepare UNIX Computer wizard and select the Allow the computer to join itself to the zone option to allow a computer to manage its own account. 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. Administrator s Guide for Linux and UNIX 80

81 Allowing password resets for computer accounts 2 Select the computer account, right click, then select AD 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 After you have checked the Active Directory permissions for a managed computer account and modified them if necessary, you can assign zone administration rights to the account through Access Manager. To give administrative rights to the computer account: 1 Open the Access Manager console. 2 In the console tree, select Zones, and if necessary, Child Zones, then select and expand the zone in which you are interested. 3 Right-click, then click Delegate Zone Control. 4 Click Add, select Computer from the Find list, then click Find Now. 5 In the results, select Domain Computers, click OK, then click Next. 6 Click Join computers to the zone and optionally, Remove computers from the 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 the Planning and Deployment Guide. 7 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 --zone zonename --user computername$ --password computername For example, if the computer name is valencia and the Active Directory domain is arcade.com, you would run a command similar to the following: adjoin arcade.com --zone finance --user valencia$ --password valencia Chapter 6 Managing computers 81

82 Designating a computer as a NIS server Designating a computer as a NIS server If you are using one or more managed computers as a NIS server to provide agentless authentication to NIS client requests or to publish NIS network maps, you can identify those computers in the Access Manager console. To identify a computer that services NIS client requests in a zone: 1 Open the Access Manager console. 2 In the console tree, click Zones and if necessary, Child 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 AD Properties. 5 Click the Centrify Profile tab. 6 Check the Allow this computer to authenticate NIS users option, then click OK. By default, this setting adds the computer account as a member attribute of the domain/ Program Data/Centrify/Zones/ZoneName/Computers/ zone_nis_servers object. The zone_nis_servers object is a global Active Directory group. It can be converted to a universal group, if needed. For example, if you add a computer that is joined to a different domain than the other computers in the group, you are prompted to change the group type to universal. Note The Centrify Network Information Service, adnisd, must be running on the designated computer for the computer to service NIS client requests. If the adnisd process in running and receives a request, it will respond to the request with information from the current zone. Changing the zone for the computer When you join a domain, you must join a specific zone unless you are connecting through Auto Zone. Over time, you may want to migrate computer accounts from one zone to another. You can change the zone information for a computer at any time, if needed. You can change the zone for a computer in either of these ways: Through AD Properties By cut and paste (drag and drop) To change the zone for a computer through its AD Properties: 1 Open the Access Manager console. 2 In the console tree, click Zones and if necessary, Child Zones, then open the zone where the computer account is located. Administrator s Guide for Linux and UNIX 82

83 Changing the zone for the computer 3 Click Computers to display the list of computers in the details pane. 4 Select the computer that you want to modify, then right-click and select AD 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 Access Manager console, you must restart the Centrify UNIX 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. Note If the computer has role assignments defined, you may be prevented from moving the computer until you remove the role assignments. 8 Click Yes to acknowledge the need to restart the Centrify UNIX agent on the UNIX computer for the zone information to be updated. To change the zone for a computer by cut and paste: 1 Open the Access Manager console. 2 In the console tree, click Zones and if necessary, Child 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 right-click and select Cut. 5 Navigate to the new zone and select the Computers node, right-click and select Paste. After you change the zone in the Access Manager console, you must restart the Centrify UNIX 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. Note If the computer has role assignments defined, you may be prevented from moving the computer until you remove the role assignments. 6 Click Yes to acknowledge the need to restart the Centrify UNIX agent on the UNIX computer for the zone information to be updated. Chapter 6 Managing computers 83

84 Changing the domain for a computer Changing the domain for a computer Once a computer joins a domain, you must leave that domain by using the 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 or the Administrator account. 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 --zone corpit --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. 5 Type the Active Directory password for the user account you specified. For more information about using the adjoin and adleave commands, see Appendix A, Using Centrify 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 preadjoin condition. This includes reverting PAM, NSS, and Kerberos configuration files to their pre-adjoin states and deleting the /etc/krb5.keytab file. You must leave the domain before you can move a computer account to a new domain or remove the Centrify UNIX agent 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: Administrator s Guide for Linux and UNIX 84

85 Renaming a server 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 [email protected]: adleave --user [email protected] 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 and the Centrify UNIX agent is stopped. Renaming a server If you need to rename a UNIX server that is joined to a domain, you should first leave the domain, rename the server, then rejoin the domain. Otherwise, you could have issues with the service connection point or service principal name for the server. To rename a joined server 1 On the UNIX server open a terminal and run the following command as root to leave the domain: /usr/sbin/adleave 2 Rename the server. 3 In the terminal window, run the following command to rejoin the domain: /usr/sbin/adjoin domain -z zonename You will be prompted to enter your Active Directory credentials. Customizing configuration settings for a computer You can configure many aspects of the environment for individual computers by applying a Group Policy Object to a site, domain, or organizational unit that includes managed computers and enabling Centrify group policies. For example, you can use policies to customize PAM operations, the length of time to wait for connections between the Centrify UNIX agent and Active Directory, or how frequently to change the computer account password. For information about the group policies available and how to enable them, see the Group Policy Guide. If you are not deploying Centrify group policies, you can also customize the configuration settings in any computer s local configuration file. For more information about setting the parameters in the Centrify configuration file, see the Configuration Parameter Reference Guide. Chapter 6 Managing computers 85

86 Running reports for computers Running reports for computers To view information about computer accounts, you can run the following default report definitions or create your own custom reports: The default Classic Zone - Authorization Report for Computers lists which users are allowed to access each computer. The report includes details from the user s UNIX profile for each user listed, including the user s Active Directory user name, UNIX user name, zone, UID, shell, home directory and primary group.administrative tasks for each zone and the users or groups have been delegated to perform each task. This report does not work for hierarchical zones. The default Computers Report lists computer account information for each computer in each zone, including the computer account name in Active Directory, the computer s DNS name, the computer s operating system, and the version of the Centrify UNIX agent installed on the computer, if available. The Computer Summary Report lists the Active Directory name, DNS name, operating system and version, Centrify Agent version, join date, whether a license is required, and when the password was last changed for each computer. The Stale Computers Report lists the stale computers. You may also obtain information about the computers in your environment by running the Centrify Deployment report, which you can install and run independently of the Access Manager console; see Using Centrify Deployment report on page 200. For more information about generating and working with reports, see Generating predefined and custom reports on page 188. To see information about the audit level, rights, and roles that are in effect for each computer, run one of the following reports: Hierarchical Zone - Computer Effective Audit Level Hierarchical Zone - Computer Effective Rights Hierarchical Zone - Computer Effective Roles See Running reports for roles and rights on page 178 for more information. Administrator s Guide for Linux and UNIX 86

87 Chapter 7 Importing existing users and groups This chapter describes how to import users and groups from an existing identity store and map those users and groups to Active Directory users and groups with the Access Manager console. If you are not importing existing users and groups from local configuration files, such as /etc/passwd and /etc/group, or existing NIS domains, you can skip this chapter. The following topics are covered: Determining the source for existing user information Preparing to import users and groups Using the Import from UNIX wizard Checking for conflicts and matching candidates Mapping UNIX profiles to Active Directory accounts Resolving conflicts for pending users and groups Resolving other issues for pending users and groups Making imported information available to NIS clients Determining the source for existing user information In many cases, you may already have UNIX account information defined in local configuration files (such as /etc/passwd and /etc/group) or in a networked identity store, such as NIS, NIS+, or LDAP, or in both. If you do, you can import that information and map it to Active Directory users and groups. To prepare for migration, you first need to determine where each computer gets its user information. You also need to analyze the existing information to determine if there are any conflicts and how the existing user population should be mapped into zones. Once you have collected the appropriate information and determined your zone requirements, you can import the existing information into Active Directory and the appropriate zones using the Access Manager console and the Import from Unix wizard. Note The next sections describe the steps for importing users and groups from an existing identity store into a zone. For more detailed information about planning the migration of an existing user population, including how to analyze and consolidate existing information before importing, see the Planning and Deployment Guide. 87

88 Preparing to import users and groups Preparing to import users and groups With the Import from UNIX wizard, you can import directly from NIS servers and domains or from properly-formatted text files, such as local /etc/passwd and /etc/group files or files generated using the getent passwd and getent group commands. Each identity store may require its own zone, at least during initial deployment, and, therefore, is imported separately. To prepare for an import: Identify each source of user information and analyze the information to determine your zone requirements. Run getent passwd, getent group, or niscat commands to export user information and save it in properly-formatted text files. These commands enable you to import user information from multiple identity stores, for example, both local files and NIS domains, or from a source that cannot be imported directly, such as NIS+ servers and domains. Verify that you can access NIS servers and domain from the Windows network if you want to import information directly from NIS maps rather than export the information to a text file. Verify that you can access individual /etc/group and /etc/passwd files from the Windows network if you want to import information directly from individual /etc/ group and /etc/passwd files. Copy any text files from which you want to import information to a file share on the Windows network. Review the /etc/passwd, /etc/group, or text files you generated to remove account entries that don t need to be mapped to Active Directory accounts. You can automatically exclude system accounts with UID or GID values from 0 to 99 during the import process, but may want to remove other accounts prior to the import. You may also want to review the remaining entries to determine whether the entries map to existing Active Directory accounts or require new Active Directory objects. Using the Import from UNIX wizard You can import user and group information from local /etc/group and /etc/passwd files or from data exported from another identity store to a properly-formatted text file; see the previous section for information about identifying and preparing identity stores for import. Administrator s Guide for Linux and UNIX 88

89 Using the Import from UNIX wizard To import user and group information: 1 Open Access Manager console, expand Zones and if necessary Child Zones, and expand the zone into which you want to import users and groups. Select UNIX Data, right-click, then click Import from Unix. 2 Select the import source to use: Select Deployment Manager then click Browse to import information from Deployment Manager. If you use Deployment Manager to find computers in your environment, it stores information, including local users and groups, in a database file named datastore.sdf. Depending on your operating system, this file is located by default in one of these locations: C:\Users\userName\AppData\Roaming\Centrify\DeploymentManager or C:\Documents and Settings\User\Application Data \Centrify\DeploymentManager Click Next and go to Step 2. Select Network Information Service (NIS) to import information from an NIS server. If you select this option, you must also type the name of the NIS or NIS+ domain and the host name of the NIS or NIS+ server from which you want to import information into Active Directory. The NIS domain and server must be accessible from the Windows network for information to be imported successfully. Click Next and go to Step 4. Select UNIX configuration files to import information from text files, such as / etc/passwd and /etc/group. Click Browse to locate each file.the text files can be named with any file names you choose, but must be in the proper format for /etc/group and /etc/passwd files for fields to be imported correctly. Although the files can be imported independently, Centrify recommends you import both files at the same time. Click Next and go to Step 4. 3 If you selected Deployment Manager in Step 2, select the computers from which to import UNIX information. If you selected Network Information Service or UNIX configuration files in Step 2, go to Step 4. 4 Select the import options you want to use, then click Next. Chapter 7 Importing existing users and groups 89

90 Using the Import from UNIX wizard The available options vary depending on whether you are importing from UNIX files or from Deployment Manager or NIS. For example: Select this Include option types Users Groups Include system accounts Automatically shorten the Unix name to 8 characters To do this Specify whether to import users, groups, or both. Note: These options are available for NIS and Deployment Manager import only. When importing from UNIX files, you select whether to import only users, only groups, or both, on the previous page. The current page shows the choice you made. Import all accounts from the data source including accounts with UID or GID values from 0 to 99. This option is available only when importing from UNIX files. By default, the import wizard ignores accounts with UID or GID values from 0 to 99 during the import process. On most systems, UIDs and GIDs in this range are reserved for system or application accounts, such as root, tty, and ftp, which typically do not need to be imported and managed through Active Directory. If you select the Include system accounts option, these accounts will be included in the list of Pending Import Groups and Pending Import Users. You can then choose to map the accounts to Active Directory or remove them. Note There can be other system accounts with UID or GID values greater than 100. By default, the import manager can only automatically filter the accounts with UID or GID values less than 100. Even if you choose to allow automatic filtering, you may need to remove additional system accounts from the Pending Import list. Limit UNIX user and group names to a maximum of 8 characters. By default, the import wizard imports user and groups name as they are defined in the data source. In some operating environments, however, user and group names cannot be longer than 8 characters. If you have an environment that does not support user and group names longer than 8 characters, you can select Automatically shorten the Unix name to 8 characters to automatically remove any extra characters in the name during the import process. 5 Select a location for storing pending import data, then click Next. For example, to store pending data for the current zone in an XML file, select Store in XML file and specify the location for the file. If the file does not already exist in the default location, you are prompted to create it. To select another location for the XML file, click Browse. 6 Review the summary of information to be imported, and check the Check data conflicts while importing option if you want to check for conflicts and potential matching candidates during the import process, then click Finish. Note If you select the Check data conflicts while importing option in the Import from Unix wizard, the import process may take some time to complete if you have a large number of users or groups. If you don t check this option, you must check the status of users or groups before you can map them to users and groups in Active Directory. Administrator s Guide for Linux and UNIX 90

91 Checking for conflicts and matching candidates When you click Finish to close the Import from Unix wizard, all of the user and group information to be imported is placed in Active Directory or in an XML file as Pending Import. You can then decide how each user and group should be mapped to accounts in Active Directory. Checking for conflicts and matching candidates The process of moving information from Pending Import to UNIX profiles in Active Directory is a manual one. It requires you to review each group and user object and determine how it should be handled. To move a user or group from Pending Import to a UNIX profile attached to an Active Directory user or group account, you must first check for potential conflicts and for potential matching user or group candidates in Active Directory. After this initial check, you need to resolve any conflicts and determine the Active Directory group or user each pending group or user should be mapped to. To check the status of pending information: 1 In the Access Manager console, open UNIX Data > Users or UNIX Data > Groups under the zone where you imported user and group information. For example, if you imported information for the Finance zone, open that zone, then expand the UNIX Data and Groups or Users node. 2 Select Pending Import to display the list of users or groups to be imported. If you did not select the Check data conflicts while importing option in the Import from UNIX wizard, the Pending Import list will not display any status. For example: If you did not check the data in the Import from UNIX wizard, no status is displayed. Check for conflicts and potential matches in Active Directory If the Pending Import list displays other icons and the result of the initial check for the Status column, you can skip to Mapping UNIX profiles to Active Directory accounts on page 92. If the current status is not displayed for the groups and users to be imported, you must check the status before continuing. 3 Select a user or group in the Pending Import list, right-click, then click Check status. If you select a Pending Import group, Access Manager checks for an Active Directory group with a common name (CN) or samaccountname that is the same as the UNIX group name. Chapter 7 Importing existing users and groups 91

92 Mapping UNIX profiles to Active Directory accounts If you select a Pending Import user, Access Manager checks for an Active Directory user with a common name (CN) that is the same as the pending user s GECOS field, or samaccountname that is the same as the UNIX user name. If there is a match, Access Manager displays that group or user as the default Active Directory candidate. For example: Icons indicate the results of the check The Status column indicates conflicts and potential issues y Note You can check the status of multiple users or groups at a time, but it is best to work with subsets of users and groups to reduce the impact on performance and improve the manageability of the import process. If a potential matching candidate is found in Active Directory, the status for the UNIX profile is Ready to import. If Access Manager can t identify a potential candidate in Active Directory or there are other issues, the status for the pending group or user displays a warning, such as No import candidate found. If a pending group or user cannot be imported because of a conflict, the status for the pending group or user describes the type of error encountered. Mapping UNIX profiles to Active Directory accounts After you check the status of a pending group or user, you can choose the appropriate action to take to map the pending group or user to an Active Directory group or user. The actions you can take depend on the object you select and its current state. For example, if you select a pending group, you can choose to: Accept the default Active Directory candidate for the selected group if a candidate is identified. Create a new Active Directory group and attach the selected UNIX group profile to it. Extend an existing Active Directory group to include the selected UNIX group profile. Merge the members of the selected UNIX group with an existing UNIX group in Active Directory. Delete the selected UNIX group. View and modify the properties of the selected UNIX group. Note You should map pending group profiles to Active Directory groups before mapping pending user profiles to Active Directory users to ensure the necessary groups are available for Pending Import users. Administrator s Guide for Linux and UNIX 92

93 Mapping UNIX profiles to Active Directory accounts Accepting the Active Directory candidate If Access Manager finds a potential match for the group or user in Active Directory, it displays the matching candidate in the details pane. If the matching candidate is the appropriate group or user to map the pending group or user to, you can accept the suggested candidate. To accept the Active Directory group or user candidate suggested by Access Manager: 1 In the Access Manager console, open UNIX Data > Users or Groups under the zone where you imported user and group information. 2 Click Pending Import to display the list of users or groups to be imported. 3 Select the group or user in the Pending Import list. 4 Right-click, then click Accept. After you accept the Active Directory candidate for a pending group or user, the group or user is removed from the Pending Import list. Accepting pending group members If you accept the default Active Directory candidate for a pending import group, all of the pending members that have an Active Directory candidate associated with them are also imported, and added as members of the Active Directory group. If any of the group s members fail to be imported, the status of the pending import group is changed to Imported, but the group remains in the Pending Import list until the remaining members can be successfully imported. Modifying pending group members You can modify the members of a group while it is in a Pending Import or Imported state by selecting the group and viewing its properties. From the Properties dialog box, you can click the Members tab to add or remove members of the group or find and assign the Active Directory user each member of the group should be associated with. Creating a new Active Directory account If Access Manager did not find a potential match for the group or user in Active Directory, you may need to add a new Active Directory account for the pending group or user. To create a new Active Directory group or user object for the group or user you are importing: 1 In the Access Manager console, open UNIX Data > Users or Groups under the zone where you imported user and group information. 2 Click Pending Import to display the list of users or groups to be imported. 3 Select the group or user in the Pending Import list. Chapter 7 Importing existing users and groups 93

94 Mapping UNIX profiles to Active Directory accounts 4 Right-click, then click Create new AD group or Create new AD user. When you select this action, you are prompted to provide the additional information needed to create the group or user account. For example, if you are creating a new group account you are prompted to specify: Location of the container for the group, typically Users. Active Directory name for the group. Pre-Windows group name. Scope of the group. Similarly, if you are creating a new Active Directory user account you are prompted to specify: Location of the container for the user, typically Users. Display name for the user. Initial password for the user. Windows logon name for the user. 5 Review your settings, then click Next. 6 Verify that the option to Enable the Active Directory group or user is selected, then click Finish to add the group or user profile available to the zone and complete the import process. Select to enable the UNIX profile Note Enabling the Active Directory group or user for the zone moves the UNIX profile out of the Pending Import list. If you skip this step, the UNIX profile remains in the Pending Import list until you accept the Active Directory candidate at a later time. Adding a profile to an existing Active Directory account If Access Manager did not find a potential match for the group or user in Active Directory but an appropriate Active Directory account exists, you need to select the Active Directory group or user account that should be extended to include the UNIX profile. Administrator s Guide for Linux and UNIX 94

95 Mapping UNIX profiles to Active Directory accounts To extend an existing Active Directory group or user object to include the UNIX profile you are importing: 1 In the Access Manager console, open UNIX Data > Users or Groups under the zone where you imported user and group information. 2 Click Pending Import to display the list of users or groups to be imported. 3 Select the group or user in the Pending Import list. 4 Right-click, then click Extend existing AD group or Extend existing AD users to add the selected profile to an existing Active Directory group or user. Note If an Active Directory user has more than one UNIX profile in a zone, the user must log on to computers in the zone with the UNIX profile name he wants to use. Logging on with the Active Directory user login name (the user s samaccountname) may prevent the user from accessing some files because the account has multiple UNIX profiles associated with it. 5 Click Next if Access Manager displays the appropriate group or user to map the UNIX profile to or click Find Now or Advanced Search to find the Active Directory group or user to which you want to add the UNIX profile. Type a search string to locate the account, then click Find Now. Select the appropriate Active Directory group or user to which you want to add the UNIX profile, then click OK. Check the Active Directory group or user account displayed, then click Next. 6 Review how the pending group or user will be mapped to the Active Directory group or user, then click Next to import the information. 7 Click Finish to add the group or user and enable the UNIX profile for the zone. If you do not enable the group or user to use Access Manager, the new Active Directory group or user becomes the default candidate for importing at a later time by clicking Accept. Merging pending group members into an existing group If Access Manager did not find a potential match for a Pending Import group in Active Directory, you may want to merge the members of the Pending Import group into a group that already has a UNIX profile in the zone. To add the members of a selected group to a UNIX group profile that already exists in the zone: 1 In the Access Manager 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. Chapter 7 Importing existing users and groups 95

96 Mapping UNIX profiles to Active Directory accounts 3 Select the group in the Pending Import list. 4 Right-click, then click Merge into existing Unix group. 5 Select the UNIX group to which you want to add members, then click Next. 6 Review your settings, then click Next. 7 Click Finish to update the UNIX profile for the zone. Deleting a UNIX profile for a pending group or user If there are no suitable candidates to map a UNIX profile to, you may want to remove a pending group or user from the Pending Import list. To remove a pending import group or user: 1 In the Access Manager console, open Users or Groups under the zone where you imported user and group information. 2 Click Pending Import to display the list of users or groups to be imported. 3 Select the group or user in the Pending Import list. 4 Right-click, then click Delete. 5 Click Yes to confirm the deletion. Viewing or modifying properties for a pending group or user If there are conflicts between a pending UNIX profile and information in Active Directory, you may need to modify the properties associated with the pending group or user before you can take any other action. To display or modify the details about a pending group or user: 1 In the Access Manager console, open Users or Groups under the zone where you imported user and group information. 2 Click Pending Import to display the list of users or groups to be imported. 3 Select the group or user in the Pending Import list. 4 Right-click, then click Properties. If you select a pending group, the properties include the UNIX profile, the time of the import, the file location the information was imported from, the members of the group, and the status of the group. If you select a pending user, the properties include the UNIX profile, the time of the import, the file location the information was imported from, and the status of the user. Administrator s Guide for Linux and UNIX 96

97 Resolving conflicts for pending users and groups Resolving conflicts for pending users and groups After you check Active Directory for potential conflicts and matching candidates, you may have several users and groups that indicate there are issues that need to be resolved before the user or group can be imported. There are several reasons why a pending user or group cannot be imported immediately. For example, pending groups cannot be imported if: The group s GID is negative. There is another UNIX group with the same GID already defined in the zone. There is a UNIX group with the same group name already defined in the zone. The matching Active Directory candidate already has a UNIX profile in the zone. Similarly, pending users cannot be imported if: The user s UID is negative. The user s primary group GID is negative. There is a UNIX user with the same user name already defined in the zone. These types of errors ( ) must be resolved before you can import the user or group. To resolve these issues, you can modify the properties for the pending user or group, modify the properties of the user or group profile that conflicts with the pending user or group, delete the pending user or group rather than import it, or remove the existing profile that conflicts with the pending user or group. For example, assume you are importing a passwd file that includes the UNIX user account pierre with the UID 1001, but there is already an UNIX profile in the zone with the UNIX name pierre and UID of 500. When you check the status for the pending user pierre, its status will indicate there is an error. To resolve a conflict that is preventing a group or user from being imported: 1 In the Access Manager console, open UNIX Data > Users or Groups under the zone where you imported user and group information. 2 Click Pending Import to display the list of users or groups to be imported. 3 Select the group or user, right-click, then click Properties. 4 Change the information for the pending group or user to eliminate the conflict, then click OK. For example, change the UNIX user name of the pending import user pierre to another name, such as pierre2. 5 Click Check status to check for any additional issues that may need to be resolved. Once you have resolved any issues that prevent an account from being imported, you then need to determine an appropriate course of action. For example, you need to determine Chapter 7 Importing existing users and groups 97

98 Resolving other issues for pending users and groups whether the conflicting pierre user accounts are used by the same person or refer to different users, so you can decide whether to remove one of the profiles from the zone or if a separate zone is needed. Resolving other issues for pending users and groups In addition to the errors that prevent a pending user or group from being imported, there are several conditions that generate a warning ( ) to indicate that there are issues you may want to resolve before importing. These issues do not prevent you from importing the user or group, but indicate potential problems that you should try to resolve before importing the pending user or group by taking an appropriate action. When you check the status for a pending user, you may see a warning displayed if: No matching Active Directory candidate is found. To import the user, you need to identify or create an Active Directory user for the pending user. There is a password hash in the zone-specific attribute for the matching Active Directory user that is different from the password hash for the pending import user. If you accept the matching Active Directory candidate and import the pending user, the Active Directory user s password hash will be overwritten. There is another pending user with the same UID or the same UNIX user name. Before importing, you should resolve the UID or user name conflicts between the pending users. There is a UNIX user with the same UID already defined in the zone. Before importing, you should resolve the UID conflict between the existing UNIX profile and the pending user. The pending user belongs to groups that do not exist in the zone. Before importing, you should import all the pending groups the pending user is a member of. The matching Active Directory candidate already has a UNIX profile in the zone. When you check status for a pending group, you may see a warning displayed if: No matching Active Directory candidate is found. To import the group, you need to identify or create an Active Directory group for the pending group. There is another pending group with the same GID or the same UNIX group name. Before importing, you should resolve the GID or group name conflicts between the pending groups. There is a UNIX group with the same GID already defined in the zone. Before importing, you should resolve the GID conflict between the existing UNIX profile and the pending group. The matching Active Directory candidate already has a UNIX profile in the zone. Administrator s Guide for Linux and UNIX 98

99 Making imported information available to NIS clients In many cases, warnings do not require you to make changes to the properties of a pending user or group. For example, if a group displays the warning that no import candidate is found, it simply means that you need to decide on the appropriate action, such as creating a new Active Directory group or merging the pending group s members into the UNIX profile of another group. If you do need to make changes to a pending user or group to correct any of these potential problems, however, you should click Check status after the change to check for any additional issues that may need to be resolved. Making imported information available to NIS clients You can make user and group information stored in Active Directory available to computers and applications without the Centrify UNIX agent through NIS client requests and the optional Centrify Network Information Service. The Centrify Network Information Service is a separate daemon process, adnisd, that can receive and respond to NIS client requests using the information stored in Active Directory. For more information about deciding whether to use the Centrify Network Information Service to service authentication requests, see the Planning and Deployment Guide. For information about configuring the Centrify Network Information Service and NIS clients, see Centrify Network Information Service Administrator s Guide. Chapter 7 Importing existing users and groups 99

100 Chapter 8 Managing group profiles This chapter describes how to give Active Directory groups access to Centrify-managed computers in Centrify zones and how to manage group profiles and properties using the Access Manager console. The following topics are covered: Creating group profiles for Active Directory groups Managing Active Directory group membership Adding groups from another trusted forest Modifying zone-specific settings for a group profile Modifying a group object s properties Customizing additional settings for groups Assigning groups to roles Running reports for groups This chapter focuses on adding and managing UNIX profiles and performing related tasks. For information about planning user and group migration and access controls, see the Planning and Deployment Guide. Creating group profiles for Active Directory groups You can create a Centrify group profile for any existing domain local, global, or universal security groups you have defined in the Active Directory forest. A group profile consists of zone-specific settings but the same profile information can be used across multiple zones. Creating a profile for an Active Directory group allows you to use Windows role-based access control and group-based filters to manage user access to managed computers. Associating a group profile with an Active Directory group also enables you to take advantage of nested group membership and group policies applied to a domain or organizational unit (OU) that contains Active Directory groups. A complete profile for a group consists of the GID and UNIX group name attributes that are defined for a group in the /etc/group file. Although associating Active Directory security groups with zone-based group profiles can be convenient in many organizations, you are not required to link group profiles to Active Directory groups. In addition, creating a profile for an Active Directory group does not create profiles for any members of the group. User accounts must be explicitly given their own profiles. 100

101 Creating group profiles for Active Directory groups Note This section provides a simplified view of managing Active Directory groups in Access Manager. In a complex environment, adding groups to a zone requires careful planning to create the zone structure, determine which UNIX groups (and users) to migrate to Active Directory, and which accounts to create for them in Active Directory. The Planning and Deployment Guide walks you through the complete process of creating a zone structure, importing users and groups, and creating Active Directory identities for them. You can create the profiles using the Access Manager console, Active Directory Users and Computers, ADEdit, or programmatically using the Centrify Windows API. To create a UNIX profile for a group using Access Manager: 1 Open the Access Manager console. 2 In the console tree, click Zones and select the zone name to which you want to add the Active Directory group. 3 Expand UNIX Data and select Groups, right-click, then click Create UNIX Group. 4 Type a search string to locate the Active Directory group for which you want to create a profile, then click Find Now. For example, type fin to display the Finance Users and Finance Admins groups. 5 Select one or more groups in the results, then click OK. 6 Review the zone profile settings for the group and make any changes, then click OK. You must supply a value for at least one of the fields, but you can leave a field blank and unchecked to give the group a partial profile for this zone. You can complete the profile by providing a value for this field in a child zone of the current zone. For example, if you use the same group name but different numeric identifiers on a set of computers, you can inherit the group name from a parent zone and set the different numeric identifiers in the child zones. If you selected more than one group, review the profile settings for the each group and modify the default settings, if necessary, then click OK. If you are adding groups with similar names, you might need to modify the UNIX group name to distinguish the groups. For example, if you are adding both the Finance Admins and Finance Users groups to the same zone, you can change the default UNIX group name to finadmin and finuser to make it easier to tell the groups apart. Keep in mind that in some operating environments group names cannot be more than 8 characters and special characters may not be supported. For more information about defining group membership for UNIX users or adding users to their primary group in Active Directory, see Adding Active Directory users to zones on page 109. For more information about the differences in group handling between Active Directory and the UNIX environment or planning access control using group filters, see the Planning and Deployment Guide. Chapter 8 Managing group profiles 101

102 Managing Active Directory group membership Managing Active Directory group membership One of the key benefits of using Centrify software to manage UNIX users through Active Directory is that you can take advantage of existing Active Directory structures and tools that you are using to manage your Windows environment. For example, you can use Active Directory groups for provisioning and controlling access to zones: The Zone Provisioning Agent (see Provisioning user and group profiles automatically on page 50) can be configured to automate the provisioning of users through Active Directory groups. Users who are added or removed from an AD group managed by the Zone Provisioning Agent, are automatically added or removed from a zone. See the Planning and Deployment Guide for detailed information about setting up zones to use the Zone Provisioning Agent. Use group membership to control access to computers within a zone. You can assign roles to Active Directory groups to control access to a zone for all members in the group. See Assigning users and groups to a role on page 160. Note that the role assignment itself is not sufficient to grant access to members of a group. Each Active Directory user in the group must have a user profile defined in the zone as well. Membership in a group does not necessarily mean a user has a zone profile, unless the group is linked to a zone through the Zone Provisioning Agent for automatic update; see Provisioning user and group profiles automatically on page 50. Identifying a primary group In most UNIX environments, a user s primary group identifier (GID) is a private group that exists solely for that user. The user is not included as a member of the private primary group. You can follow this convention by using a UNIX-only private group that is not linked to an Active Directory group or managed in Active Directory or assign users any Active Directory group with a group profile as a primary group. Because users are not added as members of their private primary group, the primary group identifier (GID) setting does not affect the user s actual Active Directory group membership, eliminating the need to manage primary groups for UNIX users through Active Directory. You set the primary group identifier in a user s profile when adding the user to a zone; see Adding Active Directory users to zones on page 109. The Planning and Deployment Guide discusses in detail best practices for identifying users primary groups depending on the environment. Using Zone Provisioning Agent to provision zones The Zone Provisioning Agent is a separate tool that enables automated provisioning of user and group accounts into Centrify zones. You configure the Zone Provisioning Agent to Administrator s Guide for Linux and UNIX 102

103 Marking a group profile as required monitor specific Active Directory groups that are linked to a zone. When you add or remove users or groups from the monitored groups, the Zone Provisioning Agent adds or removes corresponding users or groups in the zone. You can configure the business rules for adding and removing groups and how the attributes associated with a user profile or a group profile are generated. See Provisioning user and group profiles automatically on page 50 for more information The Zone Provisioning Agent is also explained in detail in the Planning and Deployment Guide. Marking a group profile as required On most UNIX systems, a user can only be a member of a limited number of groups at once. Because of this limitation, it is useful to be able to change a user s effective group membership to add and remove groups when necessary. You can use the adsetgroups command to dynamically manage the set of Active Directory groups that are available to a UNIX account. You also have the option to specify that membership in a specific group is required in a zone. If you specify that a group is required, users who are members of the group cannot remove the required group profile from their currently active set of groups. To mark a group as required: 1 Open the Access Manager console. 2 In the console tree, click Zones and expand the zone name for which you want to add a required group. For example, expand the default zone. 3 Expand Groups, then select the group name you want to make required. 4 Right-click, then select Zone Profile to display the Centrify Profile for the group. 5 Check the Users are required to be members of this group option. 6 Click Permissions to set specific permissions for this group, if needed, then click OK. For more information about using the adsetgroups command, see Using adsetgroups on page 343 or the adsetgroups man page. Adding groups from another trusted forest In most cases, when you create a profile for a group in a zone, the Active Directory group already exists in the local Active Directory forest. You can, however, also add profiles for remote groups to a zone without adding them to the local forest. If you have established a two-way external or forest trust relationship with a remote Active Directory forest, you can add groups from that remote forest to Centrify zones. You add remote groups to the zone in the same way you add profiles for local Active Directory groups except that you must select the remote forest or domain before searching for the group. Chapter 8 Managing group profiles 103

104 Modifying zone-specific settings for a group profile To add groups from another trusted forest to a zone: 1 Open the Access Manager console. 2 In the console tree, click Zones and select the zone name to which you want to add the Active Directory group. For example, select the default zone. 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 Create UNIX Group. 4 In the Find Users dialog box, 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 groups from the w2k3r2.dev forest to a current zone in the local forest. 5 Type a search string to locate the group in the selected forest or domain, then click Find Now. 6 Select one or more groups in the results, then click OK. 7 Review the UNIX profile settings for the group and make any changes necessary, then click OK. Modifying zone-specific settings for a group profile You can modify the zone-specific settings in a UNIX profile for an Active Directory group using the Access Manager console, ADEdit command-line utility, Active Directory Users and Computers, or programmatically using the Centrify Windows API. To modify the zone-specific settings for a group profile: 1 Open the Access Manager console. 2 In the console tree, click Zones and if necessary, expand Child Zones to select the zone that contains the group profile you want to modify. Then expand UNIX Data > Groups, select the group name, and right-click and select Zone Profile. 3 Edit the UNIX profile as needed, then click OK. For example, click Permissions to set any special permissions on the selected group. Overriding a group profile definition When you add a group and create a zone profile in a zone, the profile is inherited by any child zones. It generally does not make sense to change the profile for a group in a child zone as there are only two profile fields, but if you wish you can override either of the Administrator s Guide for Linux and UNIX 104

105 Modifying a group object s properties profile fields to create a new identity for the group in a child zone or for a computer account, by adding the group to a child zone or a computer account. Modifying a group object s properties You can modify the group profile or group object properties for an Active Directory group using the Access Manager console, the ADEdit command-line utility, Active Directory Users and Computers, or programmatically using the Centrify Windows API. To modify a group object s AD properties: 1 Open the Access Manager console. 2 In the console tree, click Zones and if necessary, expand Child Zones to select the zone that contains the group profile you want to modify. Then expand UNIX Data > Groups, select the group name, and right-click and select Zone Profile. 3 Select a group name, right-click, then click AD Properties. 4 Click the Centrify Profile tab. Edit the UNIX profile and any other properties, as needed, then click OK. For example, click Add to add a group profile for the Active Directory group to another zone, or click Members to add members to the group. Customizing additional settings for groups You can configure many aspects of the environment for individual groups by enabling and applying Centrify group policies. For example, you can set group policies to bypass Active Directory authentication for specific groups or to allow users in some groups to be approved from prevalidation. For more information about working with group policies, see the Group Policy Guide. If you are not deploying Centrify group policies, you can also customize access controls for users and groups with the settings in any computer s local Centrify configuration file. For more information about setting the parameters in the Centrify configuration file, see the Configuration Parameter Reference Guide. Assigning groups to roles You can centrally manage the operations users can perform on managed computers through the creation of roles that define specific rights. You can then assign groups to different roles to control which operations the members of the group are allowed to perform, the computers where they are allowed to perform those operations, and when they should be allowed or denied permission to perform those operations. Chapter 8 Managing group profiles 105

106 Running reports for groups For more information about defining rights and roles and assigning groups and users to roles, see Chapter 10, Authorizing users. For details on assigning groups to roles, see Assigning users and groups to a role on page 160. Note You can assign Active Directory groups to roles without defining a user profile for the users contained in the group. However, the Active Directory user must have a complete user profile in the zone for rights and roles to be enforced. The profile may be defined explicitly in the zone in which the role is assigned, or inherited from a parent zone. Select a zone and right-click and select Show Effective UNIX User Rights to see users who have a role assigned for the zone and a complete profile. Select Show Omitted Users to include users who have a role but an incomplete profile (shown in red) or a complete profile but no role. Running reports for groups To view information about group accounts and profiles, you can run one or more default reports or create your own custom reports. The default Groups Report lists group profile information for each group in each zone, including the following: Active Directory group name. UNIX group name. Numeric group identifier (GID). Whether the group is an orphan. For more information about generating and working with reports, see Generating predefined and custom reports on page 188. Administrator s Guide for Linux and UNIX 106

107 Chapter 9 Managing user profiles This chapter describes how to give Active Directory users access to managed computers in Centrify zones and how to manage user profiles and properties using the Access Manager console. The following topics are covered: Understanding user profiles Adding Active Directory users to zones Using Zone Provisioning Agent to provision zones Adding users from another trusted forest Adding multiple profiles for a user to a zone Modifying zone-specific settings for a user profile Modifying the user profile and object properties Working with read-only domain controllers Applying password policies and changing passwords Working in disconnected mode Mapping local UNIX accounts to Active Directory Setting a local override account Customizing other settings for users Assigning users to roles Setting runtime variables Running reports for users This chapter focuses on adding and managing UNIX user profiles and performing related tasks. For information about planning the migration of an existing user population and setting up user- or group-based access controls, see the Planning and Deployment Guide. 107

108 Understanding user profiles Understanding user profiles You can create a UNIX profile for any existing Active Directory user by adding the user to a zone, or to a computer account for the zone. The profile determines how the Active Directory user is identified on a UNIX computer and consists of the same NSS data that is defined for users on UNIX computers in the /etc/passwd file. A complete UNIX profile includes the following fields: Field Login name UID Primary group GECOS Value UNIX login name for this user in the current zone. The user identifier (UID) for this user in the current zone. The UNIX group profile to use as the primary group for this user. General information for the user similar to the UNIX /etc/passwd GECOS field. Home directory The default home directory for this user in the current zone. Shell The default login shell for this user. As explained earlier (see Understanding identity and access in hierarchical zones on page 35, a user s identity is determined by the profile tree, not by a profile in a single zone. By default, a user added to a parent zone inherits the same profile in a child zone so it is not necessary to add users to child zones. However, in a child zone, or in a computer account for the zone, you can add a user and override the definition of any of the profile fields to create a different identity for that user in the child zone or for that computer. For example, you could set the Shell field for a user to /bin/bash in a zone, but set it to / usr/bin/ksh on an AIX computer that joins the zone; or set the Home directory field to / home in a zone, and set it to /Users on a Mac OS X computer that joins the zone. It is possible to define a partial profile in a zone by leaving one or more of the NSS fields blank. A complete profile (all profile fields defined) is required to effectively identify a user when a computer joins a zone but a profile in a child zone, or for the joined computer, can complete the missing fields from the parent zone to create a complete profile. Although a complete profile uniquely identifies a user in a zone, the profile does not give a user access to computers in the zone. To have access to a computer, a user requires at least one role assignment in addition to a complete profile (see Chapter 10, Authorizing users. ). A user with a complete profile and at least one role is considered an effective user. To see effective user rights: Select a zone, right-click and click Show Effective UNIX User Rights. Select a computer account, right-click and click Show Effective User Rights. For more information about effective rights, see Identifying effective users on page 113. Administrator s Guide for Linux and UNIX 108

109 Adding Active Directory users to zones Adding Active Directory users to zones You can enable access to Linux and UNIX computers in any zone for existing Active Directory users by doing the following: Creating a UNIX profile for the Active Directory user Assigning the user a role There are several different ways you can add Active Directory users directly to a zone. For example, you can add users to a zone from Access Manager or Active Directory Users and Computers. You can also add users by running commands or executing scripts using the Centrify Access Module for PowerShell on Windows computers or the ADEdit application on Linux or UNIX computers. The steps in this section explain how to create an identity by adding an Active Directory user directly to a zone from Access Manager. This is a simple way you can create the UNIX profile if UNIX users already have an Active Directory account. For information on assigning a role, see Chapter 10, Authorizing users. To add users to a zone using Access Manager: 1 Open the Access Manager console. 2 Expand the Zones node, and if necessary the Child Zones node until the zone of interest is visible. 3 Expand the zone of interest and UNIX Data. Select Users, right-click and click Add User to Zone. 4 Type a search string to locate the user account, then click Find Now. For example, type qa to display the qa1, qa2 and qa3 users. 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. Chapter 9 Managing user profiles 109

110 Adding Active Directory users to zones For example: If you selected more than one user, repeat Step 6 for each user. Setting the profile attributes When you add an existing Active Directory to a zone, Access Manager displays a default new user profile. You can accept or change the default values for any of the profile attributes, as needed. The UNIX profile consists of the following attributes you can set. For this property Login name UID Primary group GECOS You can do this Set the UNIX login name for this user in the current zone. By default, it shows the login name of the user you are adding. Set the user identifier (UID) for this user in the current zone. Select the primary group for the user from one of the following options: <auto private group> sets the user s primary group name and GID to be the same as the user s UNIX login name and UID. Private groups are not stored or managed in Active Directory. <...> enables you to select a specific Active Directory group with a UNIX group profile. <not defined> enables you to type in a group identifier (GID) not associated with any Active Directory group. Enter general information for the user similar to the UNIX /etc/passwd GECOS field. You can specify variables in this field; for example: %{u:samaccountname} to set the user s GECOS field to their samaccountname. Administrator s Guide for Linux and UNIX 110

111 Adding Active Directory users to zones For this property Home directory Shell You can do this Set the default home directory for this user in the current zone. You can specify variables in this field; for example: %{home}/%{user} to set the home directory to the user s /home/username directory, where %home is set to the default value, /home. Select the default login shell for this user from the list of shells available. You can specify variables in this field. For example, %{shell} to set the user s shell to the default shell defined for this computer in this zone. Defining partial UNIX profiles Access Manager allows you to create a partial profile by leaving any of the fields blank. However, you must provide a value for at least one of these attributes or the wizard prevents you from going to the next page. If you intend to leave a field blank, leave its check box blank, otherwise, the wizard does not allow you to continue until you provide a value. If a user has an incomplete profile in a zone, any role assignments to that user will not be effective. Keep in mind, however, that a user can have an incomplete profile in a parent zone, and if any missing attributes are defined in a child zone, that user is enabled for role assignments in the child zone. Defining valid UNIX profile names User profile names can consist of letters, numbers, hyphens, underscores, periods and dashes. Some operating environments may have additional restrictions. For example, some operating environments do not support user names that are longer than 8 characters or require that the first character of the user name be alphabetic. Because UNIX user names typically use only lowercase characters, the default user profile name displayed follows this convention. If you modify the default profile name and include uppercase characters, keep in mind that the proper case must be used when entering the user name. For compatibility with Samba, the dollar sign ($) can also be used at the end of the user name. In general, other special characters, such as! and &, are not supported. If the Windows name includes unsupported special characters, Access Manager replaces them with underscores for the UNIX login name. For example, Access Manager converts a Windows logon name with special characters, such as qa:user2 into a valid UNIX login name of qa_user2. Using variables in a profile You can specify variables in several of the profile attributes. In addition, if default values are defined for users in the current zone, the corresponding values are in the default profile. For more information about using variables, see Setting runtime variables on page 128. Chapter 9 Managing user profiles 111

112 Adding Active Directory users to zones In more complex environments where existing legacy accounts must be migrated, more planning is typically required. If you are migrating existing login and service accounts, see the Planning and Deployment Guide. The Planning and Deployment Guide walks you through the complete process of creating a zone structure, importing users and groups, and creating Active Directory identities for them. You should also refer to the Planning and Deployment Guide if you plan to use the Zone Provisioning Agent to automate the process of creating user and group profiles when you add users to a monitored Active Directory group. Overriding a user profile definition When you add a user and create a zone profile in a zone, the profile is inherited by any child zones. You can override any of the profile fields to create a new identity for the user in a child zone or for a computer account, by adding the user to a child zone or a computer account. To override a profile definition 1 Open the Access Manager console. Expand the Zones node, and the Child Zones node until the zone of interest is visible. Or if you are overriding the profile for a computer account, expand the Computers node to see the computer of interest. 2 Expand the zone or computer of interest and expand UNIX Data. Select Users, rightclick and click Add User to Zone. 3 Type a search string to locate the user account, then click Find Now. For example, type rd to display the user rdavis. 4 Select the user and click OK. 5 The UNIX profile settings show that all fields are inherited from the parent zone. 6 Select one of the fields, Shell, for example, and type /usr/bin/ksh to give the user rdavis a different shell in this zone or for this computer. For example, the shell is now defined appropriately for an AIX computer. Administrator s Guide for Linux and UNIX 112

113 Adding Active Directory users to zones 7 Click OK to save the profile for this zone. Identifying effective users The Console provides a menu command, Show Effective UNIX User Rights, that allows you to see the effective users for any zone. An effective user is one who has a complete profile in a zone and has at least one role assigned for that zone. You cannot look at any particular nodes in a zone to determine effective users because effective users are determined dynamically, through inheritance and child zone and computer-level overrides. When you run Show Effective UNIX User Rights, Access Manager does the following to determine effective users: Traverses the profile tree from the top down to the selected zone to identify users and establish their profiles by determining which profile data is inherited from parent zones, and which data, if any, is overridden in a child zone or at the computer level. Traverses the access tree from the top down to the selected zone to determine the accumulated list of role assignments and rights for each user. Correlates the profile and access results to identify the users who have a complete profile for the current zone and computer, and determine their accumulated role assignments and rights. To show effective users for a zone or computer: 1 Open the Access Manager console. Expand the Zones node, and if necessary the Child Zones node until the zone of interest is visible. Chapter 9 Managing user profiles 113

114 Adding Active Directory users to zones 2 Select the zone of interest, right-click and click Show Effective UNIX User Rights. Note Access Manager shows the effective users for the zone in general it does not take into account role assignments that may have been added for a particular computer users in those roles will not be shown. To see effective users for a particular computer in the zone, select it from the drop-down list in Computer. 3 (Optionally) Select Show omitted users to include users who have an incomplete profile or do not have a role assignment. Users with an incomplete profile are shown in red. Select the user and the Zone tab to see which profile fields are missing. 4 Select a user and the following tabs to see information for the user for the selected zone or computer: Zone Profile lists the values for all UNIX user profile fields and the location in which they are defined. Role Assignments lists the user s role assignments for the selected zone or computer. The Object Assigned column shows whether the assignment is explicit Administrator s Guide for Linux and UNIX 114

115 Adding Active Directory users to zones or from an assignment to a group to which the user belongs (group@domain). Location of Assignment is the zone or computer role in which the assignment was made. PAM Access lists the PAM access (log on) rights granted by the roles to which the user belongs for the selected zone or computer. It shows the name of the right, the specific PAM applications that are allowed (* indicates all PAM applications), where it is defined, and to which role it belongs. Commands lists the command rights granted by the roles to which the user belongs for the selected zone or computer. It shows the name of the command, the path to the UNIX command defined for the command right, where it is defined, and to which role it belongs. Chapter 9 Managing user profiles 115

116 Using Zone Provisioning Agent to provision zones SSH Rights lists the SSH rights granted by the roles to which the user belongs for the selected zone or computer. It shows the name of the SSH right, the SSH applications that are allowed, where it is defined, and to which role it belongs. Viewing audit sessions If you are running DirectManage Audit, you can audit any zoned users. One way to automate this is to assign the Audit right, Audit if possible, or Audit required, to a role. Audit if possible is applied by default to all roles. You can view audit sessions in the Access Manager console if you want. To view audit sessions 1 On a Windows computer, open the DirectManage Access console. 2 Expand a zone, then expand UNIX Data > Users, then select a user, right-click and select View DirectAudit Sessions. Using Zone Provisioning Agent to provision zones The Zone Provisioning Agent is a separate tool that enables automated provisioning of user and group accounts into Centrify zones. You configure the Zone Provisioning Agent to monitor specific Active Directory groups that are linked to a zone. When you add or remove users or groups from the monitored groups, the Zone Provisioning Agent adds or removes corresponding users or groups in the zone. You can configure the business rules for adding and removing groups and how the attributes associated with a user profile or a group profile are generated. See Provisioning user and group profiles automatically on page 50 for more information The Zone Provisioning Agent is also explained in detail in the Planning and Deployment Guide. Adding users from another trusted forest In most cases, when you add a user profile to a zone, the Active Directory user already exists in the local Active Directory forest. You can, however, add remote users to a zone without adding them to the local forest. If you have established a one- or two-way trust relationship with a remote or external Active Directory forest, you can add users from that Administrator s Guide for Linux and UNIX 116

117 Adding users from another trusted forest remote forest to Centrify zones. You add remote user accounts to the zone in the same way you add profiles for local Active Directory users 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 zone: 1 Open the Access Manager console. 2 In the console tree, click Zones and select the zone name to which you want to add the Active Directory user. If necessary, expand Child Zones until you see the zone of interest. 3 Expand UNIX Data, then select Users, right-click and click Add User to Zone. 4 In the Find Users dialog box, click Browse, then select the remote trusted forest or a specific domain in the trusted forest, then click OK. For example, if there is a one- or 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 current zone in the local forest: Local forest Trusted 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. Note If you use attribute variables (see Setting runtime variables) to define any part of the user profile, keep in mind that the Centrify agent cannot directly read any of the attributes for a user from a one-way trusted forest. The agent can retrieve the userprincipalname and samaccountname from the zone profile for the user. However, it will be unable to retrieve other user attributes. Therefore, at runtime, when the agent attempts to resolve variable definitions, you could end up with no information in some Chapter 9 Managing user profiles 117

118 Adding users from another trusted forest of the fields. For example, if you use the displayname attribute for the GECOS field, it will be blank for a user from a one-way trusted forest. Identifying users from remote forests Users from a remote forest are identified in the Access Manager console with the following icon: Using valid logon names for users from a remote forest If you add users from trusted external forests to a zone, you should be aware that those users can only log on or be identified using: UNIX profile name enabled for the zone. Full Active Directory user name and home domain name. When users are defined in a local forest, they can be located in Active Directory by their UNIX profile name, their userprincipalname, or their samaccountname in the form of their user logon name alone or in its full pre-windows 2000 format of domainname\username, so any of these identities can be used to access user information or log on. To identify a user from a trusted external forest, however, you must use either the user s UNIX profile name for the zone or the user s samaccountname followed by the user s domain name in the form of samaccountname@domainname. Using the UNIX profile name or the samaccountname@domainname to identify a user ensures the name is unique when there are cross-forest trust relationships. For example, if an Active Directory user from a trusted external forest (sierra.org) has the Active Directory logon name of sofia.perez and a UNIX profile name of sofiapz, the user can be identified using: [email protected] sofiapz You cannot use sierra\sofia.perez or sofia.perez without the domain to retrieve information or authenticate from a remote forest. In addition, the userprincipalname (username@domainname) for any user may be different from the samaccountname@domainname. For example, if you use alternate UPN suffixes, the domain name used in the userprincipalname may be different from the domain name that uniquely identifies the user. Similarly, a user s pre-windows 2000 user logon name (samaccountname) may be different from the user name used in the userprincipalname. For example, if the Active Directory user [email protected] has a pre-windows 2000 user logon name of SIERRA\perez.s, that user would be found as [email protected]. Administrator s Guide for Linux and UNIX 118

119 Adding multiple profiles for a user to a zone Adding multiple profiles for a user to a zone It is possible for an Active Directory user to have more than one UNIX profile defined in a zone. If you attempt to add a new UNIX profile for an Active Directory account that already has a UNIX profile in the current zone, the Console displays a warning but allows you to continue. If an Active Directory user has more than one UNIX profile in a zone, however, the user should log on to computers in the zone with the UNIX profile name he wants to use. Logging on with the Active Directory user login name the user s samaccountname attribute might prevent the user from accessing some files because the account has multiple UNIX profiles and UIDs associated with it. ln most cases, users can log on with their Active Directory account name if you have created parent and child hierarchical zones that address conflicting profile attributes. However, if you are using classic zones or hierarchical zones that don t address the need for multiple UNIX profiles, users might encounter file ownership issues. Enabling and disabling users in classic zones If you have added user profiles to classic zones, you can enable or disable their UNIX profiles in those zones at any time. Enabling and disabling a UNIX profile is not applicable in hierarchical zones. To enable or disable the UNIX profile for multiple users in a classic zone, select all of the user names to enable or disable using the CTRL or SHIFT keys, right-click, then click Enable UNIX Account or Disable UNIX Account. Modifying zone-specific settings for a user profile You can modify the zone-specific settings in a UNIX profile for an Active Directory user using the Access Manager console, the ADEdit command-line utility Active Directory Users and Computers, or programmatically using the Centrify Windows API. The following procedure shows how to do so by using the Access Manager console. To modify the zone-specific settings in a user profile for an Active Directory user: 1 Open the Access Manager console. In the console tree, select Zones to display the list of zones, expand the zone of choice, and expand UNIX Data > Users. Chapter 9 Managing user profiles 119

120 Modifying the user profile and object properties 2 Select the user, right-click and click Zone Profile.: 3 Edit the UNIX profile as needed, then click OK. For example, click Permissions to set any special permissions on the selected user. Modifying the user profile and object properties You can modify the user profile or user object properties for an Active Directory user account using the Access Manager console, the ADEdit command-line utility, Active Directory Users and Computers, or programmatically using the Centrify Windows API. The following procedure shows how to do so by using the Console. To view and modify the Centrify and Active Directory object properties: 1 Open the Access Manager console. In the console tree, select Zones to display the list of zones, expand the zone of choice, and expand UNIX Data > Users. 2 Select a user name, right-click, then click AD Properties to display all of the properties for the selected user. Administrator s Guide for Linux and UNIX 120

121 Working with read-only domain controllers 3 Click the Centrify Profile tab. For example: 4 Edit the UNIX profile and any other properties, as needed, then click OK. For example, click Add to add a UNIX profile for the selected user to another zone. Working with read-only domain controllers If the Active Directory forest includes read-only domain controllers, you should force replications when adding or modifying users and groups in a zone. Forcing replication ensures that the new information is available right away. To force replication after updating a zone: 1 Click Start > Administrative Tools > Active Directory Sites and Services. 2 In the console tree, expand Sites, then select the Active Directory site that contains the connection over which you want to replicate directory information. For example, select DEFAULT-FIRST-SITE. Chapter 9 Managing user profiles 121

122 Applying password policies and changing passwords 3 Expand Servers, then select the domain controller for which you want to force replication. For example: 4 Click NTDS Settings. 5 In the details pane, right-click the connection over which you want to replicate directory information, then click Replicate Now. If you choose not to force replication, the changes made to the zone will not take effect until replication is complete for the forest. Applying password policies and changing passwords The Centrify agent 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, the agent 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. The Centrify agent 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, it 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 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. You can also change your own password at any time using adpasswd. Administrator s Guide for Linux and UNIX 122

123 Working in disconnected mode 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 the adpasswd man page. 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 [email protected] [email protected] 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 252. Working in disconnected mode Once an Active Directory user logs on to a UNIX computer successfully, the authentication is cached by the Centrify UNIX agent. 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. 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 Chapter 9 Managing user profiles 123

124 Mapping local UNIX accounts to Active Directory 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 take effect and the user is denied access or prompted to provide an updated password. Because changing the password for an Active Directory account requires a connection to an Active Directory domain controller, users cannot change their own Active Directory password when working in disconnected mode. Note If users log out of a session while disconnected from Active Directory, they can be authenticated using the information in the cache when they log back on because they have been successfully authenticated in a previous session. They cannot, however, be authenticated automatically to any additional services after logging back on. To enable automatic authentication for additional services, the user s credentials must be presented to the Key Distribution Center (KDC) then issued a ticket that can be presented to other services for unprompted, single sign-on authentication. Because the KDC is unavailable when disconnected from Active Directory, single sign-on authentication is also unavailable. You can configure many aspects of how credentials are handled, including how frequently they are updated or discarded, through Centrify group policies or parameter settings in the Centrify configuration file. For more information about using group policies and the group policies available, see the Group Policy Guide. For information about changing settings in the configuration file, see the Configuration Parameters Reference Guide. Mapping local UNIX accounts to Active Directory When you migrate local users to Active Directory, you typically ignore the default operating system accounts, which must remain as local accounts on the UNIX computers that join the Active Directory domain. If you wish, you can use Centrify group policies or configuration parameter settings to control any special handling for select local accounts. Note Although this mapping is especially useful for system and application service accounts, you can map any local user account to an Active Directory account. For example, you can use group policy or configuration parameters to map a local account to an Active Directory account, giving you Active Directory-based control over password policies, such as password length, complexity, and expiration period. Mapping a local account to Active Directory is especially useful for accounts that have special privileges, such as local system accounts or service accounts for applications. By mapping these types of accounts to an Active Directory account and password: You control access to the account because users need to know the Active Directory password for the account. You ensure Active Directory password policies are applied to the account password, so that each password is complex enough or changed frequently enough to be secure. Administrator s Guide for Linux and UNIX 124

125 Mapping local UNIX accounts to Active Directory You can specify that the password synchronization service keep passwords synchronized between the local accounts and the AD accounts by using group policy (Computer Configuration > Policies> Centrify Settings > DirectControl Settings > Login Settings > Set sync mapped users) or by setting the pam.sync.mapuser parameter on individual systems. Password synchronization requires the installation of either the Centrify Password Synchronization extension component or the Microsoft Password Synchronization Service on all domain controllers The Centrify Password Synchronization extension is selected for installation on the host by default when you install DirectManage Access features. If you do not have the Microsoft Password Synchronization Service installed on the domain controllers, you can use the Centrify Password Synchronization extension instead. Use Centrify autorun to install just the Password Synchronization extension or run the password extension standalone setup program, CentrifyDC_PasswordSync-ver-platform.exe (where ver is the suite version and platform is either Win32 or Win64) to install it. To map a local account to an Active Directory account, you can: Enable and configure the Set user mapping group policy in a Group Policy Object applied to one or more computers. Set the pam.mapuser.username configuration parameter on any individual local computer. You can also map user accounts by using the Deployment Manager. See the Deployment Manager User s Guide for more information. Configuring group policy to map local accounts This section shows how to use group policy to map local accounts. To map a local UNIX user account to an Active Directory user with the User Map group policy: Note This procedure assumes that you have installed the Group Policy Editor Extension, have a Group Policy Object linked to an appropriate site, domain, or organizational unit, and have installed the centrifydc_settings.xml administrative template. 1 Create an Active Directory user account if you do not have one map to. 2 Select the Group Policy Object and click Edit to open the object in the Group Policy Object Editor. 3 Select DirectControl Settings > Set user mapping policy, right-click, then click Properties. 4 Click Enabled, then click Add. 5 Type the local account name in UNIX User. Chapter 9 Managing user profiles 125

126 Mapping local UNIX accounts to Active Directory 6 Type the Active Directory account name or click Browse to look for the Active Directory user to map the local user to, then click OK. For example, if the local user name is oracle and the Active Directory account you created to map the user to is Oracle Admin: 7 Click Add to create other user maps or click OK to save this configuration. When users attempt to sign on using the local oracle account, they must provide the password for the Oracle Admin 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 creating and linking Group Policy Objects that include configuration settings, see the Group Policy Guide. Using the pam.mapuser parameter to map local accounts This section shows how to use a configuration parameter to map local accounts. To map a local user account to an Active Directory user by modifying the configuration file: 1 Create the Active Directory user account you want to use. For example, assume you want to use one Active Directory account for all of the oracle service accounts in a particular zone. If the zone name is central-div, you can create an Active Directory user account named oracle_central-div. 2 On the UNIX computer, open the configuration file /etc/centrifydc/ centrifydc.conf. 3 Locate the pam.mapuser.root configuration parameter and uncomment the line to change the default setting. 4 Modify the local account mapping to identify the local user account you want mapped to the Active Directory user you created. You can use environment variables such as $DOMAIN, $ZONE, or $HOSTNAME with this configuration parameter if you used the domain, zone, or host name in the Active Directory account name. For example, if you are mapping the local oracle service account and the Active Directory user account you created is named oracle_central-div: pam.mapuser.oracle: oracle_$zone Administrator s Guide for Linux and UNIX 126

127 Setting a local override account 5 Save the changes to the configuration file, then run the adreload command to reload the configuration file and have the changes take effect. For more information about editing configuration parameters, see the Configuration and Tuning Reference Guide. Setting a local override account In most cases, every computer should have at least one account that can be authenticated locally to ensure you can access the computer when the network or Active Directory is not available or the Centrify UNIX agent, adclient, 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 default root override account or add additional local users using the Allow localhost users group policy or by modifying the computer s agent configuration file. You should note that setting a local override account using syntax is supported on most Linux and UNIX platforms. It is not supported, however, on AIX computers. On AIX computers, if you enable and apply the Allow localhost users group policy or configure the pam.allow override property, attempting to log on with the local override account causes authentication to fail. Customizing other settings for users You can configure many aspects of the environment for individual users by enabling and applying Centrify group policies. For example, you can set group policies to bypass Active Directory authentication for specific users or allow some users to be preapproved for authentication on computers they have never used. For more information about working with group policies, see the Group Policy Guide. If you are not deploying Centrify group policies, you can also customize access controls for users with the settings in any computer s local Centrify configuration file. For more information about setting the parameters in the Centrify configuration file, see the Configuration and Tuning Reference Guide. Assigning users to roles Access Manager enables you to centrally manage the operations users can perform on managed computers through the creation of roles that define specific rights. You can then assign users to different roles to control which operations they are allowed to perform, the computers where they are allowed to perform those operations, and when they should be allowed or denied permission to perform those operations. For more information about Chapter 9 Managing user profiles 127

128 Setting runtime variables defining rights and roles and assigning users to roles, see Chapter 10, Authorizing users. For details on assigning users to a role, see Assigning users and groups to a role on page 160. Note You can assign Active Directory users to roles without defining a user profile for them. However, the Active Directory user must have a complete user profile in the zone for rights and roles to be enforced. The profile may be defined explicitly in the zone in which the role is assigned, or inherited from a parent zone. Select a zone and click Show Effective UNIX User Rights to see users who have a role assigned for the zone and a complete profile. Select Show Omitted Users to include users who have a role but an incomplete profile (shown in red) or a complete profile but no role. Setting runtime variables Access Manager maintains a set of runtime variables that you can use in place of specific values in user-profile attributes. You may also create your own variables at any level in the profile tree: parent zone, child zone, or computer object. Runtime variables are resolved by the Centrify UNIX agent when a UNIX computer joins a zone. The predefined runtime variables are: Use this variable %{domain} %{home} %{host} %{shell} %{site} %{user} %{zone} To specify this The domain to which the computer is joined. The root home directory; it is /home on all computers, except Mac OS X (/Users) and Solaris (/export/home). The host name of the joined computer. The shell for the user; it is /bin/bash on all computers except Solaris and HP (/bin/sh) and AIX (/usr/bin/ksh) The AD site of the joined computer. The user s UNIX name. The zone to which the computer is joined. At runtime, adclient resolves variables based on two configuration parameters and any variable definitions in the zone profile tree. The configuration parameters are: nss.runtime.defaultvalue.var.variablename A set of parameters one for each predefined variable that defines the default value for each parameter as shown in the table. These values are used if the variable is not explicitly defined in a the zone, or by the nss.runtime.var.variablename parameter in the configuration file. For example: nss.runtime.defaultvalue.var.home: /home nss.runtime.defaultvalue.var.shell: /bin/bash Administrator s Guide for Linux and UNIX 128

129 Setting runtime variables nss.runtime.var.variablename A configuration parameter that allows an administrator to specify a specific value for any of the predefined variables in the configuration file. The value in the configuration file is essentially a machine-level override as it applies only to the computer on which it is defined and overrides any other setting for the variable, including the default value, or a specific value in a zone Properties page; for example: nss.runtime.var.home: /Users nss.runtime.var.shell: /bin/sh To override the default definition for any predefined variable in a zone, you can simply add a variable with the same name to the zone, by using the zone Properties page or by using ADEdit. Zone variables, and zone variable definitions are inherited down the profile tree, which means that a variable could have one definition at the top of the tree and a different definition at the bottom. The value that is applied depends at which level of the zone hierarchy a computer joins the domain. You can also use any user attributes as variables, by using the following form: %{u:attributename} For example, in the GECOS field of a user s zone profile, you could specify the user s samaccountname, as follows: %{u:samaccountname} You can run the adquery user username -j command on a UNIX computer to see a list of user attributes; for example: adquery user qa1 -j Note Keep in mind when using attribute variables that if you add users to a zone from a one-way trusted forest, the Centrify agent will only be able to retrieve values for the userprincipalname and samaccountname attributes. Therefore, at runtime, when adclient resolves variable definitions, fields that contain any other variables will be blank for a user from a one-way trusted forest. To define zone-level overrides for predefined variables, or to define new variables 1 Open the Access Manager console. Chapter 9 Managing user profiles 129

130 Setting runtime variables 2 In the console tree, expand the Zones node, and expand the zone hierarchy as far as necessary to see the zone of interest. Select the zone and right-click, then click Properties. Select the Variables tab. 3 Click Add and type a variable name and value: Name: BizUnit Value: Marketing 4 To override the definition of a predefined variable, just add the name of a predefined variable, such as home, and enter a new value. For example, click Add and type: Name: home Value: /export/home. 5 Click OK to save the variable definition, and OK again to close the dialog box. Note You can edit or remove a user-defined variable from this page as well. Administrator s Guide for Linux and UNIX 130

131 Running reports for users To modify zone-specific settings for a user profile, see Modifying zone-specific settings for a user profile on page 119. To modify default user profile settings for a zone, see Setting zone properties on page 44. Running reports for users To view information about user accounts and profiles, you can run one of more default reports or create your own custom reports: The default Users Report lists information from the UNIX profile for each user in each zone, including the user s Active Directory user name, UNIX user name, UID, shell, home directory and primary group. The default User Account Report lists account details for the Active Directory users that have UNIX profiles in each zone. This report includes the Active Directory display name, the Active Directory logon name, the Active Directory domain for the account, and details about the account status, such as whether the account is configured to expire, locked out, or disabled and the date and time of the account s last logon. The default Hierarchical Zone - User Effective Rights report lists the effective rights for each user on each computer. The report shows the name of the right, it s type, and where it is defined. For more information about generating and working with reports, see Generating predefined and custom reports on page 188. Chapter 9 Managing user profiles 131

132 Chapter 10 Authorizing users This chapter describes how to establish role-based access controls for the managed computers in your environment. The following topics are covered: Understanding authorization Defining specific rights Creating roles for job functions in a zone Creating a computer role Assigning users and groups to a role Working within assigned roles Exporting and importing rights and roles Modifying rights, roles, and role assignments Viewing rights and roles Migrating from sudo to dzdo Running reports for roles and rights 132

133 Understanding authorization Understanding authorization You can centrally manage the operations that users can perform on Centrify-managed computers, including the ability to log in, through a system of rights and roles. A right represents a specific operation that a user is allowed to perform. Rights are classified as follows: System rights are built into role definitions and can be enabled or disabled, but users cannot add, modify, or delete them. System rights come in three categories: UNIX rights specify whether and how a user can log in to a computer (password or non-password login, or both) and determine whether a user logs into a normal shell or into a restricted shell. Rescue rights allow a user to log in to a computer to correct a problem in case of system failure. Windows rights specify rights for Windows users and are not discussed in the current document. See the Administrator s Guide for Windows for details about assigning roles to Windows users. Audit settings specify whether auditing is required for the role. Audit settings are built into role definitions and administrators can set the level (required, if possible, or not required), but cannot add, modify, or delete them. PAM Access rights identify the specific PAM-enabled applications a user can access. PAM rights can be created by administrators and added to any role. Commands identify specific commands a user can run and whether those commands can be run under the user s own account or as another user account. Commands can be created by administrators and added to a role for privileged execution, or to a role that defines a restricted environment. SSH-Rights are predefined and identify the specific SSH services that a user who is enabled for PAM SSH access can run. Although rights are fundamental to authorization, you cannot assign them directly to users. Rather, rights are combined into roles that reflect the needs of a specific job function, such as database administrator, or the ability to perform a particular task, such as log in, and it is roles that you assign to users. To access a computer, an Active Directory user must have an identity in the form of a complete UNIX profile and an assignment to at least one role that is valid in the zone to which the computer is joined. Note that the profile and the role assignment can be explicit for the zone or the computer itself, or inherited from a parent zone. A role can be assigned to individual Active Directory users or to Active Directory groups, in which case the role applies to all users in the group. In this way you can define UNIXspecific roles in Access Manager, but manage the users to whom they apply completely through Active Directory. Chapter 10 Authorizing users 133

134 Understanding authorization You can also assign roles to individual local users. In this case, you cannot assign PAM access rights or SSH rights to the role. You can still set the audit level for the role. The rights from multiple role assignments accumulate, which provides great flexibility and granularity in how you define and assign rights and roles. For example, one role could control login only, and another role could provide a set of privileged commands, such that a user assigned to both roles could log in and execute the privileged commands. In this way, not every role requires PAM applications or login system rights, as long as a user is assigned a role that has those rights. Understanding what roles provide Until you assign roles, no Active Directory users have rights that allow them to access the computers in their environment. Adding Active Directory users to a zone and creating UNIX profiles for them makes them candidates for access to the computers in the zone. Having a profile and a role assignment creates an effective user who can access computers and perform tasks on them. Although rights can be combined in a variety of ways, roles essentially fall into these categories: Roles that grant UNIX system rights and add PAM applications to allow Active Directory users to log in to their default shell. The predefined UNIX Login role is an example of this type of role. It gives users the rights to log into their default shell through any of the standard PAM applications (login, ftp, telnet, etc.) and to do so with or without a password. It also specifies an audit level for the role. The majority of the users from your UNIX environment probably require this role and no other as it grants them login access to their UNIX computer, and permission to execute the base set of commands that is defined for them in their UNIX environment. By default, this type of role also typically requests that users be audited if possible. Roles that grant users additional privileges to perform tasks they are not allowed to perform with their base set of rights by using the dzdo command (similar to sudo). Essentially, this type of role adds specific command rights to a default shell role and is appropriate for UNIX users who need elevated rights to perform specific tasks. This type of role can be applied to an Active Directory user or a local user. Roles that provide strictly controlled access to a defined subset of shell commands in a customized restricted environment shell (dzsh). This type of role is appropriate for users who need access to a limited set of commands to perform their job because it specifically identifies and limits the commands that can be executed. This type of role can be applied to an Active Directory user or a local user. Note There is one other type of role called a computer role, which is not strictly a role in the sense of a set of rights encapsulated in a role and assigned to a user or group rather it is a set of role assignments (a set of users with a set of roles) linked to a group of computers so it is not included in the current discussion of rights and roles, but is explained in detail Administrator s Guide for Linux and UNIX 134

135 Defining specific rights later; see Creating a computer role on page 156. Defining specific rights Rights describe specific operations that users in a given role are allowed to perform. You can define the following types of rights: PAM access rights to control who can access which PAM applications in a zone. Command rights to control who has permission to run specific commands in a zone. Note that these rights can be added for a role with a normal shell login, in which case the rights provide functionality similar to the UNIX sudo command but are configured using Centrify role settings and the zone s authorization store rather than through a sudoers configuration file. Or these rights can be added to a restricted shell environment, in which case these are the only commands that a user in the role is allowed to run. System rights which include UNIX rights that determine who can log in, whether they can do so with a password or non-password log in, and whether they must use a restricted environment or their default shell, and rescue rights that allow a user to log in when the auditing system is required but unavailable. Auditing rights which specify whether auditing is requested, required, or neither, in order to log in. The rights that you define are specific to the zone where you configure them, and to any child zones of that zone. Once configured, though, you can copy and paste (drag and drop) right definitions from one zone to another or export all or part of the information to a file and import it into other zones, as needed. Configuring rights for access to PAM applications At least one of a user s roles must explicitly add PAM access rights to the role, otherwise the user has no access to PAM-enabled applications and no way to log in to a computer. You can add the predefined login-all PAM right to a role to give users in the role access to all PAM-enabled application, or you can create separate rights for each PAM application: ftp, sshd, login, and so on, and assign them to roles as appropriate. To define a right for access to a PAM application: 1 Open the Access Manager console. In the console tree, select Zones to display the list of zones, expand the zone of choice, and expand Authorization > UNIX Right Definitions. 2 Select PAM Access, right-click, then click Add PAM Access Right. Chapter 10 Authorizing users 135

136 Defining specific rights 3 Enter the following information: For this Name Application Description Do this Type your name for the application. It can be different than the application name. The name of a PAM-enabled application. You can use wildcards in this field to perform pattern matching for the application name. For example, you can specify *ftp* to match all PAM-enabled applications containing the string ftp, such as vsftpd, ftpd, and ftp. The Application Name field supports glob pattern matching syntax. For example, the name can contain a question mark (?) to represent any single character, an asterisk (*) to represent any string, including an empty string, or an expression enclosed by brackets ([...]). For more detailed information about using wildcard patterns and glob syntax, see the glob man page. Specific application names depend on the application and the operating environment where the application is being accessed. For example, the table that follows lists several common PAM-enabled applications and the appropriate name to use for them on different platforms An optional description of the application. The following table lists common PAM-enabled applications and the appropriate name for them on different platforms: For this application On Use this name telnet ftp graphical desktop Common Linux platforms, such as Red Hat, Debian, SuSE, Centos, and Ubuntu, HP-UX, and Irix Sun Solaris VMware ESX, Oracle Linux, Scientific Linux Common Linux platforms, such as Red Hat, Oracle Linux, and Scientific Linux, and VMware ESX Some Linux platforms, such as Debian, Centos, and Ubuntu, Sun Solaris, HP-UX, Irix Common Linux platforms, such as Red Hat, Debian, Oracle Linux, Centos, Scientific Linux, and Ubuntu Sun Solaris and HP-UX SuSE and Irix login telnet remote vsftpd ftp gdm dtlogin xdm ssh Most platforms sshd Debain and Ubuntu ssh Depending on the specific operating environment and version you are using, however, you may need to modify the default application name. Administrator s Guide for Linux and UNIX 136

137 Defining specific rights The predefined right, login-all, enables access to all PAM applications, by specifying an asterisk (*) in the Application field. You can add this right to any role to enable access to all PAM applications for the role. This right is added to the predefined UNIX Login role. Note The ssh right allows a user in the role to log in with SSH. You can also add one or more SSH rights to restrict a role with SSH access to specific SSH services; see Finetuning SSH access with SSH rights on page Click OK to save the PAM access right. After you define a new PAM right, it is available to add to any role in the zone or in any child zones. You can also copy and paste or drag and drop a PAM right from one zone to another. Simply select the right definition and click Copy from the right-click context menu, then select the Authorization/Right Definitions/PAM Access node in a different zone and click Paste. To add a PAM right to a role 1 Open the Access Manager console. In the console tree, select Zones to display the list of zones, expand the zone of choice, and expand Authorization > Role Definitions. 2 Select a role, right-click and click Add Right. The Console displays a list of all PAM rights and command rights that are available to add to the role. 3 Select one or more PAM rights and click OK. Note that the predefined login-all right grants access to all PAM applications. To see the rights, including PAM rights, for any role, select the role in the Console tree and the rights are shown in the right pane. To remove a right, select it, right-click and click Delete. Fine-tuning SSH access with SSH rights By default, when a user is granted the PAM ssh access right, the user has access to all SSH applications. However, an administrator can add SSH-Rights to a role to limit users in the role to specific SSH applications. SSH rights work in conjunction with the PAM ssh right. If a user does not have the PAM ssh right assigned in any roles, then applying the SSH rights has no effect. When a user attempts to log in with SSH, adclient first verifies that at least one role for the user has the PAM ssh right. It then checks to see which SSH rights the user has before allowing or denying the action the user is attempting. The following table lists the SSH rights that are available. You can apply multiple SSH rights to a given role. SSH rights can only be applied to Active Directory users and therefore cannot be applied to a role that accepts local users. Chapter 10 Authorizing users 137

138 Defining specific rights Table 1. SSH Rights Select this dzssh-all dzssh-direct-tcpip dzssh-exec dzssh-scp dzssh-sftp dzssh-shell dzssh-subsystem dzssh-tcip-forward dzssh-tunnel dzssh-x11-forwarding To do this Allow all SSH services. Allow local and dynamic port forwarding (ssh-l, ssh -D) Allow command execution. Allow scp connection Allow sftp connection Allow terminal (tty/pty) connection Allow external subsystem except sftp subsystem which has its own right. Allow remote port forwarding (ssh -R). Allow tunnel device forwarding. Allow X11 forwarding. Note Be certain that you have installed the Centrify-compiled version of OpenSSH. The Centrify version of OpenSSH is installed by default with the Centrify UNIX agent. The default secure shell rights are only applicable for the Centrify-compiled version of SSH. Adding SSH rights to the Console Although SSH rights are predefined, they are not visible and available for assignment in a zone by default. To make them available, follow the steps in this procedure. To add predefined SSH rights to a zone 1 In the Access Manager console, select Zones to display the list of zones, expand the zone of choice, and expand Authorization and select UNIX Right Definitions. If SSH rights have already been added you will see the SSH Rights node. If not, go to the next step. 2 Right-click and select Generate predefined rights. SSH rights are now available to add to roles. Applying SSH rights to a role You can apply SSH rights to any role as long as the role does not accept local users. Although SSH rights require the PAM ssh right to be effective, the role to which you add SSH rights does not necessarily require the PAM access right. As long as one role for a user contains the PAM ssh right, then applying SSH rights to any role for the user will be effective. In addition to adding the rights to a role, to make SSH rights effective, you must set a parameter in the sshd configuration file; generally, you use a group policy setting to set this parameter for all your UNIX computers, though you may also set this parameter on an Administrator s Guide for Linux and UNIX 138

139 Defining specific rights individual computer by editing the configuration file as explained in the following procedures. To apply SSH rights to a role 1 In the Access Manager console, select Zones to display the list of zones, expand the zone of choice, and expand Authorization > Role Definitions. 2 Select the role that requires SSH rights, then right-click and select Add Right. All available rights appear in the window. Note If SSH rights are not shown, it may be that SSH rights are not visible in the Console (see the previous section, Adding SSH rights to the Console on page 138). Also, keep in mind that because SSH rights cannot be applied to local users, if a role accepts local users, SSH rights cannot be applied to the role and no SSH rights will appear in this window. In this case, select or create a different role to use. 3 Select one or more SSH rights from the list. 4 Click OK to add the selected SSH right or rights to the role. Use group policy to set the ServiceAuthLocation parameter for all computers 1 On a Windows computer, open the Group Policy Management Editor and edit a group policy object that applies to your UNIX computers. 2 Expand User Configuration > Policies > Centrify Settings > SSH Settings and doubleclick Enable application rights. 3 Click Enable, then click OK. This setting adds the following parameter to the /etc/centrifydc/ssh/sshd_config file for all computers to which the group policy object applies. It sets the path to the dzsshchk command which verifies the rights for users when they log in with SSH: ServiceAuthLocation /usr/share/centrifydc/libexec/dzsshchk Edit the sshd_config file to set the ServiceAuthLocation parameter for a single computer 1 Log in to a UNIX computer that will accept SSH log in. 2 Open the file /etc/centrifydc/ssh/sshd_config with a text editor. 3 Find and uncomment the line: ServiceAuthLocation /usr/share/centrifydc/libexec/dzsshchk This configuration parameter sets the path to the dzsshchk command which verifies the rights for users when they log in with SSH. 4 Save and close the file. 5 Repeat this procedure for each UNIX computer that will accept SSH log in. Chapter 10 Authorizing users 139

140 Defining specific rights Defining command rights Command rights define one or more UNIX commands that can be executed on a UNIX computer by a user in the role to which the rights are added. When you define a command right, you can specify whether it can be used in a role as an elevated right (executed with dzdo), added to a restricted environment, or both. See Step 4. To define a command right: 1 Open the Access Manager console, select Zones to display the list of zones, expand the zone of choice, and expand Authorization > UNIX Right Definitions. 2 Select Commands, right-click, then click New Command. 3 On the General tab, provide the following information: For this property Name Description Command Do this Type a short descriptive name for the command. The privileged command name is required and must not be more than 63 characters in length or contain any special characters, such as asterisks (*), slashes (\ /), question marks (?), or quotation marks ( ). Type a detailed description for the command. This field is optional. Type a command you want to add. Command is a required field and should include any parameters or options, as needed. Depending on the button you select below the Command field (Glob expressions or Regular expressions), you can use glob pattern matching syntax or extended regular expression syntax within the Command field. The default is glob pattern matching. For example, with glob pattern matching, the command can contain a question mark (?) to represent any single character, an asterisk (*) to represent any string, including an empty string, or an expression enclosed by brackets ([...]). You can also use an exclamation point (!) at the start of a command to disallow matching commands. For example, you can prevent users from specifying the program to use for viewing man pages (man P) that may allow them to use programs that are not allowed by specifying the following commands:!man P*!man * -P* man Commands that start with the exclamation point take precedence over others that don t. For example, if you type the commands!ls l and ls * users will be prevented from running the ls command with the -l option, even though ls * specifies that all options are allowed. If a command is followed by empty quotation marks (""), the command can only run without any options. For more detailed information about using wildcard patterns: With glob syntax, see the glob or glob(7) man page. With regular expressions, see the regexp(5) or regex(7) man page. Administrator s Guide for Linux and UNIX 140

141 Defining specific rights For this property Glob expressions Regular expressions Match path Priority (available in hierarchical zones only Do this Specify the type of pattern matching to use for wildcard characters in the Command field and the Match path > Specific path field. Glob expressions, the default, specifies glob pattern matching syntax. The description of the Command field and the Match path fields provides some examples of glob pattern matching. See the glob and glob(7) man pages for detailed information. Regular expressions specifies extended regular expression pattern matching. See the regcomp and regexec man pages for detailed information. You can also see the regexp(5) or regex(7) man pages. Select an appropriate path for matching the command name specified on the different operating environments you support. Select Standard user path to use the local operating system s common set of user directories to match the path of the command specified. Select Standard system path to use the directories the root user would normally get on the local operating environment to match the path of the command specified. Select System search path if you want to search for the specified command in a predefined set of locations. The locations are defined in the dzdo.search_path configuration parameter. If you select System search path and the dzdo.search_path parameter is not defined, the current user s path is used to search for the command. Select Specific path if you want to define a custom set of locations for matching the path of the command specified. If you select this option, you can specify one or more paths, separated by a colon. Depending on the button you select above the Match path field (Glob expressions or Regular expressions), you can use wildcard patterns to generate matching path names. For example, with glob pattern matching, the path can contain a question mark (?) to represent any single character, an asterisk (*) to represent any string, including an empty string, or an expression enclosed by brackets ([...]). The path must start with a slash (/), however, unless you are matching all paths (*). For example, if the command you specify is ls and you set the match path to *, the ls command from any path is allowed. If you set the Command to * and the match path to *, any command from any path is allowed. For more information about using wildcard patterns to expand path names, see the glob or glob(7) man page, or for regular expression syntax, see the regcomp, regexec, regex(7) and regexp(5) man pages. An integer that determines the priority of the command the lower the number the higher the priority. In certain cases, when multiple commands are defined with a glob or regular expression, the UNIX client may resolve to multiple commands. The priority determines which command comes with higher priority. 4 Click the Restricted Shell tab to specify whether and how the command can be run in a restricted shell. Note You may configure a command for use in both a restricted shell and by dzdo (see the next step) if you wish. Chapter 10 Authorizing users 141

142 Defining specific rights Select Can be used in a restricted role to allow this command to be added to a role that places the user in a restricted shell. Then select one of the following options: Select this User running the command Specific user or uid To do this Run the command as the currently logged in user. Enter a user name or UID to specify a user account under which to run the command. For example, specify root to require that a user must have root privileges to execute the command. Click Apply and go to the next step. 5 Click the Run As tab to specify whether this command can be used by dzdo, and if so, to list the user accounts under which the command can be run, and the primary groups that can be set for the command. Administrator s Guide for Linux and UNIX 142

143 Defining specific rights Select Can be used by dzdo to allow the command to be added to a role for privileged execution, then select from the following options to specify the pool of user accounts that can execute the command, and the primary groups that can be set for the command:. Select this User Group To do this Select one of the following options to specify who can execute the command: Any User Allow any user to execute the command with dzdo. One of the following users or uids Click Add to add a user to the pool of users allowed to run this privileged command. The user account for running a command can be either an Active Directory user with a UNIX profile in the zone or a local UNIX user account; however, the user account that logs in and invokes the privileged command must be associated with an Active Directory account. For example, specify root to require that a user must have root privileges to execute the command. Select one of the following options to specify which primary groups can be set when a user executes the command: Any Group Allow the user to specify any group to be set as the primary group when running the command with dzdo. One of the following groups Click Add to add a group to the pool of groups that can be set as the primary group when running this command with dzdo. If you are not configuring environment variables or additional execution attributes, you can click OK after setting the Run As properties for the command. If you want to configure environment variables or customize additional execution attributes, you can click Apply and go on to the next step. Chapter 10 Authorizing users 143

144 Defining specific rights 6 Click the Environment tab if you want to configure the environment variables to use in the restricted environment. To customize the environment variables used, select one of the following options: Select Reset environment variables if you want to reset the listed set of environment variables when the user runs the restricted environment command. In addition to the listed environment variables, the dzdo.env_keep configuration parameter in the centrifydc.conf file defines a default set of environment variables to retain from the current user s environment. If you select this option and want to specify additional environment variables to retain from the user s environment, you can enter them in a comma-separated list in Additional environment variables to keep, or click Edit, then Add, and type the environment variable name you want to retain. Select Remove unsafe environment variables if you want to retain existing environment variables while removing a default set of unsafe environment variables when running the restricted environment command. The list of unsafe environment variables is defined by the dzdo.env_delete configuration parameter in the centrifydc.conf file. If you select this option, and want to specify additional environment variables to remove, you can enter them in a comma-separated list in Additional environment variables to remove, or click Add, type the environment variable name, then click OK to remove the specified environment variable setting when the user runs the command. You can also select Add environment variables to define new environment variables to add when running the restricted environment command. Enter variables in a comma- Administrator s Guide for Linux and UNIX 144

145 Defining specific rights separated list in the form name=value, or click Edit then Add to add new variables and values. You can add new variables regardless of which of the other options you select. 7 Click the Attributes tab if you want to set other execution attributes for the command running in a restricted environment. For this Authentication required Preserve group membership Allow nested command execution Unmask value Do this Check this option to require the user to be authenticated before running a privileged command. If authentication is required, specify whether the password used should be the password for the logged-on user or the target run-as user. Check this option to retain the user s group membership while executing commands in a restricted environment. Check this option to allow the restricted environment command to start another program or open a new shell. You should uncheck this option if you want to prevent the command from starting another program or opening a new, unrestricted shell while executing an allowed command. Set the umask value to use for the restricted shell. 8 Click OK to save the new command. 9 Repeat Step 3 through Step 8 for each command you want to define. The rights you defined are now available to add to roles. Chapter 10 Authorizing users 145

146 Defining specific rights To add a command right to a role 1 Open the Access Manager console, select Zones to display the list of zones, expand the zone of choice, and expand Authorization > Role Definitions. 2 Select a role, right-click and click Add Right. The Console displays a list of PAM rights and command rights that are available to add to the role. 3 Select one or more Command rights and click OK. Note The Console warns you if you are adding a right as a privileged command that is not enabled to be run by dzdo or are adding a right to a restricted shell that is not enabled to be run in a restricted shell. If you ignore the warning and add the right to the role, it will have no effect. You must enable command rights for privileged execution (dzdo), for use in a restricted shell (dzsh), or both when you create them. To see the rights, including command rights, for any role, select the role in the Console tree and the rights are shown in the right pane. To remove a right, select it, right-click and click Delete. Configuring system rights System rights are predefined and built into every role definition. Unlike command rights, which you define and then add to a role, you cannot add, modify, or delete system rights; you can only enable or disable them on the System Rights tab of a role s property page or New Role definition page. The following types of system rights are available for every role: UNIX rights specify whether and how a user can log in to a UNIX computer. Windows rights specify whether and how users can log in to a Windows computer. These rights are not described in the current manual. See the Administrator s Guide for Windows for information. Rescue rights allow a user to log in to correct a problem in case of system failure. Four UNIX rights are defined: Note UNIX rights can only be applied to Active Directory users. If a role is configured (on the General tab) to allow local users, UNIX rights will not appear on the System Rights tab. Select this Password login and non-password (SSO) login are allowed Non password login (SSO) is allowed To do this Allows an Active Directory user to log in with a password. Note that this right allows a user to log in without a password as well, whether the next right, Non password login..., is enabled or not. Allows an Active Directory user to log in without a password, for example, via single sign-on. Administrator s Guide for Linux and UNIX 146

147 Defining specific rights Select this Account disabled in AD can be used by sudo, cron etc. Login with non-restricted shell To do this Allows a disabled service account to log in. Some UNIX cron tasks are run under an account mapped to a disabled AD account. With this right, a UNIX client can ignore the disabled state and allow a service account to log in. Allows the user to log in to their default, non-restricted shell, in which they can execute the standard commands to which they have permission. When this option is not selected, the user is logged into the dzsh restricted environment and may only execute the commands that are assigned to the restricted role. In order to be able to log in to a computer, a user must be assigned to at least one role with either the Password login and non-password (SSO) login are allowed or Non-password login is allowed UNIX right enabled. By default, no system rights are enabled for a new role. Note In addition to a login UNIX right, the ability to log in requires a way to log in; that is, access to at least one PAM application. In a UNIX environment, a typical user has rights to log into their default shell through any of the standard PAM applications (login, ftp, telnet, etc.) with or without a password. The predefined role called UNIX Login, which enables the password, non-password, and non-restricted shell system rights, and adds a PAM right that grants access to all PAM applications, facilitates role assignments for these typical UNIX users on managed computers. Rather than create your own login role to assign to typical UNIX users, you can simply assign them this predefined role. The Login with non-restricted shell right determines whether users are assigned their default shell or assigned to the dzsh restricted-shell environment. The rights granted by roles accumulate such that users are granted all the rights from all the roles to which they are assigned. This means that you do not have to grant system rights to every role you define as long as you assign one role with login rights (such as the predefined UNIX Login role) to any user you want to be able to log in. A single rescue right is defined: Select this In the event of system failure, user is permitted to log on to correct the problem To do this Prevent all users from being locked out in case of system failure The reason for the rescue right is that the Audit required right prevents users from logging in unless they are audited. If the auditing system is down or unavailable for any reason, and the computer is a sensitive computer such that all users are in a role with auditing required, no one will be able to log in to the computer until auditing is available. If the problem is with the DirectAudit agent on the computer, this rescue right allows a user to log in and fix the auditing problem. Chapter 10 Authorizing users 147

148 Defining specific rights Note A user who logs in with the rescue right will still be audited through the system log. To enable or disable a system right: 1 Open the Access Manager console, expand the zone of interest, and expand the Authorization node. Do one of the following: For a new role, select Role Definitions, right-click and select Add Role. Enter a name and optional description for the role. For an existing role, expand Role Definitions, right-click the role whose system rights you want to enable and select Properties. 2 Click the System Rights tab. Select the check box for each of the rights you want to enable for this role. Note UNIX rights can only be applied to Active Directory users. If a role is configured (on the General tab) to allow local users, UNIX rights will not appear on the System Rights tab. 3 Click OK to save the role definition. Configuring audit levels Audit rights, which are predefined and built into every role definition, specify whether and under what conditions a user must be audited in order to log in. Unlike command rights, which you define and then add to a role, you cannot add, modify, or delete audit rights; you can only set the level on the Audit tab of a role s property page or New Role definition page. The following audit levels are defined: Select this Audit not requested/required Audit if possible Audit required To do this Auditing is not requested nor required for a user in the role. Audit a user in the role if DirectAudit is installed and set up. If DirectAudit is not available, allow the user to log in without being audited. This option is selected by default for new roles. Always audit the user. If auditing is not available, a user in this role is not allowed to log in. On a sensitive computer that requires auditing for all users, you should provide the system rescue right to prevent all users from being locked out if there are problems with the DirectAudit agent on the computer. The rescue right allows a user to log in and correct the problem, even if auditing is required and not available. Administrator s Guide for Linux and UNIX 148

149 Defining specific rights To select the audit level for a role: 1 Open the Access Manager console, expand the zone of interest, and expand the Authorization node. Do one of the following: For a new role, select Role Definitions, right-click and select Add Role. Enter a name and optional description for the role. For an existing role, expand Role Definitions, right-click the role whose system rights you want to enable and select Properties. 2 Click the Audit tab. Select the radio button for the right you want to enable for this role. 3 Click OK to save the role definition. Predefined roles and rights A number of predefined rights and roles are available to address common UNIX authentication configurations. When defining new roles, keep in mind that rights accumulate: users effective rights include the rights from all the roles to which they are assigned. Predefined rights The following predefined PAM rights are available: Name login-all Description Grants access to all PAM applications by specifying *. for the command name. This right is added to the predefined UNIX Login role. You can add it to any role for which you want global PAM access. ssh Grants access to ssh on Debian and Ubuntu 6 and 7. sshd Grants access to ssh on all Linux and UNIX computers except Debian and Ubuntu 6 and 7. Chapter 10 Authorizing users 149

150 Defining specific rights Predefined roles The following predefined roles are available: Name Rescue - always permit login listed scp sftp UNIX Login Windows Login winscp Description Grants Rescue rights to prevent all users from being locked out in case of system failure. Specifically, if all users on a sensitive computer must be audited in order to log in, if auditing failed for any reason, all users would be locked out. This role allows a user to log in to correct the problem. This role accepts local accounts, and as such does not allow any PAM access or SSH rights. Makes a user visible in a zone but does not grant any UNIX rights, PAM rights, or command rights. It does grant the Audit if possible right. This is a specialized role that is designed for situations in which a user has left a project and no longer has access to a zone. In this situation, the files that the user created will no longer show an owner, only a UID. If you assign the listed role, however, the user still has no effective rights in the zone, but their files will continue to show an owner. This role does not accept local accounts. Grants scp access. This role does not accept local accounts. Grants sftp access. This role does not accept local accounts. Grants typical UNIX user login rights such that users in this role are enabled to log in to their default shell through any of the standard PAM applications (login, ftp, telnet, etc.) with or without a password. This role grants the following UNIX rights: Password login and non-password (SSO) login are allowed Non-password (SSO) login is allowed Login with non-restricted Shell It also grants the Audit if possible right and adds the predefined PAM right, login-all, which grants universal PAM access (*.). This role does not accept local accounts. Grants typical Windows user login rights including console login and remote login. It also grants the Audit if possible right. This role accepts local accounts, and as such does not allow any PAM access or SSH rights. Grants winscp access. This role does not accept local accounts. Administrator s Guide for Linux and UNIX 150

151 Creating roles for job functions in a zone Creating roles for job functions in a zone Rights control the specific operations, tasks, or environments you want to grant access to. Roles describe job functions that require a specific set of rights, and, if applicable, the specific days and times the role should be available for performing the operations allowed. To create a role for a job function, you need to do the following: Create a new role. Optionally, specify days and time in which the role is available. Specify a normal shell (by enabling the system right: Login with non-restricted shell), or a restricted shell (by leaving the system right Login with non-restricted shell disabled). Optionally, enable system rights for login; if you do not enable login rights, users in this role must also be assigned at least one other role that enables login, such as the predefined UNIX Login role. Optionally, add PAM rights to the role, such as the predefined login-all right; if you do not add PAM rights, users in this role must also be assigned at least one other role that provides PAM rights, such as the predefined UNIX Login role. Add command rights to the new role. Note When you assign a role to a user, you may assign a duration for the role by specifying starting and ending times for the role. For example, if the role applies to a contractor who will be hired for a specific amount of time and you want to automatically disable the role after they finish the job and leave the organization, you can specify the starting and ending times when you assign the role. To create a new role and assign rights to it: 1 Open the Access Manager console, expand the zone of interest, and expand the Authorization node. Chapter 10 Authorizing users 151

152 Creating roles for job functions in a zone 2 Select Role Definitions, right-click and select Add Role. Enter a name and optional description for the role. For example: 3 If you want to apply this role to local user accounts, select Allow adding local accounts to this role. If you select this option, this role cannot be used to apply UNIX rights to the role as UNIX rights only make sense for Active Directory users, not local users. 4 If you want to restrict when this role is available, click Available Times, then select the days and times to allow or deny access for users assigned to the role. For example, to prevent users from performing the operations defined for the role on weekdays before Administrator s Guide for Linux and UNIX 152

153 Creating roles for job functions in a zone 7:00 AM, weeknights after 10:00 PM, and on Saturdays and Sundays, you could set the available times like this: 5 Click the System Rights tab and do the following for UNIX rights: Note If the role is for local users, UNIX rights will not appear because UNIX rights do not apply to local users. You may add rescue rights only. If you are adding Windows rights, see the Administrator s Guide for Windows, or click F1 for help. To create a role that is analogous to a typical UNIX login, you would grant the following system rights: Select Login with non-restricted Shell to allow users in the role to log in to their default shell. They will be able to execute their base set of commands as defined by the UNIX environment, as well as any privileged commands that you add to this role. Optionally, select the Password login and non-password (SSO) login are allowed option to allow both password login and login with a Kerberos ticket (single sign-on) if you want to assign login rights in the role. Or select Non-password (SSO) login is allowed to allow login single sign-on only. Note that roles in your organization may be structured such that login rights are granted by a separate, specific login role, in which case you do not want to assign them here. To create a role that puts the user in a restricted shell, leave Login with non- Restricted Shell un-selected. A user in this role logs into the dzsh restricted environment and may only execute the commands that are assigned to the role. Click F1 for details about the options available on this page, including Account disabled in AD can be used by sudo, cron, etc (which has a specialized use but is needed for most roles). 6 Remain on the System Rights tab and select In the event of system failure, user is permitted to logon to correct the problem if you want to allow a user in this role to log in when auditing is required but the audit system is unavailable. See rescue rights for more information. You should only apply this right to a select number of users. Chapter 10 Authorizing users 153

154 Creating roles for job functions in a zone 7 Click the Audit tab to specify the audit level for the role. The default audit level is Audit if possible which works for most users. Click F1 or see Configuring audit levels on page 148 for details about the audit options. 8 Click OK to save the role. 9 In the Console tree, select the role and right-click and click Add Right to add PAM or command rights to the role. You may select multiple rights. The list shows rights from the current zone and from any parent zones. When you add command rights, Access Manager verifies that the command is appropriate for the role you have defined, that is, it can be executed as a privileged command (if the role defines a normal shell), or in a restricted environment (if the role defines a restricted shell). 10 Click OK to add the commands to the role. You can add additional rights or remove rights at any time for a role. To add a right, select the role in the console tree, right-click and click Add right. To delete a right, select the role in the console tree, select the right in the right pane, rightclick and click Delete. Creating a login role for a service account Certain service accounts may require a special type of login. For example, some UNIX cron tasks may run under an account mapped to a disabled AD account, which means the account will be unable to log in. To enable service accounts in this situation, you can use the system right: Account disabled in AD can be used by sudo, cron etc. When this right is enabled, a UNIX client can ignore the disabled state and allow a service account to log in. To enable this right for a role, use the System Rights tab of a role s property page or of the New Role Wizard. Creating a role with enhanced commands UNIX commands that require elevated permissions can be defined in the sudoers configuration file run by using the sudo command. Centrify provides similar functionality, but the commands are configured through command rights, are executed with the dzdo command, and use the Centrify zone s authorization store rather than a sudoers configuration file. User s in this type of role have access to their base set of UNIX commands as defined by the UNIX environment and to all the commands with enhanced privileges that are specified by the role. When executing privileged commands, users must use the dzdo command, much Administrator s Guide for Linux and UNIX 154

155 Creating roles for job functions in a zone like using sudo. Whether the user must enter a password when executing a privileged command depends on how authentication options are specified in the command definition: No password required (the default) The password for the user who is executing the command The password for the target account that is executing the command. To create a role that can execute commands with enhanced privileges, do the following: Create command rights to define the commands you need. Create a role and enable the UNIX right: Login with Non-Restricted Shell (unless the role is for local users, in which case you don t need to add UNIX rights). Add the command rights to the role. Creating a role with a restricted shell environment On UNIX computers, Centrify provides a customized Bourne shell, dzsh, that provides environment variables, job control, command history, and command access as defined by Centrify roles. To create a role that defines a restricted shell, do the following: Create command rights to define the commands you need. Create a role and disable the UNIX right: Login with Non-Restricted Shell Add the command rights to the role. Understanding the limitations of a restricted environment The restricted environment does not enforce rights for commands run outside of the shell. For example, if using a graphical desktop manager, the user can run commands and applications that are launched from menu selections in the graphical user interface. In addition, limiting the user s command set in the dzsh shell does not prevent the user from running built-in shell commands, accessing the file system, or seeing process or system information. For example, even in a restricted environment with no rights to run any commands, a dzsh user could get a process listing using the following script: for i in /proc/[0-9]*; do read PROC < $i/cmdline; echo $PROC; done Because the shell scripting environment allows the operations, the user can effectively access information that the command set defined for his restricted environment does not allow. Keeping a restricted environment secure There are many ways sophisticated users can get around limitations placed on a restricted environment. For example, most text editors, such as vi and emacs, allow shell escapes. Chapter 10 Authorizing users 155

156 Creating a computer role Giving users permission to run programs that allow shell escapes in a restricted environment enables them to open a new unrestricted environment with none of the restrictions placed on them in their defined environment, Similarly, giving users access to commands that set or modify local time and date settings may allow them avoid time constraints for running commands or the expiration date and time for specific role assignments. In some cases, even individual command line options may provide users with the means to run commands not defined in their restricted environment. For example, allowing the user to run the tar command with --use-compress-program program_name allows user to run the specified program_nam even though the program_name is not an allowed command in their restricted environment. In choosing the commands to allow in a restricted environment, therefore, you should carefully consider ways to plug potential security holes the commands may introduce or whether there are alternative commands that provide the same functionality more securely. For example, if you need to give a user access to an editor, such as vi or vim, you could restrict the ability to execute nested commands to prevent users from opening a new shell from within the editor; see Step 7 of Defining command rights. Alternatively, you could add the rvi command to the restricted environment instead of vi or vim because rvi doesn t allow the user to open a new shell. Creating a computer role A computer role associates a group of computers in a zone with a set of role assignments to users or groups. In other words, a computer role specifies a group of computers and identifies the users and their roles for these computers. For example, in many organizations, a set of computers is dedicated to a specific function, such as hosting an Oracle database, or to a functional area, such as payroll, such that the users of these computers require a common set of access rights. Computer roles are designed specifically for setting up rights to these kinds of dedicated computers. A note about the name Computer role does not refer to a DirectAuthorize role, but rather to the role that the computer, or group of computers, plays in the organization; for example, database server, financial server, and so on. To define a computer role, you must do the following: Create a unique Active Directory security group for each computer role. You can create the Active Directory group and add its computer account members in Access Manager when you create the computer role, or before creating the computer role using Active Directory Users and Computers. Identify the users for the computer role and create Active Directory groups for them. Administrator s Guide for Linux and UNIX 156

157 Creating a computer role You might want to define multiple sets of user-based roles. For example, a computer role for Oracle servers might require a database users group, a database administrators group, and a backup operators group. Identify the rights for each set of user-based roles. You might want to create specific rights, role definitions, and role assignments for different sets of users, or use existing roles. For example, the database users group might only require the predefined UNIX Login role definitions, while the database administrators group might require access to privileged commands, and the backup operators groups might be only be allowed to run a specific set of commands in a restricted shell. Create the computer role in Access Manager and specify the Active Directory group that contains the computers that are members of the computer role. In Access Manager, add role assignments to the computer role you created by specifying the Active Directory groups you identified, and assigning one or more roles to each one. Note Computer roles are very different objects than user-based roles (a set of rights). Never re-purpose or expand a user role to be a computer role. Instead, create your set of computer roles separate from your set of user roles. You can define a computer role at any level of the zone hierarchy and it is valid at that level and all levels down the tree. Once a computer role is created, it is totally scalable and easy to manage even as your organization changes and grows. For example, if another Oracle database server comes online, you add it to the computer group you created in Active Directory. If other DBAs join your organization, you add them to the group you created for Oracle administrators in Active Directory. The computer role continues to function smoothly and there is no need to edit it to accommodate these common kinds of organizational changes. Of course, if you want to change the computer role itself, for example, by adding or removing role assignments, you can do so at any time in Access Manager. Note The following procedure shows how to create a computer role by using the Access Manager console. You can also create and edit computer roles by using ADEdit commands. To create a computer role: 1 Open the Access Manager console, expand the zone of interest, and expand the Authorization node. 2 Select Computer Roles, right-click and click Create Computer Role. Chapter 10 Authorizing users 157

158 Creating a computer role 3 Type a name for the computer role and an optional description, then select one of the following options from Computers group: <Create group > to create a new Active Directory group of computers if you do not have an existing group you want to use. You can then click Browse to select the container to use for the new group, type a name and select the scope of the group. <...> to search for an existing group of computers to use. Type a name or partial name, click Find Now, then select the desired group from the list. For example, create a new computer role named oracle_servers and click Create group to create a new Active Directory security group for the computers that host Oracle database instances. 4 Click OK, then OK again to save the new computer role. Add computer accounts to the computer role If you created a new Active Directory group for the computer role, you must add one or more computer accounts to the new Active Directory group to make those computer accounts members of the computer role. If you specified an existing Active Directory group for the new computer role, you can see its current members in the Access Manager console. Administrator s Guide for Linux and UNIX 158

159 Creating a computer role To add computers to the computer role using Access Manager: 1 Select the new computer role. 2 Select Members, right-click, then select Add Computer. 3 Type the name of a computer or click Find Now to search for the computer accounts to add. 4 Select one or more computers and click OK to automatically add computers to the Active Directory group associated with the computer role. Alternatively, you can also add or remove computer accounts as members of the computer role and Active Directory group using Active Directory Users and Computers or ADEdit commands. After you have specified the Active Directory security group you want associated with a computer role, the account membership is synchronized so you can use Access Manager or another program to make changes. Add role assignments to the computer role After you have specified the Active Directory group to use for the computer accounts that you want to assign to a computer role, you must identify users who have specific access rights on the computers in the new computer role. You should have already created the rights and role definitions for different set of users. You should have also assigned either predefined or custom roles to different sets of users to grant or restrict their rights. To associate user role assignments with a computer role: 1 Select the new computer role, for example, oracle_servers. 2 Select Role Assignments, right-click, then select Assign Role to see a list of role definitions in the current zone and any parent zones. 3 Select the role definition that you want to add to the computer role, then click OK. 4 Click Add AD Account to search for and select an Active Directory user or security group to assign to the role. You can select User or Group as the object to find, type all or part of the user or group name, then click Find Now. For example, type ora to search for and select the oracle_db_admins Active Directory group then click OK. 5 Click OK to complete the role assignment for the selected user or group in the selected computer role. Repeat these steps for each role definition you want to assign to users and groups in this computer role. For example, if you have an Active Directory oracle_db_users group that should be allowed to log on a nd run shell commands on the computers in the oracle_servers computer role, you would select the predefined UNIX Login role in Step 3 Chapter 10 Authorizing users 159

160 Assigning users and groups to a role and assign that role definition for the computers in the oracle_servers computer role to the oracle_db_users group in Step 4. Viewing and modifying a computer role You can view information about computer roles by expanding Authorization and Computer Roles for a zone. However, computer roles are also closely linked to the Active Directory groups that define their scope and role assignments, so there are several different ways you might view or modify information about a computer role. For example, you might use Access Manager, Active Directory Users and Computers, or ADEdit commands, depending on what you are trying to do. In Access Manager, you can expand a computer role, then select Role Assignments to see the users, groups, and role definitions that have been assigned on the computers that are members of the computer role. You can also expand a computer role, then select Members to see the computers to which the role assignments apply. To see the Active Directory group assigned to the computer role in Access Manager, select the computer role, right-click, then select Properties. If you are using Active Directory Users and Computers, you can view the properties for the Active Directory group associated with the computer role and click the Members tab to see the computers assigned to the computer role. If you want to add a computer to an existing computer role, you can simply add that computer to the Active Directory group associated with the computer role without making any changes in Access Manager. Similarly, if users join or leave your organization, you can simply add or remove those user accounts in the appropriate Active Directory groups that are associated with the computer role. For example, if you define the oracle_servers computer role to associate a specific set of computers with a role assignment that grants administrative rights to users in the Active Directory security group oracle_db_admins, you could simply add the user account for Frank.Smith to the Active Directory security group oracle_db_admins to give that user administrative access on the computers that are members of the oracle_servers computer role. You do not need to make any changes in Access Manager. To modify the rights and role assignments for a computer role, you must use Access Manager or ADEdit commands. Assigning users and groups to a role You can assign a role to an Active Directory user or an Active Directory group in which case it applies to all members of the group or to a local UNIX user or a local Window s user. Although you can assign a role to an Active Directory user who does not have a profile in the zone, the role will not be effective unless the user has a complete profile for the zone, either defined in the zone or inherited from a parent zone. Note that a zone profile for a Administrator s Guide for Linux and UNIX 160

161 Assigning users and groups to a role group does not create zone profiles for the users of the group. User profiles must be defined explicitly for each user. You may only assign roles that accept local accounts to local UNIX or Window s users. You can assign a role that is defined in the current zone or in a parent zone. You can also specify optional start and end times for the role assignment. To assign users and groups to a role in a zone: 1 Open the Access Manager console, navigate to the zone of choice, expand Authorization and select Role Assignments, then right-click and select Assign Role. 2 Select the role to assign and click OK. Chapter 10 Authorizing users 161

162 Assigning users and groups to a role 3 Specify a start time and select the user account to which to assign the role. Not available for roles that do not allow local accounts By default, the role is set to start immediately and never expire. You can set a duration for the role assignment by setting the start and end times. For example, for a contractor with a specified end time, you can set the end time to automatically disable the role on the date that the contractor leaves the company. Uncheck either of these options to set a date and time in the Start time or End time field. Press F1 for help with this or any other field on the Assign Role page. 4 Select whether the role assignment applies to all Active Directory accounts, all local accounts, or specific Active Directory and local accounts. If you want to automatically assign a role to every user added to the Active Directory forest or trusted forests, you can select All Active Directory accounts for convenience. This option is similar to selecting Authenticated Users or Everyone system groups. For example, if you want to assign all Active Directory users the UNIX Login role by default, you can select this option. However, only those users who also have a complete UNIX profile will be able to log on to the UNIX computers joined to the domain. If you select Accounts below to add a specific Active Directory or local account, click Add AD Account to browse for Active Directory users or groups to add, or click Add Local Account to add local UNIX or Window s accounts to the role. This button does not appear for a role that does not allow local accounts. 5 Click OK to complete the role assignment. Administrator s Guide for Linux and UNIX 162

163 Working within assigned roles Assigning non-zone users to roles Users must have an explicit or inherited profile in a zone before they can perform any operations on managed computers or be granted privileged or restricted command access. However, you can assign users to roles prior to adding their profiles to the zone, which enables you to define what they can and can t do before they have access to computers in the zone at all. On the other hand, users with a profile in the zone, but no role assignment in the zone, have no access to any computers in the zone, including login, until you assign a role. Rights and role assignments for local users You can assign roles to both Active Directory users and local UNIX and Windows users if you have configured the role to allow assignment to local users. Although Windows users require a role in order to log in, local UNIX users do not require a role for log in, and in fact, cannot be assigned a role that contains system login rights. Roles for local UNIX users are for the purpose of assigning specific command rights. Working within assigned roles Once you have defined rights, roles, and role assignments for a zone, the first test to verify enforcement is by logging on as a user to a computer joined to a zone in which the role applies. To see the roles and rights defined for a zone, select the zone, right-click and click Show Effective UNIX User Rights. Next, depending on the type of role, you can test the operations the user can perform for a specific role by using dzinfo username --test command to check whether a user has permission to run a specified command. Note that you must enter the complete path to the command and enclose the command in single or double quotes. For example, suppose you have given a user, qa1, rights to run the id command as root. You could run the following command on a UNIX computer: [user1@rh5]# dzinfo qa1 --test /bin/id Testing: User = qa1 command = /bin/id User qa1 can run the command as 'root' via dzdo, authentication will not be required, noexec mode is off Users and groups not assigned to roles in the zone are not affected in any way. Using privileged commands If a user is assigned to a role that includes privileged command rights, the user can run those privileged commands by invoking the dzdo command, any command line options, and the privileged command name. The dzdo command provides functionality similar to the UNIX sudo command to enable a user to execute a command using another user account. For example, you can define Chapter 10 Authorizing users 163

164 Working within assigned roles reboot as a privileged command that users can execute using the root user account. A user assigned to a role that includes this right can then execute the command as root by typing a command similar to the following: dzdo reboot The basic syntax for dzdo is: dzdo [options] command For more information about running dzdo and using dzdo command line options, see Using dzdo on page 358 or the dzdo man page. The dzdo command does not interfere or inter-operate with any UNIX sudo operation or sudoers configuration. Any existing configuration remains in effect and is unaffected by DirectAuthorize. Using PAM-enabled applications If a user is assigned to a role that includes PAM application rights, the user can only access the authorized PAM-enabled applications. For example, users who are assigned to a role that includes the right to access FTP (ftpd) can connect to the FTP server by typing a command similar to the following: ftp ginger.ajax.org Using a restricted environment shell If a user is only assigned to roles that use a restricted environment, the user can only access the specific commands that have been defined for each of those restricted environments. When the user who only has access to restricted environments logs on to the console or opens a new terminal in a desktop environment, a customized DirectAuthorize shell (dzsh) is opened. The dzsh shell is a Bourne-based shell that provides the subset of commands the user is allowed to run and automatically runs each allowed command as the user it is configured to run as. If the user attempts to run a command he is not authorized to use in his current role, the shell displays a warning. For example, if the user is not authorized to run the uname command, the following message is displayed: $ uname uname: command not allowed Setting or changing the active role Users who are only assigned to one or more restricted environments roles are only allowed to run commands within the DirectAuthorize shell (dzsh). Within the DirectAuthorize shell, a user can only be in one active role at a time to prevent ambiguity about the commands the user can run or the user account that should be used to execute those commands. For example, if the user carol is assigned to the lab_staff restricted environment role that specifies the tar command should run as root and to the temps restricted environment role that specifies the tar command should run as tmp_admin, she needs to specify which role she is using for DirectAuthorize to run the tar commands under the proper account. Administrator s Guide for Linux and UNIX 164

165 Exporting and importing rights and roles Within the DirectAuthorize shell, users can switch between available restricted environment roles, as needed, using the built-in role command. If a user has been assigned to the Backup Operators (backup_ops) role and the DirectAuthorize Managers (dz_managers) role, he can run the role command to specify which role should be active so that only commands from that role apply. For example, to switch from the backup_ops role to the dz_managers role: $ role dz_managers Role changed to: dz_managers For more information about using the role option in a DirectAuthorize shell (dzsh), see the man page for dzsh. Viewing available roles The dzinfo command enables users to view information about the roles they have available and what they are allowed to do within their different roles. You may want to add this command to all of your restricted environment roles to allow users to check their definitions and availability within the DirectAuthorize restricted environment shell. For more information about using the dzinfo command, see the man page for dzinfo. Using a graphical desktop manager in a restricted environment In some operating environments, users who are placed into a restricted environment may not be able to log on using a graphical user interface desktop manager unless they are explicitly given permission to run the desktop manager or related commands within the dzsh restricted environment. For example, on Red Hat Linux, users must be allowed to run /usr/bin/dbus-launch to log on using KDE or Gnome desktop manager. To allow restricted environment users to log on using KDE or Gnome on Red Hat, you must add dbus-launch to the list of allowed commands for the restricted environment user s role. If you want to prevent restricted environment users from logging on using the graphical user interface, you can restricted their access to specific PAM-enabled applications such as ssh and telnet. Exporting and importing rights and roles Once you have defined rights, roles, and role assignments in one zone, you can export part or all of that information to a file, then import the information into a new zone and modify it as needed. For example, you can choose to export all the rights you have defined in one zone but create a completely new set of roles for those rights in the import zone. Rights, roles, and role assignments are all inherited from parent to child zones, so generally there is no need to import or export roles within a zone hierarchy, but you may want to do so across zones. Note You can also copy and paste role definitions between zones. Chapter 10 Authorizing users 165

166 Exporting and importing rights and roles Exporting a zone s rights and role definitions You can export right and role definitions to an xml file that you can then use to import these definitions into another zone. To export rights and role definitions: 1 Open the Access Manager console, expand the zone of interest, select the Authorization node, right-click and click Export Roles and Rights. 2 Select the information you want to export, then click Next. For example, to export all of the information, click All to select all rights and all role definitions. 3 Click Browse to specify a location and file name for the export file, then click Next. For example: 4 Review the information to be exported, then click Finish. Importing rights and role definitions into a new zone You can import rights and role definitions that you have previously saved from a different zone. You can also copy a paste or drag and drop rights and roles to a different zone. Note Right and roles that are defined in a parent zone may be used in a child zone. For example, you can add a right defined in a parent zone to a role in a child zone, or assign a role defined in a parent zone to a user in a child zone. To import rights, role definitions, and role assignments: Before you begin, be certain you have saved rights and role definitions from a different zone and know the location of the xml file in which they are saved. 1 Open the Access Manager console, expand the zone of interest, select the Authorization node, right-click and click Import Roles and Rights. 2 Click Browse to navigate to the file that contains the authorization information you want to import, then click Next. 3 Select the information you want to import, then click Next. 4 Review the information to be imported, then click Finish. To copy rights, role definitions, or role assignments: You can copy and paste or drag and drop right definitions, role definitions, or role assignments between zones. It is not always possible to copy role assignments, for example, if the role specified for the role assignment is not defined in the new zone. 1 Open the Access Manager console, expand the zone of interest, select the Authorization > UNIX Right Definitions > PAM Access or Commands (Role Administrator s Guide for Linux and UNIX 166

167 Modifying rights, roles, and role assignments Definitions or Role Assignments) node, select the right (or role) to copy, right-click and click Copy. 2 Open a different zone and select the Authorization > UNIX Right Definitions PAM Access or Commands (Role Definitions or Role Assignments) node, rightclick and click Paste. 3 Alternately, you can select the right or role and drag it to the Right Definitions, Role Definitions, or Role Assignments node in the other zone. Modifying rights, roles, and role assignments When you make changes to rights, roles, or role assignments, these changes take effect on managed computers at the next cache update interval, as set by the adclient.cache.expires parameter or the Set object expiration group policy (Computer Configuration > Policies > Centrify Settings > DirectControl Settings > Network and Cache Settings > Set object expiration). The default value for this parameter is 10 minutes. If you want these changes to take place immediately, you can flush the cache on individual computers by using the following procedure. To flush the cache and update authorization changes: 1 Log on or switch to the root user on the managed computer. 2 Run the adflush command to clear the UNIX agent cache. For example: # /usr/sbin/adflush Viewing rights and roles Access Manager allows you to view the status and effective rights for any user in a zone, whether they have been assigned a role or not. You can view detailed information about the rights and role assignments for users in the following ways: Using the Show Effective UNIX User Rights command in the Access Manager console (right-click the zone and select the command from the menu). If a user is not assigned a role, be certain to select the Show omitted users option, otherwise, information will not be shown for the user. Running the dzinfo command line program on any managed computer. You can view summary information about the rights and roles defined for multiple zones in a forest by running the User Privileged Command Rights or User Role Assignment reports. Chapter 10 Authorizing users 167

168 Viewing rights and roles Displaying rights for an individual user in the console The Access Manager console allows you to view the profile, role assignments, privileged commands, and PAM access rights for a user. To view rights for an individual user in the Access Manager console: 1 Open the Access Manager console. In the console tree, expand Zones and if necessary, Child Zones, and select the zone of interest. 2 Right-click and click Show Effective UNIX User Rights. You can Select Show omitted users to add users who have an incomplete profile or do not have a role assignment. Users with an incomplete profile are shown in red. Select the user and the Zone tab to see which profile fields are missing. 3 Select a user and the following tabs to see information for the user for the selected zone or computer: Zone Profile lists the values for all UNIX user profile fields and the location in which they are defined. Role Assignments lists the user s role assignments for the selected zone or computer. The Object Assigned column shows whether the assignment is explicit (user@domain) or from an assignment to a group to which the user belongs (group@domain). Location of Assignment is the zone or computer role in which the assignment was made. Administrator s Guide for Linux and UNIX 168

169 Viewing rights and roles Rights lists the rights granted by the roles to which the user belongs for the selected zone or computer. It shows the type of right, where it is defined, and to which role it belongs. 4 In the drop-down list for Computers, you can select a computer to view effective users for a particular computer in the selected zone.select a user in the results, then click OK to display that user s rights. For example: Checking user rights with the dzinfo program DirectAuthorize also provides a command line program, dzinfo, to enable you to view roles and rights on managed computers. The dzinfo program enables you to view roles and rights for one or more specific users or for the currently logged on user. Note Running the dzinfo program to view roles and rights for specific users requires root permission. Therefore, you may want to create a privileged command for dzinfo to allow administrators to view rights and roles for other users. The program does not require root permission to view rights and roles for the currently logged on user. To view roles and rights for a specific user: 1 Log on or switch to root on a managed computer. 2 Run the dzinfo command for a specific user with the username in the command line. For example, to see the rights and roles assigned to the user sonya: dzinfo sonya Alternatively, if you have defined a privileged command to run the dzinfo command as root, you can invoke the program using dzdo. For example: dzdo dzinfo sonya If roles and rights have been configured for the user, the command displays information similar to the following: Zone Status: DirectAuthorize is enabled User: sonya Forced into restricted environment: Yes Role Name Avail Restricted Env role-lab Staff Yes rs-lab_staff PAM Application Avail Source Roles login Yes role-lab Staff sshd Yes role-lab Staff gdm Yes role-lab Staff Privileged commands: Name Avail Command Source Roles (molly has no privileged command rights) Chapter 10 Authorizing users 169

170 Migrating from sudo to dzdo Commands in restricted environment: rs-lab_staff Name Avail Command Run As rs-lab_staff-whoami Yes whoami self rs-lab_staff-pwd Yes pwd self rs-lab_staff-uname Yes uname tim rs-lab_staff-who Yes who self rs-lab_staff-groups Yes groups self You can run dzinfo without parameters to see the roles for the current user. To see more detailed information, such as the days and times a role is available, you can use the --verbose option. For example, to see detailed information for the currently logged on user, you could type the following command: dzinfo --verbose You can also use the dzinfo program to test whether a user has the right to run specific commands. For more information about using dzinfo and the dzinfo command line options, see the dzinfo man page. Migrating from sudo to dzdo You can use Centrify software to create a sophisticated set of roles and rights that you can assign to Active Directory zoned users to control operations on UNIX computers. At the same time, privilege management is handled on UNIX computers by the sudo facility (through a sudoers file), or more accurately, by a different sudoers file on each UNIX computer in your environment. This section explains how to migrate all privilege management of UNIX computers from sudoers to Active Directory through Access Manager authorization features. To begin, you need root-level permission to read the sudoers file on each UNIX computer. In Active Directory, you will need permission to import the sudoers file. If you are following the best practice guidelines from the Planning and Deployment Guide, and you created a Zone Administrator s group, members of that group have the required permissions. You can also apply more granular permissions if you want: specifically, permissions to manage roles and rights and manage role assignments. See the Planning and Deployment Guide for details. Identify the sudoers file on each computer and copy to a Windows computer The sudoers file is located by default at /etc/sudoers, and generally, this is the file to import from each computer. However, there are some exceptions: If sudo was compiled with the --sysconfdir option to specify a different location for sudoers you need to find the actual location. Run sudo -V to see the sudo configuration options, including the path to the sudoers file. If your environment has an automatic mechanism for distributing a single sudoers file to the entire network, you can use that one file and don t need to import multiple files. Administrator s Guide for Linux and UNIX 170

171 Migrating from sudo to dzdo Copy the file to a location on a Windows computer that has the Access Manager console installed. To be safe, give the file a name that tells which computer it is from, for example, oracle_server.sudoers, qa1_server.sudoers, etc. Note You can use DirectManage Deployment Manager to copy the default sudoers file for a UNIX computer to a location on your Windows computer. However, if the sudoers file is not in the default location, you should manually copy the file. Import the sudoers file This section shows how to use Access manager to import the sudoers file into a Centrify zone. To import the sudoers file 1 Copy the sudoers file for each UNIX computer to a location on a Windows computer that has the Access Manager console installed. Give each file a name that identifies its source, such as oracle_server.sudoers, qa1_server.sudoers, etc. 2 On the Windows computer, open the Access Manager console and navigate to the zone in which to import the sudoers file. If you have a sudoers file that covers most of your UNIX environment, you should probably import this to a parent zone. If the file is used on a single computer, you should select a child zone. 3 Select the zone, right-click and select Import sudoers file. 4 Click Browse and navigate to the location in which you copied the sudoers file, select the file and click Open, then click Next. 5 Verify the contents of the file, then click Next. The wizard lists any errors and warnings. Note If you previously imported a sudoers file, importing a new sudoers file will overwrite the data from the previous import. If you have not yet converted the data from the previous import to roles and rights in the console, click Cancel to exit the wizard, then convert the imported data to DirectAuthorize roles and rights as described in Converting sudoers data to DirectAuthorize on page 172 before importing an additional sudoers file. 6 If the file contains errors or warnings, you can click Details to see a list. Select an error or warning and click Go To (or double-click) to see the definition in the sudoers file. Chapter 10 Authorizing users 171

172 Migrating from sudo to dzdo You can continue, if you wish, with warnings, but must fix any errors before continuing (the Next button is not available). Make note of any errors and warnings to fix, then click Close to close the error list. 7 Do one of the following If the file contains errors or if you want to fix warnings before importing the file click Cancel to exit the wizard. Navigate to the location in which you copied the sudoers file, open it with a text editor and fix, delete, or comment out the lines containing errors, then save the file. Repeat Step 3 - Step 5 to re-import the file. If the file contains no errors and you are ready to import, click Next. 8 Click Finish. The import wizard creates a new node called Sudoers, which contains sub nodes for the types of data contained in a sudoers file (User Alias, Runas Alias, etc.). Note If the Sudoers node is not visible, refresh the display by selecting the Authorization node, then right-click and select Refresh. You can now convert the sudoers data to roles, rights, and role assignments in the Centrify zone. Note If you intend to import more than one sudoers file to a single zone, you must convert the imported data to DirectAuthorize roles, rights, and role assignments before importing another sudoers file, otherwise the next import overwrites the existing data. Converting sudoers data to DirectAuthorize The sudoers import wizard stores the imported data in containers in Access Manager. You can view this data and convert it to roles, rights, and role assignments. Before you import the sudoers file and convert the aliases and user specifications to roles, rights, and role assignments, be certain that you have imported all the users and groups specified in the sudoers file into Active Directory, and have added them to the zone in which you are importing the sudoers file. Otherwise, you will receive errors when you attempt to convert user specifications in the imported sudoers file to role assignments in the Access Manager console. In addition, keep in mind that the roles you create from a sudoers specification do not contain any UNIX system rights or PAM access rights. You can assign these through other roles, for example, when you add users to a zone you can also assign a role such as the UNIX Login role to give them rights to log in. Or you can add UNIX system rights and PAM access rights to the roles after you create them from the sudoers specifications. Administrator s Guide for Linux and UNIX 172

173 Migrating from sudo to dzdo To view the imported sudoers data 1 On the Windows computer, open the Access Manager console and navigate to the zone in which you imported the sudoers file. 2 Navigate to Authorization > Sudoers and you will see nodes for User Alias, Runas Alias, and so on. Note If the Sudoers node is not visible, refresh the display by selecting the Authorization node, then right-click and select Refresh. Within each item are objects for the sudoers definitions that were imported. For example, within User Alias are alias definitions, each one of which contains the user accounts defined for that alias. Note Some nodes may be empty depending on whether the sudoers file defined any aliases of that type. Each type of alias converts to a different type of DirectAuthorize data. See the following sections for information, or select a node and press F1 to get information about how to convert each type of alias definition to DirectAuthorize data. Note You do not need to import all of your aliases. You can simply ignore aliases that are obsolete or no longer relevant. Importing User Aliases A User_Alias is a way in UNIX of defining a set of users without necessarily creating a group. However, each one that you convert will become an Active Directory group. Assigning users to groups simplifies user management because if users change roles or leave the company, you can simply remove their group membership, without deleting their accounts, and effectively, they no longer have access to the roles assigned to members of the group. You can create an Active Directory group from a user alias or map it to an existing group. To create a group from the alias 1 Select the alias name, right-click and select Create AD Group. 2 Verify the container location, or click Browse to select a different container, then click Next. 3 Verify the group name (it defaults to the alias name) and scope, add a prefix or suffix if desired, then click Next. The wizard lists any warnings or errors; you must fix any errors before continuing, but can create a group with warnings. 4 Click Next, then Finish to create the group. Chapter 10 Authorizing users 173

174 Migrating from sudo to dzdo To map a user alias to an existing group 1 Select the alias name, right-click and select Map to AD Group. 2 Select Remove original AD group membership or cancel the selection depending on whether you want to keep the current members of the group when adding the users from the alias definition. If you select this option, the wizard removes the existing members of the group when adding the new members. If you do not select this option, the wizard adds the new members to the existing members. 3 Click Browse, then enter search criteria to identify the group and click Find Now. 4 Select the name of the group and click OK. The wizard imports the users defined by the alias into the specified Active Directory group. It also issues a warning message that it can t import users who are defined by the alias but who are not defined in Active Directory. Viewing Runas Aliases A runas alias defines a group of one or more users who other users are able to run commands as. Select and double-click the alias name to expand it and see the users who are defined for it. You cannot directly import runas aliases, however, if a user specification includes a runas alias, you can view the runas definition in the Runas Alias node, and import the commands defined in the specification. See Importing User Specifications on page 175. Importing Host Aliases Host_Aliases are popular in centralized sudoers files because they allow assigning privileges to groups of computers rather than managing on an individual computer and file basis. They convert naturally to computer roles, which also assign privileges to groups of computers. When you convert a Host_Alias to a computer role, the wizard creates a new computer role, creates an Active Directory group that contains the computers defined in the host alias, and adds these computers to the new computer role. Because it s an Active Directory group, the group of computers can span multiple zones and include computers that are joined to different zones. To complete the computer role definition, you must add role assignments, which specify the roles that specific users and groups are allowed to perform on the computers defined in the computer role. To create a computer role from a host alias 1 Select the alias name, right-click and select Create Computer Role. Administrator s Guide for Linux and UNIX 174

175 Migrating from sudo to dzdo 2 Click Next to accept the location for the group of computers, or change the location, then click Next. 3 Verify or change the name, select whether to add a prefix or suffix to the name, and select the group scope, then click Next. 4 Click Next to create the new computer role in the Access Manager console and the new Active Directory group of computers. The computers defined in the alias are automatically added to the new Active Directory computer group and to the Members node of the new computer role; for example, the following screen shot shows the Members node for a computer role created from a host alias named MAILSERVERS that defines two computers, smtp and smtp2 : 5 To add role assignments to the computer role, navigate to Authorization > Computer Roles >rolename, select Role Assignments, then right-click and select Assign Role. 6 Select the role and click OK. 7 Select Accounts below and click Add AD Account. 8 In Find, select User or Group, enter search criteria, then click Find Now. 9 Select the user or group, click OK, then OK again to make the role assignment. Viewing Command Aliases The Command Alias node shows commands that were imported from the sudoers file however, it is really just a preview you can t edit or delete these commands. But you can use User Specifications to assign Command_Aliases to roles, role groups, and computer roles. Importing User Specifications In the sudoers file, user specifications make use of alias definitions to assign commands and privileges to users. You can import user specifications to make role assignments. To import user specifications to make role assignments 1 Select the user specification, right-click and select Import. Chapter 10 Authorizing users 175

176 Migrating from sudo to dzdo The commands to be created are displayed. 2 Click Next. The role to be created is displayed. The role defaults to Role_n you can change it after it is created. 3 Click Next. The role assignment to be created is displayed. If the wizard is unable to make the role assignment, the role is marked with an error ( ) symbol, the Next button is grayed out, and the Remarks field displays an error message. For example, the import could fail for the following reasons: Reason for failure The user for whom the role assignment will be made does not belong to the zone. The computer role cannot be created because no computers are specified in the user specification. Error message Failed to find user username in zone/ Host alias aliasname must have member. 4 Click Next, then Finish. 5 Complete the following optional steps to rename the role to something more meaningful, if you wish. a Navigate to Authorization > Role Definitions and select the new role (for example, Role_2). b Right-click and select Rename, then enter a more meaningful name for the role. c Navigate to Authorization > Role Assignments to see that the role assignment has been made and that the name of the role has been updated. The roles you create from a sudoers specification do not contain the UNIX system rights or PAM access rights that are necessary for log in. You can provide these rights in a number of different ways: Assign these rights directly to each user through a separate role assignment. For example, the predefined UNIX Login role grants password and non-password login, and access to all PAM applications. This is the recommended approach as it allows maximum flexibility in creating and assigning roles. Add UNIX system rights and PAM access rights to each new role you create. To assign log in rights to users 1 Open the Access Manager console, expand the zone of interest, and expand Authorization. 2 Select Role Assignments, then right-click and select Assign role. 3 Select the role to assign and click OK. Administrator s Guide for Linux and UNIX 176

177 Migrating from sudo to dzdo For example, the predefined UNIX Login role provides password and non-password login, as well as access to all PAM applications. If you have specifically defined a different role for log in access, select that role. 4 Select Accounts below and click Add AD Account to select the users to assign to this role. 5 Enter search criteria and click Find Now to retrieve a list of Active Directory users. 6 Select one or more users and click OK. 7 Click OK to make the role assignment to the specified users. To add UNIX rights and PAM access rights to roles imported from sudoers 1 Open the Access Manager console, expand the zone of interest, and expand Authorization > Role Definitions. 2 Select one of the new roles, then right-click and select Add Right. 3 Select the right to assign and click OK. The Type column shows all the PAM access rights. For example, the predefined loginall right provides access to all PAM applications. If you have specifically defined a different right for PAM in access, select that right. 4 Select the role again, then right-click and select Properties. 5 Click the System Rights tab and select the UNIX rights to add. Click F1 to get details about each type of right, or see Configuring system rights on page 146. You may also add rescue rights or go to the Audit tab to change audit settings (see Configuring audit levels on page 148). 6 Click OK. Purging sudo data from the console Once you have validated the sudo conversion, you can purge the sudoers data you imported. 1 On a Windows computer, open the Access Manager console and navigate to and expand the zone in which you imported the sudoers file. 2 Select Sudoers then right-click and select Purge. The Sudoers node and sub nodes are removed from the Console. Mapping sudo to dzdo To execute DirectAuthorize privileged commands users must type dzdo and the command name. If you want, you can map sudo to dzdo, which allows your users, who are Chapter 10 Authorizing users 177

178 Running reports for roles and rights accustomed to using sudo to execute privileged commands, to continue to type sudo commandname, but in fact, will be executing dzdo commandname. Of course, in order for this to work, the user must be authorized by a role to execute the specified command. To map sudo to dzdo 1 On a Windows computer, open the Group Policy Management Editor. 2 In the Group Policy Management Editor, expand Computer Configuration > Policies > Centrify Settings > DirectControl Settings, click Dzdo Settings, then double-click Replace sudo by dzdo. 3 Select Enabled, then click OK. Running reports for roles and rights To view information about rights and role assignments, you can run the following default report definitions or create your own custom reports: The default Hierarchical Zone - UNIX User Effective Rights report lists the effective rights for each user on each computer. The report shows the name of the right, it s type, and where it is defined. The default Hierarchical Zone - Windows User Effective Rights report lists the effective rights for each user on each computer. The report shows the name of the right, it s type, and where it is defined. The default Hierarchical Zone - Zone Role Privileges report lists the roles that are defined for each hierarchical zone and the rights granted to each of these roles. The default Hierarchical Zone - Computer Audit Level report lists the audit level for all authorized users on each computer. The default Hierarchical Zone - Computer Effective Rights report lists the privileges granted on each computer. The default Hierarchical Zone - Computer Effective Roles report lists the roles assigned on each computer. The default Hierarchical Zone - Computer Role Assignments, Hierarchical Zone - Computer Role Membership, and Hierarchical Zone - Computer Role Membership Grouped by Zone reports list the role assignments and member computers for the computer roles for each zone. The default Classic Zone - User Privileged Command Rights Grouped by zone report lists the privileged commands that have been defined for each user in each zone where rights and roles are enforced. This report includes the domain name, user profile name, name of each privileged command, the scope to which the role assignment applies, and the description of the right. Administrator s Guide for Linux and UNIX 178

179 Running reports for roles and rights The default Classic Zone - User Role Assignments Grouped by zone report lists the role assignments for each user in each zone where rights and roles are enforced. This report includes the domain name, user profile name, the list of roles the user is assigned to in each zone, and the scope to which the user s role assignment applies. The default Classic Zone - Zone Role Privileges report lists the privileged roles that have been created in each zone where rights and roles are enforced. This report includes the role name, and for each role, the name and type of each right that the role contains. For more information about generating and working with reports, see Generating predefined and custom reports on page 188. Chapter 10 Authorizing users 179

180 Chapter 11 Managing license containers and keys This chapter describes how to update and manage Centrify license keys for servers, workstations, and supported applications. The following topics are covered: Understanding how licensing works Adding license containers Assigning a specific license container to a zone Viewing the license summary Adding license keys Removing a license key Running a report for licenses Understanding how licensing works Although licensing is based on the number of servers and workstations you authorize for access, license validation does not impact the operation of any production systems. Instead, license validation is handled through the Access Manager console so that the administrator is notified if there are not enough license keys to cover the number of Centrify-managed systems. With this licensing enforcement model, the Access Manager console always checks for license keys at startup to verify that there are enough license keys installed for all UNIX and Windows computers with valid accounts in Active Directory. If the number of licensed servers and workstations exceeds the total number of licenses you have purchased, the Access Manager console will display the Manage Licenses dialog box to enable you to add license keys. Once you have installed enough license keys to cover all the configured UNIX, Linux, Mac OS X, or Windows computers, the Access Manager console will open at startup and allow you to perform all of the normal administrative tasks. Understanding license types Licenses are issued based on how a computer is used. For example, a computer can be licensed as a UNIX or Windows workstation or as a standard UNIX or Windows server, or as an application server. The following types of licenses are available: Workstation Licenses (UNIX or Windows) permit a specific number of UNIX or Windows workstations to be available to Active Directory users. Workstation licenses 180

181 Adding license containers are intended for computers that are used interactively by one or two concurrent users but that do not host applications accessed by multiple users. There are separate UNIX workstation and Windows workstation licenses. Server Licenses (UNIX or Windows) permit a specific number of servers to be available to Active Directory users accessing server-based applications. Server licenses are for computers that are accessed by multiple concurrent users and typically host a specific type of application. There are separate UNIX workstation and Windows workstation licenses. Application Licenses permit servers to be available for Active Directory users accessing specific applications hosted on these servers. Understanding license keys Depending on whether you have purchased software licenses, your license keys might provide limited evaluation usage of the software for a specific number of days, or permanent access to features for a set number of computers. If you initially install using an evaluation license key, you must eventually replace that evaluation key with one or more permanent license keys to continue using the software. 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 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. 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 software on a Windows computer or after installation using the Access Manager console. For information about using the Access Manager console to add licenses, see Adding license keys on page 186. Adding license containers 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 Chapter 11 Managing license containers and keys 181

182 Adding license containers 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: 1 Open Access Manager console. 2 In the console tree, right-click DirectManage Access Manager, then click Manage Licenses. 3 Click the Update tab. 4 In the License container section, click Add. Click Add to add a new license container object to Active Directory Administrator s Guide for Linux and UNIX 182

183 Adding license containers 5 Browse to select a location for the new license container, then click Create. 6 Select either container or organizational unit to indicate the type of object to create, and type a name for the new license container object and click OK. 7 Click OK to close the Browse for container dialog box. 8 When prompted to confirm the creation of the container object, click Yes to add the license container to Active Directory. 9 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. Chapter 11 Managing license containers and keys 183

184 Assigning a specific license container to a zone Assigning a specific license container to a zone If you choose to use more than one license container in the forest, you can assign a specific license container to an individual zone. This option is useful if you want to manage zones independently with each zone using its own set of license keys rather than having all zones use a common pool of licenses. If you assign a specific license container to a zone, however, only the license keys installed in that container can be used for the computers in that zone. For example, if you create a license container object named ajax.org/performix Licenses, add a license key for 10 Workstation license to that container, and assigned that container to the Performix Division zone, those ten workstation licenses are available specifically for the computers you add to the Performix Division zone. To assign a license container to a zone: 1 Open the Access Manager console. 2 If prompted to connect to a forest, specify a domain controller, and, if needed, the user credentials for connecting to the domain controller, then click OK. 3 In the console tree, select Zones to display the list of zones. 4 Select a zone and right-click, then click Properties. 5 On the General tab, select a specific Licenses container from the list of available License containers for the zone to use, then click OK. For example: Select a License container from the list of available License containers For more information about setting zone properties, see Setting zone properties on page 44. Administrator s Guide for Linux and UNIX 184

185 Viewing the license summary Viewing the license summary As discussed in Understanding how licensing works on page 180, 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: 1 Open Access Manager console. 2 In the console tree, right-click DirectManage Access Manager, then click Manage Licenses. 3 Click the Summary tab. 4 Select All license containers to see a summary of all of the licenses installed in all of the license containers defined in the forest. The Computers section lists the total number of UNIX shell workstation and server licenses you have installed and activated with licensing keys. Because the number of UNIX shell licenses includes workstations and servers, the Licensed value represents the maximum number of computers authorized to join Active Directory domains in the current forest if All license containers is selected. The number of Used licenses indicates the number of computers currently joined to Active Directory domains that allow access to a UNIX shell or applications. Chapter 11 Managing license containers and keys 185

186 Adding license keys The Applications section lists the total number of application licenses of each application type 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. If you want to see licensing information for a specific license container, select the container from the list of available License containers. For example: Select a specific license container to view only information about the licenses in that container If you select a specific license container, the Licensed value only represents the number of licenses available in the selected container and the number of Used licenses only represents the licenses used in the zones that are associated with the selected container. Adding license keys If you need to add license keys to enable more computers to join the domain: 1 Open Access Manager. 2 In the console tree, right-click DirectManage Access Manager, then click Manage Licenses. 3 Click the Update tab. 4 Select the appropriate License container from the list of available license containers. 5 In the License keys section, click Add. 6 Type the new license key, then click OK. 7 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. 8 Click OK. Removing a license key If you want to delete a license key you have previously installed: Administrator s Guide for Linux and UNIX 186

187 Running a report for licenses 1 Open Access Manager console. 2 In the console tree, right-click DirectManage Access Manager, then click Manage Licenses. 3 Click the Update tab. 4 Select the license key you want to remove, click Remove, then click OK. Running a report for licenses To view information about the licenses you have installed and used, run the Centrify Deployment Report, which you run independently of the Access Manager console. To run Deployment Report tool 1 Click Start > All Programs > Centrify Server Suite 2014 > Centrify Utilities and Tools > Deployment Report. Note If you do not see the Deployment Report in the Start menu, contact your Windows administrator to install it. The Deployment Report is an independent package that an administrator must install separately from the Access Manager console. 2 Click Next to accept the domain controller that is shown and current credentials, or enter a different domain controller and select the check box to enter different credentials if the current users does not have permissions to retrieve deployment information, then click Next. 3 Enter the name and folder for the report and decide whether to hide forest and host names in the report. The report is generated by default in C:\Users\username\Documents with the name Centrify_Deployment_Report_yyyymmdd. If a report of the same name already exists, the report will add an incremented version number suffix. Select Hide forest and host names from the report to keep forest and host names private by generating random names for them. 4 Click Next, Next, and Finish to generate the report. For more information about the Deployment Report, see Using Centrify Deployment report on page 200. Chapter 11 Managing license containers and keys 187

188 Chapter 12 Generating predefined and custom reports Access Manager includes a Report Center with several default reports that provide summarized and detailed information about users, groups, computers, zones, and licenses. The Report Center also provides a Report Wizard that you can use to modify the content or format of any default report or create your own custom reports. This chapter describes how to view, modify, and save report results in the Report Center and how to use the Report Wizard to create your own report definitions. The following topics are covered: Understanding the importance of reports Understanding the default report definitions Understanding current and snapshot results Generating a report from current or saved results Creating and modifying report definitions Exporting and importing report definitions Configuring SMTP for ing reports Using Centrify Deployment report Using the database loader and report command line utilities Understanding the importance of reports Reports provide you with information about the users, groups, computers, and zones you are managing and the properties associated with them. They can be useful for auditing who has access to different systems, the availability of licenses, and the current status of accounts. 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 permission to perform specific tasks. Reports can help simplify accounting and auditing of user access and provide the information you require for capacity planning and regulatory compliance. For any report you create you can choose different ways to filter, group, sort, and format the information included. You can also choose to save reports in different file formats so they can be displayed on web sites or imported into other programs. Note By default, all Authenticated Users can run reports in the Report Center. No additional rights need to be granted to enable users to run reports. 188

189 Understanding the default report definitions Understanding the default report definitions Access Manager console includes a number of default report definitions that you can use to generate commonly requested reports out-of-the-box without modifications or use as a basis for customized reports of your own. These default report definitions are listed under the Report Center node in the Access Manager console. Note In addition, independently of the Access Manager console, you can install and run the Centrify Deployment report, which provides information about the deployment of Centrify software in your environment, including a list of computers that have the access control agent or auditing agent installed, any orphaned computers, and used and unused licenses. The default report definitions provide the following information if you run them unmodified: This predefined report Classic Zone - Authorization Report for Computers Classic Zone - Authorization Report for Users Classic Zone - User Privileged Command Rights Grouped by Zone Classic Zone - User Role Assignments Grouped by Zone Classic Zone - Zone Role Privileges Computer Summary Report Computers Report Groups Report Includes this information by default Lists each computer in the zone and indicates which users are allowed to access each computer. The report includes details from the user s UNIX profile for each user listed, including the user s Active Directory user name, UNIX user name, zone, UID, shell, home directory and primary group. Lists each user account in the zone and indicates which computers each user can access. The report includes details from the user s UNIX profile for each user listed, including the user s UNIX user name, zone, UID, shell, home directory and primary group. Lists the privileged commands that each user has permission to run and the scope to which the user s rights apply. The report is sorted by zone for the zones where rights and roles are enforced. Lists the role assignments for each user in each zone. The report includes the domain name, user profile name, the list of roles the user is assigned to in each zone, and the scope to which the user s role assignment applies. The report is sorted by zone. Lists the roles that are defined for each classic zone and the rights granted by each of these roles. Lists computer account information for each computer in each zone, including the computer account name in Active Directory, the computer s DNS name, the computer s operating system, and the version of the Centrify UNIX agent installed on the computer, if available. Lists computer account information for each computer in each zone, including the computer account name in Active Directory, the computer s DNS name, the computer s operating system, and the version of the Centrify UNIX agent installed on the computer, if available. Lists group information for each group in each zone, including the Active Directory group name, the UNIX group name, the UNIX group identifier (GID), and whether the group is an orphan. Chapter 12 Generating predefined and custom reports 189

190 Understanding current and snapshot results This predefined report Hierarchical Zone - Computer Effective Audit Level Hierarchical Zone - Computer Effective Rights Hierarchical Zone - Computer Effective Roles Hierarchical Zone - Computer Role Assignments Hierarchical Zone - Computer Role Membership Hierarchical Zone - Computer Role Membership Grouped by Zone Hierarchical Zone - UNIX User Effective Rights Hierarchical Zone - Windows User Effective Rights Hierarchical Zone - Zone Role Privileges Stale Computers Report User Account Report Users Report Zone Delegation Report Zones Report Includes this information by default Lists the audit level in effect for computers in each zone. Lists the privileges granted on each computer. Lists the roles assigned on each computer. Lists the computer roles that are defined for each zone. The report includes the users and groups and their associated roles. Lists the computer roles that are defined for each computer and the zone to which they belong. Lists the computer roles that are defined for each computer grouped by the zone to which they belong. Lists the effective rights for each UNIX user on each computer. The report shows the name of the right, it s type, and where it is defined. Lists the effective rights for each Windows user on each computer. The report shows the name of the right, it s type, and where it is defined. Lists the roles that are defined for each hierarchical zone and the rights granted by each of these roles, including where each right is defined. Lists the stale computers. Lists account details for the users that have UNIX profiles in each zone. The report includes the Active Directory display name, the Active Directory logon name, the Active Directory domain for the account, and details about the account status, such as whether the account is configured to expire, locked out, or disabled and the date and time of the account s last logon. Lists information from the UNIX profile for each user in each zone. The report includes the user s Active Directory user name, UNIX user name, UID, shell, home directory and primary group. Lists the administrative tasks for each zone and the users or groups have been delegated to perform each task. This report indicates which users or groups have permission to perform specific tasks, such as add groups, join computers to a zone, or change zone properties. Lists the zone properties for each zone. The report includes the zone name, list of available shells, the default shell, the default home directory path, the default primary group, the next available UID, reserved UIDs, the next available GID, and reserved GIDs. Understanding current and snapshot results Each report definition can be used to retrieve a current report of live data at any point of time. You can also use the report definition to a take a snapshot of the live data to save the result retrieved in a dated report that can be accessed later. For example, you may want to Administrator s Guide for Linux and UNIX 190

191 Understanding current and snapshot results take a weekly or monthly snapshot of data to compare the results of a specific report over time. Retrieving current results The report retrieves the current results the first time you click the Current node for any report definition. When you click Current the first time, it retrieves the appropriate information from Active Directory as it exists at that moment. The results are not updated continuously, however. You can refresh the current results at any time by selecting Current, right-clicking, then clicking Refresh. To retrieve the current results for an existing report definition: 1 In the console tree, click the Report Center. 2 Expand the report definition name for which you want to retrieve results, then click Current. For example, to retrieve the current information for the Users Report, expand the Users Report report definition, then click Current. Depending on the report definition, the results may be nested under the Current node. For more information about viewing results in the Access Manager console, see Viewing current or saved results in the console on page 191. For information about generating report output from the results, see Generating a report from current or saved results on page 192. Taking a snapshot of results The current data for any report definition is subject to change as you add or delete accounts or change account properties. In some cases, however, it is useful to have historical reports that capture data at specific points in time, for example, for quarterly reports or year-end analysis. To save the results from a report so they can be accessed later, you can create a snapshot of the data. To take a snapshot for a report definition: 1 In the console tree, click the Report Center. 2 Select the report definition for which you want a snapshot, right-click, then click Take a Snapshot. For example, to take a snapshot of the results of the User Account Report, select the User Account Report report definition, then click Take a Snapshot. Viewing current or saved results in the console When you select either Current or Saved results in the Access Manager console, the data is not formatted into a static report. Instead, the results from the current or saved report are presented in nested form using the panes displayed and you can select the objects included in the results to perform additional tasks. For example, if you select the Chapter 12 Generating predefined and custom reports 191

192 Generating a report from current or saved results Hierarchical Zone - Computer Role Assignments report, then click Current, the results for each zone are nested under the Current node. You can then select a specific zone to see computer role information for that zone displayed in the results pane. Select a zone The specific information displayed in the results pane depends on the type of report you select. For example, if you select the Hierarchical Zone - UNIX User Effective Rights report and an individual user name, the results pane includes a list of computers where the user has effective rights, the roles the user has been assigned, and the specific rights granted on each computer. Generating a report from current or saved results You can generate a static report for any report definition using either current or saved results. A static report is a formatted view of the results that can be displayed, printed, or saved. You can save static reports as: HTML documents (.htm) Adobe Acrobat documents (.pdf) Microsoft Excel documents (.xls) XML documents (.xml) You can also customize the formatting of the static report to change how information is grouped and sorted, which columns of information are included in the report, how columns are displayed, and the fonts and colors used in table headings and rows. To generate a static report from an existing report definition: 1 In the console tree, click the Report Center. 2 Expand the report definition for the type of report you want to generate. For example, to run the User Effective Rights Report, expand the Hierarchical Zone - UNIX User Effective Rights report definition. 3 Select either Current or a Saved and dated snapshot of previously retrieved results, right-click, then click Display Report. Note In most cases, 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. Administrator s Guide for Linux and UNIX 192

193 Generating a report from current or saved results The report is displayed in a new window. From the report window you can customize the report format, save the report as a specific type of document, the report to another person, or print the report. Modifying the format of a generated report Once you have generated a report, you can modify its format in several ways. For example, you can modify the properties used for grouping and sorting, the sort order used, which columns are displayed in the output, the column names to use, and the fonts and colors to use. You should note that the specific properties you can use for grouping, sorting, and in the report layout depend on the properties defined for the report you have selected. To change the properties available in a report, use the Modify Report Wizard. To modify the content or layout of a generated report: 1 In the generated report window, click Report > Format. 2 Click the Group tab to change how the information in a report is grouped or to add grouping criteria. To add grouping criteria, select a property from the Group based on selected properties list and either Ascending or Descending order, then click Add. To remove grouping criteria, select a property in the Group by list, then click Remove. Chapter 12 Generating predefined and custom reports 193

194 Generating a report from current or saved results To change the order in which grouping is done when grouping by more than one property, select a property in the Group by list, then click Move up or Move down. For example, if you are modifying the Computers Report, you can group computers by zone, then within each zone by agent version number. Select a property to group by here Click Add to add the selected property to the Group by list 3 Click the Sort tab to change how the information in the report is sorted or to add sorting criteria. To add sorting criteria, select a property from the Sort based on these criteria list and either Ascending or Descending order, then click Add. To remove sorting criteria or change the sort order for a sort criteria, select a property in the Sort by list, then click Remove. To change the order in which sorting is done when sorting by more than one property, select a property in the Sort by list, then click Move up or Move down. For example, you can sort results by zone name in ascending or descending order. 4 Click the Layout tab to change the columns displayed in the report. To remove a property from the report, clear the Column checkbox. To change the display name or column width for a property, select the property name, then type a new column name or set a new column width. To change the column order from left to right, select the property name, then click Move up to shift a column to the left or Move down to shift a column to the right. 5 For example, check the properties you want to include in the report and uncheck the properties to exclude. If you include a property in the report, you can also specify the display name for the column and the column width.click the Summary tab to change the summary fields in the report. Select a property from the Summaries based on these criteria field and click Add. You can also add a summary field that is concatenated from multiple fields by selecting and adding properties from Create/Edit concatenated field. Administrator s Guide for Linux and UNIX 194

195 Generating a report from current or saved results For example, you can add summaries for the Active Directory DNS name and the OS name for the Computers Report. 6 Click the Font & Color tab to change the fonts and colors used in the report. Select an report attribute from the list of Display items, then select a font family, size, style, and colors to use for the selected attribute. For example, you can change the color of a table or group header by selecting the Table Header or Group Header from the list of Display items, then select the Foreground and Background colors to use. Saving or printing a generated report Once you have generated a report, you can save the report to a variety of file formats. Saving a report to different file formats gives you options for printing, distributing, and manipulating the report information. For example, if you want to post reports on a Web site, you can save reports as HTML (.htm) documents. If you want to incorporate report data in an Excel spreadsheet, you can save the report as an Excel (.xls) document. If you want to share a generated report with other departments, you may want to save the report as an Adobe Acrobat (.pdf) document. If you want to manipulate a report programmatically or import it into a database, you may want to save it as XML. You may also print a report. To save a generated report: 1 In the generated report window, click Report > Save As, then select the type of document to save the report as. You can save the report to any of the following formats: HTML Document PDF Document Excel Document XML 2 Select a location and type a file name for the report, then click Save to save the report in the selected format. Although you can save a generated report as an XML document and report definitions are XML documents that can be imported and exported from one Access Manager console to another, you cannot use the generated report output as a new report definition or import generated reports into the Access Manager console. To share reports with other administrators, you must export the report definition to XML. Other administrators can then import your report definition and generate their own reports from the imported report definition. Chapter 12 Generating predefined and custom reports 195

196 Creating and modifying report definitions To print a generated report: 1 In the generated report window, click Report > Page Setup to set page margins or printing options or Report > Print Preview to preview the report output. 2 Click Report > Print to print the report on the default printer. Creating and modifying report definitions Report definitions define the content and format of reports. The report definition describes the information the objects and their properties and relationships to retrieve, and how the information retrieved should be grouped and sorted in report output. You can delete, modify, or rename any existing report definition, including the default report definitions, using the Access Manager console. You can also create your own custom report definitions. The report definitions are stored as XML files for each user who creates report definitions in one of the following locations depending on your operating system: Documents and Settings\user\Application Data\Centrify\DirectControl\Queries C:\Users\user\AppDAta\Roaming\Centrify\DeploymentManager Creating a new report definition To create a new report definition: 1 In the console tree, select the Report Center, right-click, then click New Report Wizard. 2 Type the report name and a description of the report, then click Next. The report definition name can start with an alphabetic character or an underscore character (_), followed by any combination of alphabetic, numeric, underscore (_), hyphen (-) or spaces up to a maximum length of 64 characters. For example: Sample Zones Report Dept Select the primary object you want to report on, then click Next. Selecting the primary object controls the properties that are available for reporting. For example, if you select Active Directory Users for the report, the report can include information associated with the Active Directory user account, such as the account status, password restrictions, or the user s address and telephone number. If you select Zone Users, the report can include information about the user s UNIX profile but not the Active Directory account status unless you link this criteria to the report in Step 4. For example, to report on Zones as the primary object, select Zones from the list of objects. Administrator s Guide for Linux and UNIX 196

197 Creating and modifying report definitions 4 Select whether you want to link other criteria to the primary object included in the report, then click Next. For a simple report that only includes the properties associated with the primary object, select No, then click Next. For more complex reports, select Yes and a criteria to use, then click Next. For example, if you want to include UNIX user information in the report, you can select Yes to add a related link, then select Zones that contain Zone Users:The specific criteria you can choose depends on the primary object you select. For example, if you are creating a report about Zone Users, you can specify users in open zones, users in all zones, only the users that have been granted access to zone computers, or users that have permission to join a computer to the zone. Linking a primary object to other criteria makes additional properties available for inclusion in the report. For example, if you select Zone Users that are profiles of Active Directory users, you can report on properties associated with the Active Directory user account, such as the account status, the user s department, job title, or home phone number. If you select Zone Users that can access zone computers, the report can include computer account properties. You can continue adding relationship criteria to the report and clicking Next, as needed, until you have defined all of the criteria you want to use to generate the report. The specific objects and relationships you can choose depend on the primary object and each previous selection. When you are finished defining the criteria for the report, select No then click Next. For each object to be included in the report, select the specific properties to display, then click Next.For example: Select each object Select which object properties to include in the report Select Zones to choose the zone properties to include in the report. Chapter 12 Generating predefined and custom reports 197

198 Creating and modifying report definitions Select Zone Users to choose which use UNIX profile attributes to include in the report. Select Zone Computers to choose the computer account properties to include in the report. 5 Select the type of filter you want to apply, if any, then click Next. To add a filter: Select a property for filtering. The properties you can select as filters depend on the objects and properties you selected in Step 4. For example, if you include the UNIX user name, UID, and primary group name in the report, you can filter the report using any or all of these properties. Select the criterion to use when matching the filter string. For example, you can specify that the filter starts with, contains, is, or ends with the specified string. Type the string you want to match, then click Add. Add any other filters, then click Next. 6 For example, you can create a filter to include only the information for the domains that start with ajax in the domain name.review the report definition, then click Finish. 7 Select Zones, right-click, then click Refresh to update the Report Center with your new report definition. Modifying the content of an existing report definition If you want to change the properties available in a report, you can use the Modify Report Wizard to change the report definition. To modify the information retrieved in an existing report definition: 1 In the console tree, click the Report Center. 2 Select the report definition that you want to modify, right-click, then click Modify Report Wizard. 3 At the Welcome page in the Report Wizard, click Next. 4 Modify the name or description of the report, if needed, then click Next. 5 Select a new primary object to report on, if needed, then click Next. 6 Modify any other criteria related to the primary object included in the report, then click Next. 7 Modify the specific the specific properties to display, then click Next. 8 Modify the filters applied, if any, then click Next. For example, to remove a filter, select the filter, then click Remove. Administrator s Guide for Linux and UNIX 198

199 Exporting and importing report definitions 9 Review the report definition, then click Finish. Modifying the format of an existing report definition To modify the default formatting and report layout in an existing report definition: 1 In the console tree, click the Report Center. 2 Select the report definition that you want to modify, right-click, then click Format. 3 Click the Group tab to change how the information in report is grouped or to add grouping criteria. 4 Click the Sort tab to change how the information in the report is sorted or to add sorting criteria. 5 Click the Layout tab to change the columns displayed in the report, including the properties you want to report, the display name for each column, and the column width. 6 Click the Style tab to configure the fonts and colors used in the HTML, PDF, and Excel versions of the report. Select a document type, then click Configure. Select a font family, size, style, and the colors to use for titles, headers, and content of the report. Exporting and importing report definitions Report definitions are stored for each user in one of the following locations depending on the operating system: Documents and Settings\user\Application Data\Centrify\DirectControl\Queries C:\Users\user\AppDAta\Roaming\Centrify\DeploymentManager You can share report definitions by exporting the definition to an XML file and importing it into the Report Center on another computer or into another user s Access Manager console. You can also export report definitions to create new reports based on existing report definitions. To export and import previously created report definitions: 1 In the console tree, expand the Report Center node. 2 Select the report definition name that you want to export, right-click, then click Export. 3 Navigate to an appropriate directory, type a file name, then click Save. 4 In the console tree, select the Report Center, right-click, then click Import. Chapter 12 Generating predefined and custom reports 199

200 Configuring SMTP for ing reports 5 Navigate to the appropriate directory, select the report definition file name, then click Open. Configuring SMTP for ing reports Configuring the information for connecting to a mail server in the Access Manager console enables you to reports to a specific user or alias. To view or modify the Simple Mail Transfer Protocol (SMTP) settings for ing reports: 1 In the console tree, select the DirectManage Access Manager node and right-click. 2 Select Options. 3 Click the SMTP Configuration tab. 4 Specify a valid sender s user name and address, a recipient s user name and address, the SMTP server name and port number for outgoing mail, and the server authentication requirements, if any, then click OK. Using Centrify Deployment report The Centrify Deployment report generates information about the use of access control features, authorization services, and auditing services in your environment. The Deployment report can be installed and run independently of the Access Manager Console. This report generates the following information: A list of all computers that have the Centrify UNIX agent, Centrify Windows agent, or DirectAudit agent running. A list and count of orphaned systems. A count of the number of each type of license and the serial number for each license. The tool generates a comma separated value (csv) file, which is readable by a text editor or by a spreadsheet program such as Excel. Installing and running the Deployment Report as an independent tool The Deployment Report tool is available as a separate, self-extracting installation package: Centrify_Deployment_Report-version-winxx.msi To install Deployment Report tool 1 Download Centrify_Deployment_Report-version-winxx.msi to a location on a Windows computer. Administrator s Guide for Linux and UNIX 200

201 Using Centrify Deployment report 2 Double-click Centrify_Deployment_Report-version-winxx.msi to open the installer. 3 Click Next to accept the license agreement and default installation folder (C:\Program Files\Centrify\Deployment Report), then Install to begin installation. 4 Click Finish to complete the installation. To run Deployment Report tool 1 Click Start > All Programs > Centrify Server Suite 2014 > Centrify Utilities and Tools > Deployment Report. 2 Click Next to accept the domain controller that is shown and current credentials, or enter a different domain controller and select the check box to enter different credentials if the current users does not have permissions to retrieve deployment information, then click Next. 3 Enter the name and folder for the report and decide whether to hide forest and host names in the report. The report is generated by default in C:\Users\username\Documents with the name Centrify_Deployment_Report_yyyymmdd. If a report of the same name already exists, the report will add an incremented version number suffix. Select Hide forest and host names from the report to keep forest and host names private by generating random names for them. 4 Click Next, Next, and Finish to generate the report. Understanding the Deployment Report output The Deployment Report generates the output in the following categories: Issues lists any issues that prevent a full report. Deployment Summary lists how many agents of each type are licensed, and for each type, how many licenses are used and how many are still available. License Report provides details about the licenses, including the key, count, serial number and expiration date. Checksum is the encrypted data of the deployment information. If you send the report to Centrify support, they run a verification tool that uses the checksum information to determine that the report has not been tampered with. Therefore, it is important not to modify any information above the END OF REPORT SUMMARY line. System Report displays the status of systems that have the access control agent or the auditing agent installed. The status is Active, Inactive, Express, or Orphaned. Chapter 12 Generating predefined and custom reports 201

202 Using the database loader and report command line utilities Using the database loader and report command line utilities In addition to the Report Center reports in Access Manager, Centrify provides separate command line utilities that enable you to efficiently create and populate a SQLite database with current Centrify-specific Active Directory object properties, then create and execute SQL queries of the database to produce useful text file-based reports. These command line utilities are addbloader, adreport, and adreport2. By using addbloader and adreport2, you can produce reports that include information about the relationships between users, computers, groups, zones, roles, role assignments, PAM access rights, and privileged commands. To produce reports using adreport2, you must first run addbloader. The addbloader command creates a SQLite database and reads a set of custom-specified Centrify Active Directory object properties from Active Directory to populate the database with that information. Once the database is populated, you can run adreport or adreport2 with a variety of options to create custom reports to obtain very granular information about the Centrify Active Directory environment. The addbloader, adreport, and adreport2 command line utilities are installed with the Centrify agent. After you install the agent, you should create the addbloader configuration file. The addbloader command uses the information in the configuration file and the command line parameters you specify to log on to an Active Directory domain, define the path to the database, specify the administrator user name and password, and identify the hierarchical zone from which the SQLite database is populated. You should note that there is no default addbloader configuration file included with the command line utilities. You must create the file yourself using any text editor. In the configuration file, you need to specify bind and load information for the zones in which you are interested. You should also turn caching on in the configuration file. The following is an example of a basic addbloader configuration file: bind centrify-qa.test administrator {myp@$swd} cache on load_ad_users DC=centrify-qa,DC=test load_root "cn=finance,cn=global,cn=zones,ou=unix,dc=centrify-qa,dc=test" Administrator s Guide for Linux and UNIX 202

203 Using the database loader and report command line utilities load_root "cn=global,cn=zones,ou=unix,dc=centrify-qa,dc=test" In this example, the credentials for binding to the domain are included in the configuration file. In most cases, you would specify the administrator user name and password as command line options instead of in the configuration file. After you have created the configuration file, you can run a command similar to the following to create and populate the SQLite database: /usr/share/centrifydc/adedit/addbloader -db /tmp/zone_report -config./ zone_report.config In this example, the options used specify the following: -db -config Specifies the path, including the file name, to the SQLite database file you are creating. Specifies the name of configuration file that you have created. In this example, the configuration file is named zone_report.config in the current directory. If the password is not stored in the configuration file, you would be prompted for the password when you run the addbloader command. Using the configuration file to control the scope of the database You can use the addbloader configuration file to populate the SQLite database with only the zone information you need for your reports. By limiting the database to specific zones, you can control the size of the database and improve performance when generating the reports. You should note, however, that you can only load information for hierarchical zones. Classic zones are not supported. If you want to monitor the progress of the addbloader command as it loads the zones specified in the configuration file, you can include the v option in the command line. Using the report command line utilities The database created with the addbloader command is fully compatible with both the adreport and adreport2 command line utilities. Using the original adreport The adreport utility produces simple one-dimensional reports. The basic syntax for adreport is: adreport -db dbpath -report reportname [-filter filter ] [-sep csv tab char] For more information about the syntax and these options, see the man page for adreport. The original adreport utility includes the following predefined report types: User Report Computer Report Command report Assignment report Chapter 12 Generating predefined and custom reports 203

204 Using the database loader and report command line utilities Special assignment report Effective assignment report Role report Effective role report Using the new adreport utility Centrify Server Suite 2014 includes a new version of the reporting utility, adreport2, that supports two-dimensional query target options. For example, you can use adreport2 to produce a User-By-Computer report rather than just a User or Computer report that you could produce using the adreport utility. Because adreport2 supports two-dimensional targets, you can use it to perform more specific searches, generate more complex report types, and provide more effective assignment reports. The two-dimensional query target options format is: ReportNameByFilterField For example, you can produce user reports filtered by computer, zone, Active Directory user or other fields. By default, the adreport2 utility supports the following predefined reports for users: UserByAny UserByADUser UserByComputer UserByZone UserByUname UserByUid UserByUserComputer Depending on the report you want to run, you can specify the following command line options: -filter filter -value value -value2 value2 -sep csv tab char Specifies a filter to narrow the corresponding report results. Specify a value for the corresponding report. For example, use zone name as a value for RoleByZone report. Some reports can have two filtering fields. Specify an additional value for the corresponding report. For example, you might use computer name as value2 for UserByUserComputer report. Specify whether to create a comma separated list, tab-separated list, or a user-specified separator character list. For example, to generate a UserByADUser report for the UNIX user chris, you might specify a command line similar to the following:./adreport2.tcl -db myreport.db -report UserByADUser -value 'chris%' The report output is formatted into the following fields, separated by the pipe ( ) character: Administrator s Guide for Linux and UNIX 204

205 Using the database loader and report command line utilities zone_name computer_dns_name user_principal_name uname uid home shell gid pas sflag ssoflag allowflag shellflag permitflag auditlevel For example: Global comp100.jz.test chris_carter %{home}/ %{user} %{shell} AuditIfPossible FIN utest1.jz.test [email protected] chris_carter %{home}/ %{user} %{shell} AuditIfPossible The following is an example of further narrowing the report results using standard SQL syntax using the filter command option:./adreport2.tcl -db myreport.db -report UserByAny -filter "zone_name='fin' and computer_name like 'utest%' and (user_upn like 'nina%' or user_upn like 'chris%')" For example: FIN utest1.jz.test [email protected] chris_carter %{home}/ %{user} %{shell} AuditIfPossible FIN utest1.jz.test [email protected] nina_norris %{home}/ %{user} %{shell} AuditIfPossible FIN utest2.jz.test [email protected] chris_carter %{home}/ %{user} %{shell} AuditIfPossible FIN utest2.jz.test [email protected] nina_norris %{home}/ %{user} %{shell} AuditIfPossible For more information about command syntax, command line options, and the predefined reports available, see the man page for adreport2. Chapter 12 Generating predefined and custom reports 205

206 Chapter 13 Troubleshooting authentication and authorization This chapter describes how to use diagnostic tools and log files to retrieve information about the operation of Centrify software and how to identify and correct problems within your environment. The following topics are covered: Understanding diagnostic tools and log files Analyzing information in Active Directory Configuring logging for agent Collecting diagnostic information Working with DNS, Active Directory, and Centrify software Understanding the Centrify DNS client Filtering the objects displayed Understanding diagnostic tools and log files Centrify Server Suite 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 operation, your Active Directory connections, and the configuration settings for individual UNIX and Linux computers. Although logging is not enabled by default for performance reasons, log files provide a detailed record of Centrify agent (adclient) activity. This information can be used to analyze the behavior of adclient and communication with Active Directory to locate points of failure. However, log files and other diagnostic tools provide an internal view of operation and are primarily intended for Centrify experts and technical staff. In most cases, you should only enable logging when you need to troubleshoot unexpected behavior, authentication failure, or problems with connecting to Active Directory or when requested to do so by Centrify Support. Other troubleshooting tools, such as command line programs, can be used at any time to collect or display information about your environment. 206

207

208 Analyzing information in Active Directory Select this option Empty profiles in hierarchical zones Empty zones Foreign Security Principal Clean Up Incomplete user UNIX data Inconsistency in granting NIS server permissions Inconsistent computer object names Insufficient permission for agent version update Insufficient permission for OS version update To do this Check for hierarchical zones that contain users or groups that have no profile data defined. Check for zones that have no computers, users, or groups. Check for foreign security principal objects whose corresponding security principal has been removed. Check for users whose profile is incomplete in the entire zone hierarchy; any such users will be unable to login to a computer even if they are assigned a login role for the computer. Note that a profile may be incomplete at any level of the zone hierarchy but as long as it is complete at the level where a computer is joined, it is considered a complete profile, and if the user has a login role, they may log into the computer. Check that there is a zone_nis_servers group in each zone that supports agentless authentication and that the group contains all the NIS servers that have been defined for the zone. The zone_nis_servers group is required to assign permissions to managed computers that act as NIS servers, and should not be manually deleted or modified. This option checks that the group exists and includes all of the computers acting as NIS servers to ensure data integrity. Check for discrepancy between the DNS name for a computer in Active Directory and its Centrify computer profile name. Check whether the computer object in Active Directory has sufficient permission to update the version number property of the Centrify UNIX agent in the computer s serviceconnectionpoint object. If the computer object does not have permission to change this property, the version number cannot be displayed. Check whether the computer object in Active Directory has sufficient permission to update the version number property of the operating system in the computer s serviceconnectionpoint object. If the computer object does not have permission to change this property, the operating system version number cannot be displayed. Administrator s Guide for Linux and UNIX 208

209 Analyzing information in Active Directory Select this option Invalid right assignments To do this Check whether an invalid right has been assigned to a role. This error occurs if a right has been added to a role and subsequently the right becomes invalid. Generally, a right becomes invalid if it is edited with a third-party tool, such as ADSI Edit, and an attribute is set to an invalid value. For example, Access Manager creates AD objects of type msds- AZOperation for command- and PAM-application- rights, and assigns a HEX value to the msds-azoperationid attribute of these objects. The range of reserved values for this attribute is as follows: Command: (HEX) 0500, FF,FFFF Invalid role assignments Invalid role assignments (DZ V2) Orphan child zones Orphan role assignments PAM application: (HEX) 0200, FF,FFFF If this attribute is set to a value that is out of the reserved range, the right will be invalid and will no longer appear in the Console. If the right has been assigned to a role, the Analyze command (Invalid right assignment routine) returns an error. You can select the error in the Analysis Results node and use the Action menu to delete it from the role if you wish. Check whether invalid role assignments exist in the zone. Typically, invalid role assignments occur when a role assignment is defined for a computer account and the computer leaves a zone without cleaning up roleassignment objects. Check for role assignments that contain multiple roles or multiple users. Note that this error only occurs if you are using third-party tools to edit role assignments. The Console and ADEdit both prevent you from creating invalid role assignments. Note that a role assignment consists of a single user and a single role. To assign multiple roles to a user, you create multiple role assignments, which the Console stores in the form user@domain role/sourcezone; for example: [email protected] login/engineering [email protected] vi_power/engineering [email protected] test/engineering Check for child zones that have an invalid parent zone. The information identifying the parent-child zone relationship is stored in the child zone in the form of a HEX string and the name of the domain to which the parent zone belongs. If this identifier is deleted, or changed to an invalid format, or if the parent zone is deleted but the child zone remains in the domain, Analyze (Orphan child zones) returns an error. Note that this error typically occurs only if you use third-party tools to edit zone objects in Active Directory. If you delete a parent zone in the Console, or by using ADEdit, any child zones are deleted as well. Check for role assignments that consist of a non-existent role or user, or that do not contain a role or user. Typically, this error only occurs if you are using third-party tools to edit Centrify objects in Active Directory. If you delete a role or user in the Console (or in ADUC), the role assignment will be deleted as well (the change will be visible after you refresh the display) and Analyze will not return an error. Chapter 13 Troubleshooting authentication and authorization 209

210 Analyzing information in Active Directory Select this option Orphan zone data objects and invalid data links Restricted roles Zone created under another zone Zone information in old format Zoneless computers To do this Check for zone data that have no corresponding Active Directory objects or have invalid links to Active Directory objects. For example, if you delete an Active Directory user but do not remove the profile for this user in a zone, the zone profile becomes an orphan and is flagged as such by this option. Check for roles that have been assigned commands that cannot be executed. When rights are created, they can be defined to run in a restricted-shell role, in an enhanced role (with dzdo), or with both. If a command that has not been defined to run in a restricted-shell is added to a restricted-shell role, this check returns an error. Check for zone information created in another zone s parent container. Note that this check does not look at hierarchical zones because it is expected that child zones are physically contained in their parent zone. Check for zone information stored in an obsolete Centrify zone format. Check for computers that do not belong to any zone. 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 and viewing the information listed in the right pane. For example: Administrator s Guide for Linux and UNIX 210

211 Analyzing information in Active Directory For additional information, select the warning or error, right-click, then select Properties. For example: Understanding common scenarios that generate results For most organizations, it is appropriate to check the data integrity of the Active Directory forest on a regular basis. Although running the Analyze command frequently may not be necessary for small networks with few domain controllers, there are several common scenarios that you should consider to determine how often you should check the forest for potential problems. The most likely reasons for data integrity issues stem from: Multiple administrators performing concurrent operations. Administrators using different domain controllers to perform a single operation. Replication delays that allow duplicate or conflicting information to be saved in Active Directory. Insufficient permissions that prevent an operation from being successfully completed. Network problems that prevent an operation from being successfully completed. Partial or incomplete upgrades that result in inconsistency of the information stored in Active Directory. Using ADEdit rather than the Console to create, modify, or delete zone objects, which may lead to problems, such as inadvertently creating a circular zone structure or an empty profile. Chapter 13 Troubleshooting authentication and authorization 211

212 Analyzing information in Active Directory Using third-party tools, such as ADSI Edit, to edit objects directly in Active Directory, which may lead to corrupted or invalid zone objects. Running Analyze periodically helps to ensure the issues these scenarios can cause are reported in the Analysis Results, so you can take corrective action. Responding to Analysis Results Depending on the type of warning or error generated in the Analysis Results, you may be able to take corrective action or access additional information. For example, if a computer account lacks the necessary permission to update Active Directory with the agent version it has currently installed, the Analysis Result will enable you to update the computer s account permissions to allow changes to that attribute. The following table describes the warnings and errors you may see in the Analysis Results after running the Analyze wizard and how to resolve potential issues. Check Result Responsive action Computers joined to multiple zones Cyclic zone hierarchy Duplicate groups in zone If there are any computers joined to multiple zones, an error is displayed. If the parent-child relationship of any zones is circular, an error is displayed. If there are any duplicate groups in a zone, a warning is displayed. No responsive action can be taken directly within the Analysis Results for this issue. In general, this issue only occurs if an administrator runs adleave with the --force option then runs adjoin to join the computer to a different domain without removing the old computer profile from Active Directory. You should identify the appropriate zone for the computer, then use the Access Manager console to delete the computer profile from any additional zones. Break the circular relationship. No responsive action can be taken directly within the Analysis Results for this issue. In general, this issue only occurs if multiple administrators perform concurrent operations or there are replication delays that allow a duplicate group profile to be added to a zone. For example, if two administrators add the same group to a zone using different domain controllers, there will be duplicate group profiles after the domain controllers complete replication. You should use the Access Manager console or ADSI Editor to delete the duplicate group profiles from the zone. Administrator s Guide for Linux and UNIX 212

213 Analyzing information in Active Directory Check Result Responsive action Duplicate service principal name in the forest Duplicate users in zone Duplicate SFU zones Duplicate zone default container If any duplicate service principal names (SPNs) are found for users or computers in the forest, a warning is displayed. If there are any duplicate users in a zone, a warning is displayed. If more than one Centrify SFU zone is found in the forest, a warning is displayed. If a duplicate default parent container for zones is found, a warning is displayed. No responsive action can be taken directly within the Analysis Results for this issue. Right-click the warning and click Properties to identify the duplicate SPN. Open the account properties for the user or computer and modify or remove the duplicate serviceprincipalname value. No responsive action can be taken directly within the Analysis Results for this issue. In general, this issue only occurs if multiple administrators perform concurrent operations or there are replication delays that allow a duplicate user profile to be added to a zone. For example, if two administrators add the same user to a zone using different domain controllers, there will be duplicate user profiles after the domain controllers complete replication. You should use the Access Manager console or ADSI Editor to delete the duplicate user profiles from the zone. No responsive action can be taken directly within the Analysis Results for this issue. Because an SFU zone is associated with an Active Directory SFU schema extension, there should be a maximum of one SFU zone in an Active Directory forest. In general, this issue only occurs if multiple administrators perform concurrent operations or there are replication delays that allow a duplicate. You should use the Access Manager console or ADSI Editor to delete any duplicate SFU zones. No responsive action can be taken directly within the Analysis Results for this issue. In general, this issue only occurs if multiple administrators perform concurrent operations or there are replication delays that allow a duplicate default container for new zones. Having more than one default parent container for zones can result in an unexpected default value in the Create New Zone wizard. You should use the ADSI Editor to delete any duplicate Zones parent containers from the forest. Chapter 13 Troubleshooting authentication and authorization 213

214 Analyzing information in Active Directory Check Result Responsive action Empty computer roles Empty profiles Empty zones Incomplete user UNIX data Inconsistency in granting NIS server permissions If a computer role does not have any member computers or role assignments, a warning is displayed. If a user or group profile has been added to a zone but has no attributes defined, an error message is displayed. If any zone does not contain users, groups, or computers, a warning is displayed for each type of object. For example, if a zone has computers and groups, but no users, only the user warning is displayed for that zone. If a user s NSS profile is incomplete in the entire zone hierarchy, a warning message is displayed. If the Active Directory group zone_nis_servers is not found in a zone configured for agentless authentication, an error is displayed. If the membership of the zone_nis_servers group is not consistent with the computers authorized as NIS servers, a Membership inconsistent error is displayed. If a zone is configured to support agentless authentication and the zone_nis_servers group exists but does not contain all computers in the zone, an informational alert is displayed. If the computer role has no member computers, right-click the warning in the Analysis Results, then select Add computers to add computers, or Delete Computer Role to remove the computer role. If a computer role has computer members but no role assignments, the only available response from the Analysis Results zone is to delete the computer role. You can, however, select the computer role in the Console, and add role assignments to its Role Assignments node. Right-click the warning in the Analysis Results, then select Delete empty profile to delete the profile from the zone, or Modify profile to define one or more attributes for the user or group. No responsive action can be taken directly within the Analysis Results for these issues. In general, this issue occurs early in a deployment before you have populated zones. You should use the Access Manager console to add missing objects to the zone. If the empty zone is not a valid zone, right-click the zone and select Delete. Right-click the warning in the Analysis Results, then select Modify zone profile to define additional attributes to complete the user s profile. Right-click the error in the Analysis Results, then select Create NIS servers group to create the zone_nis_servers group for agentless authentication. Note that your account must have permission to create this object for the operation to be successful. Right-click the error in the Analysis Results, then select Fix group membership to modify the membership list for the zone_nis_servers group. No responsive action can be taken directly within the Analysis Results for these issues. You should verify that all of the computers you want to use as NIS servers in the zone are configured to allow agentless authentication. Administrator s Guide for Linux and UNIX 214

215 Analyzing information in Active Directory Check Result Responsive action Inconsistent computer object names Insufficient permissions for agent update Insufficient permissions for OS upgrade Invalid right assignment Invalid role assignment Invalid role assignment (DZ V2) Orphan child zones Orphan UNIX data objects If there is a discrepancy between the DNS name in AD and the Centrify computer profile name, a warning message is displayed. If a computer account does not have permission to write to the keywords attribute, an error is displayed. If a computer account does not have permission to modify operating system properties, a warning is displayed. If a right for a role is invalid, a warning message is displayed. If a role assignment is invalid, a warning message is displayed. If multiple roles are assigned to a user, a warning message is displayed. If a child zone has an invalid parent zone, an error message is displayed. If an object has no parent object, a warning message is displayed. Right-click the error in the Analysis Results, then select Fix group membership to Right-click the error in the Analysis Results, then select Grant permission to computer account to update the permissions on the computer account object. Right-click the error in the Analysis Results, then select Grant computer permission to modify operating system properties to update the permissions on the computer account object. Right-click the error in the Analysis Results, then select Delete Right to delete the right from the role. Restricted roles If a restricted-shell role is assigned a right that cannot be run in a restricted shell, a warning message is displayed. Right-click the error in the Analysis Results, then select Delete Commands to remove the commands from the role, or select Allow running in restricted role to allow running the command in the restricted role. Chapter 13 Troubleshooting authentication and authorization 215

216 Analyzing information in Active Directory Check Result Responsive action Zone information in old format If a zone was created using the version 2.x console and includes a Private Groups container, a warning is displayed. If a computer profile was created using the version 2.x console, the warning Unix computer is in old format is displayed. If a group profile was created using the version 2.x console, the warning Unix group is in old format is displayed. If a user profile was created using the version 2.x console, the warning Unix user is in old format is displayed. If any computers in the zone are running version 2.x or 3.x agents, you should ignore this warning to ensure compatibility for those agents. If all of the agents in the zone have been upgraded, you can right-click the warning in the Analysis Results, then select Remove privategroupcreation attribute to update the zone format. If any computers in the zone are running version 2.x or 3.x agents, you should ignore this warning to ensure compatibility for those agents. If all of the agents in the zone have been upgraded, you can right-click the warning in the Analysis Results, then select Remove managedby and unix_enabled attribute to update the computer profile in the zone. If all of the agents in the zone have been upgraded, you can right-click the warning in the Analysis Results, then select Remove managedby attribute to update the group profile in the zone. If all of the agents in the zone have been upgraded, you can right-click the warning in the Analysis Results, then select Remove managedby and app_enabled attribute to update the user profile in the zone. Administrator s Guide for Linux and UNIX 216

217 Configuring logging for agent Check Result Responsive action Orphan UNIX data object Zone created under another zone Zoneless computers If a computer, group, or user profile exists, but no corresponding Active Directory computer, group, or user object is found, the warning Orphan UNIX data object is displayed. If a computer, group, or user profile has inconsistent links, an informational Inconsistent links alert is displayed. If a computer, group, or user profile does not have a parentlink value defined, a Missing parentlink warning is displayed. If the parent container for a zone is another zone object, an error is displayed. The computer ObjectName contains Centrify information but it is not in a zone. In general, this issue occurs if an administrator removes an Active Directory computer, group, or user object manually using ADSI Editor or Active Directory Users and Computers but the corresponding data is not removed for the UNIX profile. Right-click the warning in the Analysis Results, then select Remove orphan profile to remove all of the UNIX properties associated with the orphan profile. Computer, group, and user profiles are associated with Active Directory computer, group, and user objects through either the managedby attribute (agent version 2.x) or a parentlink value in the keywords attribute (agent version 3.x and later). If the links refer to different Active Directory objects, you will see this alert. Right-click the alert in the Analysis Results, then select Overwrite with the active link to remove outdated links. Right-click the warning in the Analysis Results, then select Missing parentlink to add the parentlink value to the keywords attribute. No responsive action can be taken directly within the Analysis Results for these issues. You should move the zone to another parent container or delete and recreate the zone in a different location. Right-click the warning in the Analysis Results, then select Move to Zone to search for and select the zone you want to place the computer in. Configuring logging for agent By default, the Centrify UNIX agent 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 agent-specific logging and record that information in a log file. Enabling logging for the Centrify UNIX agent To enable logging on the Centrify UNIX agent: 1 Log in as or switch to the root user. Chapter 13 Troubleshooting authentication and authorization 217

218 Configuring logging for agent 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 agent activity is written to the /var/log/ centrifydc.log file. If the adclient process stops running while you have logging on, the addebug program records messages from PAM and NSS requests in the /var/ centrifydc/centrify_client.log file. Therefore, you should also check that file location if you enable logging. For performance and security reasons, you should only enable logging when necessary, for example, when requested to do so by Centrify 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 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 FATAL ERROR WARN INFO To log this type of information 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. 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. 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. Informational messages that describe operational status or provide event notification. Administrator s Guide for Linux and UNIX 218

219 Collecting diagnostic information Logging for Access Manager Although most logging activity focuses on the actions of the Centrify UNIX agent, you can also enable or disable logging for the Access Manager console and configure the types of messages to record in the log file by selecting options in the Access Manager console. To configure logging for operations handled through the Access Manager console: 1 Open the Access Manager console. 2 In the console tree, select DirectManage Access Manager, 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 C:\Users\user\AppData\Roaming\Centrify\DirectManage folder and is updated as you perform different operations in the Access Manager console. Logging to the circular in-memory buffer If the Centrify UNIX agent s adclient process is interrupted or stops unexpectedly, a separate watchdog process (cdcwatch) automatically enables an in-memory circular buffer that writes log messages passed to the logging subsystem to help identify what operation the adclient process was performing when the problem occurred. The in-memory buffer is also mapped to an actual file, so that if there s a system crash or a core dump, the last messages leading up to the event are saved. Messages from the in-memory circular buffer have the prefix _cbuf, so they can be extracted from a core file using the strings command. The in-memory circular buffer allows debug-level information to be automatically written to a log file even if debugging is turned off. It can be manually enabled by restarting the adclient process with the -M command line option. The default size of the buffer is 128K, which should be sufficient to log approximately 500 messages. Because enabling the buffer can impact performance, you should not manually enable the circular buffer or modify its size or logging level unless you are instructed to make the changes by Centrify Support. Collecting diagnostic information 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 Support. For more information about the options available and the information returned with each option, see Using adinfo on page 285. Chapter 13 Troubleshooting authentication and authorization 219

220 Working with DNS, Active Directory, and Centrify software 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: magnolia Joined to domain: ajax.org Joined as: magnolia.ajax.org Current DC: ginger.ajax.org Preferred site: Default-First-Site-Name Zone: ajax.org/centrify/zones/corporate Last password set: :47:57 PST CentrifyDC mode: connected Licensed Features Enabled Working with DNS, Active Directory, and Centrify software Centrify agents are designed to perform the same set of DNS lookups that a typical Windows workstation performs to find the nearest domain controller for the local site. This DNS lookup enables the Centrify UNIX 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. Centrify agents also use DNS to find the Kerberos service providers and the global catalog service providers for the Active Directory forest. In a typical Windows environment, the DNS server role is updated dynamically to contain the service locator (SRV) DNS entries for Active Directory s LDAP, Kerberos, and global catalog services, so this information is available for Centrify agents to use. However, there are some configurations of DNS that may not provide all of the SRV records for the set of domain controllers that provide Active Directory service to the enterprise. You may also run into problems if DNS for the enterprise runs on UNIX servers that cannot locate your Active Directory domain controllers. The next sections describe how you can adjust DNS or Centrify agent to ensure they work together properly in your environment. Configuring the DNS server role on Windows One of the most common scenarios for running DNS in an environment with Active Directory is to add the DNS server role to a Windows domain controller or another Windows server. If you are already using DNS in Active Directory and dynamically publishing DNS service records, no additional configuration should be necessary. If you are using DNS in Active Directory but have disabled dynamic updates, you should change the configuration for the DNS server role to allow dynamic updates. Making this change will allow Centrify agents to properly locate domain controllers in the site and select an appropriate new domain controller if a connection to its primary domain controller is lost or the managed computer is moved to a new location on the network. Administrator s Guide for Linux and UNIX 220

221 Working with DNS, Active Directory, and Centrify software Configuring DNS running on UNIX servers 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 manually set the location of the Active Directory domain controller in the Centrify configuration file. Checking whether DNS can resolve the domain controller 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 ping command is successful, it indicates the DNS server is aware of the Active Directory domain you want to join and no further changes are needed. If the ping command is not successful, you will need to take further action to resolve the issue. Resolving issues in locating Active Directory domain controllers If the UNIX computer cannot find the Active Directory domain controller, there are several ways you can resolve the issue. Depending on your environment and specific situation, you should consider doing one of the following: Set up DNS on the target Active Directory domain controller and the manually configure the nameserver entry in the /etc/resolv.conf file to use that domain controller as described in Setting up DNS service on a target domain controller on page 221. Set the Centrify 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 223. Setting up DNS service on a target domain controller One of the simplest ways to ensure that the UNIX computers 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 Chapter 13 Troubleshooting authentication and authorization 221

222 Working with DNS, Active Directory, and Centrify software 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. Adding a DNS server role to an Active Directory domain controller To configure the DNS service on a Windows Server 2003 domain controller: Note The specific steps for configuring the DNS server vary depending on the version of the Windows operating system you are using. The following steps describe how to configure DNS on Windows Server 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 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. Administrator s Guide for Linux and UNIX 222

223 Working with DNS, Active Directory, and Centrify software 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 configuration file. To manually specify a domain controller, add the following entry to the Centrify configuration file, /etc/centrifydc/centrifydc.conf: dns.dc.domain_name: server_name [server_name...] For example, if you want to ensure the Centrify agent uses the domain mylab.test and the domain controller named dc1.mylab.test, you could 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 The Centrify agent will attempt to connect to the domain controllers in the order specified. For example, if the domain controller dc1.mylab.test cannot be reached, the agent 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_nam entry to the configuration file to specify the location of the global catalog. For example: dns.gc.mylab.test: dc3.mylab.test Chapter 13 Troubleshooting authentication and authorization 223

224 Understanding the Centrify DNS client You can add as many domain and domain controller entries to the Centrify 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 the Centrify UNIX agent 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 The Centrify agent 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 , you would run the following command: fixdns dc1.mytest.lab The fixdns script will then make the necessary changes to the /etc/hosts and the Centrify 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. Understanding the Centrify DNS client Centrify provides a DNS subsystem that completely bypasses the local DNS resolver to address issues that occur with many local DNS resolvers, such as: Degraded performance when connecting to and continuing to use a slow DNS server or when attempting to use dead DNS servers. Degraded performance when reacquiring a DNS server that went offline and has come back online. Degraded performance related to DNS timeouts. Platform-related DNS idiosyncrasies, such as MDNS, appending.local suffixes, and so on. The Centrify DNS subsystem performs the following functions: Administrator s Guide for Linux and UNIX 224

225 Understanding the Centrify DNS client Looks up hosts by name Looks up hosts by IP address Queries DNS service location records (SRV) to discover Domain Controllers that support Active Directory related services including KDC, KPASSWD, LDAP and global catalog. Resolving a host name or IP address When the DNS client subsystem receives a DNS requests, it attempts to resolve the host name or IP address by first checking the /etc/hosts file. If the file contains a valid entry to resolve the specified host name or IP address, the DNS client subsystem processes the DNS request. Entries in /etc/hosts must be in the following format: IPv4_address hostname alias alias... where: IPv4_address must be in the first position hostname is a fully-qualified domain name and must be in the second position. aliases are optional and follow the address and hostname entries. For example: ginger.acme.com ginger Note Service (SRV) record queries cannot be satisfied from the /etc/hosts file. If resolution by /etc/hosts is unsuccessful, the DNS subsystem attempts to select a DNS server that can be used to resolve the host name or IP address (as described in the next section, Selecting a DNS server). Selecting a DNS server If unable to resolve a hostname or IP address by finding an entry in the /etc/hosts name (as described in the previous section, Resolving a host name or IP address on page 225), the Centrify DNS subsystem attempts to find a DNS server to resolve the host name or IP address, as follows: It checks for a working DNS server that has already been selected (cached in memory and stored in /var/centrify/kset.dns.server), and if available, uses it. If a working DNS server is not already selected, it checks /etc/resolv.conf for configured DNS servers, and if populated, selects the fastest one from the list. If no working DNS servers are found, the request fails. At this point, DNS is considered down, and the Centrify DNS subsystem waits for the interval specified by the dns.dead.resweep.interval (default is 60 seconds), before attempting again to find a DNS server. Chapter 13 Troubleshooting authentication and authorization 225

226 Filtering the objects displayed Specifying DNS-related parameters Parameters in the Centrify configuration file control many aspects of Centrify DNS subsystem operation. Although you can set any of these parameters, the default settings should provide you with optimal DNS operation. See the Configuration and Tuning Reference Guide for details about any of these parameters. The DNS subsystem periodically checks in the background to see if a DNS server that is faster than the currently selected one is available. The dns.alive.resweep.interval parameter determines how often this background check occurs; the default value is one hour (3600 seconds). When a DNS server is selected, its address is stored in the kset.dns.server file, and it is used for all DNS requests until one of the following occurs: It stops responding. A new server sweep discovers a faster DNS server and replaces it. Adclient is stopped and restarted, which triggers a sweep for a new DNS server. The specified server is no longer in the list of servers in /etc/resolv.conf. For the sweep, the dns.sweep.pattern parameter determines the probe pattern that is used to find a live DNS server; that is, it sets the protocol to use (TCP or UDP) and the amount of time to wait for a response. By default, this parameter specifies both a TCP and UDP probe. The dns.timeout and dns.udp.retries parameters determine the amount of time to wait, and how often to re-send a request when the current server does not respond to a request. If the current server does not respond to a request within the specified time out period, it is considered down and Centrify looks for a different server. If it cannot find a live server, DNS is considered down, and the Centrify UNIX agent waits for the period of the dns.dead.resweep.interval parameter, 60 seconds by default, before performing a sweep to find a new server. Filtering the objects displayed For performance or security reasons, you might want to filter or limit the objects displayed in the Access Manager console. Depending on your environment, you might want to display more or less information by setting filter options. These filter settings enable you to control both the number and type of objects displayed. You should note, however, that these settings can affect the performance of the console. To filter the objects listed in Access Manager: 1 Open Access Manager. 2 In the console tree, select DirectManage Access Manager, right-click, then click Options. Administrator s Guide for Linux and UNIX 226

227 Filtering the objects displayed 3 Click the Filter Settings tab. 4 Select Load all zones to automatically open either all zones in the connected forest or all zones in a specific parent container. If you select this option and connected forest all zones in the forest are opened automatically each time you start Access Manager. Selecting this option prevents you from opening or closing any zones manually. Depending on the number of zones you have, you might experience slower performance in the console if you select this option. If you select this option and container, you can then click Browse to search for a container from which to automatically load zones. Selecting this option prevents you from opening or closing any zones manually. Depending on the number of zones you have in the selected container, you might experience slower performance in the console if you select this option. 5 Select Show disabled Active Directory accounts to display disabled computer and user accounts or uncheck this option to hide disabled objects. 6 Select Show orphans to display all users, groups, and computers that have a UNIX profile or uncheck this option to hide all orphan profiles. Orphan profiles are the service connection points that no longer have a corresponding Active Directory object. Hiding or removing orphan profiles can improve console performance. For information about locating orphan profiles by running an analysis on the Active Directory forest, see Analyzing information in Active Directory on page Select Show Auto Zone to display the users, groups, and computers that have joined the Auto Zone or uncheck this option to hide Auto Zone information. 8 Set the Maximum number of items to be displayed in the list option to limit the total number of objects displayed in the console, up to total maximum allowed (65535). This setting applies to all of the objects displayed in Access Manager, including zones, computers, users, groups, pending users, pending groups, NIS maps, and all defined rights, roles, and role assignments. Lowering the maximum number of items displayed improves performance when browsing the listed items. Note that this setting does not affect the number of items you can define, only the number displayed. 9 Click OK. Chapter 13 Troubleshooting authentication and authorization 227

228 Appendix A Using Centrify UNIX commands This appendix provides an overview of the command line interface and complete reference information for the command-line programs you can run on Centrify-managed systems. The following topics are covered: Understanding when to use command-line programs Displaying usage information and man pages Understanding common result codes Using adcache Using adcheck Using adchzone Using adclient Using addebug Using addbloader Using addns Using adfinddomain Using adfixid Using adflush Using adgpupdate Using adid Using adinfo Using adjoin Using adkeytab Using adleave Using adlicense Using admigrate Using adobfuscate Using adpasswd Using adquery Using adreload Using adreport 228

229 Using adrmlocal Using adsendaudittrailevent Using adsetgroups Using adsmb Using adupdate Using dzdo Using dzedit Using dzinfo Using dzsh Using nisflush Using OpenLDAP commands Appendix A Using Centrify UNIX commands 229

230 Understanding when to use command-line programs Understanding when to use command-line programs UNIX command-line programs are installed by default when you install the Centrify UNIX agent. The commands are typically installed in one of the following directories: /usr/sbin, /usr/bin, or /usr/share/centrifydc/bin. 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 adclient service library to enable you to add a UNIX, Linux, or Mac OS X computer to an Active Directory domain, leave the Active Directory domain, 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. Specific tasks these commands perform include: The adjoin command (the most important one) adds a UNIX computer to an Active Directory domain. It is the command you use first on each UNIX computer. Use adleave if you want to remove a UNIX computer from its current Active Directory domain or from the Active Directory forest entirely. Use adpasswd to change an Active Directory account password from a UNIX computer. Use adquery to retrieve information from Active Directory for a user or group. 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 To display a summary of usage information for a UNIX command-line program, type the command and the --help or -h option. For example, to see usage information for the adleave command, type: adleave --help The usage information includes a list of options and 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 (man) page. For example, to see the manual page for the adleave command, type: man adleave Administrator s Guide for Linux and UNIX 230

231 Understanding common result codes Understanding common result codes Centrify command-line programs share a number of result codes. The following table lists the result codes that are reserved for use by the command-line programs. Result Error name Indicates 0 ERR_SUCCESS Successful completion of the operation. 6 ERR_OTHERS Miscellaneous errors occurred during the operation. 7 ERR_USAGES Usage error occurred during the operation. 8 ERR_OP_ABORTED Operation aborted by user. 9 ERR_ROOT_PRIV Root privilege is required for the operation. 10 ERR_NOT_JOINED Computer is not currently joined to any Active Directory domain. 11 ERR_ALREADY_JOINED Computer is already joined to the current Active Directory domain. 12 ERR_JOINED_ANOTHER_DOMAIN Computer is currently joined to another Active Directory domain. 13 ERR_ADCLIENT_DOWN The adclient process is not running or not available. 14 ERR_ADCLIENT_DISCONNECTED The adclient process is running in disconnected mode. 15 ERR_ADLCIENT_STARTUP The adclient process failed to start. 16 ERR_DNS_TIMEOUT The DNS server is not responding and may be down. 17 ERR_DNS_GENERIC A generic DNS problem occurred during the operation. 18 ERR_INVALID_DOMAIN_NAME The Active Directory domain name is incorrect or not found in DNS. 19 ERR_INVALID_LOGON User name or password provided is not correct. 20 ERR_ACCOUNT_DISABLED The account specified has been disabled. 21 ERR_ACCOUNT_EXPIRED The account specified has expired. 22 ERR_ACCOUNT_EXISTS The account specified already exists, 23 ERR_ACCOUNT_NOTFOUND The account specified was not found in Active Directory. 24 ERR_PASSWORD_EXPIRED The account password has expired. 25 ERR_ZONE_NOTFOUND The zone cannot be found. 26 ERR_CONTAINER_NOTFOUND Invalid Active Directory container object. 27 ERR_INSUFFICIENT_PERM The account specified does not have permission to perform the operation. 28 ERR_CLOCK_SKEW The time difference between system clocks is beyond the acceptable range. Appendix A Using Centrify UNIX commands 231

232 Understanding common result codes Result Error name Indicates 29 ERR_COMPUTER_NAME Invalid computer account. 30 ERR_CRED_INVALID Invalid credentials. 31 ERR_SERVICE_TKT_INVALID Invalid service ticket. 32 ERR_POLICY_NOT_MATCH Policy not matched. 33 ERR_REJECT_CHG_PASSWD Password change rejected. 34 ERR_WORKSTATION_DENY Workstation denied. 35 ERR_NOT_FIND_USER No matching user found. 36 ERR_NOT_FIND_GROUP No matching group found. 37 ERR_NOT_CONNECT_ADCLIENT An attempt to open a connection to the adclient process failed. 38 ERR_ADLCIENT_STOP Unable to stop the adclient process. 39 ERR_QUOTA_EXCEEDED The user has exceeded the number of join operations allowed. 40 ERR_OPEN_FILE The attempt to open a file failed. 41 ERR_READ_FILE The attempt to read a file failed. 42 ERR_COPY_FILE The attempt to copy a file failed. Command-specific result codes are listed in the reference section for individual commandline programs. Administrator s Guide for Linux and UNIX 232

233 Using adjoin 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_name [--zone zone_name --workstation] 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 remove the computer account from the old domain by running adleave. Once the computer has left the old domain, you can run adjoin to join the new domain. Note To run adjoin, you must be logged in as root. By default, adjoin 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 time so the timestamp of Kerberos tickets is within an acceptable time difference for authentication. Determines the license type by reading the license-mode field in the license file. Checks whether a computer account already exists for the local computer in Active Directory, and if necessary creates a new Active Directory computer account. Adds the computer account to the specified zone (--zone option) or to Auto Zone (--workstation option) 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 alone has control of the account. Starts the adclient process on the local computer. You must specify the zone to join or connect through Auto Zone, unless you use the -- selfserve option to join a precreated computer to the zone in which it was created, or use --selfserve to rejoin a computer to a domain that it previously left. If you are running Centrify Express you can only join a domain through Auto Zone, not by connecting to a specific zone. See the Centrify Express Administrator s Guide for more information. Appendix A Using Centrify UNIX commands 233

234 Using adjoin Setting valid options You can use the following options with the adjoin command. Use this option -u, --user -p, --password userpassword To do this 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. Specify the account password. 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 execution. Administrator s Guide for Linux and UNIX 234

235 Using adjoin Use this option -c, --container containerdn To do this Specify the distinguished name (DN) of the container or Organizational Unit in which to place this computer account. You can specify the containerdn by: Canonical name (ajax.org/unix/services) You cannot specify a partial name for the canonical name. Fully distinguished name (cn=services, cn=unix,dc= ajax,dc=org) Relative distinguished name without the domain suffix (cn=services,cn=unix). For example, to place the computer in the UNIX/Services container within the ajax.org domain using the canonical name, you could specify: --container ajax.org/unix/services The DN you specify can refer to any container within the directory but does not need to 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, 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 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. Appendix A Using Centrify UNIX commands 235

236 Using adjoin Use this option -n, --name computername -N, --prewin2k accountname To do this 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. This option is most commonly used if you have a disjointed DNS namespace. For example, if the local UNIX host is a member of the DNS zone ajax.org, but is joining the Active Directory domain emea.ajax.org, you can use this option to join the domain with a computer name that is different from the name of the computer in DNS: -n finserv.emea.ajax.org This option can also be used in conjunction with the --alias option if the computer has multiple IP addresses and there are DNS records for those addresses, or with the --precreate option to specify the name of the computer to precreate. The maximum length for computer account names in Active Directory is 64 characters (the limit on AD common names); however, it is recommended that you limit names to 15 or fewer characters because this limit conforms to the maximum length allowed by the NetLogon service, which is the preferred service for adclient to use for NTLM pass-through authentication. NetLogon is fast and automatically returns a user's group membership. If you specify more than 15 characters adclient uses LDAP methods to fetch the user's group membership and create the computer account. Because LDAP methods are subject to the permissions on the AD container for the computer account, you may need administrative permissions to execute this command when specifying a computer name longer than 15 characters. Specify the pre-windows 2000 name for this computer in Active Directory. The pre-windows 2000 name is the name stored in the samaccountname attribute. The maximum length for the samaccountname attribute is 19 characters. Note Although the actual limit is 19 characters, it is recommended that you limit the name to 15 characters because some Windows functions use this attribute as a NetBIOS name, which has a 15-character limit. If the name is larger than 15 characters, less efficient NTLM authentication methods are used. If you do not specify this option, the default pre-windows 2000 name is the computer account name truncated at 15 characters. This option enables you to manually specify the pre-windows 2000 name you want to use. This option is most commonly used if the naming conventions for computer account names result in names that are longer than the 15 character limit. Administrator s Guide for Linux and UNIX 236

237 Using adjoin Use this option -f, --force -a, --alias computeralias -z, --zone zonename -C, --noconf -s, --server domaincontroller -Z, --zoneserver domaincontroller -D, --dnsname DNSHostName To do this 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. 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. Specify the name of the zone in which to place this computer account. You must specify this option or use the --workstation option to join to a domain through Auto Zone. Note If you are using Centrify Express, you cannot use this option. You must join a domain through Auto Zone by using the --workstation option. If individual zone names are not unique across the Active Directory forest, you can use the canonical name of the zone to uniquely identify the zone you want to join. For example, if you have more than one Finance zone, you can use the full canonical name of the zone to specify which Finance zone to join. If you specify a zone name and the named zone does not exist, the join operation fails. Note If users and groups are unique across the forest and not required to be segregated into zones, you can join the Active Directory domain by using the --workstation option to connect to Auto Zone instead of specifying a zone. The --workstation and --zone options are mutually exclusive and you must specify one or the other. 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. 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. Specify the name of the domain controller to use for zone operations. You can use this option, for example, if the zone is defined in a different domain than the one you are joining. Note You cannot use this option if you are using Centrify Express. Specify the host name of the DNS server that you prefer to use. You can use this option to override the automatic selection of a DNS server based on the information in the computer s configuration files. Appendix A Using Centrify UNIX commands 237

238 Using adjoin Use this option -g, --gc domaincontroller -U, --upn userprincipalname -T, --trust -k, --des -l, --ldap To do this Specify the name of the domain controller to use for global catalog operations. You can use this option if the default domain controller is not writable or does not support global catalog operations. Specify a user principal name (UPN) for the computer account in Active Directory. 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. Note Using this option requires running adjoin with an account with full administrator privileges. You can also set group policy to allow a nonadministrator user to set this option (Computer Configuration > Windows Settings > Security Settings > User Rights Assignment > Enable user and computer accounts to be trusted for delegation). See the following Microsoft tech notes for more information: Allow a computer to be trusted for delegation for specific services. Computer Management Tasks (see Specify that a computer be trusted for delegation ). When using this option, clear the local cache on the client before joining the domain. Set the computer account to use the Data Encryption Standard (DES) for keys. Use LDAP methods to fetch the user's group membership and create the computer account. Because LDAP methods are subject to the permissions on the AD container for the computer account, you may need administrative permissions to execute this command when specifying this option. Administrator s Guide for Linux and UNIX 238

239 Using adjoin Use this option -P, --precreate To do this Precreate a computer account in Active Directory without joining the domain. If you use this option, you must also specify --name to provide the name of the computer account to precreate, and specify either --zone to provide the name of the zone in which to precreate the account, or -- workstation to specify Auto Zone instead of a specific zone. The --precreate option does the following: Creates a computer object in Active Directory in the organizational unit you specify or the Computers container. Resets the computer account password to computer s host name (in lower case). Creates an Extension object in the zone. The following permissions are granted to the computer object: Read and Write to: operatingsystemservicepack, operatingsystem, and operatingversion attributes in Computer object. Reset the computer's password. Read useraccountcontrol attributes of the Computer object. Validate write to: serviceprincipalname and dnshostname attributes. By precreating the computer account and its serviceconnectionpoint, you can allow any user to join the computer to a domain without granting any special rights or performing any zone delegation. This option also enables you to create all the computer accounts you want in a batch job and automate how computers join the domain. -m, --compat Precreate a computer object that is compatible with agent version 2.x and later. You must specify this option if you want the precreated computer object to be compatible with agent version 2.x and later. Appendix A Using Centrify UNIX commands 239

240 Using adjoin Use this option -S, --selfserve -A, --attempt -V, --verbose -v, --version To do this Use the computer object s account credentials to join the domain. Note You cannot use this option if you are using Centrify Express. To use this option, you must have done one of the following: Precreated the computer account in Active Directory by using the Pre- Create Computer wizard or the adjoin --precreate option; see Preparing computer accounts on page 76. Previously joined the computer to a domain, then left using the adleave --reset option, which resets the computer account to a precreated, pre-joined state, such that you can rejoin the domain using the --selfserve option. If you use the --selfserve option, you don t need to specify a zone for the computer. The computer is automatically made a member of the zone where the precreated object was created. You must, however, specify the Active Directory domain to successfully add the computer to the domain. Note If you precreated the computer account with the --workstation (Auto Zone) option, you must specify the --workstation option when joining the domain with the --selfserve option. For example: adjoin acme.com --selfserve --worksation --name testcomputer Attempt to grant authenticated users read permissions to Password Settings objects (PSOs) so that the computer account can read finegrained password security policies in the current domain. Note that the administrator(s) may need to grant authenticated users read permissions to PSOs in trusted domains and forests as well for more accurate password expiration times for cross-domain and cross-forest users. Display 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. Display version information for the installed software. Administrator s Guide for Linux and UNIX 240

241 Using adjoin Use this option -w, --workstation -x, --extramap mapname -i, --noinit domain To do this Join the computer to an Active Directory domain by connecting to Auto Zone rather than by making the computer a member of any specific zone. When joined to Auto Zone, every Active Directory user and group defined in the forest and any users defined in a two-way trusted forest are valid UNIX users or groups. You can use this option when: Active Directory identities are unique for the forest and trusted external forest. Active Directory users and groups only require one set of properties for all computers and do not need to be segregated into zones for any reason. For the join to be successful, all of the domains in the forest and the trusted external forest must be unique. If domains are not unique across the forest trust, you must manually configure a unique prefix for each trusted domain using parameters in the centrifydc.conf configuration file. Note The --workstation and --zone options are mutually exclusive. Specify an NSS map to add to the configuration. You can specify this option multiple times to add multiple maps. For example: adjoin acme.com -z finance -x protocols Do not preload the cache. Specify the fully-qualified domain name you want the local computer to join. There is no default setting, so this argument is required. 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 --zone Finance 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 host name and Organizational Unit, you could type a command line similar to the following: adjoin --workstation --user [email protected] --name orlando --container ou=unix computers sales.acme.com You are then prompted to provide the password for the user [email protected]. If the password is correct and the local computer can successfully connect to Active Directory, a new computer account is added to Active Directory using the computer name orlando in the UNIX computers Organizational Unit. Appendix A Using Centrify UNIX commands 241

242 Using adjoin Note When specifying 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 [email protected] but your account is actually defined in the sf.mission.org domain, you must use that domain when specifying the user account. For example: adjoin --workstation --user [email protected] la.mission.org If zone names are not unique across the Active Directory forest, you can use the canonical name of the zone to uniquely identify the zone you want to join. For example, if you have more than one default zone, you could type a command line similar to the following: adjoin --user trey --zone ajax.test/unix/zones/default javadev.ajax.test Understanding the files modified by 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 Most platforms /etc/nsswitch.conf PAM configuration file Red Hat Linux /etc/pam.d/system-auth All other Linux HPUX, Solaris /etc/pam.d/* /etc/pam.conf LAM configuration file AIX /usr/lib/security/methods.cfg Login control files AIX /etc/security/user In addition, the following files are created in the /var/centrifydc directory by running adjoin or by starting the Centrify UNIX agent for the first time: Name daemon dc.cache gc.cache dcdn.idx extmgr.idx gcdn.idx gid.idx Purpose This is the pipe which clients open to communicate to the agent. Cache of objects from the Domain Controller Cache of objects from the Global Catalog Cache index Cache index Cache index Cache index Administrator s Guide for Linux and UNIX 242

243 Using adjoin Name gname.idx search.idx uid.idx uname.idx kset.domain kset.domaincontroller kset.host kset.schema kset.site kset.zone kset.zonename reg/*/*/* Purpose Cache index Cache index Cache index Cache index The domain name The domain controller host name The host name used to join The current schema version The preferred site The Zone GUID Readable zone name 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. Understanding join-specific result codes Most of the common result codes described in Understanding common result codes on page 231 apply to join operations. In addition to those common codes, however, the adjoin Appendix A Using Centrify UNIX commands 243

244 Using adjoin command can generate join-specific result codes when there are errors that prevent a computer from joining a domain. The following table lists these join-specific result codes. Result Error name Indicates 156 ERR_JOIN_ATTRMAP The mapping of computer account properties to Active Directory attributes failed. If you encounter this problem, you may need to map all attributes, then rerun the adjoin command. 157 ERR_JOIN_UPDATE The computer failed to join the domain. If you encounter this problem, you may need to take corrective action: Check whether the computer s hostname exceeds 15 characters. If the hostname exceeds 15 characters, shorten it or use the --name option to specify a name that is 15 characters or less, then rerun the adjoin command. Check whether the computer's primary DNS suffix matches the Active Directory domain DNS name or another allowed primary DNS suffix. If the DNS suffix does not match the Active Directory domain or is not an allowed primary DNS suffix, you may need to change the DNS or domain configuration, then rerun the adjoin command. 158 ERR_STRONGER_AUTH_NEEDED A stronger authentication method is required by Active Directory. If you encounter this problem, you should set the LDAP traffic encryption parameter, adclient.ldap.packet.encrypt, to Allowed or Required in the centrifydc.conf configuration file, then rerun the adjoin command. 159 ERR_UNEXPECTED_LDAP_REFERRAL There was an unexpected referral response. This is usually caused by an erroneous replication object in Active Directory. If you encounter this problem, you should check the zone container for replication errors, then rerun the adjoin command. 160 ERR_SPN_NOT_UNIQUE The serviceprincipalname (SPN) was not unique. Each SPN must be unique across the Active Directory forest. If you encounter this problem, you should use a serviceprincipalname that is unique across the forest, then rerun the adjoin command. You can search for duplicate service principal names using the Analyze wizard. 161 ERR_SERVERNAME_INVALID The domain server was specified using an IP address. If you encounter this problem, you should specify the domain controller name using a fully-qualified DNS name. 162 ERR_CHANGE_DIR The attempt to change to the data directory failed. Administrator s Guide for Linux and UNIX 244

245 Using adleave Result Error name Indicates 163 ERR_DOMAIN_NOT_TRUSTED The domain specified is not in the same forest or is not a trusted domain. If you encounter this problem, you should check the trust relationship for the domain or use a different domain, then rerun the adjoin command. 164 ERR_MULTIPLE_ZONES_FOUND Multiple zones were detected. If you encounter this problem, you should check the zones defined, then rerun the adjoin command and specify only one zone. add one for 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 preadjoin 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 adclient process. Note To run adleave you must be logged in as root. Appendix A Using Centrify UNIX commands 245

246 Using adleave Setting valid options You can use the following options with this command: Use this option -u, --user -p, --password userpassword -s, --server domaincontroller -Z, --zoneserver domaincontroller -C, --noconf To do this 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. 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. 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. Specify the name of the domain controller that you prefer to use to disconnect from the domain. You can use this option to override the automatic selection of a domain controller based on the Active Directory site information. Specify the name of the domain controller to use for zone operations. You can use this option, for example, if the zone is defined in a different domain than the domain you are leaving. Note You cannot use this option if you are using Centrify Express. 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. Administrator s Guide for Linux and UNIX 246

247 Using adleave Use this option -f, --force -G, --nogp -r, --remove -R, --restore -t, --reset -v, --version -V, --verbose To do this 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. Indicate that you do not want to revert any group policies applied to the computer to their original state. Note This option has no effect when using Centrify Express. Group policies are not supported by Centrify Express. Normally, if you leave a domain, any group policy changes that have been applied to UNIX configuration files are reverted to restore the files to their pre-join state. Remove the computer account from Active Directory. Restore system configuration files to their pre-join state without leaving the domain. Reset the computer account to its precreated, pre-joined state. This option resets the computer account password to the hostname (in lowercase) and disables the computer zone object. Specifying --reset allows you to leave a domain, then rejoin using the adjoin --selfserve option, which allows you to specify machine credentials when joining a domain. This option is valuable for virtual, cloudcomputing environments that require the ability to dynamically join and leave a domain. Display version information for the installed software. Display detailed information for each operation. 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: Appendix A Using Centrify UNIX commands 247

248 Using adcheck adleave --user --noconf You are then prompted for the password for the user 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 Understanding adleave-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adleave command can generate leave-specific result codes when there are errors that prevent a computer from leaving a domain. The following table lists these leavespecific result codes. Result Error name Indicates 156 ERR_STOP_NIS_ADCLIENT The adleave command was unable to stop the adnisd or adclient process. If you encounter this problem, you may need to manually stop the processes, then rerun the adleave command. 157 ERR_DELETE_CONTENT The adleave command was unable to delete all content. 158 ERR_LEAVE_FAILED The attempt to leave the domain failed. If you encounter this problem, you may need to rerun the adleave command with the --force option. 159 ERR_CONNECT_DC The adleave command was unable to connect to domain controller. If you encounter this problem, you may need to rerun the adleave command with the --force option. 160 ERR_SYNC_TIME Time is not synchronized between the local system clock and the domain controller. Using adcheck The adcheck command can be used to perform operating system, network, and Active Directory tests to verify that a computer is ready to join the specified Active Directory domain. The domain should be a fully-qualified domain name, for example, sales.acme.com. The output from adcheck includes, notes, warnings, and fatal errors, including suggestions on how to fix them. By default, adcheck performs the following tests: Operating system check to verify that the operating system is supported and at the correct patch levels, and that there is sufficient disk space. Network check to verify DNS and SSH. Administrator s Guide for Linux and UNIX 248

249 Using adcheck Active Directory check to verify various aspects of the Active Directory configuration, including the domain name, time and domain synchronization, and checking up to 10 domain controllers (which can be extended by an adcheck parameter for large domains). You must specify a domain unless you are running the operating system check only (-t os). Note The adcheck program is run automatically when you install the Centrify UNIX agent by running the install.sh program or the graphical-user-interface installer on a Mac OS X platform. The basic syntax for the adcheck program is: adcheck [domainname] [--alldc] [--siteonly] [--bigdomain number] [--checkspace] [--tmp_path] [--xml filename][--test os net ad] [--servername domaincontroller] [--user username][--password passwd] [-- xdomain] [--verbose] [--version] Setting valid options You can use the following options with this command: Use this option To do this -a, --alldc Check all domain controllers. This option overrides the --siteonly and --bigdomain options. The --servername option overrides this option. If you do not specify --alldc, --siteonly, or -- servername, adcheck checks the number of domain controllers specified by the --bigdomain option (default is 10). -b, --bigdomain number Specify the number of domain controllers to check. The default is 10. The --alldc --siteonly, and --servername options override this option. -c, --check-space var_size:usr_size:tmp_size -m, --tmp_path path -N, --skip-ntp Note: Use this option only if requested to do so by Centrify Support. By default, adcheck performs a check (SPACECHCK) to verify that the directories required by the agent, /var, /usr, and /tmp, have enough disk space. Specify the size, in megabytes (MB), for var_size, usr_size, and tmp_size. For example, enter the following command to verify that / var has at least 500MB, /usr has at least 100MB, and /tmp has at least 10MB: adcheck acme.com -c 500:100:10 Specify the directory in which to generate temporary output. Be certain that this directory has execute permission, otherwise adcheck will fail to run. By default, adcheck generates temporary output in /tmp for normal users and /var/centrify/tmp for root users. Use this option to skip the NTP port check, which adcheck uses to probe the NPT port (123) to determine whether the domain controller is available. If the domain controller has the SNTP service turned off (for example, the computer synchronizes on a different time source), adcheck reports the failure. Appendix A Using Centrify UNIX commands 249

250 Using adchzone Use this option -p, --password passwd -P, --performance -s, --servername domaincontroller -S, --siteonly -t, --test os net ad -T, --dnsmarg threshold -u, --user username -v, --version -V, --verbose -x, --xml filename -X, --xdomain To do this The password for the user who is executing the command. If this parameter is omitted, you are prompted for a password. Output a warning message if only one domain controller is found for a domain. The warning message appears in the ADDC section of the output. For optimal performance, more than one DC per domain is recommended. Specify the domain controller to connect to when performing the network checks. You can use this option to override the automatic selection of a domain controller based on the Active Directory site information. This option overrides the --alldc, --siteonly, and --bigdomain options. Check all domain controllers for the first detected site. This option overrides the --bigdomain option. The --alldc and -- servername options override this option. Run a subset of the tests, as follows: os Operating system check only; does not require that you specify a domain. net Network check only; requires that you specify a domain. ad Active Directory check, which also runs the network check; requires that you specify a domain. You can enter multiple -t options to specify multiple sub-tests, for example: adcheck ajax.com -t os -t net Specify the response-time threshold, in seconds, which determines whether the DNS server should be classified as marginal. If the DNS response time exceeds the threshold, adcheck issues a warning and lists the marginal DNS servers in the DNSCHECK section of the output. The default value is 0.1 seconds. Specify a user with rights to perform the Active Directory checks. If this option is not specified, the command uses cached Kerberos credentials for the current user, and if it cannot find credentials, it uses administrator. Display version information for the installed software. Display diagnostic information about the host, the domain, and the domain controller. Specify the filename in which to generate XML output. Check trusts in addition to the specified domain. Using adchzone The adchzone command allows you to move a joined computer from a classic zone to a hierarchical zone. Administrator s Guide for Linux and UNIX 250

251 Using adlicense Before moving the computer be certain to migrate the classic zone's data to a hierarchical zone by running the admigrate command. The basic syntax for the adchzone program is: adchzone [options] -z zonename -u username [-p password] Setting valid options You can use the following options with this command: Use this option To do this -z zonename Specify the distinguished name of the hierarchical zone to join. This parameter is required. -u username Specify the Active Directory User Principal Name or Samaccountname of a user account with permission to delete the computer account in the classic zone and add a profile for the computer in the new zone. If you omit this parameter, adchzone uses Kerberos credentials for the current user. This parameter is required. -p password Specify the password for the user account. You will be prompted if you omit this parameter. -v Print verbose information while the command runs. Examples of using adchzone The following command moves the joined computer on which the command is run to the hierarchical zone finance, which is a child zone of the parent zone global. /usr/share/centrifydc/adedit/adchzone \\ -z "cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com" \\ -u administrator -p passwd Using adlicense The adlicense command can be used to enable or disable licensed features on a local computer. If you execute adlicense with no options, it displays the current licensing mode, either licensed or express. In licensed mode, a computer has access to group policies and may join any existing zones. If you execute adinfo on a computer in licensed mode, the following information is displayed in the output: Licensed Features: Enabled In express mode, a computer may not download or execute group policies, cannot join a zone, and is automatically joined to Auto Zone. Also, the number of Centrify managed Appendix A Using Centrify UNIX commands 251

252 Using adpasswd computers that can be in the AD domain at the same time is limited. If you execute adinfo on a computer in express mode, the following information is displayed in the output: Licensed Features: Disabled To run adlicense you must be logged in as root. The basic syntax for the adlicense program is: adlicense [--licensed] [--express] [--verbose] [--version] Setting valid options You can use the following options with this command: Use this option -l, --licensed -e, --express -V, --verbose -v, --version To do this Enable licensed features, including the ability to use group policies and join a specific zone. After you enable licensed features, the computer is still joined to Auto Zone. You may keep the computer joined to Auto Zone or join a specific zone, in which case, you must first leave the zone with adleave, then rejoin the domain with the adjoin --zone command. To enable licensing, you must have installed a valid license key. Enabling licensing consumes a license. Disable licensed features. This option unmaps group policies and prevents the computer from joining any specific zones. The computer is automatically joined to Auto Zone. If you are running in licensed mode, and execute adlicense -- express to switch to Express mode, a license is restored. Note You cannot use this option if the computer is currently joined to a zone. You must first leave the domain, then connect to Auto Zone when rejoining the domain. Display detailed information about the operation performed. Display version information for the installed software. 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 Administrator s Guide for Linux and UNIX 252

253 Using adpasswd 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. 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. Setting valid options You can use the following options with this command: Use this option -a, --adminuser adminuser[@domain] -p, --adminpass adminpassword -V, --validate To do this Identify an Active Directory user account 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. Specify the password for the Active Directory administrative account when changing another user s Active Directory password. If you do not provide the password at the command line, you are prompted to enter the password before the command executes. However, if adpasswd detects Kerberos credentials, it uses those for the command, and if these credentials are not sufficient, you receive an error message rather than a prompt for a password. 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. Check the validity of a user s password. This option is used to verify whether a specified user can log on with the specified password. Appendix A Using Centrify UNIX commands 253

254 Using adpasswd Use this option -o, --oldpass oldpassword -n, --newpass newpassword -v, --version To do this 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 password at the command line, you are prompted to enter the old password before the command executes. 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. 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. Display version information for the installed software. 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. 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, [email protected], 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 Administrator s Guide for Linux and UNIX 254

255 Using adupdate specifies an Active Directory administrative account, with the authority to change the password for Jane s account: adpasswd --adminuser [email protected] [email protected] 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 [email protected]: xxx Repeat password: xxx To check whether a user can log on with a specific password, you can use the --validate option. For example: adpasswd --validate [email protected] Password: xxx If the user name and password are valid and can be authenticated by Active Directory, a successful validation message is displayed. If the user name and password specified cannot be authenticated, the command displays a message indicating the authentication failure: Password validate failed for user pablo Account cannot be accessed at this time Please contact your system administrator Understanding adpasswd-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adpasswd command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_PASSWDFILE_MISS The password could not be updated because the passwd file could not be found. 157 ERR_PASSWDFILE_BUSY The password could not be updated because the passwd file was being used by another program. Using adupdate The adupdate command enables administrators to perform user and group account management tasks from the command line on any Centrify-managed system. These user and group management tasks you can perform include the following: Adding a new user to a zone Modifying a user s UNIX profile Disabling and enabling a user s access to a zone Deleting users from a zone Adding an Active Directory group to a zone Modifying a group s UNIX profile Appendix A Using Centrify UNIX commands 255

256 Using adupdate Managing the group s membership Deleting an existing Active Directory group from a zone Synchronizing the time on the local computer with its domain controller Each of these tasks can include command line options that enable the task to be accomplished using a script. The basic syntax for the adupdate program is as follows: adupdate add delete modify user group [options] Note You must specify the administrative task to perform, then whether the task applies to a user or group before you specify any other command line options. In addition, the options required to complete an administrative task depend on which task you are performing. For more information about the syntax and the options you need to use for each task, see the appropriate section for the administrative task you are performing. Adding a UNIX user profile You can use adupdate add user to add a specified user to the zone associated with the computer where the command is run. You can also use this command to create a new user account in Active Directory, if desired. The basic syntax for adding a new user with the adupdate program is: adupdate add user -U user[@domain] [options] UNIXlogin You must specify the Active Directory user that the new UNIX user profile should be associated with. In specifying the Active Directory user, you must use the user@domain format if the user is a member of a domain other than the host computer s domain. Administrator s Guide for Linux and UNIX 256

257 Using adupdate Setting options for a new user profile You can use the following options with the adupdate add user command: Use this option -a, --admin user[@domain] -p, --password password -U, --user loginname -C, --create To do this Identify an Active Directory user account with sufficient rights to add a new user profile or new user account to Active Directory in the current domain. You must use the user@domain format to specify the user account if the administrative user is not a member of the host computer s current domain. If you do not specify this option, the current Kerberos credentials are used. If there are no Kerberos credentials available, the default value is the Administrator user account. Specify the password for the Active Directory user account with administrative rights. If you are using the current Kerberos credentials, you don t need to specify the password at the command line. If you are not using the current Kerberos credentials and do not specify 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. You can pipe the password into standard input for scripting purposes. Specify the Active Directory user that the new UNIX user profile should be associated with. This option is required. You can use the user s Windows login name, for example, the samaccountname attribute or the user s userprinicpalname attribute to identify the Active Directory account. The name you specify can also include spaces if properly quoted according to the rules of the UNIX shell you are using. For example, if you want to specify a first name and last name: --user 'Kay Li' You should use the user@domain format to specify the login name if the user is not a member of the host computer s currently joined domain. If you are also using the --create option to create a new Active Directory user and do not specify the --first name option in the command line, the name you specify for the --user loginname is also used for the displayname and CN attributes in Active Directory. Create a new Active Directory user. If you don t specify this option, the user account you specify for the --user option must already exist in Active Directory. Appendix A Using Centrify UNIX commands 257

258 Using adupdate Use this option -d, --home home_directory -g, --group initial_group -G, --groups groupname,[...] -i, --foreign-sid sid_value -u, --uid uid_value -o, --allow-duplicate -s, --shell shell_path To do this Specify the UNIX home directory for the new user. The default home directory path is set by appending the user s login name to default_home. For example, if the user s login name is kay: /default_home/kay Note You cannot specify this option when connected to Auto Zone. Specify the group name or numeric identifier of the user s primary group. Note You cannot specify this option when connected to Auto Zone. If you specify a group name, the group name must exist in Active Directory. If you specify a numeric group identifier (GID), the group identifier should refer to a group with an existing UNIX profile defined for the zone. By default, a user s primary group is the value specified as the default group GID for the zone, if one is defined, or the next available UID and GID if you are using user-specific primary groups. List additional groups the user is a member of. Use commas to separate group names. For example: --groups qa02,sap,javax You can specify the groups by UNIX group name or samaccountname attribute. The groups you specify do not need to have a UNIX profile already defined for the zone. There is no default group list. By default, only a user s initial group is defined. Specify the Active Directory security identifier (SID) for a UNIX user to add from a one-way trusted forest. You can retrieve the SID of the user with the adquery user -i command. Specify the numeric value of the user identifier (UID) for the UNIX user account. Note You cannot specify this option when connected to Auto Zone. This value must be a positive integer and must be unique in the zone unless you specify the -o option to allow duplicate values. If you do not specify the --uid option, the next available UID in the zone is used by default. You should not specify UID values between 0 and 99. Values between 0 and 99 are typically reserved for system accounts. Allow the UID value for the new user to be the same as the UID used in another user profile. Note You cannot specify this option when connected to Auto Zone. Specify the user s login shell. If you don t specify this option, the system selects the default login shell for the operating environment when the user logs on. Note You cannot specify this option when connected to Auto Zone. Administrator s Guide for Linux and UNIX 258

259 Using adupdate Use this option -m, --make-home [-k, --skeleton skeleton_directory] -f, --first name -l, --last name -w, --new-password password -W, --show-password To do this Create the user s home directory automatically if it does not already exist. Note You cannot specify this option when connected to Auto Zone. If you specify this option and the --skeleton option, the files and directories contained in skeleton_directory are copied to the new home directory. If you don t specify the --skeleton option, the files contained in the directory specified by the pam.homeskel.dir configuration parameter are copied to the new home directory instead. The --skeleton option is only valid in conjunction with the -- make-home option. If you don t specify this option, the adupdate command does not create the user s home directory or copy any files. Specify the first name of the Active Directory user. The name you specify is mapped to the givenname LDAP attribute and is used as the first component for the displayname and cn attributes. If you don t specify this option, the givenname attribute is left blank and the samaccountname is used for the displayname and cn attributes. This option is ignored if you are not using the -- create option to create an Active Directory account. Specify the last name of the Active Directory user. The name you specify is mapped to the sn LDAP attribute and is used as the second component for the displayname and cn attributes if the --first name option is specified. This option is ignored if you are not using the --create option to create an Active Directory account. Specify the initial password for the new user account. If you not specify a password for the user, you are prompted to enter and reenter the password before the command executes. Whether you specify the user's password at the command line or when prompted, the password must adhere to the domain s password policy requirements for length and complexity. Generate and display an initial password for the new user account. This option enables the account to be created with a random password, which can then be reset later when the user logs on. Appendix A Using Centrify UNIX commands 259

260 Using adupdate Use this option -c, --container containerdn -S, --spn serviceprincipalname -P, --principal userprincipalname -V, --verbose -v, --version UNIXlogin To do this Specify the distinguished name (DN) of the container or Organizational Unit (OU) in which to place this user account. The DN represents the direct parent object for the user. You can specify the containerdn by: Canonical name (ajax.org/unix/services) Fully distinguished name (cn=services, cn=unix,dc= ajax,dc=org) Relative distinguished name without the domain suffix(cn=services,cn=unix). For example, to place the account in the UNIX/Services container within the ajax.org domain using the canonical name, you could specify: --container ajax.org/unix/services The DN you specify can refer to any container within the directory but does not need to 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, to place this user in the paris.regional.sales.acme.com organizational unit within the acme.com domain, you would specify: ou=paris, ou=regional, ou=sales Note You must specify a container for the new user object when creating a new user account with the adupdate command. You can use the domain s default Users container object, for example, ajax.org/users, or any other existing parent container object. If the container you specify does not exist in Active Directory, however, the user account will not be created. In addition, you must have permission to add entries to the specified container. Specify the serviceprincipalname to use as the service principal name for this user account. Specifying a service principal name is particularly useful for if you intend to use prevalidated authentication. To specify the serviceprincipalname, you should use the format: service/samaccountname For example, to add a service principal for the prevalidation service, preval, for the user account kai: --spn preval/kai kai Specify a user principal name (UPN) for the user account in Active Directory. You may only specify this option when creating new AD users. Display detailed information about each operation as it is performed. Display version information for the installed software. Specify the UNIX login name for the user in the current zone. Administrator s Guide for Linux and UNIX 260

261 Using adupdate Examples of using adupdate add user To add a new UNIX profile for Active Directory user Wilson Perez if you are logged on with a user account with permission to add new users to the domain, you could type a command line similar to the following: adupdate add user -U wilson [email protected] wilson You are then prompted for the password for the new account and to retype the password for the new account. To add a new user account when your current user account does not have permission to add new users to the domain, you must provide the user name and password for an account with permission to add new users to the domain. For example, if the user [email protected] is an administrator with permission to add users to the atlas.acme.com domain, you could type a command line similar to the following: adupdate add user --uid admin [email protected] --create --user [email protected] --first Chris --last Roberts chris You are then prompted for the password for the [email protected] account. If the user name and password for the administrator s account are valid, you are then prompted for the password for the new account and to retype the password for the new account. Modifying a user profile You can use adupdate modify user to modify login information for a user account with a UNIX profile defined for the current zone. You cannot modify an Active Directory account that does not have a UNIX profile defined for a zone. The basic syntax for the adupdate modify user program is: adupdate modify user [options] UNIXlogin Appendix A Using Centrify UNIX commands 261

262 Using adupdate Setting options for modifying a user profile You can use the following options with the adupdate modify user command: Use this option -a, --admin user[@domain] -p, --password password -l, --login newunixlogin -d, --home home_directory -m, --move-home To do this Identify an Active Directory user account with sufficient rights to modify user profiles in the current domain. You must use the user@domain format to specify the user account if the administrative user is not a member of the host computer s current domain. If you do not specify this option, the current Kerberos credentials are used. If there are no Kerberos credentials available, the default value is the Administrator user account. Specify the password for the Active Directory user account with administrative rights. If you are using the current Kerberos credentials, you don t need to specify the password at the command line. If you are not using the current Kerberos credentials and do not specify 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. You can pipe the password into standard input for scripting purposes. Change the UNIX login name for the specified user. For example, to change the login name for the UNIX user james from jim to james: adupdate modify user --login james jim Note You cannot specify this option when connected to Auto Zone. This option does not make any other changes. If you use this option, you should also use other options to create a new home directory name that reflects the new login name or move the contents of the user s old home directory to a new home directory name. Create a new UNIX home directory for the specified user. Note You cannot specify this option when connected to Auto Zone. You can use this option in conjunction with the --move-home option to move the contents of a user s current home directory to a new home directory. The new home directory is created automatically if it does not already exist. Move the contents from a user s old home directory to a new home directory. Note You cannot specify this option when connected to Auto Zone. Administrator s Guide for Linux and UNIX 262

263 Using adupdate Use this option -g, --group initial_group -G, --groups groupname,[...] -i, --foreign-sid sid_value -u, --uid uid_value -o, --allow-duplicate -s, --shell shell_path To do this Modify the group name or numeric identifier of the user s primary group. Note You cannot specify this option when connected to Auto Zone. If you specify a group name, the group name must exist in Active Directory. If you specify a numeric group identifier (GID), the group identifier must refer to an existing group with a UNIX profile defined for the zone. By default, a user s primary group is the value specified as the default group GID for the zone, if one is defined, or the next available UID and GID if you are using user-specific primary groups. Modify the additional groups the user is a member of. Use commas to separate group names. For example: --groups qa02,sap,javax You can specify the groups by UNIX group name or samaccountname attribute. The groups you specify do not need to have a UNIX profile already defined for the zone. There is no default group list. By default, only a user s initial group is defined. Specify the Active Directory security identifier (SID) for a UNIX user to modify from a one-way trusted forest. You can retrieve the SID of the user with the adquery user - i command. Modify the numeric value of the user identifier (UID) for the UNIX user account. Note You cannot specify this option when connected to Auto Zone. This value must be a positive integer and must be unique in the zone unless you specify the -allow-duplicate option to allow duplicate values. If you do not specify the --uid option, the next available UID in the zone is used by default. You should not specify UID values between 0 and 99. Values between 0 and 99 are typically reserved for system accounts. Allow the UID value for the user to be the same as the UID used in another user profile. Note You cannot specify this option when connected to Auto Zone. Change the user s login shell. Note You cannot specify this option when connected to Auto Zone. If you don t specify this option, the system selects the default login shell for the operating environment when the user logs on. Appendix A Using Centrify UNIX commands 263

264 Using adupdate Use this option -L, --lock on off -f, --forcepw on off -k, --des on off -S, --spn serviceprincipalname -P, --principal userprincipalname -x, --remove-spn serviceprincipalname -z, --enable on off -U, --unlock To do this Enable or disable a user s account in Active Directory. Change whether the specified user should be forced to enter a password at the next logon. Change the Use DES encryption types for this account setting in Active Directory for the specified user. Specify the serviceprincipalname to add for this user account. Specifying a service principal name is particularly useful for if you intend to use prevalidated authentication. To specify the serviceprincipalname, use the format: service/samaccountname For example, to add a service principal for the prevalidation service, preval, for the user account kai: --spn preval/kai kai Specify a user principal name (UPN) for the user account in Active Directory. Specify the serviceprincipalname to remove for this user account. For example, to remove the service principal for the prevalidation service, preval, for the user account kai: --remove-spn preval/kai kai Enable or disable access to the current zone for the specified user. Note You cannot specify this option when connected to Auto Zone. Unlock a user account that has been locked because of failed password attempts. Administrator s Guide for Linux and UNIX 264

265 Using adupdate Use this option -X, --extattr [+ -]name=value -V, --verbose -v, --version UNIXlogin To do this Add, delete, or modify the value of an extended attribute for the user. Note You cannot specify this option when connected to Auto Zone. Typing a plus sign (+) before the attribute name adds the extended attribute if it doesn't exist. Typing a minus sign (-) before the attribute name removes the attribute, if it exists. For example, to set the value of the extended attribute aix.rlogin: adupdate modify user -X +aix.rlogin=true jae Note Extended attributes are only applicable on AIX computers. You can use adquery and the keyword help to view a list of the supported extended attributes. For example: adquery user --extattr help Note Certain extended attributes, such as the system privileges, or capabilities attributes, are only supported by agents with methods in the Loadable Authentication Module (LAM) version 5.2 or later. To be able to query and use these extended attributes, you must be running AIX 5.2 or later, and set the value of the lam.method.version parameter in the centrifydc.conf configuration file to version 5.2 (520). See the Configuration and Tuning Guide for details about this parameter. Display detailed information about each operation as it is performed. Display version information for the installed software. Specify the UNIX login name for the user in the current zone. The user must exist and be enabled for UNIX access in the same zone as the computer. Examples of using adupdate modify user To change the UID for a UNIX user profile if you are logged on with an account with permission to modify user information in the domain, you could type a command line similar to the following: adupdate modify user --uid 700 jcole To change the UNIX user name and home directory for the UNIX user jim to kuoj if you are logged on with an account with permission to modify user information in the domain, you could type a command line similar to the following: adupdate modify user --login kuoj --home /home/kuoj --move-home jim To force the user kuoj to change his password the next time he logs on, you could type a command line similar to the following: adupdate modify user --forcepw on kuoj Note You may need to refresh the console you are using to verify changes were made. Appendix A Using Centrify UNIX commands 265

266 Using adupdate Deleting a user profile You can use adupdate delete user to remove an existing user profile from the current zone or to delete an Active Directory user. The basic syntax for the adupdate delete user program is: adupdate delete user [options] user[@domain] Setting options for deleting a user profile You can use the following options with the adupdate delete user command: User this option -a, --admin user[@domain] -p, --password password -R, --rmhome -r, --remove -i, --interactive -V, --verbose To do this Identify an Active Directory user account with sufficient rights to remove an Active Directory user account from the domain. You must use the user@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 current Kerberos credentials are used. If there are no Kerberos credentials available or user account specified, the Administrator user account is used to connect to Active Directory. Specify the password for the Active Directory administrative 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. Remove the user s home directory on the Centrifymanaged system. Remove the associated Active Directory user account from Active Directory without interactive confirmation. Confirm the deletion of the UNIX profile or Active Directory user account interactively before removing the user. Display detailed information about each operation as it is performed. Administrator s Guide for Linux and UNIX 266

267 Using adupdate User this option -v, --version To do this Display version information for the installed software. Specify the UNIX user profile name or Active Directory user login name for the user in the current zone. The user must exist and be enabled for UNIX access in the same zone as the computer. If the user name you specify does not uniquely identify the user, you must include the domain name in the command line. For example: Examples of using adupdate delete user To remove the UNIX user profile from the current zone if you are logged in with a user account with permission to delete user information from the domain, you could type a command similar to the following: adupdate delete user -V sunni To remove a UNIX profile account if your current user account does not have permission to delete users from the domain, you must provide the user name and password for an account with permission to delete users from the domain. For example, if the user [email protected] is an administrator with permission to remove user profiles from the domain, you could type a command similar to the following: adupdate delete user --admin [email protected] -V sunni You are then prompted for the Active Directory password for the [email protected] account. If the user name and password for the administrator s account are valid, the user profile is removed from Active Directory. If you also want to remove the Active Directory user account, you could type a command similar to the following: adupdate delete user --admin [email protected] --verbose --remove --interactive sunni After you provide the Active Directory password for the [email protected] account, this command connects to Active Directory and prompts you to confirm whether you want to delete the account: Delete Centrify Corporation user CN=Sunni Ashton,CN=Users,DC=ajax,DC=org? (Yes/No) You can then type y to confirm that you want to delete the user. Note You may need to refresh the console you are using to verify changes were made. Adding a new group You can use adupdate add group to add a new group profile to the current zone. The basic syntax for the adupdate add group program is: adupdate add group [options] groupname Appendix A Using Centrify UNIX commands 267

268 Using adupdate Setting options for adding a group You can use the following options with the adupdate add group command: User this option -a, --admin user[@domain] -p, --password password -C, --create -G, --group name canonical_name -g, --gid -o, --allow-duplicate -R, --required To do this Identify an Active Directory user account with sufficient rights to add a new Active Directory group to the domain. You must use the user@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 current Kerberos credentials are used. If there are no Kerberos credentials available or user account specified, the Administrator user account is used to connect to Active Directory. Specify the password for the Active Directory administrative 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 in 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. Create a new UNIX group profile and Active Directory group. Specify the group name to be associated with the new UNIX group in canonical form or by its samaccountname attribute in Active Directory. This option is required and is used for the samaccountname, displayname, and LDAP common name (cn) attributes in Active Directory. Specify the numeric value of the group identifier (GID) for the new group profile. Allow the GID value for the new group to be the same as the GID used in another group profile. Make the new group a required group for all of the users who are members of the group. Required groups cannot be removed when users change their active set of groups using the adsetgroups command. Administrator s Guide for Linux and UNIX 268

269 Using adupdate User this option -c, --container containername -t, --type local global universal -V, --verbose -v, --version groupname To do this Specify the relative distinguished name (RDN) of the container or Organizational Unit in which you want to place this group account. The RDN represents the direct parent object for the group. Note You must specify a container for the new group object when creating a new group with the adupdate command. You can use the domain s default Users container object, for example, ajax.org/users, or any other existing parent container object. If the container you specify does not exist in Active Directory, however, the group account will not be created. In addition, you must have permission to add entries to the specified container. Specify the type of Active Directory security group to create. The valid group types are domain local, global across domains, or universal. If you don t specify the group type, the group is added as a global group by default. Display detailed information about each operation as it is performed. Display version information for the installed software. Specify the UNIX name for the group. Examples of using adupdate add group To add the group profile qa002 to the Active Directory QA group if you are logged in with a user account with permission to add groups to the domain, you could type a command line similar to the following: adupdate add group -g G ajax.org/users/qa qa002 To create a new Active Directory group with a UNIX profile if you are logged in with a user account with permission to add groups to the domain, you could type a command line similar to the following: adupdate add group --create --container Users --gid group ajax.org/ Users/QA --type universal qa002 Modifying an existing group You can use adupdate modify group to modify the UNIX group profile name, numeric identifier, or membership. Note You can only use this command with security groups, not distribution groups. In addition, the group must have a UNIX profile in a zone; you cannot modify an Active Directory group that does not have a UNIX profile defined for a zone. The basic syntax for the adupdate modify group program is: Appendix A Using Centrify UNIX commands 269

270 Using adupdate adupdate modify group [options] groupname Setting options for modifying a group You can use the following options with the adupdate modify group command: User this option -a, --admin user[@domain] -p, --password password -g, --gid -o, --allow-duplicate -n, --name groupname -m, --member user group -r, --remove user group To do this Identify an Active Directory user account with sufficient rights to modify an Active Directory group. You must use the user@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 current Kerberos credentials are used. If there are no Kerberos credentials available or user account specified, the Administrator user account is used to connect to Active Directory. Specify the password for the Active Directory administrative 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 in 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. Modify the numeric group identifier (GID) for the specified group profile. Allow the GID value for the group to be the same as the GID used in another group profile. Modify the UNIX group name for the specified group. Add a new user or group as a member of the specified group. You may specify multiple -m options on a single command line. You can specify either a UNIX name or samaccountname for the user or group to add. If Direct Control cannot resolve the user name because it conflicts between Active Directory and the Centrify zone, it returns an error message. The user or group to add must have a UNIX profile in a zone; you cannot add an Active Directory user or group that does not have a UNIX profile defined for a zone. In addition, a group to add must be a security group, not a distribution group. Remove a user or group as a member of the specified group. Administrator s Guide for Linux and UNIX 270

271 Using adupdate User this option -R, --required -V, --verbose -v, --version groupname To do this Make the specified group a required group for all of the users who are members of the group. Required groups cannot be removed when users change their active set of groups using the adsetgroups command. Display detailed information about each operation as it is performed. Display version information for the installed software. Specify the UNIX name for the group. The group must exist and be enabled for UNIX access in the same zone as the computer. Examples of using adupdate modify group To change the GID for a UNIX group profile if you are logged on with an account with permission to modify group information in the domain, you could type a command similar to the following: adupdate modify group --gid 700 javax To add a new user to the UNIX group javax if you are logged on with an account with permission to modify group information in the domain, you could type a command similar to the following: adupdate modify group --member jcole -V javax To add a group or user as a new member of a UNIX group, the group or user must be enabled for UNIX access in the host computer s zone. In addition, you can only specify one new user or group member each time you run this command. To remove a group or user from the list of members for a group, you could type a command similar to the following: adupdate modify group --remove luis -V javax Deleting a group You can use adupdate delete group to remove an existing group profile from the current zone or delete an Active Directory group. The basic syntax for the adupdate delete group program is: adupdate delete group [options] groupname Appendix A Using Centrify UNIX commands 271

272 Using adupdate Setting options for deleting a group You can use the following options with this command: User this option -a, --admin user[@domain] -p, --password password -i, --interactive -r, --remove -V, --verbose -v, --version groupname To do this Identify an Active Directory user account with sufficient rights to remove an Active Directory user account from the domain. You must use the user@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 current Kerberos credentials are used. If there are no Kerberos credentials available or user account specified, the Administrator user account is used to connect to Active Directory. Specify the password for the Active Directory administrative 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. Confirm the deletion of the group profile interactively before removing the group. Remove the Active Directory group associated with the group profile. Display detailed information about each operation as it is performed. Display version information for the installed software. Specify the UNIX name for the group. The group must exist and be enabled for UNIX access in the same zone as the computer. Examples of using adupdate delete group To remove the UNIX group profile from the current zone when you are logged in with an account with permission to delete groups from the domain, you could type a command line similar to the following: adupdate delete group performx If you also want to remove the Active Directory group associated with the UNIX group, you could type a command similar to the following: adupdate delete group --admin paolo --verbose --remove --interactive unixdev Administrator s Guide for Linux and UNIX 272

273 Using adupdate After you provide the Active Directory password for the paolo account, this command connects to Active Directory and prompts you to confirm whether you want to delete the group. For example: Delete Centrify Corporation group CN=Unix developers,cn=users,dc=ajax,dc=org? (Yes/No) You can then type y to confirm that you want to delete the group. Note You may need to refresh the console you are using to verify changes were made. Updating the system clock You can also use the adupdate command to synchronize the system clock on the local computer with its domain controller. The syntax for synchronizing the time on the local computer with its domain controller is: adupdate time Understanding adupdate-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adupdate command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_READ_CDC_SETTING An agent setting could not be read. 157 ERR_NOT_SUPPORT_ZONE The type of zone you are attempting to update is obsolete and no longer supported. 158 ERR_USER_IN_ZONE The user profile you are attempting to add already exists in the zone. 159 ERR_USER_IN_AD The user you are attempting to add already exists in Active Directory. 160 ERR_DUP_UID The user s UID already exists in the zone. 161 ERR_NOT_FIND_CENTRIFY_GROUP_OBJ The group profile could not be found. 162 ERR_NOT_SPECIFY_INIT_GROUP A default group has not been defined for the zone. If a default primary group does not exist for a zone, you must specify the GID of the user s primary group. 163 ERR_NOT_SPECIFY_CONTAINER You must specify a container for the Active Directory object you are adding. 164 ERR_CANNOT_ADD_CENTRIFY_USER The Centrify user profile cannot be added, for example, because the user name or UID already exist in the zone. 165 ERR_CANNOT_CREATE_HOME_DIR The home directory could not be created. 166 ERR_SKIP_CREATE_HOME_DIR The automatic creation of the user s home directory will be skipped. Appendix A Using Centrify UNIX commands 273

274 Using adquery Result Error name Indicates 167 ERR_ADD_USER_FAILED The attempt to add a user failed. 168 ERR_TIME_SYNC_FAILED The attempt to synchronize system clocks failed. 169 ERR_CANNOT_UPDATE_USER The user account cannot be updated in Active Directory. For example, you may see this error if the user account running the command does not have sufficient permissions to modify the user account. 170 ERR_MOD_USER_FAILED The attempt to modify the user profile failed. 171 ERR_DEL_USER_FAILED The attempt to delete the user profile failed. 172 ERR_CANNOT_DELETE_USER The user account cannot be deleted in Active Directory. For example, you may see this error if the user account running the command does not have sufficient permissions to delete the user. 173 ERR_GROUP_IN_ZONE The group profile you are attempting to add already exists in the zone. 174 ERR_GROUP_IN_AD The group you are attempting to add already exists in Active Directory. 175 ERR_NOT_FIND_AD_GROUP_OBJ The Active Directory group could not be found. 176 ERR_DUP_GID The group s GID already exists in the zone. 177 ERR_CANNOT_ADD_CENTRIFY_GROUP The Centrify group profile cannot be added, for example, because the group name or GID already exist in the zone. 178 ERR_ADD_GROUP_FAILED The attempt to add a group failed. 179 ERR_CANNOT_UPDATE_GROUP The group account cannot be updated in Active Directory. For example, you may see this error if the user account running the command does not have sufficient permissions to modify the group. 180 ERR_MOD_GROUP_FAILED The attempt to modify the group failed. 181 ERR_CANNOT_DELETE_GROUP The group cannot be deleted in Active Directory. For example, you may see this error if the user account running the command does not have sufficient permissions to delete the group. 182 ERR_DEL_GROUP_FAILED The attempt to delete the group failed. Using adquery The adquery command enables you to query Active Directory for information about users and groups from the command line on a Centrify-managed system. The options you can use Administrator s Guide for Linux and UNIX 274

275 Using adquery depend on whether you are looking up user information or group information. You can look up information for a specific user or group or for all of the users or groups in a zone. The basic syntax for the adquery program is as follows: adquery user group [options] [username groupname] You can specify a single option in the command line to have the information returned as one value per line suitable for use in scripts. If you specify multiple options in the command line, the information returned is formatted in a list with field labels identifying each value. Querying user information You can use adquery user command to look up one or more details about one or more specified users in Active Directory. If you don t specify any users in the command line, the command lists all of the users in the zone. The basic syntax for querying user information is: adquery user [options] [username] You can specify the username in any supported format. If the user name includes any blank spaces, the name should be enclosed by quotation marks. For example, if you want to specify an Active Directory account name consisting of a first name and a last name, you can type a command similar to the following: adquery user --samname --enabled "Jae Park" All options, including --all, return formatted attributes and values, with the exception of --dump, which returns raw attributes and values, and --attribute, which allows you to specify individual raw attributes. Raw attributes are the form in which attributes are stored internally in Active Directory or in a Centrify zone, that is, without regard to readability. For example, the raw attribute for the account expiration date is a numeric string: #adquery user -j grep -i expires accountexpires: whereas, the formatted attribute shows a date field: #adquery user - x Sat Jan 8 00:00: Appendix A Using Centrify UNIX commands 275

276 Using adquery Setting valid options for user information You can use the following options with the adquery user command: Use this option -b, --attribute attributename To do this Display the value of the specified Active Directory or Centrify raw attribute. Use the -j (--dump) option to see a list of raw attributes. The -A (--all) option returns formatted attributes and values. Note Attribute names are case-sensitive. Internal Centrify attributes begin with an underscore character. You can specify multiple --attribute (-b) options, in which case, the name of the attribute is returned along with the value. For example: #-b cn rajai davis #-b cn -b samaccountname cn:rajai davis samaccountname:rdavis -h, --home -g, --group -G, --groups -a, --adgroups -s, --shell -u, --uid -p, --display -o, --gecos -n, --unixname -M, --samname -i, --sid -P, --principal -S, --service Display the specified user s home directory or the home directory for all users in the zone. Display the specified user s primary group identifier (GID) or the primary group identifier (GID) for all users in the zone. List the UNIX-enabled groups the user is a member of. List all of the Active Directory groups the user is a member of. Active Directory groups are listed by canonical name. Display the user s default shell. Display the user identifier (UID) for the specified user or for all users in the zone. Display the displayname attribute for the user or for all users in the zone. Display the contents of the GECOS field for the user or for all users in the zone. Display the UNIX login name for the specified user or for all users in the zone. Display the Active Directory logon name for the specified user or for all users in the zone. Display the Active Directory security identifier (SID) for the specified user or for all users in the zone. Display the Kerberos user principal name (UPN) for the specified user or for all users in the zone. Display the Kerberos service principal name (SPN) for the specified user or for all users in the zone. Administrator s Guide for Linux and UNIX 276

277 Using adquery Use this option -C, --canonical -H, --hash -x, --acct-expire -w, --pwd-expire -c, --pwd-nextchange -l, --pwd-lastchange -k, --locked -d, --disabled -e, --enabled -D, --dn To do this Display the Active Directory canonical name for the specified user or for all users in the zone. Display the UNIX password hash for the specified user if you are using password synchronization between Active Directory and computers managed by the Centrify agent You must be logged on as the root user or querying Active Directory for your own account information to retrieve the password hash. Display the date the user account expires. You must be logged on as the root user or querying Active Directory for your own account information to retrieve this information. Display the date the current password for the user account expires. You must be logged on as the root user or querying Active Directory for your own account information to retrieve this information. Display the date after which the user may change their password. You must be either logged on as the root user or be querying Active Directory for your own account information to retrieve this information. Display the date of the last password change for the user. You must be logged on as the root user or querying Active Directory for your own account information to retrieve this information. Determine whether the Active Directory account for the user is locked because of failed attempts to log on. You must be logged on as the root user or querying Active Directory for your own account information to retrieve this information. Determine whether the Active Directory account for the user has been disabled. You must be logged on as the root user or querying Active Directory for your own account information to retrieve this information. Determine whether the Active Directory account for the user has been enabled for UNIX access in the current zone. Display the distinguished name (dn) for the specified user or for all users in the zone. Appendix A Using Centrify UNIX commands 277

278 Using adquery Use this option -W, --userworkstations -A, --all -j, --dump -F, --cache-first -r, --separator char -R, --list-separator char -f, --prefix To do this List the value of the user s Active Directory userworkstations attribute, which specifies the computers from which the user may log into the domain. If the output is blank, the user is not restricted to a particular computer. List all of the information returned by the other command line options for the user. List all the user s raw attributes and values. Read data from the cache rather than from Active Directory. Only read from Active Directory if an object has expired. Specify the separator character or string (char) to use between fields. The default separator between fields is a colon (:). For example: jae:uid:525 Specify the separator character or string (char) to use between the values in a list. The default separator between values in a list is a comma (,). For example: jae:unixgroups:testlab,dev2 Add the user s UNIX user name as a prefix when returning single values. This option formats the information returned to include the user s UNIX name when you are querying for a specific attribute, such as the user s UID or displayname. This option is not necessary if you query for multiple attributes in the command line. If you query for multiple attributes, the information returned is formatted with the user s UNIX name and a label identifying each attribute by default. Administrator s Guide for Linux and UNIX 278

279 Using adquery Use this option -X, --extattr -v, --version To do this Display the list of extended attributes or the value of a specified extended attribute. Note Extended attributes are only applicable on AIX computers. You can use the keyword help to view a list of the supported extended attributes. For example: adquery user --extattr help Note Certain extended attributes, such as the system privileges, or capabilities attributes, are only supported by agents with methods in the Loadable Authentication Module (LAM) version 5.2 or later. To be able to query and use these extended attributes, you must be running AIX 5.2 or later, and set the value of the lam.method.version parameter in the centrifydc.conf configuration file to version 5.2 (520). See the Configuration Parameters Guide for details about this parameter. To look up the value of a specific extended attribute, include the name of the attribute in the command line. For example, to look up the value of the aix.rlogin extended attribute: adquery user -X aix.rlogin jae Display version information for the installed software. Querying group information You can use adquery group command to look up one or more details about a specified group or multiple groups in Active Directory. If you don t specify any groups in the command line, the command lists all of the groups in the zone. The basic syntax for querying group information is: adquery group [options] groupname You must use the canonical format for the group name if specifying the Active Directory group name. For example, if you want to specify the Active Directory group name, you can type a command similar to the following: adquery group ajax.org/users/testexpert Team All options, including --all, return formatted attributes and values, with the exception of --dump, which returns raw attributes and values, and --attribute, which allows you to specify individual raw attributes. Raw attributes are the form in which attributes are stored internally in Active Directory or in a Centrify zone, that is, without regard to readability. For example, the raw attribute for the group type is a numeric string: #adquery group -j grep -i type dnsadmin:grouptype: whereas, the formatted attribute shows a name: #adquery group - t local security Appendix A Using Centrify UNIX commands 279

280 Using adquery Setting valid options for group information You can use the following options with the adquery group command: Use this option -b, --attribute attributename To do this Display the value of the specified Active Directory or Centrify raw attribute. Use the -j (--dump) option to see a list of raw attributes. The -A (--all) option returns formatted attributes and values. Note Attribute names are case-sensitive. Internal Centrify attributes begin with an underscore character. You can specify multiple --attribute (-b) options, in which case, the name of the attribute is returned along with the value. For example: #-b cn DnsAdmins #-b cn -b samaccountname cn:dnsadmins samaccountname:dnsadmins -m, --members -a, --admembers -s, --sammembers -g, --gid -q, --required -n, --unixname -M, --samname -i, --sid -C, --canonical -D, --dn -A, --all -j, --dump List the UNIX members of the specified group or of all groups in the zone. List the Active Directory members of the specified group or of all groups in the zone. List Active Directory members of the specified group or all groups in the form: name@domain; for example, [email protected] Display the group identifier (GID) for the specified group or of all groups in the zone. Display whether membership in the specified group is required or not. For more information about required groups, see adsetgroups. Display the UNIX group name for the group. Display the Active Directory name for the group. Display the Active Directory security identifier (SID) for the group. Display the Active Directory canonical name for the group. Display the distinguished name (dn) for the group. List all of the information returned by the other command line options for the group. If you use this option without specifying a group name, the command lists details for all of the groups in the zone. List all the group s raw attributes and values. Administrator s Guide for Linux and UNIX 280

281 Using adquery Use this option -F, --cache-first -r, --separator char -R,--list-separator char -f, --prefix -t, --type -v, --version To do this Read data from the cache rather than from Active Directory. Only read from Active Directory if an object has expired. Specify the character or string (char) to use as the separator between an attribute name and its value. The default separator between attributes and values is a colon (:). For example: unixname:qa-euro Specify the character or string (char) to use as the separator between the values in a list. The default separator between values in a list is a comma (,). For example: unixgroups:unixdev,testexpe Add the UNIX group name as a prefix when returning single values. This option formats the information returned to include the UNIX group name when you are querying for a specific attribute, such as the group GID or membership list. This option is not necessary if you query for multiple attributes in the command line. If you query for multiple attributes, the information returned is formatted with the UNIX group name and a label identifying each attribute by default. Display the scope and group type for a specified group. The valid group types are: local security global security universal security Display version information for the installed software. Examples of using adquery You can use adquery to return a specific value for a user or group or to list multiple details about a user or group. The format of the output depends on whether you specify a single attribute or multiple attributes on the command line. For example, if you want to see a complete list of details about the group unixdev, you would type: adquery group --all unixdev This command returns the results for the unixdev group in the following format: unixname:unixdev gid:400 required:false dn:cn=unix Developers,CN=Users,DC=ajax,DC=org grouptype:global security samaccountname:unix Developers sid:s canonicalname:ajax.org/users/unix Developers members:ajax.org/users/ashish Menendez,ajax.org/Users/Ben Waters,ajax.org/ Users/Monte Fisher,ajax.org/Users/Jae Kim,ajax.org/Users/Jay W. Appendix A Using Centrify UNIX commands 281

282 Using adquery Reynolds,ajax.org/Users/Pierre Leroy,ajax.org/Users/Rae Parker,ajax.org/ Users/Zoe Green unixmembers:ashish,ben,fisher,jae,jay,pierre,rae,zoe Similarly, to see a complete list of details about the user [email protected], type: adquery user --all [email protected] This command returns the results for the user in the following format: unixname:jae uid:409 gid:400 gecos:jae Kim home:/home/jae shell:/bin/bash dn:cn=jae Kim,CN=Users,DC=ajax,DC=org samaccountname:jae display:jae sid:s userprincipalname:[email protected] serviceprincipalname: canonicalname:ajax.org/users/jae Kim passwordhash:x accountexpires:never passwordexpires:thu Apr 12 15:21: nextpasswordchange:fri Mar 2 14:21: lastpasswordchange:thu Mar 1 14:21: accountlocked:false accountdisabled:false zoneenabled:true unixgroups:unixdev,testexpe memberof:ajax.org/users/unix Developers, ajax.org/users/domain Users,ajax.org/Performix/TestExpert Team Specifying a single attribute for users and groups When you specify a single attribute in the command line, the information is displayed as one value per line without any attribute label or identifier. For example, if you want to return the canonical name for the qa-euro group as an unlabeled value, you would type: adquery group --canonical qa-euro This command displays the canonical name without any prefix or label: ajax.org/users/qa Europe Similarly, if you want to return only the UID for the user [email protected], you would type: adquery user --uid [email protected] To list a single attribute about multiple groups or users, you can specify the additional groups or users in the command line. For example, to see a list of the UNIX user names of Active Directory members for the testexp, performx and unixdev groups, you would type: adquery group --members testexp performx unixdev This command returns the UNIX user names of the members in each group in the following format: ben,fisher,jae,jolie,rae Administrator s Guide for Linux and UNIX 282

283 Using adquery zoe ashish,ben,fisher,jae,jay,pierre,rae,zoe If you want the results to include the UNIX user name or group name, you can add the -- prefix option to the command line. For example, to include the UNIX group name with a membership list for the testexp, performx and unixdev groups, you would type: adquery group --members --prefix testexp performx unixdev This command returns the members in each group in the following format: testexp:ben,fisher,jae,jolie,rae performx:zoe unixdev:ashish,ben,fisher,jae,jay,pierre,rae,zoe Specifying multiple attributes for users and groups When you query multiple attributes for a user or group, the results display the UNIX user or group name, followed by an attribute label to identify the attribute values displayed. For example, to return the samaccountname and unixgroups for the users rae, ben, ashish, and jae, you would type: adquery user --samname --groups rae ben ashish jae This command returns the requested information for each user in the following format: rae:samaccountname:rae-old rae:unixgroups:unixdev,testexpe,perform2 ben:samaccountname:ben ben:unixgroups:qualtrak,unixdev,testexpe ashish:samaccountname:ashish ashish:unixgroups:qualtrak,unixdev jae:samaccountname:jae jae:unixgroups:unixdev,testexpe,perform2 Listing information for all users and groups in a zone If you don t specify a username or groupname in the command line, the adquery command returns information for all users or all groups in the current zone. The format of the output depends on whether you specify a single attribute or multiple attributes and any other options you set. For example, to list the UNIX group names and GIDs for all of the groups in the current zone, you would type: adquery group --gid --prefix This command returns the group names and GIDs in the following format: unixdev:400 oracle:700 qualtrak:800 performi:401 perform2:402 financeu:403 testexpe:404 integrit:405 Similarly, to return a list of UIDs and display names for all of the users in the current zone, you would type: adquery user --uid --display For example: Appendix A Using Centrify UNIX commands 283

284 Using adgpupdate rae-old:uid:10003 rae-old:displayname:rae S. Parker jay:uid:501 jay:displayname:jay W. Reynolds zoe:uid:502 zoe:displayname:zoe Green ben:uid:503 ben:displayname:ben Waters ashish:uid:504 ashish:displayname:ashish Menendez fisher:uid:505 fisher:displayname:monte Fisher pierre:uid:506 pierre:displayname:pierre Leroy lynn:uid:507 lynn:displayname:lynn Hogan tess:uid:508 tess:displayname:tess Adams jolie:uid:509 jolie:displayname:jolie Ames-Anderson jae:uid:510 jae:displayname:jae Kim 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. 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 might occur more or less frequently in your environment. For information about setting computer and user group policies, see the Group Policy Guide. For information about customizing the group policy update, see the Configuration and Tuning Reference Guide. 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 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. Administrator s Guide for Linux and UNIX 284

285 Using adinfo Setting valid options You can use the following options with this command: Use this option -T, --target [Computer User] -V, --verbose -v, --version To do this Restrict the group policy update to either Computer group policy or User group policy. Displays information about each step in the group policy update process as it occurs. This option is useful for troubleshooting purposes. Display version information for the installed software. Using adinfo 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. 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 of the following: adinfo [--domain] [--gc] [--zone] [--zonedn] [--site] [--server] [--name] [-- all] [--support [--output filename] [--path paths] [--debugcache][--diag [domain]] [- config] [--mode] [--fips] [--joinedcount] [--sysinfo all [dns],[domain],[netstate],[adagent],[config],[health],[zone]] [--test] [-- Appendix A Using Centrify UNIX commands 285

286 Using adinfo verbose] [--version] [--auth [domain]] [--ntlmauth [domain]] [--servername domain_controller] [--computer] The --domain, --gc, --zone, --zonedn, --site, --server, and --name options are intended for use in scripts to return the current Active Directory domain, global catalog domain controller, zone, site, domain controller, and computer account name, respectively. The other options provide more detailed or operation-specific information. You can use the --user and --password options in conjunction with the --all, --support, --diag, or --auth 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. Note The last line returned by adinfo on Mac OS X and Linux computers shows Licensed Features: Enabled Disabled to indicate whether the standard or express version of the agent is running. This information is only relevant to Mac OS X and Linux computers so it does not appear when you run adinfo on other platforms. Setting valid options You can use the following options with this command: Use this option -d, --domain -G, --gc -z, --zone To do this 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 10. Return the name of the local computer s Active Directory domain controller used for global catalog operations. If the computer isn t currently joined to an Active Directory domain, then the command exits and returns an exit status of 10. Return the name of the local computer s Active Directory zone or Auto Zone if a computer is joined to Auto Zone and not a member of any specific zone. If the computer isn t currently joined to an Active Directory domain, then the command exits and returns an exit status of 10. Administrator s Guide for Linux and UNIX 286

287 Using adinfo Use this option -Z, --zonedn -s, --site -r, --server -n, --name -a, --all To do this Return the distinguished name (DN) of the local computer s Active Directory zone or the distinguished name (DN) of the computer s Active Directory domain if the computer is joined to Auto Zone. The distinguished name is the name that uniquely identifies an entry in the directory, beginning with the most specific attribute and continuing with progressively broader attributes. If the computer isn t currently joined to an Active Directory domain, then the command exits and returns an exit status of 10. Return the name of the local computer s Active Directory site. If the computer isn t currently joined to an Active Directory domain, then the command exits and returns an exit status of 10. Return the fully-qualified name of the local computer s Active Directory domain controller. If the computer isn t currently joined to an Active Directory domain, then the command exits and returns an exit status of 10. Return the fully-qualified name of the local computer s computer account name in Active Directory. If the computer isn t currently joined to an Active Directory domain, then the command exits and returns an exit status of 10. Return the following information: Local host name Domain the computer is joined to Computer account name in Active Directory Local preferred site Centrify 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 Whether licensed features are enabled (Mac OS X and Linux only) 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. Appendix A Using Centrify UNIX commands 287

288 Using adinfo Use this option -t, --support -o, --output filename -P, --paths path -D, --debugcache To do this Return all of the information supplied by the --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 You can use the --paths option to specify additional locations from which to collect and return information. This option is typically used to send complete diagnostic information to a file, which can then be sent to Centrify Corporation Technical Support for analysis. By default, the output for the command is written to the file /var/ centrify/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. To send --support output to stdout, use a hyphen (-) in the command line in place of the filename. 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. Send output to the specified file. By default, output for the command is written to the file /var/centrify/tmp/adinfo_support.txt. To send the output specified by the --support option to stdout, use a hyphen (-) in the command line in place of the filename. You can also use redirection (>) or piping ( ) to save the output to a different location or filename. Use with the --support option to collect information from additional locations. By default, the --support option collects the following 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 Collect cache and NIS map files for analysis and put them in a compressed file, /var/centrify/tmp/ adinfo_debugcache.tar.gz, that you can send to Centrify Corporation Technical Support for analysis. You must use the root account with this option. Administrator s Guide for Linux and UNIX 288

289 Using adinfo Use this option -g, --diag [domain] -c, --config -m, --mode -f, --fips -j, --joinedcount To do this 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 or IP address 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 a 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. Return the parsed contents of the configuration file. Display whether the computer is currently connected to Active Directory or running in disconnected mode. If the adclient process is not running, the computer is considered disconnected (to re-connect restart adclient). This option returns connected to indicate connected and down to indicate disconnected. Note: The computer must be joined to the domain controller for the -m option to return the adclient state. Display whether the computer is enabled for FIPS mode. Display the number of computers joined to each zone. Appendix A Using Centrify UNIX commands 289

290 Using adinfo Use this option -y, --sysinfo all dns,domain,netstate,adagent, config,health,zone -T, --test -V, --verbose -v, --version -u, --user -p, --password userpassword -A,--auth [domain] To do this Display system information for the current domain. You can specify one or more options in a comma-separated list, or specify all to show all available information: all Display all available system information; specifying this option is the same as specifying all the following options. dns Display the address, state, and cache contents of the current DNS server. domain Display domain info map for the current domain. netstate Display network state. adagent Display binding information and connection status for the agent. config Display adclient in-memory configuration parameter values. health Display system health status for the local host. zone Display the distinguished name for the zone. For example, to show DNS, domain, and configuration information, type the following command: adinfo --sysinfo dns,domain,config Test the availability of the ports required for authentication through Active Directory. Display detailed information about each operation as it is performed. You can use this option in combination with other options. Display version information for the installed software. Identify an Active Directory user account with 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. Specify the password for the Active Directory user 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. Authenticate the user name and password for the user specified with the --user option against the specified domain. If you don t specify a domain, the user is validated against the currently joined domain. This option only validates that the specified user name and password can be authenticated by Active Directory. You cannot use this option in combination with other options to display other types of information Administrator s Guide for Linux and UNIX 290

291 Using adinfo Use this option -N,--ntlmauth [domain] -S, --servername domain_controller -C, --computer To do this Authenticate the NTLM user name and password for the user specified with the --user option against the specified domain. If you don t specify a domain, the user is validated against the currently joined domain. This option only validates that the specified NTLM user name and password can be authenticated by Active Directory. You cannot use this option in combination with other options to display other types of information Connect to a specific domain controller to perform network diagnostics. You can use this option in combination with any of the other options. Display the service principal names (SPNs) associated with the computer account. Examples of using adinfo In most cases, you use the adinfo command to provide information that will help you diagnose and resolve problems with the Centrify 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: magnolia Joined to domain: ajax.org Joined as: magnolia.ajax.org Pre-win2k name: magnolia Current DC: ginger.ajax.org Preferred site: Default-First-Site-Name Zone: ajax.org/program Data/Centrify/Zones/default Last password set: :37:22 PST CentrifyDC mode: connected Licensed Features: Enabled Note Whether licensed features are enabled or disabled is only relevant for Linux and Mac computers and is not shown for Solaris and other UNIX systems. 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: ajax.org 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 Appendix A Using Centrify UNIX commands 291

292 Using adinfo 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 magnolia EL #1 Thu Apr 22 00:27:41 EDT 2004 i686 OS: Red Hat Enterprise Linux ES Version: 3 (Taroon Update 2) Number of CPUs: 1 IP Diagnostics Local host name: magnolia FQDN host name: magnolia (domain missing?) Local IP Address: Domain Diagnostics: Domain: ajax.org Subnet site: Default-First-Site-Name DNS query for: _ldap._tcp.ajax.org Found SRV records: ginger.ajax.org:389 Testing Active Directory connectivity: Domain Controller: ginger.ajax.org ldap: 389/udp - good ldap: 389/tcp - good smb: 445/tcp - good kdc: 88/tcp - good kpasswd: 464/tcp - good Domain Controller: ginger.ajax.org:389 Domain controller type: Windows 2003 Domain Name: AJAX.ORG isglobalcatalogready: TRUE domainfunctionality: 0 = (DS_BEHAVIOR_WIN2000) forestfunctionality: 0 = (DS_BEHAVIOR_WIN2000) domaincontrollerfunctionality: 2 = (DS_BEHAVIOR_WIN2003) Forest Name: AJAX.ORG DNS query for: _gc._tcp.ajax.org Testing Active Directory connectivity: Global Catalog: ginger.ajax.org gc: 3268/tcp - good Domain Controller: ginger.ajax.org:3268 Domain controller type: Windows 2003 Domain Name: AJAX.ORG isglobalcatalogready: TRUE domainfunctionality: 0 = (DS_BEHAVIOR_WIN2000) forestfunctionality: 0 = (DS_BEHAVIOR_WIN2000) domaincontrollerfunctionality: 2 = (DS_BEHAVIOR_WIN2003) Forest Name: AJAX.ORG Administrator s Guide for Linux and UNIX 292

293 Using adinfo Retrieving zone data from ajax.org Centrify DirectControl 2.x zones: ConsumerDiv - ajax.org/program Data/Centrify/Zones/ConsumerDiv Manufacturing - ajax.org/program Data/Centrify/Zones/Manufacturing London - ajax.org/program Data/Centrify/Zones/London Centrify Microsoft SFU zones: default - ajax.org/program Data/Centrify/Zones/default Computer Account Diagnostics Joined as: magnolia Key Version: 5 Service Principal Names: nfs/magnolia.ajax.org nfs/magnolia host/magnolia.ajax.org host/magnolia ftp/magnolia.ajax.org ftp/magnolia cifs/magnolia.ajax.org cifs/magnolia HTTP/magnolia.ajax.org HTTP/magnolia Centrify DirectControl Status Running in connected mode To test whether a specific user can be authenticated by a specific Active Directory domain controller, you could type a command similar to the following: adinfo --auth --user rae --servername ginger.ajax.org You are then prompted for the Active Directory password for the user rae account. If Active Directory can authenticate the user, a confirmation message similar to the following is displayed: Password for user rae is correct To test connectivity and the availability of required ports on the Active Directory domain controller, you could type a command similar to the following: adinfo --test If the computer is joined to a domain and the connection to Active Directory succeeds, the command displays information similar to the following: Domain Diagnostics: Domain: ajax.org DNS query for: _ldap._tcp.ajax.org DNS query for: _gc._tcp.ajax.org Testing Active Directory connectivity: Global Catalog: ginger.ajax.org gc: 3268/tcp - good Domain Controller: ginger.ajax.org ldap: 389/tcp - good ldap: 389/udp - good smb: 445/tcp - good kdc: 88/tcp - good kpasswd: 464/tcp - good ntp: 123/udp - good Appendix A Using Centrify UNIX commands 293

294 Using addebug Understanding adinfo-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adinfo command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_MACHINE_PASSWORD_CHANGED The computer account password has been changed. If you encounter this error, you may need to manually reset the computer account password in Active Directory, then rerun the adinfo command. 157 ERR_KRB_READ_FORMAT A Kerberos format error occurred when reading the Kerberos configuration file. You should rename or remove the configuration file, then rerun the adinfo command. 158 ERR_NOT_FQDN_NAME The server name must be a fullyqualified domain name. Using addebug The addebug command is used to start or stop detailed logging activity for the Centrify agent (adclient) process on a local UNIX computer. If you do not specify an option, the addebug command displays its current status, indicating whether logging is active or disabled. The basic syntax for the addebug program is: addebug [on off] [option] To run this command, you must be logged in as root. When you run this command with the on option, all of the Centrify adclient activity is written to the system log directory in the centrifydc.log file or the journal file. For most operating systems, the system log directory is /var/log. However, for HPUX computers, the system log directory is /var/admin/syslog. In addition, some distributions of Linux, such as Fedora 20, write system messages to the journal file instead of the traditional syslog location. For performance and security reasons, you should only enable Centrify logging when necessary, for example, when requested to do so by Centrify Support, and for short periods of time to diagnose a problem. Keep in mind that sensitive information may be written to the log file and you should evaluate the contents of the file before giving others access to it. If the adclient process stops running while logging is on, the addebug program records messages from PAM and NSS requests in the /systemlog/centrify_client.log file. Therefore, you should also check that file location if you enable logging. Administrator s Guide for Linux and UNIX 294

295 Using addebug Setting valid options You can use the following options with this command: Use this option on off clear syslog journal status set module.name level To do this Start logging all adclient process activity in the centrifydc.log file or journal file as described above. Stop logging adclient process activity. Clear the existing log file, then continue logging activity to the cleared log file. If the local computer uses systemd journal to log system messages, this option is not supported. This option forces either the traditional syslog daemon or systemd journal daemon to reload its configuration file. Specifying this option is useful if you are running DirectSecure.: If the local computer uses the traditional syslog daemon to log data, use the syslog option. If the local computer uses systemd journal to log data, use the journal option. If the local computer writes system messages to the journal, log files are located in the /var/log/journal and /run/log/journal directories. You can use journalctl to view and manage journal log files. Print the current log level of all modules; supported levels are TRACE, DEBUG, INFO, WARNING, ERROR, FATAL and DISABLED. Set a module and level. You can set a level without a module, in which case it applies to the default (log) module, or you can specify a module name and set the level for that module. The level must be specified by one of the following key words, which specify log levels from highest (TRACE) to lowest (DISABLED). All caps is required for the keyword: TRACE, DEBUG, INFO, WARNING, ERROR, FATAL and DISABLED. Examples of using addebug You use the addebug command to start and stop detailed agent-specific logging to help you trace and resolve problems. 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 /systemlog/centrifydc.log file similar to the following:... Dec 14 00:31:59 jon adjoin[11198]: com.centrify.join: Joining domain garfield.com Appendix A Using Centrify UNIX commands 295

296 Using admigrate 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' Dec 14 00:31:59 jon adjoin[11198]: com.centrify.daemon.adbinding: Attempting connection to server Dec 14 00:31:59 jon adjoin[11198]: com.centrify.daemon.adbinding: Connecting to odie.garfield.com:389 Dec 14 00:31:59 jon adjoin[11198]: com.centrify.daemon.adbinding: Connected... For performance and security reasons, you should only enable agent logging when necessary, for example, when requested to do so by Centrify Corporation Technical Support, and for short periods of time. To discontinue logging, type: addebug off Using admigrate The admigrate command allows you to migrate a classic zone to a hierarchical zone. You can migrate a classic zone to a new peer hierarchical zone, or you can specify a parent zone for the migration. When you specify a parent zone, admigrate puts profile data from the source zone into the new parent zone, and override data, groups, roles and rights, and NIS maps into the new child zone. You can run admigrate multiple times and specify the same parent zone to migrate multiple classic zones to child zones of a single parent. By default, admigrate migrates users, groups, role and right definitions, role assignments, and NIS maps from the classic zone, to the hierarchical zone. You can specify a subset of data by using one or more of the -users, -groups, -privileges, and -nismaps options. When migrating right and role data, admigrate runs a series of checks to verify that none of the names from the classic zone will conflict after migration. If admigrate finds conflicts, it issues an error message (and quits without creating the new zone) or a warning message (and completes the migration), depending on the type of error. Note If you specify the -n option, admigrate will perform the name checks, and issue an error message if conflicts are find, but will complete the migration and create the new zone even with conflicting name errors. You should rename conflicting roles in the new zone after migration is complete. The admigrate command performs the following checks: Verifies that no restricted environment command has the same name as a privileged command because after migration they will be in the same namespace (Commands) and will conflict. The admigrate command will exit with an error if there are conflicts. You must rename one of the rights before running admigrate again. Administrator s Guide for Linux and UNIX 296

297 Using admigrate Verifies that no PAM rights are named login-all, which is a predefined PAM right in a hierarchical zone. The admigrate command will exit with an error if there is a conflict. You must rename the right before running admigrate again. Verifies that no roles are named UNIX Login, listed, login_at_roles, or login_all_apps, because these are predefined role names in a hierarchical zone. If conflicting names are found, admigrate will rename the role by appending the objectguid attribute to the name, issue a warning message, and complete the migration to the new zone. Checks whether the migrated names for PAM applications contain special characters (other than alphanumeric, space, underscore (_), or dash (-). The migrated names are based on the value (application name) for the PAM application, not on the user-defined name. However, if the value contains an illegal special character, admigrate continues to run but issues a warning and uses the user-defined name rather than the value. The basic syntax for the admigrate program is: admigrate [options] -in classiczone -z targetzone -config filename [-hz parentzone] Setting valid options You can use the following options with this command: Use this option -in classiczone To do this Specify the distinguished name of the classic zone to migrate. This parameter is required. -z targetzone Specify the distinguished name of the new zone. If this zone exists, the admigrate command will fail unless the -f option is specified, in which case the zone is overwritten and any existing zone information will be lost. This parameter is required. -hz parentzone Specify a parent zone for the migration. The specified zone must be an existing zone. When you specify this option, admigrate creates the zone named by the -z option as a child zone of this parent zone. You may run admigrate as many times as necessary and specify the same parent zone each time to migrate multiple classic zones to a set of child zones in the same parent zone. Appendix A Using Centrify UNIX commands 297

298 Using admigrate Use this option -config filename To do this Specify a configuration file to use with the migration. The configuration file is primarily useful to specify bind information if you are migrating zones from domains that are different from the target zone s domain. This file is a tcl file that gets sourced. For example, the file could contain bind calls, such as the following: bind acme.com administrator {myp@$swd} bind -write eng.acme.com administrator {@lt!pas$} -f Overwrite the target zone (specified by -z) if it already exists. If the specified zone already exists and you do not specify the -f option, the admigrate command exits unsuccessfully. -users -groups -privileges -nismaps -n, Migrate user data to the new zone. Migrate groups to the new zone. Migrate right and role definitions and role assignment to the new zone. Migrate NIS maps to the new zone. Prevent name conflicts from aborting the migration. When migrating right and role data, admigrate runs a series of checks to verify that none of the names from the classic zone will conflict after migration. If conflicts are found, some checks return a warning message and some an error message. By default, if a name conflict error is returned, admigrate terminates without creating a new zone. If you specify the -n option, admigrate will still issue an error message when conflicts are found, but will finish the migration and create the new zone. After the migration is complete, you should rename conflicting names in the new zone. -v Print verbose information while the command runs. Examples of using admigrate The following command migrates the classic zone finance to a new hierarchical zone of the same name and creates this zone as a child zone of the parent zone global. It uses the bind credentials in the ~/admigrate.txt file, and outputs verbose information to the migrate_finance.txt file. /usr/share/centrifydc/adedit/admigrate \\ -in "cn=finance,cn=zones,ou=unix,dc=acme,dc=com" \\ -z "cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com" \\ -hz "cn=global,cn=zones,ou=unix,dc=acme,dc=com" \\ -config ~/admigrate.txt \\ -f -v >migrate_finance.txt Administrator s Guide for Linux and UNIX 298

299 Using adobfuscate Using adobfuscate The adobfuscate command allows you to obscure sensitive data in a log file, such as addresses, host names, and user names, before sending the file to Centrify Corporation for analysis. You create a pattern file using regular expressions to identify specific patterns in the file. The command reads the pattern file and replaces items matched by the patterns with generic values. The adobfuscate command operates in two passes. The first pass searches for patterns (as defined in the pattern file) in the log file and creates a map file that contains the specific values to be hidden, as well as a unique token to replace each one. For example, in the pattern file you can search for host names (see Examples of using adobfuscate on page 301 for specific information on how to use regular expressions in the pattern file to identify items in the log file to hide). In the map file, adobfuscate creates a list of specific host names and replacement value tuples; for example: centrify.com ajax.com hostcom_0 hostcom_1 The second pass applies the value-token tuples in the map file to the log file, replacing each instance of the value with its corresponding token. For example, each instance of centrify.com in the log file is replaced by hostcom_0. By default, the sanitized log file is written to obfuscate.txt in the directory in which you run adobfuscate. You can use the --outputfile option to specify a different filename or directory. By default, adobfuscate performs the first pass only, although you can use the --both option to perform both. Once you create a map file, you can hand edit it to add other known hostnames, addresses and so on, and if you are sure you have identified all sensitive names that might be in a log file, you can run this map file against any log file without performing the first pass each time. The basic syntax for the adobfuscate program is: adobfuscate [options] [user[@domain]] Appendix A Using Centrify UNIX commands 299

300 Using adobfuscate Setting valid options You can use the following options with this command: Use this option -b, --both -f, --logfile filename -l, --outputfile filename -m, --mapfile filename To do this Perform both passes of adobfuscate. The first pass searches the log file for patterns specified in the pattern file and creates a map file that contains values to be replaced and the token to replace them with. The second pass reads the the map file and replaces the patterns in the log file with the replacement token. When you specify the --both option, the replacement values created by pass one are used during pass two, rather than read from a map file. By default (if you do not specify the --both option), only pass one is performed. Specify the input log file. It must be a text-based file in which lines are separated by the newline character. Note Although the purpose of this command is to hide sensitive information in log files generated by Centrify commands, you can specify any valid text file. The default input file is log.txt. Specify the output log file. The default output file is obfuscate.txt in the directory in which you run adobfuscate. Specify the map file to create, or use, depending on the pass you are running. When you run only the first pass of adobfuscate (the default operation), this option (--mapfile) specifies the map file to create. When you run only the second pass of adobfuscate (- -obfuscate), this option specifies the map file to apply to the log file. Note If you use the --both option to run both passes, you do not need to specify a map file because the command creates replacement values during the first pass, and applies them to the log file during the second pass. The map file contains a list of lines, each with a value and replacement token, separated by a tab; for example: centrify.com hostcom_0 ajax.com hostcom_1 [email protected] _1 The default input map file is map.txt. Administrator s Guide for Linux and UNIX 300

301 Using adobfuscate Use this option -o, --obfuscate -p, --patternfile filename To do this Run the second pass of the operation only. The second pass reads replacement values from the specified map file and replaces matching values in the specified log file with the appropriate tokens. The default input file is log.txt. The default map file is map.txt. Specify the input pattern file to use. The pattern file contains regular expressions to find sensitive information ( addresses, hostnames, and so on) to replace with generic tokens. The default pattern file is: /etc/centrifydc/adobfuscate.conf. You can use this file as is, or use it as a template to create your own pattern file. -v, --verbose Print verbose information while the command runs. Specify multiple --verbose options to increase the verbosity level. The maximum is 2. Examples of using adobfuscate Using adobfuscate command is a multi-step process: 1 Create a pattern file to identify the types of names to hide in the log file. You can use the standard pattern file (/etc/centrifydc/adobfuscate.conf), as is, or as a template to create your own pattern file. 2 Run the first pass of adobfuscate, and specify the pattern file you just created, to create a map file that contains all the specific names to replace as well as a replacement value for each name. 3 Run the second pass of adobfuscate, and specify the map file you just created, to apply the replacement values to each specified name in the log file. The following example steps you through this process. Creating a pattern file In the pattern file, you use regular expressions to identify sensitive names that you want obscured in the log file. Each line in the pattern file uses the following syntax: action reg-expr-pattern repl-token where: action One of the following: match Replace any items that match the patterns. exclude Keep the item even if it matches the pattern. reg-expr-pattern A regular expression pattern to identify sensitive names in the log file, such as addresses and hostnames. Appendix A Using Centrify UNIX commands 301

302 Using adobfuscate repl-token The token to replace names of each type in the log file. For example, specific addresses are replaced by _n,.com host names by hostcom_n, and so on. The easiest way to create a pattern file is to modify the sample file: /etc/centrifydc/ adobfuscate.conf. The following shows the pattern matching definitions from this file: #You can define your own sensitive data by using the following format. #[action type][regular expression] [substitute value] #The action type has two optional values: match exclude. #Lines of 'match' specify patterns that should be obfuscated and must have substitute value argument. #Lines of 'exclude' specify patterns that shouldn't be matched. match /[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}/ match /[A-Z0-9-]+[A-Z0-9.-]+\.com/ hostcom match /[A-Z0-9-]+[A-Z0-9.-]+\.net/ hostnet match /[A-Z0-9-]+[A-Z0-9.-]+\.org/ hostorg match /[A-Z0-9-]+[A-Z0-9.-]+\.test/ hosttest match /[A-Z0-9-]+[A-Z0-9.-]+\.land/ hostland Also in the file are patterns to exclude: exclude /adclient\..*/ exclude /adclient\.pam\.util/ exclude /adclient\.session/ exclude /adfs\.agent/ exclude /adfs\.federationinfo/ exclude /adfs\.request/ exclude /adfs\.request\.checktoken/ exclude /adfs\.request\.parsetoken/ exclude /adfs\.test/... exclude /util\.ulimit/ The purpose of this list is to retain specific items in the log file that may be useful for analyzing a problem, but would otherwise be obscured because they match one of the specified patterns. You should browse this list and remove any specific items that you do not want to appear in a log file you send to Centrify Corporation. Running the first pass of adobfuscate After you create a pattern file, you can run the first pass of adobfuscate to create a map file: adobfuscate -f /var/log/centrifydc.log -m mymap This command applies the default pattern file (/etc/centrifydc/adobfuscate.conf) to the centrifydc log file and creates a map file called mymap. Suppose the log file contains the following text (hostnames are in bold-face type so you can easily see them): Mar 23 11:04:56 lynx1 adnisd[2247]: WARN <main> adnisd No NIS maps found on server win2k- 1.acme.com Mar 23 11:04:56 lynx1 adclient[2524]: DEBUG <fd:16 ldap fetch> base.bind.ldap win_serv- 1.acme.com:389 fetch dn="" filter="(objectclass=*)" timeout=7 Mar 23 11:04:56 lynx1 adclient[2524]: DEBUG <fd:16 get object> base.bind.ldap win_serv- 1.acme.com:389 pagedsearch base="cn=groups,cn=default,cn=zones,cn=centrify,cn=program Data,DC=mkline,DC=local" filter="(displayname=$cimsgroupversion2)" Mar 23 11:09:57 lynx2 adnisd[2247]: WARN <main> adnisd No NIS maps found on server win2k- 1.acme.com By applying the pattern file, adobfuscate creates a map file with the following entries: Administrator s Guide for Linux and UNIX 302

303 Using adrmlocal win2k-1.acme.com win_serv-1.acme.com hostcom_0 hostcom_2 Note The entry, base.bind.ldap, has the form of a hostname, and as such would normally be replaced with a hostname_n token; however, the default adobfuscate pattern file contains an entry to exclude it, so it remains in the log file: exclude /base.bind.ldap Running the second pass of adobfuscate Now run the second pass (-o option) of adobfuscate specifying the map file you just created, to obscure hostnames in the log file: adobfuscate -f /var/log/centrifydc.log -m mymap -o The sanitized log file contains the following entries: Mar 23 11:04:56 lynx1 adnisd[2247]: WARN <main> adnisd No NIS maps found on server hostcom_0 Mar 23 11:04:56 lynx1 adclient[2524]: DEBUG <fd:16 ldap fetch> base.bind.ldap hostcom_1:389 fetch dn="" filter="(objectclass=*)" timeout=7 Mar 23 11:04:56 lynx1 adclient[2524]: DEBUG <fd:16 get object> base.bind.ldap hostcom_1:389 pagedsearch base="cn=groups,cn=default,cn=zones,cn=centrify,cn=program Data,DC=mkline,DC=local" filter="(displayname=$cimsgroupversion2)" Mar 23 11:09:57 lynx2 adnisd[2247]: WARN <main> adnisd No NIS maps found on server hostcom_0 As you can see, specific hostnames have been replaced with generic host name tokens. Understanding adobfuscate-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adobfuscate command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 6 ERR_OTHERS Error when parsing the patter file or the map file. 7 ERR_USAGES Usage error. 40 ERR_OPEN_FILE Could not open file. 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. Appendix A Using Centrify UNIX commands 303

304 Using adrmlocal 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. Setting valid options You can use the following options with this command: Use this option -i, --interactive -c, --commit -f, --force -v, --version To do this Be prompted interactively for confirmation that you want to remove the duplicate local user account before performing the delete operation. 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. Remove all duplicate local user names without prompting even if there are UID or GID conflicts. Display version information for the installed 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) Administrator s Guide for Linux and UNIX 304

305 Using adfinddomain Understanding adrmlocal-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adrmlocal command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_NOT_LOAD_PASSWD_FILE The attempt to load the local password file failed. 157 ERR_NOT_CHECK_DUP_LOCAL_USER The attempt to check for duplicate user accounts failed. 158 ERR_NOT_LOAD_GROUP_FILE The attempt to load the local group file failed. 159 ERR_NOT_CHECK_DUP_LOCAL_GROUP The attempt to check for duplicate user accounts failed. 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] [--port] [--verify] [--version] [domain $] If you don t specify a domain, the command returns information for the domain the local computer is joined to. If you specify a dollar sign ($) instead of a domain, the command returns the host name and, optionally the port number, for the Global Catalog server. Setting valid options You can use the following options with this command: Use this option -f, --format name ldap ip -p, --port -w, --writable -V, --verify -v, --version [domain $] To do this Control the format of the information displayed for 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 fully-qualified host name of the domain controller. adfinddomain -f ldap ldap:://fire.arcade.org Include the port number in the output. Insure that the command finds a writable domain controller. Check whether the specified domain controller is currently operational. Display version information for the installed software. Specify the domain name or the global catalog for which you want to display information. Appendix A Using Centrify UNIX commands 305

306 Using adfixid 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 ajax.org ginger.ajax.org To display the host name for the global catalog server, type: adfinddomain $ zen.ajax.org To include the port number for the domain controller or global catalog, type: adfinddomain --format name --port ajax.org ginger.ajax.org:389 or: adfinddomain $ --port zen.ajax.org:3268 Understanding adfinddomain-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adfinddomain command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_NOT_OBTAIN_IP The command is unable to obtain the IP address for the server. 157 ERR_UNDETECT_SERVICE The command is unable to find the domain controller for the domain specified. You should verify the domain name, then try rerunning the adfinddomain command. Using adfixid The adfixid command can be used to resolve UID and GID conflicts and change the ownership of a local user s files to match the user and group IDs defined for the user in Active Directory. The basic syntax for the adfixid program is: adfixid [--commit] [--commit-all] [--report filename] [--usermap filename] [- -groupmap filename] [--id id_range] [--xdev] [--follow] [--nfs] [--undo] [-- restart] [--version] [--verbose] directory The adfixid command compares the local password database, for example, the local /etc/ passwd and /etc/group files, to the UNIX profile entries for the Centrify zone that are retrieved from Active Directory. The command generates a report of the local users and groups that have UIDs or GIDs that conflict with the information stored in Active Directory, in the following cases: Administrator s Guide for Linux and UNIX 306

307 Using adfixid A local user or group has the same local name and Active Directory name, but a different UID or GID; for example, the user gsmith has UID and GID 1006 locally, but 1007 in Active Directory. A local user or group and an Active Directory user or group with different names have the same UID or GID. For example, local user joe has UID and GID 1009 and Active Directory user jcool also has UID and GID After identifying conflicts, you can run adfixid with the --commit option to change the ownership of local users files and directories to match the user and group ID values defined in Active Directory for the zone, eliminating UID and GID conflicts. If you have mapped a local account to an Active Directory account with a different name, adfixid will add the local name to the report and suggest changing the UID, even though the UID is correct because the two names apply to the same user. For example, if you have mapped local user joe to Active Directory user jcool, adfixid will suggest changing joe s UID (1009) to something like so it does not conflict with jcool s UID. To accommodate this situation, you can use a mapping file to specify how the user and group names in the local database map to the user and group names in the UNIX profiles for the current zone. You can then run adfixid with the --usermap or --groupmap option to check for UID or GID conflicts and change file ownership while ignoring conflicts for local users or groups who are mapped to Active Directory users or groups with different names. For example, if your map file identifies the mapping between joe and jcool, joe will not appear on the conflict report. See the --usermap option and the examples for more information. By default, running the adfixid command simply lists the local users and groups that have UID or GID conflicts and require file ownership changes. If you run this command with the --commit option, adfixid searches local file systems for files owned by users defined in the /etc/passwd file, and changes the ownership and group information to match the information defined for the zone. If you run this command with the --commit-all option, adfixid also updates the /etc/passwd and /etc/group files to contain the new ID values. Note The local computer must be joined to an Active Directory domain and in a valid zone to perform most operations. This requirement is not necessary to generate a report with the --report option or to undo a previous operation with the --undo option. In addition, to run adfixid with the --commit, --commit-all, or --undo options, you must be logged in as root. Because of the operations it performs, running the adfixid command can take a significant period of time to complete its execution. Therefore, in most cases, you should limit the scope of directories to be traversed at any one time and run this command when there is minimal network traffic. Appendix A Using Centrify UNIX commands 307

308 Using adfixid Setting valid options You can use the following options with this command: Use this option -c, --commit -C, --commit-all -u, --usermap filename -g, --groupmap filename To do this Commit file ownership UID and GID changes to the file system. If you do not specify this option, by default, adfixid only displays a list of the users and groups that require ownership changes. Commit the file ownership UID and GID changes to the file system and update the local /etc/passwd and /etc/group files with the new UID and GID values, as needed. Specify the name of a file that shows any mapping between local UNIX user names and zone UNIX user names. This option is useful when user names have been rationalized in the Centrify zone but may not match the names in the local database file. The format of the user mapping file is: local_unix_name zone_unix_name When you run adfixid with this option, it ignores conflicts for local users who are mapped to Active Directory users with different names. You do not need to add entries for local UNIX user names that match a zone UNIX user name. If a name does not match any zone UNIX names, the name is ignored. If the UID for the ignored name conflicts with a zone UNIX user UID, the UID of the local UNIX user is changed to a value in the UID range set aside for conflict-resolution. For information about setting the value range for conflict resolution, see the --id option. Specify the name of a file that maps local UNIX group names to zone UNIX group names. This option is useful when group names have been rationalized in the Centrify zone but may not match the names defined in the local database file. The format of the group mapping file is: local_unix_group zone_unix_group When you run adfixid with this option, it ignores conflicts for local groups that are mapped to Active Directory groups with different names. You do not need to add entries for local UNIX group names that already match a zone UNIX group name. If a name does not match any zone UNIX group names, the name is ignored. If the GID for the ignored name conflicts with a zone UNIX group GID, the GID of the local UNIX group is changed to a value in the GID range set aside for conflict-resolution. For information about setting the value range for conflict resolution, see the --id option. Administrator s Guide for Linux and UNIX 308

309 Using adfixid Use this option -r, --report filename -i, --id id_range -x, --xdev -n, --nfs -f, --follow -R, --restart To do this Generate an audit log of every chown command that was executed by the adfixid command. When you specify the --report option, the filename parameter is required, though you can use a hyphen (-) as the filename to output information to standard out. You can generate the report at the same time as the --commit operation, or at any later time. Note This option is only valid at the same time you perform a --commit or --commit-all operation or after you have performed one of those operations. You cannot use this option to generate a preview report of changes that a --commit operation would perform. Use the adfixid command with no command line options to review conflicts prior to making file system changes. You can then use the --commit and -- report options to generate a report of the changes performed. For example: adfixid --commit --report chown_rpt1 Specify a range of values for assigning new UIDs or GIDs to use in resolving UID or GID conflicts. The id_range parameter can be of the form <start_value>-<end_value> to specify the start and end values of the range. For example: --id The default range is If you specify a single number, that value becomes the starting value for the range and the end value is MAXUID. If a local UNIX UID or GID conflicts with a zone UID or GID, the local value is mapped to a value in the specified range. For example, if a local UNIX user has a UID of 126 that conflicts with a zone UNIX user UID, the local UNIX user UID would be mapped to UID by default. If the target UID value of is already used in the zone, the next sequential value, 50127, is used instead. Prevent the adfixid command from running across file system mount points. By default, the adfixid command traverses all local, non-nfs, file system mount points. Traverse NFS directories. The adfixid command does not process NFS directories unless you specify this option. Specify that you want the adfixid command to follow symbolic links to update the target files and directories. By default, the adfixid command only updates the link file itself, if necessary, and does not traverse into symbolically-linked directories. Ignore the results of a previous run. By default, the adfixid command skips files that were changed by a previous run of the command. Using this option resets the adfixid audit log so that adfixid is not aware of what files were previously changed. If you have previously run adfixid and made changes the file owner but did not resolve conflicts between the /etc/passwd and /etc/ group files and Active Directory, using this option ignores the changes previously made and makes them again when the conflicts between the local files and Active Directory are detected. Appendix A Using Centrify UNIX commands 309

310 Using adfixid Use this option -U, --undo -v, --version -V, --verbose directory To do this Reverse the action of a previous --commit operation. All files that had the owner and/or group id changed are set back to their original values. If the /etc/passwd or /etc/group files were updated using a -- commit-all operation, this change is also reversed. Display version information for the installed software. Display the file and directory names are they are processed. This option is useful when running this command on a large file system, such as the root file system, so you can track its progress. If you specify this option, the adfixid command: Lists every file it examines. Reports every change of ownership performed for the files and directories examined. Lists any files or directories being skipped. Without this option, the adfixid command does not display its progress and may appear to stop running when it is processing a large number of files and directories on large file systems. Specify the directory or directories in which to start the search for the user files to be changed. By default, adfixid only searches local file systems, starting with the root (/) level of file system. You can, however, specify a network file system on the command line, if needed. You can use this parameter to change the file ownership for selected directories or if you want to change the file ownership in stages. For example, you may want to change the ownership for a limited number of directories before committing changes across the whole file system on a given computer. If you specify a network file system, such as an NFS or CIFS mount point, you should be sure that you do not run the command remotely on the same files from different computers. Running this command remotely from more than one computer may cause the file ownership changes to be overwritten with incorrect information. Note File ownership changes are logged in the audit file on a percomputer basis. If you run this command for a network file system, the change is recorded in the audit file on the local computer. If you run the command again from a second computer, that computer has no record that the file ownership has been previously changed. Examples of using adfixid To understand how to use the adfixid command, assume the local UNIX users defined in the local password database (/etc/passwd) are as follows: gsmith:x:1006:1006:george Smith:/home/gsmith:/bin/bash ballen:x:1007:1007:bob Allen:/home/ballen:/bin/csh joe:x:1009:1009:joe Cool:/home/jcool:/bin/bash kane:x:1226:1226:kane Lewis:/home/kane:/bin/bash jfrank:x:1345:1345:john Frank:/home/jfrank:/bin/bash The UNIX user profiles defined for the zone are: gsmith:x:1007:10000:george Smith:/home/gsmith:/bin/bash Administrator s Guide for Linux and UNIX 310

311 Using adfixid ballen:x:1006:10000:bob Allen:/home/ballen:/bin/csh jcool:x:1009:1009:joe Cool:/home/jcool:/bin/bash klewis:x:10226:10226:kane Lewis:/home/klewis:/bin/bash tyoung:x:1345:1345:ted Young:/home/tyoung:/bin/bash To simply see a list of the local users and groups with UID or GID conflicts requiring resolution, you can run the following command: adfixid This generates a report similar to the following: 4 user-id conflicts were found. Local UID Zone UID User gsmith ballen joe jfrank 2 group-id conflicts were found. Local GID Zone GID Name gsmith ballen If you want to make the file ownership changes and resolve user and group conflicts, you can run the following command: adfixid --commit The file ownership for the local user gsmith will be changed from UID and GID 1006 to UID and GID The file ownership for the local user ballen will be changed from UID and GID 1007 to UID and GID The local user joe appears as a UID conflict because the local UNIX user name is different from the zone UNIX user name. Similarly, the local user kane is be ignored because there is no mapping between the local UNIX user name and the zone UNIX user name. For these users, you would need to create and specify a user mapping file. The local user jfrank is not defined in the zone, but his local UID and GID conflicts with the user tyoung who has a profile defined in this zone. The adfixid command will assign a UID and GID from the temporary range, for example 51345, and change the ownership (chown) of all of files owned by the local user jfrank to that UID. To create a user mapping file, use a text editor and add an entry to map the local UNIX user account joe to the jcool zone UNIX user. For example: vi defaultzone_usermap Add an entry to map the local users to zone users as needed. For example: joe jcool kane klewis You can then run the adfixid command and specify the user mapping file. For example: adfixid --usermap defaultzone_usermap --commit Appendix A Using Centrify UNIX commands 311

312 Using adfixid This command will change the file ownership for the files owned by the local user kane to UID and GID The command will not change the files owned by the local user joe because once mapped there is no UID or GID conflict between the local UNIX user and the zone UNIX user. Understanding adfixid-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adfixid command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_ID_RANGE The UID or GID range you have specified is not large enough to accommodate the number of new UIDs or GIDs needed to resolve account conflicts. You should try rerunning the command with a larger range of values or with no ending UID or GID value. 157 ERR_LOAD_PASSWD_FILE The attempt to load the local password file failed. 158 ERR_LOAD_GROUP_FILE The attempt to load the local group file failed. 159 ERR_CANNOT_UNDO_CHANGES The attempt to undo changes made during a previous run of adfixid failed because the private log file used for recording the changes made could not be opened for reading. You should check the permissions on the log file and whether the account used to run the adfixid command has read permission for the file. 160 ERR_CANNOT_CREATE_REPORT The attempt to create a report of the changes by adfixid failed because the private log file could not be opened for reading. You should check the permissions on the log file and whether the account used to run the adfixid command has read permission for the file. 161 ERR_OPEN_LOG_TO_WRITE The attempt to open and write to the private log file failed. You should check the permissions on the log file and whether the account used to run the adfixid command has write permission for the file. 162 ERR_LOAD_USER_MAP The attempt to load the specified user mapping file failed. You should verify the mapping file exists in the location specified and that the account used to run the adfixid command has read permission for the file, then try rerunning the adfixid command. 163 ERR_LOAD_GROUP_MAP The attempt to load the specified group mapping file failed. You should verify the mapping file exists in the location specified and that the account used to run the adfixid command has read permission for the file, then try rerunning the adfixid command. 164 ERR_GENERATE_GROUP_MAP The attempt to map local group GIDs to Active Directory GIDs failed. 165 ERR_GENERATE_ID_MAP The attempt to map local user UIDs to Active Directory UIDs failed. 166 ERR_OPEN_DIR The attempt to open a directory failed. You may see this error if a specified target directory or subdirectory is not accessible of if the account used to run the adfixid command does not have permission to access one or more directories to be searched. Administrator s Guide for Linux and UNIX 312

313 Using adflush Using adflush The adflush command can be used to clear the cache on a local computer. Executing adflush with no options clears the Domain Controller (dc.cache) and Global Catalog (gc.cache) caches, authorization information and DNS queries (the equivalent of using the --objects, --auth, and --dns options). Executing adflush with no options also restarts the nscd daemon (pwgrd for HPUX). On Mac OS X, it flushes the system cache. The basic syntax for the adflush program is: adflush [option] Setting valid options You can use the following options with this command: Use this option -a, --auth -b, --bindings -d, --dns -e, --expire -f, --force -o, --objects -t, --trusts -H, --health -V, --verbose -v, --version To do this Remove DirectAuthorize information from the adclient authorization store cache. Force adclient to refresh its connections to domain controllers in the trusted domains in order to find more efficient ones or potentially to redistribute the connection load per server. Remove stored DNS information from the adclient local cache. Expire information for the domain controller and global catalog objects. Clear the adclient local cache of all data even if the Centrify UNIX agent is currently disconnected from Active Directory. Remove only domain controller and global catalog objects from the cache. This is the default if you do not specify any options. Refresh and replace trusted domain information by updating the /etc/ krb5.conf file. Removes system health history for the local computer. Display detailed information about the operation. Display version information for the installed software. Examples of using adflush The adflush command enables you to completely clear the cache at any time. This command can be useful when you want to force the Centrify UNIX agent to read new information from Active Directory, or when you want to remove obsolete data from the cache. You can also use this command as part of routine housekeeping to free up disc space. To clear the cache of information from the Active Directory domain controller and global catalog, you would type: adflush Appendix A Using Centrify UNIX commands 313

314 Using adid To display verbose output and force the local cache to be cleared when the Centrify UNIX agent (adclient) is running in disconnected mode without access to Active Directory, you would type: adflush --verbose --force Using adid The adid command can be used to display the real and effective UIDs and GIDs for the current user or a specified user. The basic syntax for the adid program is: adid [option] [username uid] The adid command is intended as a replacement for the standard id program to look up user and group information for a specified user. For Active Directory users, the adid command is more efficient than the standard id program because it can request the user s group membership list directly through the Centrify UNIX agent, resulting in better performance. For the standard id program, requesting a user s group membership requires the program to search through all the groups on the system to find which groups include the user as a member. If you run the adid command and specify a user who is not an Active Directory user, the adid command transfers the request to the local id program with the same arguments you have specified. Setting valid options You can use the following options with this command: Use this option To do this -a Display all of the group IDs for the specified user or the current user if no user name or user ID is specified. Note This option is provided to support compatibility with other versions of the program. The information adid displays with this option is the same as the information displayed without this option. -n, --name -u, --user --help Display only the effective user name for the specified user or the current user. You must include the --user (or -u) option on the command line to use this option. Display only the effective user ID for the specified user or the current user if no user name or user ID is specified. Display usage information for the command. Examples of using adid You can use the adid command to display user and group information for the current user or any specified user. For example, to display the user name, default group, and complete group membership for the current user, you can type: adid uid=505(alan) gid=100(users) groups=100(users),700(oracle),507(testexpert) Administrator s Guide for Linux and UNIX 314

315 Using adkeytab To display the user ID and group ID for a specific user name, you can type: adid alan uid=505(alan) gid=100(users) To display the user ID and group ID for a specific user ID, you can type: adid 505 uid=505(alan) gid=100(users) To display only the user ID for a specific user name, you can type: adid --user sloane 506 Using adkeytab The adkeytab command allows you to create and manage Kerberos key tables (*.keytab files) and coordinate changes with the Kerberos key distribution center (KDC) provided by Active Directory. With the adkeytab command you can: Create a new service account and key table Add service principals to a key table Select an existing account to adopt for a key table Change the password for a computer or service account Reset a key table (use to reset a key table that is corrupt or out of sync with the KDC in Active Directory) Delete service principals from an account Delete a service account from Active Directory and remove its key table and all related keys from the centrifydc.conf file. Note The specific options you can use on the command line for adkeytab depend on the task you want to perform. See the appropriate section for information about which options to use for each task. In addition to the task-specific options, however, you can use the [-V, -- verbose] option in conjunction with any task to display detailed information about the operations being performed for diagnostic purposes. Understanding Kerberos key tables In a Kerberos environment, each computer has at least one Kerberos key table file stored on its local disk. This keytab file lists Kerberos service principals, such as FTP (FTP/ host@realm), that are offered by the computer and provides at least one key for each of those service principals. If a computer hosts multiple Kerberos-enabled services, it may have more than one keytab file on its local disk. For example, a computer may provide Kerberos authentication for database services. The database service would then require its own keytab file on the host computer. Appendix A Using Centrify UNIX commands 315

316 Using adkeytab A keytab file contains two types of entries: One keytab entry specifies the service account that owns the key table. Other entries specify the service principals offered by the account. The service account is a special user or computer account set up in Active Directory to handle requests for the Kerberos-enabled service. Each Kerberos-enabled service on a computer requires its own service account in Active Directory, and that service account always owns the keytab file for the Kerberos-enabled service. The service principal entries in the keytab file contain: The key version number that specifies which version of the Kerberos key this is. A time stamp that specifies the date and time when the entry was created. The name of the service principal. The type of encryption used for the key. The key itself. The keys in the key table are generated each time the password for the service account changes. When the service account password changes, a new key is generated for each service principal in the table and stored as a new keytab entry with an updated key version number. Older versions of the keys are retained in the key table as separate entries with earlier version numbers up to a specified number of versions, after which they re removed from the table. In addition, each service principal has at least one entry for each type of key encryption it supports. Therefore, a single service principal typically has many entries in the key table. In its role as the Kerberos key distribution center (KDC), Active Directory has a computer account for each computer in the network and stores service principals and keys for each computer. It also has a service account for each service offered on a computer, and stores the service principals and keys for each service with the service account. When you add a UNIX computer to an Active Directory domain, the adjoin command creates a computer account in Active Directory and a local keytab file on the computer that adclient can use for authentication. The centrifydc.conf configuration file specifies the Kerberos service principals the computer offers, the location for the computer s keytab files, and the number of key versions maintained for each service principal. After the computer has joined the domain, adclient manages the computer s computer account and its associated keytab file, changing the account password and the Kerberos keys at a set interval. The adclient process does not, however, maintain keytab files for service accounts, add new keytab files, or notify Active Directory of keytab changes for service accounts. To create and manage the keytab files for service accounts, you can use the adkeytab command. The adkeytab program then uses adclient to communicate the keytab information for service accounts to Active Directory so that it can be synchronized in the KDC. Administrator s Guide for Linux and UNIX 316

317 Using adkeytab Understanding authentication and permissions for using adkeytab Executing adkeytab requires specific permissions depending on the operation. In addition, adding, modifying, or deleting Active Directory service account objects requires an authenticated LDAP connection. When executing adkeytab the user can supply credentials in any of the following ways: Supply the name and password of an Active Directory user with sufficient privileges to add, modify or delete the service account object. You can use any of the following adkeytab forms to supply a username and password for authentication: adkeytab adkeytab assumes the user is the root administrator and prompts for a password. For security, the password you enter is not echoed on the screen. adkeytab -u username adkeytab prompts for the password for the specified user. The password you enter is not echoed on the screen. adkeytab -p adkeytab assumes the user is the root administrator. Be aware that in this form of adkeytab, the password is visible on the command line. adkeytab -u -p Be aware that in this form of adkeytab, the password is visible on the command line. Use the Kerberos kinit utility to build up a credential cache for the root user so authentication is automatic. Typically, you use kinit when performing a series of operations that requires Kerberos credentials. By default, kinit is installed with installation of the agent on a computer. See the kinit(1) man page for more information. Specify Direct Control's computer account credentials for LDAP authentications. Typically, you use Direct Control's computer account credentials if adkeytab operations are being performed on Direct Control s own computer service account and the system keytab. Use the following form of adkeytab: adkeytab -m Understanding object permissions for using adkeytab To create or delete new service accounts, you need permission to the container in which you are creating or deleting the account, as follows: To create a new service account, you need Create account objects permission. To delete a service account, you need Delete account objects permission. Appendix A Using Centrify UNIX commands 317

318 Using adkeytab In addition, each adkeytab operation requires specific permissions to Active Directory attributes of the object being created or modified. For example, to add an SPN, you need read permission to the following attributes: objectcategory cn samaccountname userprincipalname msds-keyversionnumber and read/write permission to the serviceprincipalname. The following table summarizes the permissions you need for each type of adkeytab operation Operation Permission / Attribute Adopt Adopt (local) Adopt (Force) Modify SPN Modify UPN Change Passwd Reset Passwd objectcategory R R R R R R R useraccountcontrol RW RW cn R R R R R R R samaccountname R R R R R R R userprincipalname R R R R RW R R serviceprincipalname R R RW RW R R msds-keyversionnumber R R R R R R R changepassword W W W W restpassword W You can verify or modify permissions to an Active Directory object in a number of ways, including: Open the Properties page for the object in Active Directory Users and Computers and use the Security tab to set Read and Write permissions for specific attributes. See Microsoft TechNet: Assign, change, or remove permissions on Active Directory objects or attributes for more information. Use the dsacls command-line utility to set attribute permissions for the object. See Microsoft TechNet: Dsacls Overview for more information. Create a new service account and key table You can use the adkeytab command to create new service accounts for a computer. When you create a new service account, adkeytab also generates a keytab file for the new account on the local computer, and notifies the KDC in Active Directory of the new service account and keys for the computer. Administrator s Guide for Linux and UNIX 318

319 Using adkeytab The basic syntax for creating new service accounts and keytab files and synchronizing the information with Active Directory using the adkeytab command is: adkeytab --new --principal principal --keytab filename --container containerdn [options] account-name Setting options for creating a new service account and key table You can use the following options to perform this task: Use this option -n, --new -P, --principal principal -i, --ignore To do this Create a new service account in Active Directory and a new key table for the account that is stored locally as a keytab file. If you use this option to generate a new service account and keytab file, adkeytab notifies the KDC in Active Directory of the key table contents. If you use this option, you must also specify a keytab file name using the --keytab option and an account-name that is unique in the current domain. Specify a service principal to add to the new key table. You must specify at least one service principal when creating a new service account. To specify multiple service principals, use this option multiple times. For principal, type the service type of the service principal you want to add. You can specify the principal by: Service type alone (http) Service type and the host name or alias (http/firefly) Service type and the fully-qualified domain name (http/ firefly.arcade.com) If you use the service type alone, the adkeytab command generates the full principal name by expanding the name to include the account name at this computer, creating a fully-qualified domain name for the service principal account. For example, if you add the service principal http for service account firefly in domain arcade.com, adkeytab generates two service principals for the keytab file: http/[email protected] http/[email protected] If you specify the service type with either a long or short host name, the adkeytab command will only generate the exact principal name specified. Note If the service account name is different from the host name, you should have a DNS alias for the service account name that resolves to the host name of the computer. This allows you to have multiple service principals of the same type on the same computer, for example, multiple database services. Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Appendix A Using Centrify UNIX commands 319

320 Using adkeytab Use this option -K, --keytab filename -c, --container containerdn -e, --encryption-type etype To do this Specify the name and location of the new keytab file to create. For filename, specify either the relative or full path to the file you are creating. For example: --keytab /etc/krb5/test.keytab Specify the Active Directory name of the container (CN) or organizational unit (OU) into which the new service account should be placed. You can specify the containerdn by: Canonical name (ajax.org/unix/services) Fully distinguished name (cn=services, cn=unix,dc= ajax,dc=org) Relative distinguished name without the domain suffix(cn=services,cn=unix). For example, if you want to place the account in the UNIX/Services container within the ajax.org domain using the canonical name, you could specify: --container ajax.org/unix/services Note The account used to run the adkeytab command must have permission to add objects to the container or organizational unit you specify. Specify an encryption type to use in generating keys for each of the service principals you specified with the --principal option. Alternatively, you can use the --des option in place of the -- encryption-type option to automatically generate des-cbc-crc and des-cdc-md5 keys. Using the --des option is recommended if you configuring keytab entries for Oracle s Advanced Security Option or services that support older versions of Kerberos. If you use the --des option, the --encryption-type parameter is ignored. If you use the --encryption-type parameter, each etype you specify generates a key table entry for a principal/encryption type combination. For example, if you specify two service principals and one encryption type, adkeytab generates a key table entry for each service principal with a key that uses the selected encryption type. To specify multiple encryption types for a service principal, use this option multiple times. For example, if you specify one service principal and three different encryption types, adkeytab generates a separate key table entry for each encryption type for the service principal. Administrator s Guide for Linux and UNIX 320

321 Using adkeytab Use this option To do this If you do not specify an encryption type in the command line, the encryption types defined in the centrifydc.conf file are used. The default encryption types supported are: Windows 2000 server and Windows Server 2003: arcfour-hmacmd5, des-cbc-md5, and des-cbc-crc. Windows Server 2008 domain functional level supports these additional types: aes128-cts and aes256-cts. Although you can specify these types in an environment other than 2008 domain functional level, they are not useful and may cause extra network round trips during the authentication process. Note If you specify an encryption type that is not listed as a permitted encryption type in the centrifydc.conf file, the key table entry will not be created and an error is displayed. You should verify that the encryption types you want to use are listed for the adclient.krb5.permitted.encryption.types configuration parameter. -T, --trust -k, --des -d, --domain domain -U, --upn userprincipalname Set the Trust for delegation option in Active Directory for the new service account. Trusting an account for delegation allows the account to perform operations on behalf of other accounts on the network. For example, if the new service account is trusted for delegation, it can forward ticket-granting tickets and perform other delegated actions. Setting this option may require the adkeytab command to run using an account with administrator permission. Specify that all service principals for this account will use the Data Encryption Standard (DES) for keys. Setting this option enables the Use DES encryption types for this account flag in the useraccountcontrol attribute of the service account. You can use this option in place of the --encryption-type option to automatically generate des-cbc-crc and des-cdc-md5 keys. Using the --des option is recommended if you configuring keytab entries for Oracle s Advanced Security Option or services that support older versions of Kerberos. Note If you use the --des option, the --encryption-type parameter is ignored. Specify the domain in which this service account should be created. This option is used to create accounts in a domain other than the currently joined domain. If you do not specify this option, adkeytab creates the new service account in the currently joined domain by default. Set the userprincipalname attribute for the account in Active Directory. Note For user service accounts, you only need to set this option if you want the userprincipalname to be different from the default user@realm setting. Appendix A Using Centrify UNIX commands 321

322 Using adkeytab Use this option -f, --force -m, --machine -u, --user -p, --password userpassword -S, --samname To do this Overwrite an existing Active Directory object with the new account information. This option removes any existing service principals, keytab files and centrifydc.conf entries related to the specified accountname, in preparation for creating a new service account and key table. Note This option is not required for precreated accounts that are inactive. This option is only required if the existing account is active and needs to be replaced. Use the Active Directory computer account credentials generated by adclient to execute the adkeytab command. This option can be used in place of user credentials if the computer account has been granted permission to update its own account information. Note Using the local computer s credentials to update Active Directory requires local root permission when executing the adkeytab command. Specify an Active Directory user other than the current user to execute the adkeytab command. The user must have sufficient rights to add an account object to the domain. You must use the username@domain format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, adkeytab uses the current user s Kerberos credentials by default. If there are no cached credentials for the current user, adkeytab uses the Administrator user account. Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Specify a pre-windows 2000 account name for the object in Active Directory. This option sets the samaccountname attribute for the Active Directory object you are creating. You should use this option: If the account-name you are using for the object exceeds 20 characters. If you want the samaccountname attribute for the object to be different from the account-name. Note The samaccountname attribute (also known as the pre-windows 2000 name) can be a maximum of 20 characters. The attribute must be unique within the Active Directory forest. Administrator s Guide for Linux and UNIX 322

323 Using adkeytab Use this option -s, --server hostname -g, --gc hostname -V, --verbose account-name To do this Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Specify the global catalog computer you want to search to check for duplicate samaccountname attributes. Using this option enables you to avoid replication delays. Display detailed information about the operation being performed. Create the specified account-name object in Active Directory. You must specify an account-name that is unique in the current domain. In addition, the account-name must be the last argument specified in the command line. Examples for creating new service accounts and key tables To create a new DES-encrypted service account and accompanying key table, you would type a command similar to the following: adkeytab --new --keytab /etc/krb5/mydatabase.keytab --principal data1 -- principal data2 --des --container ajax.org/users --user oracleadm mydatabase This command example uses the Oracle administrator account, oracleadm, to create a dedicated service account named mydatabase for an Oracle server that offers the Kerberosenabled services data1 and data2. The command also creates a keytab file for the service account at /etc/krb5/mydatabase.keytab and adds the data1 and data2 service principals to the new keytab file, and creates DES-encoded keys for each service principal. If you were to run this command, you would need to specify the password for the oracleadm account when prompted for the command to complete its execution. When a new keytab file is created successfully, entries for its service principals are also added to the centrifydc.conf file. For example, the following command: adkeytab --new --keytab /etc/krb5/mydatabase.keytab --container "arcade.net/ UNIX/Accounts" --principal hr_db --principal ap_db --encryption-type des-cbcmd5 --user oracleadm mydatabase adds the following lines to the /etc/centrifydc/centrifydc.conf file: adclient.krb5.managed.accounts: mydatabase mydatabase.krb5.keytab: /etc/krb5/mydatabase.keytab mydatabase.krb5.service.principals: hr_db ap_db mydatabase.krb5.tkt.encryption.types.hr_db: des-cbc-md5 mydatabase.krb5.tkt.encryption.types.ap_db: des-cbc-md5 Add service principals to a key table You can use the adkeytab command to add one or more service principals to an existing key table and notify the KDC in Active Directory of the new service principals for the computer or service account. The basic syntax for adding new service principals and synchronizing the information with Active Directory using the adkeytab command is: adkeytab --addspn --principal principal [options] [account-name] Appendix A Using Centrify UNIX commands 323

324 Using adkeytab Setting options for adding service principals to a key table You can use the following options to perform this task: Use this option -a, --addspn -P, --principal principal -E, --entries kvno To do this Add a service principal to an existing account in Active Directory and generate the appropriate keys for the new service principal in the account s keytab file. If you don't specify an account-name, the adkeytab command adds the service principal to the computer account in the currently joined domain. Specify a service principal to add to the specified key table. You must specify at least one service principal. To specify multiple service principals, use this option multiple times. For principal, type the service type of the service principal you want to add. You can specify the principal by: Service type alone (http) Service type and the host name or alias (http/firefly) Service type and the fully-qualified domain name (http/ firefly.arcade.com) If you use the service type alone, the adkeytab command then generates the full principal name by expanding the short name to include the account name at this computer, creating a fully-qualified domain name (FQDN) for the service principal account. For example, if you add the service principal http for service account firefly in domain arcade.com, adkeytab generates two service principals for the keytab file: http/[email protected] http/[email protected] Note If the service account name is different from the host name, you should have a DNS alias for the service account name that resolves to the host name of the computer. This allows you to have multiple service principals of the same type on the same computer, for example, multiple database services. Specify the number of password hash entries (key version numbers) to keep in the keytab file. For the kvno, specify a positive integer between 1 and 253. If you omit the --entries parameter, the default number is 3. Note that --entries is only relevant for 2003 or newer key distribution centers (KDC). For Windows 2000, adkeytab manufactures key version numbers as long as the krb5.generate.kvno configuration parameter is true (which is the default setting). In the following circumstances the entries setting is ignored and only one password hash entry is kept: If the KDC is Windows 2000 and the centrifydc.conf parameter krb5.generate.kvno is set to false. If the KDC is Windows 2003 or newer but the dsheuristics attribute is set to For more information about the dsheuristics bit see Administrator s Guide for Linux and UNIX 324

325 Using adkeytab Use this option -e, --encryption-type etype To do this Specify an encryption type to use in generating keys for each service principal you specified with the --principal option. Alternatively, you can use the --des option in place of the -- encryption-type option to automatically generate des-cbc-crc and des-cdc-md5 keys. Using the --des option is recommended if you configuring keytab entries for Oracle s Advanced Security Option or services that support older versions of Kerberos. If you use the --des option, the - -encryption-type parameter is ignored. If you use the --encryption-type parameter, each etype you specify generates a key table entry for a principal/encryption type combination. For example, if you specify two service principals and one encryption type, adkeytab generates a key table entry for each service principal with a key that uses the selected encryption type. To specify multiple encryption types for a service principal, use this option multiple times. For example, if you specify one service principal and three different encryption types, adkeytab generates a separate key table entry for each encryption type for the service principal. -m, --machine If you do not specify an encryption type in the command line, the encryption types defined in the centrifydc.conf file are used. The default encryption types supported are Windows 2000 server and Windows Server 2003: arcfour-hmac-md5, des-cbc-md5, and des-cbc-crc. Windows Server 2008 domain functional level supports these additional types: aes128-cts and aes256-cts. Although you can specify these types in an environment other than 2008 domain functional level, they are not useful and may cause extra network round trips during the authentication process. Note If you specify an encryption type that is not listed as a permitted encryption type in the centrifydc.conf file, the service principal will not be added and an error is displayed. You should verify that the encryption types you want to use are listed for the adclient.krb5.permitted.encryption.types configuration parameter. Use the Active Directory computer account credentials generated by adclient to execute the adkeytab command. This option can be used in place of user credentials if the computer account has been granted permission to update its own account information. Note Using the local computer s credentials to update Active Directory requires local root permission when executing the adkeytab command. Appendix A Using Centrify UNIX commands 325

326 Using adkeytab Use this option -u, --user Specify an Active Directory user other than the current user to execute the adkeytab command. The user must have sufficient rights to add a service principal to the account object in Active Directory. You must use the username@domain format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, adkeytab uses the current user s Kerberos credentials by default. If there are no cached credentials for the current user, adkeytab uses the Administrator user account. -p, --password userpassword -i, --ignore -K, --keytab filename -d, --domain domain Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Specify the name and location of the keytab file to add. For filename, you can specify either the relative or full path to the file. Specify the domain in which this service principal should be added. If you do not specify this option, adkeytab uses the currently joined domain by default. -U, --upn userprincipalname Set the userprincipalname attribute for the account in Active Directory. Note For user service accounts, you only need to set this option if you want the userprincipalname to be different from the default user@realm setting. -s, --server hostname -V, --verbose account-name To do this Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Display detailed information about the operation being performed. Specify the account-name to which you are adding a service principal. If you don t specify an account-name, adkeytab adds the service principal to the computer account object in the currently joined domain. If you specify the account-name, it must be the last argument in the command line. Administrator s Guide for Linux and UNIX 326

327 Using adkeytab Examples for adding service principals a key table To add a new DES-encrypted service principal for oracle to the key table that belongs to the service account mydatabase, you would type a command similar to the following: adkeytab --addspn --principal oracle --des mydatabase To add a DES-encrypted service principal for Oracle databases named oracle_d1 and oracle_d2 to the computer account key table in the currently joined domain: adkeytab --addspn --prinicipal oracle_d1 --prinicipal oracle_d2 --encryptiontype des-cbc-md5 Select an existing account to adopt for a key table You can use the adkeytab command with the --adopt option to have the Centrify UNIX agent take over the management of keytab files for an existing account in Active Directory. This option creates the local keytab file for the account and adds entries for any existing service principal names associated with the account to the centrifydc.conf file. You can also specify additional service principal names and encryption types. The basic syntax for adopting the service principals associated with an existing account and synchronizing the information with Active Directory using the adkeytab command is: adkeytab --adopt --keytab filename [options] account-name Setting options for adopting existing service principals You can use the following options to perform this task: Use this option -A, --adopt -i, --ignore -K, --keytab filename To do this Add the appropriate keytab and centrifydc.conf entries to adopt an existing account and its service principals for management through the Centrify UNIX agent. Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Specify the name and location of the keytab file for the account. Appendix A Using Centrify UNIX commands 327

328 Using adkeytab Use this option -P, --principal principal -e, --encryption-type etype To do this Specify an additional service principal for the account in the key table. This option is not required as long as the existing account has at least one service principal already defined. To specify multiple service principals, use this option multiple times. For principal, type the service type of the service principal you want to add. You can specify the principal by: Service type alone (http) Service type and the host name or alias (http/firefly) Service type and the fully-qualified domain name (http/ firefly.arcade.com) If you use the service type alone, the adkeytab command then generates the full principal name by expanding the short name to include the account name at this computer, creating a fully-qualified domain name (FQDN) for the service principal account. For example, if you add the service principal http for service account firefly in domain arcade.com, adkeytab generates two service principals for the keytab file: http/[email protected] http/[email protected] Note If the service account name is different from the host name, you should have a DNS alias for the service account name that resolves to the host name of the computer. This allows you to have multiple service principals of the same type on the same computer, for example, multiple database services. Specify an encryption type to use in generating keys for each service principal you specified with the --principal option. Alternatively, you can use the --des option in place of the -- encryption-type option to automatically generate des-cbc-crc and des-cdc-md5 keys. Using the --des option is recommended if you configuring keytab entries for Oracle s Advanced Security Option or services that support older versions of Kerberos. If you use the --des option, the --encryption-type parameter is ignored. If you use the --encryption-type parameter, each etype you specify generates a key table entry for a principal/encryption type combination. For example, if you specify two service principals and one encryption type, adkeytab generates a key table entry for each service principal with a key that uses the selected encryption type. To specify multiple encryption types for a service principal, use this option multiple times. For example, if you specify one service principal and three different encryption types, adkeytab generates a separate key table entry for each encryption type for the service principal. Administrator s Guide for Linux and UNIX 328

329 Using adkeytab Use this option -m, --machine -u, --user To do this If you do not specify an encryption type in the command line, the encryption types defined in the centrifydc.conf file are used. The default encryption types supported are: Windows 2000 server and Windows Server 2003: arcfour-hmacmd5, des-cbc-md5, and des-cbc-crc. Windows Server 2008 domain functional level supports these additional types: aes128-cts and aes256-cts. Although you can specify these types in an environment other than 2008 domain functional level, they are not useful and may cause extra network round trips during the authentication process. Note If you specify an encryption type that is not listed as a permitted encryption type in the centrifydc.conf file, the key table entry will not be created and an error is displayed. You should verify that the encryption types you want to use are listed for the adclient.krb5.permitted.encryption.types configuration parameter. Use the Active Directory computer account credentials generated by adclient to execute the adkeytab command. This option can be used in place of user credentials if the computer account has been granted permission to update its own account information. Note Using the local computer s credentials to update Active Directory requires local root permission when executing the adkeytab command. Specify an Active Directory user other than the current user to execute the adkeytab command. The user must have sufficient rights to read the Active Directory account object and update the useraccountcontrol attribute, if necessary. If you are specifying additional service principal names, the user must also have sufficient privileges to update the account's serviceprincipalname attribute. You must use the username@domain format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, adkeytab uses the current user s Kerberos credentials by default. If there are no cached credentials for the current user, adkeytab uses the Administrator user account. Appendix A Using Centrify UNIX commands 329

330 Using adkeytab Use this option -p, --password userpassword -f, --force -l, --local -w, --newpassword newpassword -T, --trust -k, --des To do this Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Overwrite an existing Active Directory object with the new account information. This option removes any existing service principals, keytab files and centrifydc.conf entries related to the specified account-name, in preparation for creating a new service account and key table. Note This option is not required for precreated accounts that are inactive. This option is only required if the existing account is active and needs to be replaced. Update the password hashes in the local keytab file without changing the password in Active Directory. If you use this option, you must also specify the password value with the --newpassword option. This option can be useful in cluster environments where you run adkeytab to force a password change on the Active Directory object and the local keytab on a master server, then run adkeytab with the --change-password and --local options on the backup computers to synchronize the new password in the keytab files on those computers. Specify a new password to substitute for the old password. If you do not specify this option, adkeytab generates a random password. Set the Trust for delegation option in Active Directory for the new service account. Trusting an account for delegation allows the account to perform operations on behalf of other accounts on the network. For example, if the new service account is trusted for delegation, it can forward ticket-granting tickets and perform other delegated actions. Setting this option may require the adkeytab command to run using an account with administrator permission. Specify that all service principals for this account will use the Data Encryption Standard (DES) for keys. Setting this option enables the Use DES encryption types for this account flag in the useraccountcontrol attribute of the service account. You can use this option in place of the --encryption-type option to automatically generate des-cbc-crc and des-cdc-md5 keys. Using the --des option is recommended if you configuring keytab entries for Oracle s Advanced Security Option or services that support older versions of Kerberos. Note If you use the --des option, the --encryption-type parameter is ignored. Administrator s Guide for Linux and UNIX 330

331 Using adkeytab Use this option -d, --domain domain -U, --upn userprincipalname -s, --server hostname -V, --verbose account-name To do this Specify the domain in which this service principal should be added. If you do not specify this option, adkeytab uses the currently joined domain by default. Set the userprincipalname attribute for the account in Active Directory. Note For user service accounts, you only need to set this option if you want the userprincipalname to be different from the default setting. Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Display detailed information about the operation being performed. Specify the existing account-name that you want to manage keytab entries for using the Centrify UNIX agent. If you don t specify an account-name, adkeytab adopts the service principals associated with the computer account object in the currently joined domain. If you specify the account-name, it must be the last argument in the command line. Examples for adopting an existing account To adopt the existing service principals for the existing service account name oracle_acct, you could type a command similar to this: adkeytab --adopt --user oracleadm --keytab /etc/krb5/oracle_hr.keytab oracle_acct In a cluster environment, you can use adkeytab --new to create a new account principal on the primary cluster server and set its password to a known value. You can then run adkeytab --adopt with the --local and --newpassword options on all of the other computers in the cluster to create a local copy of the keytab file. For example: adkeytab --adopt --local --newpassword password --user oracleadm --keytab / etc/krb5/oracle_hr.keytab oracle_acct After running this command, all of the computers in the cluster are synchronized with the same password. Change the password for a computer or service account You can use the adkeytab command to change the password for a service or computer account. If you use adkeytab to change the password for an account, it also generates new keys for the account s service principals, writes the new keys to the account s key table, and notifies Active Directory of the changed password and new keys. The basic syntax for changing an account password and synchronizing the information with Active Directory using the adkeytab command is: adkeytab --change-password [options] [account-name] Appendix A Using Centrify UNIX commands 331

332 Using adkeytab Setting options for changing the computer or service account password You can use the following options to perform this task: Use this option -C, --change-password -l, --local -w, --newpassword newpassword -m, --machine -u, --user -p, --password userpassword To do this Change the password for a specified account-name. Using this option generates new keys in the keytab file for the specified account-name, and notifies the KDC in Active Directory of the change. Update the password hashes in the local keytab file without changing the password in Active Directory. If you use this option, you should also specify the password value with the --newpassword option. This option can be useful in cluster environments where you run adkeytab to force a password change on the Active Directory object and the local keytab file on a master server, then run adkeytab with the --change-password and --local options on the backup computers to synchronize the new password in the keytab files on those computers. Specify a new password to substitute for the old password. If you do not specify this option, adkeytab generates a random password. Use the Active Directory computer account credentials generated by adclient to execute the adkeytab command. This option can be used in place of user credentials if the computer account has been granted permission to update its own account information. Note Using the local computer s credentials to update Active Directory requires local root permission when executing the adkeytab command. Specify an Active Directory user other than the current user to execute adkeytab. The user must have sufficient rights to read the computer account password. You must use the username@domain format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, the adkeytab command uses the current user s Kerberos credentials by default. If there are no cached credentials, the adkeytab command uses the Administrator user account. Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Administrator s Guide for Linux and UNIX 332

333 Using adkeytab Use this option -i, --ignore -K, --keytab filename -d, --domain domain -s, --server hostname -V, --verbose account-name To do this Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Specify the name and location of the keytab file for the account. Specify the domain in which this service principal should be added. If you do not specify this option, adkeytab uses the currently joined domain by default. Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Display detailed information about the operation being performed. Specify the account-name for which you are changing the password. If you don't specify an account-name, the adkeytab command changes the password of the computer account object for the local computer in the currently joined domain. If you specify the accountname, it must be the last argument in the command line. Examples for changing the password To change the password for the computer account mission-sf in the currently joined domain to use a new randomly-generated password, you would type a command similar to the following: adkeytab -C To explicitly set the password for the service account mysql-sf in Active Directory, you would type a command similar to the following: adkeytab --change-password --newpassword miles8! mysql-sf Note Single quotes are required around the password in this example because the password contains a special character that would be misinterpreted by the UNIX shell. Reset a key table You can use adkeytab to reset a key table when it is out of synchronization with the KDC in Active Directory. The --reset option is typically used to reset the service account password to a known value (up to the first 14 characters of its common name) when the password hash for the service account is not the same in the application s keytab file as the password hash in the KDC. To use the --reset option, you must provide credentials for an account with permission to perform the password modification on the Active Directory object. Appendix A Using Centrify UNIX commands 333

334 Using adkeytab Note If the Centrify UNIX agent is running in disconnected mode because of a password problem, the computer account credentials are invalid and cannot be used to reset the service account password. The basic syntax for resetting a key table and synchronizing the information with Active Directory using the adkeytab command is: adkeytab --reset [options] [account-name] Running adkeytab with the --reset option resets the current password for the computer account that is stored in Active Directory, regenerate keys for the account s service principals, writes those keys into the account s keytab file, then reports the keys to the KDC in Active Directory. Setting options for resetting a key table You can use the following options to perform this task: Use this option -r, --reset -i, --ignore -u, --user username[@domain] -p, --password userpassword To do this Reset an account s key table and synchronize its contents with the key distribution center in Active Directory. Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Specify an Active Directory user other than the current user to execute adkeytab. The user must have sufficient rights to read the computer account password. You must use the username@domain format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, the adkeytab command uses the current user s Kerberos credentials by default. If there are no cached credentials, the adkeytab command uses the Administrator user account. Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Administrator s Guide for Linux and UNIX 334

335 Using adkeytab Use this option -d, --domain domain -s, --server hostname -V, --verbose account-name To do this Specify the domain in which this service principal should be added. If you do not specify this option, adkeytab uses the currently joined domain by default. Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Display detailed information about the operation being performed. Specify the account-name for which you are resetting the key table. If you don't specify an account-name, the adkeytab command resets the key table for the local computer account object in the currently joined domain. If you specify the account-name, it must be the last argument in the command line. Examples for resetting a key table To reset the key table that belongs to the service account mydatabase, you would type a command similar to the following: adkeytab --reset mydatabase To specify an Active Directory user account that is not a member of the same domain as the currently joined domain: adkeytab --reset --user [email protected] mydatabase You are then prompted to provide the password for the [email protected] account. Delete service principals from an account You can use the adkeytab command to delete a service principal from a service account and remove its keys from the key table. The basic syntax for removing service principals and synchronizing the information with Active Directory using the adkeytab command is: adkeytab --delspn --principal principal [options] [account-name] Appendix A Using Centrify UNIX commands 335

336 Using adkeytab Setting options for deleting service principals You can use the following options to perform this task: Use this option -x, --delspn -P, --principal principal -m, --machine -u, --user To do this Remove a service principal from an existing account in Active Directory and remove its keys from the account s keytab file. Specify a service principal to remove from the specified key table. You must specify at least one service principal. To specify multiple service principals, use this option multiple times. For principal, type the service type of the service principal you want to delete. You can specify the principal by: Service type alone (http) Service type and the host name or alias (http/firefly) Service type and the fully-qualified domain name (http/ firefly.arcade.com) If you use the service type alone, the adkeytab command removes all service principal names that start with the specified service type. If you specify the service type with either a long or short host name, the adkeytab command will only remove the exact principal name specified. Note If the service account name is different from the host name, you should have a DNS alias for the service account name that resolves to the host name of the computer. This allows you to have multiple service principals of the same type on the same computer, for example, multiple database services. Use the Active Directory computer account credentials generated by adclient to execute the adkeytab command. This option can be used in place of user credentials if the computer account has been granted permission to update its own account information. Note Using the local computer s credentials to update Active Directory requires local root permission when executing the adkeytab command. Specify an Active Directory user other than the current user to execute the adkeytab command. The user must have sufficient rights to delete a service principal from the account object in Active Directory. You must use the username@domain format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, adkeytab uses the current user s Kerberos credentials by default. If there are no cached credentials for the current user, adkeytab uses the Administrator user account. Administrator s Guide for Linux and UNIX 336

337 Using adkeytab Use this option -p, --password userpassword -i, --ignore -K, --keytab filename -d, --domain domain -s, --server hostname -U, --upn userprincipalname -V, --verbose account-name To do this Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Specify the name and location of the keytab file for the account. Specify the domain in which this service principal should be added. If you do not specify this option, adkeytab uses the currently joined domain by default. Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Specify the userprincipalname attribute for the account in Active Directory. Note For user service accounts, you only need to set this option if you want the userprincipalname to be different from the default user@realm setting. Display detailed information about the operation being performed. Specify the account-name from which you are removing a service principal. If you don t specify an account-name, adkeytab removes the service principal from the computer account object in the currently joined domain. If you specify the account-name, it must be the last argument in the command line. Examples for deleting service principals from an account To remove the service principal oracle_d1 from the key table that belongs to the service account berlin_db, you would type a command similar to the following: adkeytab --delspn --principal oracle_d1 berlin_db Delete a service account You can use the adkeytab command to delete a service account from Active Directory. Deleting a service account removes the account object from Active Directory, removes the Appendix A Using Centrify UNIX commands 337

338 Using adkeytab key table for the account from the local computer, and removes all keys related to the account from the centrifydc.conf file. If any of the items to be deleted is not found, the command prompts you to confirm whether you want to proceed with the delete operation for the items found. For example, if the account object is not found in Active Directory but a local keytab file is found for the service account, the command displays a warning that the account object was not found and asks you to confirm whether to continue with the delete operation for the items found. If you proceed, the command then removes the keytab file and any related keys in the centrifydc.conf file. You can use the --force option to skip checking for missing components and force the adkeytab command to proceed silently with the delete operation. To use this command to delete service accounts, you must specify a user with sufficient rights to remove account objects in Active Directory, and key tables and related keys in the centrifydc.conf file on the local computer. The basic syntax for removing service accounts from Active Directory using the adkeytab command is: adkeytab --delete --keytab filename [options] account-name Setting options for deleting service accounts You can use the following options to perform this task: Use this option -D, --delete -i, --ignore -K, --keytab filename -d, --domain domain -s, --server hostname -m, --machine To do this Remove a service account object from Active Directory and remove its key table and all related key entries from the centrifydc.conf file. Ignore the security risk of creating or updating a keytab file in a globally writeable directory, and allow the keytab file creation or update to proceed. If you attempt to create or update a keytab file in a globally writeable directory and you do not specify this option, the operation fails and an error message is displayed. Specify the full path to the keytab file you want to remove. Specify the domain in which this service principal should be added. If you do not specify this option, adkeytab uses the currently joined domain by default. Specify the domain controller you want to use for performing this operation. Using this option enables you to avoid replication delays. Use the Active Directory computer account credentials generated by adclient to execute the adkeytab command. This option can be used in place of user credentials if the computer account has been granted permission to update its own account information. Note Using the local computer s credentials to update Active Directory requires local root permission when executing the adkeytab command. Administrator s Guide for Linux and UNIX 338

339 Using adkeytab Use this option -u, --user -p, --password userpassword -f, --force -V, --verbose account-name To do this Specify an Active Directory user other than the current user to execute the adkeytab command. The user must have sufficient rights to delete account objects in Active Directory. You must use the format to specify the user account if the username is not defined in the local computer s domain. For example, if the local computer is joined to the fire.arcade.com domain, but the user marie is a member of the arcade.com domain, you must specify the --user option as: --user [email protected] If you do not specify the --user option, adkeytab uses the current user s Kerberos credentials by default. If there are no cached credentials for the current user, adkeytab uses the Administrator user account. Specify the password for the Active Directory user account running the adkeytab command. If you do not specify this option or if there are no currently cached Kerberos credentials, adkeytab prompts for a password before it 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. Skip any checking for missing components and proceed with the delete operation, ignoring any errors encountered. Display detailed information about the operation being performed. Specify the account-name of the service account you want to remove. Examples for deleting service accounts To remove the service account berlin_db, you would type a command similar to the following: adkeytab --delete --user oracleadm berlin_db Specify the encryption type for service principals If you are creating a new service account and key table or adding service principals to an existing key table, you must specify the encryption type for each service principal you add. The valid encryption types are those defined by the MIT implementation of Kerberos and specified using the adclient.krb5.tkt.encryption.types configuration parameter. Although Centrify supports all of the standard encryption types, some encryption types are only supported on particular versions of Windows. For example, Windows Server 2008 supports AES encryption, but earlier versions of Windows do not. The default encryption types supported by Windows 2000 Server and Windows Server 2003 are: arcfour-hmac-md5 des-cbc-md5 des-cbc-crc Appendix A Using Centrify UNIX commands 339

340 Using adkeytab If you are using Windows Server 2008 domain functional level, the following additional encryption types are supported: aes128-cts aes256-cts For more information about configuring the supported encryption types using group policy, see the Group Policy Guide. For more information about configuring encryption types using configuration parameters in the centrifydc.conf file, see the Configuration Parameters Reference Guide. Understanding adkeytab-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adkeytab command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_ENCRYPT_TYPE The encryption type specified is not valid or not supported. Check the list of supported encryption types, then try rerunning the command. 157 ERR_KEYTAB_NOT_ABSOLUTE_PATH The key table name you specify must be an absolute path, starting with the root directory (/). Verify the full path to the keytab file, then try rerunning the command. 158 ERR_KEYTAB_EXISTS The keytab file specified already exists. 159 ERR_KEYTAB_ILLEGAL The keytab file name or path contains illegal or invalid characters. 160 ERR_CHG_OWNERSHIP_FAILED The attempt to change ownership for the keytab file failed. 161 ERR_CHG_MODE_FAILED The attempt to change permissions to 0600 for the keytab file failed. 162 ERR_NOT_FIND_ADOBJ_KEYFILE_CONFIGKEY The Active Directory object, keytab file, and account configuration keys were not found. 163 ERR_NOT_FIND_ACC_COMPONENT Some account components were not found. 164 ERR_DEAD_LOCK The centrifydc.conf file may be locked by another process. You should try manually removing the lock by deleting centrifydc.conf.lck, then try rerunning the command. 165 ERR_NO_KEYTAB_WITH_ACC You must associate one keytab file with one Active Directory account. 166 ERR_SPN_EXISTS The service principal name (SPN) specified is not unique in the forest. You should rerun the command using a unique service principal name. 167 ERR_DEL_SPN_FAILED The attempt to delete a service principal name failed. 168 ERR_SRV_ACC_NOT_HAVE_COMPUTER_NAME The service account specified includes a computer name. Administrator s Guide for Linux and UNIX 340

341 Using adsmb Result Error name Indicates 169 ERR_KETTAB_CORRUPTED The keytab file is corrupted or has been removed. 170 ERR_NEED_NEW_PASSWD You have not specified a password for updating the local keytab file. The local option requires you to specify the account s new password. 171 ERR_MISS_ATTR The distinguished name (dn) specified is invalid. If you encounter this error, the container path may be missing one or more attributes. Verify the full path, then rerun the command. 172 ERR_REPLICATION_ERRONEOUS An unexpected referral response was received. This error is usually caused by an erroneous replication object in Active Directory. 173 ERR_NOT_FIND_DC The domain controller for the specified domain could not be found or is unavailable. 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 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 file server to use or use the nearest domain controller for the joined domain. 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 [-c credentials] [-m] [-C] [-T] [-h [hostname]] [-d domainname] [-n pattern] [-r remote_file] [-l local_file] [-V] The valid file_operations are get, getnew, put, putnew, dir, delete, mkdir, and rmdir. Setting valid options You can use the following options with this command: Use this option get getnew getmod print put To do this Get one or more files from a specified share. Get one or more files if the copy of the file on the specified share is newer than the local copy of the file. Get one or more files if the copy of the file on the specified share and the local copy of the file have different modification times. Create a spool file on the shared printer and write data to the spool file for printing. Put one or more files into the specified share. Appendix A Using Centrify UNIX commands 341

342 Using adsmb Use this option putnew dir delete mkdir rename rmdir To do this Put one or more files if the local copy of the file is newer than the copy of the file on the specified share. List the contents of a directory. Delete one or more files. Create a new directory. Rename a file. Remove a directory. -s share Specify the share name. -c credentials Specify the credentials file to use in performing the selected operation. For example, -c /tmp/krb5cc_cdc0_q2gocn -m Use the local computer s credentials. -C Convert carriage return line feeds (CRLF) in a file to line feeds (LF). -T Display the timestamp information in a computer-readable format. By default, the adsmb command displays timestamp information in a human-readable format. -h hostname Specify the host name of the file server that is exporting the share. If you don t specify a host name by using this option, the command uses the nearest domain controller for the joined domain. -d domainname Specify the domain name of the file server that is exporting the share. If you don t specify a domain name by using this option, the command uses the currently joined domain, or the domain part from the host if you specify the -h option. -n pattern Specify the pattern to use when listing the contents of a directory. The default pattern is *. -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. -V Print debug messages. 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/*" 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 similar to the following: sudo adsmb get -s sysvol -m -r arcade.com/lab/autorun.bat -l /tmp/autorun.bat Administrator s Guide for Linux and UNIX 342

343 Using adsendaudittrailevent Using adsendaudittrailevent The adsendaudittrailevent command allows you to specify audit trail events to send to the audit trail target. The audit trail target can be syslog, the Centrify auditing service (DirectAudit), or both. The basic syntax for the adsendaudittrailevent command is: adsendaudittrailevent -t, --type event_type_name -i, --info content [-v, -- version] [-h, --help] If the adsendaudittrailevent command executes successfully, a message is displayed showing the event information that was sent to the audit trail target. If the adsendaudittrailevent command fails, an error message is displayed. Setting valid options You can use the following pptions with this command: Use this option -t, --type event_type_name -i, --info content -v, --version -h, --help To do this Specify the type of event to send to the audit trail target. Supported event types are: tkt_id (Trouble ticket) Specify event information to send to the audit trail target. For example, if you are sending information about a trouble ticket event, type the trouble ticket ID here. The content that you specify here cannot exceed 444 characters. Events that are sent to syslog are subject to additional truncation if additional characters are added by syslog. Include the Centrify Server Suite version number in the event information that is sent to the audit trail target. Display help information. Examples of using adsendaudittrailevent To send information about trouble ticket 123qwe to the audit trail target, you would type the following command: adsendaudittrailevent -t tkt_id -i 123qwe If this command executes successfully, an entry for trouble ticket 123qwe is created in the auditing database, and a message similar to the following is displayed: adsendaudittrailevent[13172]: INFO AUDIT_TRAIL Centrify Suite dzdo Trouble ticket entered 5 [email protected] pid=13166 utc= status=success ticket=123qwe Using adsetgroups The adsetgroups command enables you to view or change the list of groups available for the current user. The basic syntax for the adsetgroups program is: Appendix A Using Centrify UNIX commands 343

344 Using adsetgroups adsetgroups [-a,--all] [-l,--list] [-r, --required] [-o, --optional] [-m, -- samname] [-n, --number] [-R,--remove] [-c, --clear] [-C. --command cmd] [-E, - -exec] [-i, --init] [-s --save] [-q, --quiet] [-v, --version] group On most UNIX systems, a user can only be a member of a limited number of groups at once. Because of this limitation, it is useful to be able to change a user s group membership to add and remove groups when necessary. The adsetgroups command allows you to dynamically manage the set of Active Directory groups that are available to a UNIX account. If you run the adsetgroups command with no arguments, it displays the current group list for the current user. If you specify a list of groups on the command line, those groups are added to or removed from the user s current group list, and a new shell is invoked. To add or remove groups, the local computer must be joined to a domain and zone. If you specify that membership in a specific group is required in a zone, that group cannot be removed from the currently active set of groups. Any time the list of groups is changed, for example, using the --init, --clear or when specifying a list of group names to add or remove on the command line, a new shell is created. When you exit the new shell, the previous list of groups is restored. If you use adsetgroups in a script and want to execute a command in the new shell (after changing the list of available groups), use the --command option to specify the command to execute. Setting valid options You can use the following options with this command: Use this option -a, --all -l, --list -r, --required -o, --optional -m, --samname -n, --number -R, --remove group To do this Display all the Active Directory groups that the current user is a member of. Display the current set of supplementary groups for the current UNIX user account. Display only the required groups. Display only the groups that are not required. Display the samaccountname attribute for the group instead of the group s UNIX group name. Display the group identifier (GID) value for the group. Remove all of the specified groups from the currently active set of groups. This option creates a new shell. Administrator s Guide for Linux and UNIX 344

345 Using adsetgroups Use this option -c, --clear [group] -C, --command cmd -E, --exec cmd -i, --init -s, --save -q, --quiet -v, --version group To do this Start with an empty list of groups. If you have previously saved a list of groups, you can use this option to clear the existing list and specify a different set of groups. For example, to replace an existing set of groups with the single group athena, you would run a command similar to the following: adsetgroups --clear athena This command would change the list of groups for the user to be the single group athena unless some of the user s other groups have been marked as required. This option creates a new shell. Specify a command and options to execute in the temporary shell. Enclose the command in single quotation marks; for example, to add the group dnsadmins and execute the command, ls -l: adsetgroups dnsadmins -C 'ls -l' The command line is limited to 256 characters. This option is not necessary when you run adsetgroups interactively, because you can execute commands in the new shell after it launches. However, if you run adsetgroups in a script, any commands you add to the script will not execute because the script is associated with the current shell, which stops when the new shell starts, before it is able to execute these commands. This option allows you to pass the command line directly to the temporary shell. Specify a command and options to execute by first invoking execvp. This option is similar to the --command option, except that it enables the adsetgroups command to return the exit code of the command specified by the cmd argument. If the invocation of execvp fails, the adsetgroups command returns the exit code 255. Note that the command you specify is executed using the search path and the environment variables of the current shell. Start with the last saved list of groups. This option creates a new shell. Save the current list of groups. This option sets the default list of groups for the current user when the user logs on. The saved list of groups is used when you run the adsetgroups command with the --init option. Suppress any warning or new shell messages. Display version information for the installed software. List the groups to add or remove. Examples of using adsetgroups To display the currently active list of groups for the current user, you would type a command similar to the following: adsetgroups To add the groups delta1 and portland_lab to the current set of groups, and save this list as the default for the current user, you would type a command similar to the following: adsetgroups --save delta1 portland_lab To remove the groups oxford and westlake from the current set of groups for the current user, you would type a command similar to the following: Appendix A Using Centrify UNIX commands 345

346 Using adclient adsetgroups --remove oxford westlake Understanding adsetgroups-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adsetgroups command can generate the following operation-specific result code: Result Error name Indicates 156 ERR_SETUID The attempt to run setuid failed. Using adclient Most access control operations are managed by the central process adclient. This process is automatically started when the system is first booted. The process 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. Notes Although you can run adclient directly from the command line to control the operation of the Centrify UNIX agent on a local computer, it is recommended that you do so only under the direction of Centrify Corporation support. Typically, you should start and stop adclient from a startup script; see Using the startup script on page 347. On Solaris, Mac OS X, and certain Red Hat computers, such as computers running RHEL 5.2, you cannot use the -x option to stop adclient, and on AIX computers, you cannot start or stop adclient directly from the command line. When running computers with any of these operating systems, you should use the centrifydc startup script or system resource controller commands, such as startsrc, stopsrc, and lssrc. For example, to stop the agent use: /usr/share/centrifydc/bin/centrifydc stop or to start adclient with the -d and -F options on AIX, use a command such as: startsrc -s centrifydc -a -d -F The basic syntax for running adclient at the command line is: adclient [-x] [-d] [-F] Administrator s Guide for Linux and UNIX 346

347 Using adclient Setting valid options You can use the following options with adclient: Use this option To do this -x Stop the Centrify UNIX agent if it is currently running. Note: On computers running AIX, Solaris, Mac OS X, or RHEL 5.2, this option is not available. -d Set the Centrify UNIX agent to run in debug mode when it is restarted. -F Flush the Active Directory cache when the Centrify UNIX agent is restarted. -M Enable in-memory logging of Centrify UNIX agent operations. For example, to flush the cache when the Centrify UNIX 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 adclient 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 adclient process. 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 Appendix A Using Centrify UNIX commands 347

348 Using adcache 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 adcache The adcache command enables you to manually clear the local cache on a computer. You can also use this command to dump all cache file or a specific cache file. You can also use the command to check a cache file for a specific key value and to reclaim disk space. By default, the program dumps all cache files. You can run adcache in one of two ways: Run it while the UNIX agent (adclient) is still running by using the --live option. In this case you must specify an output filename using the --outputfile option. Run it after stopping adclient. You can stop the adclient process by using the following command: /usr/share/centrifydc/bin/centrifydc stop To restart adclient run the following command: /usr/share/centrifydc/bin/centrifydc start You can automatically stop adclient, optimize the cache disk space, and restart adclient by specifying the adcache --reorg option. The basic syntax for running the adcache program is: adcache [options] Setting valid options You can use the following options with adcache: Use this option -c, --cachename path -d, --directory path To do this Specify the full path to the cache file you want to check or clear. Specify the directory for the cache files. The default directory is /var/ centrifydc. Administrator s Guide for Linux and UNIX 348

349 Using adcache Use this option -F, --fromversion version --fromversion list -h, --help -k, --key value -L, --live -o, --outputfile path -q, --quiet -r, --reorg -v, --version To do this Converts the cache file to the specified version format. Before you use the -F command after an upgrade, restart the agent. The agent must be shut down before running this command. Note: The cache is automatically upgraded when you upgrade to a newer version of the agent. Generally, it is unnecessary to manually convert the cache to the latest version. You should only run the adcache -F option if instructed to do so by Centrify Technical Support. Use adcache -F list to list the supported version numbers. (You do not need to stop the agent first to run this option.) Display the help page. Check the cache for a specific key value. Run the command while the agent is still running. When you specify this option, you must specify an output file with the --outputfile option. Specify the full path to the output file. This option is required when using the --live option. Run the command without displaying any output. This option is useful for running the command as a scheduled maintenance job. Reorganize the cache and index files and recover disk space used by negative items. To use this option, you be run the adcache command as root. If you use this option, adcache stops and restarts the adclient process. Display the CentrifyDC version number Examples of using adcache To check the domain controller cache for a specific key value while adclient is running, type a command similar to this: adcache --live -o /tmp/dccacheout.txt --cachename /var/centrifydc/dc.cache -- key andre The output is sent to the file /tmp/dccacheout.txt. To check the domain controller cache for a specific key value, after stopping adclient, type a command similar to this: adcache --cachename /var/centrifydc/dc.cache --key andre Dumping /var/centrifydc/dc.cache ADObject: <GUID=83db76a5dfca5243a788d98128d2e101> Acquired: Fri Sep 21 16:10: Deserialized data: _ExpiryTime(s):-1, _Foreign(s):False, _GECOS(s):Andre Garcia, _Gid(s):500, Appendix A Using Centrify UNIX commands 349

350 Using adcache _HomeDirectory(s):/home/andre, _LoginShell(s):/bin/bash, _ObjectExtended(s):a30d50f5ef182e42b7687fa1ae07b776, _ParentLink(s):S , _PwSync(s):altSecurityIdentities, _SID(s):S , _ShellEnabled(s):True, _Uid(s):504, _UnixName(s):andre, _dn(s):cn=andre Garcia,CN=Users,DC=ajax,DC=org, _extendedobjusn(s):127065, _groupguidlist(s):<guid= a73a49b251b156fae5d6fb>,<guid=2d7305a27dfc 884eb95ed5d4404a9016>,<GUID=d663e7d2088e6c4d8d89c0919f4a2b6e>, _hashtimestamp(s): , _maxpwdage(s):-1, _minpwdage(s): , _objectcategory(s):person, _pacgroups(s): c1d70eac103d99d0639e , c1d70eac103d99d0639e , c1d70eac103d99d0639e , _passwordhash(s):b450a ea44d980322df1773b10, _passwordsalt(s):$1$wjkhxueb$, _server(s):ginger.ajax.org, accountexpires(s): , cn(s):andre Garcia, displayname(s):andre Garcia, msds-keyversionnumber(s):3, name(s):andre Garcia, objectcategory(s):cn=person,cn=schema,cn=configuration,dc=ajax,dc=org, objectclass(s):top,person,organizationalperson,user, primarygroupid(s):513, pwdlastset(s):-1, samaccountname(s):andre, usnchanged(s):1, useraccountcontrol(s):512, To reorganize the cache and index files and recover disk space used by negative items, you would run the following command: adcache --reorg You should run the adcache --reorg command on a regular basis in a cron job to remove negative results and to prevent the cache from consuming too much disk space. When you use the --reorg option do not stop and restart the Centrify UNIX agent, this is done automatically by the command.depending on how quickly the size of the cache tends to increase in your environment, you may want to schedule this command to run approximately once a week. Administrator s Guide for Linux and UNIX 350

351 Using adreport Understanding adcache-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adcache command can generate command-specific result codes when errors are encountered. The following table lists these command-specific result codes. Result Error name Indicates 156 ERR_ADCLIENT_NOT_SHUTDOWN The Centrify UNIX agent is currently running. You should stop the adclient process, then attempt to rerun the command. 157 ERR_CACHE_CORRUPT The cache may be corrupt. Using adreport The adreport command generates user, computer, command, assignment and role data about a zone. The adreport command generates a report from the database created by the addbloader command. You must run addbloader to create a sqlite database containing information about a zone before you can run adreport to generate a report. The basic syntax for the adreport program is: adreport -db dbpath -report user computer command assignment special_assignment effective assignment role effective role [-filter filter][-sep csv tab char] The adreport utility produces simple one-dimensional reports. In Centrify Server Suite 2014, there is a new version of the reporting utility, adreport2, that supports twodimensional query targets. For example, you can use adreport2 to produce a User-By- Computer report rather than just a User or Computer report that you could produce using the older adreport utility. For details about using the new reporting utility, see the man page for adreport2. Setting valid options You can use the following options with this command: Use this option -db dbpath -report user computer command To do this Specify the path to the database file created by the addbloader command. Specify whether to generate user, computer, command, assignment, or role data. If you specify computer, command, assignment, or role information, you can filter the information to display. Appendix A Using Centrify UNIX commands 351

352 Using adreload Use this option -filter filter To do this Specify a filter for the computer, command, assignment, or role information to display. The filter for user, report, and assignment related reports is based on the user s UPN. The filter for computer related reports is based on the computer DNS name. The filter for command report is based on the command. The filter for role related reports is based on role name. For all filters, use the % character for wildcard matches. sep csv tab char Specify whether to create a comma separated list, tab-separated list, or user-specified character list. Examples of using adreport The following command generates a user report from the database file /tmp/user_report. /usr/share/centrifydc/adedit/adreport \\ -db /tmp/user_report \\ -report user Using adreload The adreload command enables you to force the Centrify UNIX agent (adclient) to reload configuration properties in the /etc/centrifydc.conf file and in other files in the / etc/centrifydc directory. Running this command enables changes made to the configuration properties to take effect without restarting the adclient process. Running adreload, however, does not reload the properties set with the following configuration parameters: auto.schema.search.return.max adclient.ldap.timeout adclient.ldap.socket.timeout adclient.udp.timeout adclient.clients.threads adclient.clients.threads.max adclient.use.all.cpus adclient.clients.listen.backlog adclient.dumpcore For the configuration parameters listed above, you must restart the adclient process for changes to take effect. The basic syntax for running the adreload program is: adreload This command returns the following exit codes: This exit code Indicates 0 Command executed successfully 2 Process not authorized 3 Reload failed Administrator s Guide for Linux and UNIX 352

353 Using addbloader Setting valid options You can use the following option with adreload: Use this option -h, --help To do this Display the usage message. Examples of using adreload To reload the configuration properties on a local computer after making changes to the / etc/centrifydc/centrifydc.conf file, you would type a command similar to this: adreload Understanding adreload-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the adreload command can generate the following operation-specific result code:. Result Error name Indicates 156 ERR_RELOAD_CENTRIFYCONF The attempt to reload the centrifydc.conf file failed. Using addbloader The addbloader command allows you to create a database file with zone information. You can use the adreport command to generate reports from this file, or read it with standard sqlite tools. The basic syntax for the addbloader program is: addbloader -db dbpath -config filename [-v] Setting valid options You can use the following options with this command: Use this option -db dbpath -config To do this Specify the location in which to create the database file, including the file name. Specify a configuration file that you have created. In the configuration file, you need to specify bind and load information for the zones For example, the configuration file could contain information such as the following: bind acme.com administrator {myp@$swd} cache on load_root "cn=finance,cn=global,cn=zones,ou=unix,dc=acme,dc=com" \\ load_root "cn=global,cn=zones,ou=unix,dc=acme,dc=com" \\ -v Print verbose information while the command runs. Appendix A Using Centrify UNIX commands 353

354 Using addns Using addns Examples of using addbloader The following command creates a database file containing zone information. /usr/share/centrifydc/adedit/addbloader \\ -db /tmp/zone_report \\ -config./zone_report.config -v The addns command enables you to dynamically update DNS records on an Active Directory-based DNS server in environments where the DHCP server cannot update DNS records automatically. For example, if you are using an Active Directory-based DNS server configured for secure updates with a router acting as a DHCP server, the router cannot automatically register its DHCP clients with the DNS server because it has no way of establishing a security context that will allow the update. By running the addns command, you can use Kerberos credentials to establish a security context for updating the DNS records in the Active Directory-based DNS server. With the addns command, you can: Create or update a local host s IP addresses in DNS. Create or update a specified host s IP addresses in DNS. Update pointer records in DNS. Remove the local or another host s DNS records. Remove the local or another host s IP addresses in DNS. List details about a DNS record. Note In most cases, you do not need to use this command if a host s IP address is managed by a Windows-based DNS server and the host obtains its IP address from a Windows-based DHCP server because the DHCP server updates the DNS record for the host automatically. If you are not using a Windows-based DNS server, you should use nsupdate or a similar command appropriate to the operating environment of the DNS server to update DNS records. The basic syntax for running the addns program is: addns -U [-u <user> -p <pwd>] [-d <domain>] [-s <svr>] [-n <host>] [-i <ip>)+] [-r] [-t <value>] addns -D [-u <user> -p <pwd>] [-d <domain>] [-s <svr>] [-n <host>] addns -A [-u <user> -p <pwd>] [-d <domain>] [-s <svr>] [-n <host>] [-i <ip>)+] addns -L [-d <domain>] [-s <svr>] [-n <host>] [-i <ip>)+] Administrator s Guide for Linux and UNIX 354

355 Using addns Options You can use the following options with addns: Use this option -U, --update -A, --add -D, --delete -L, --list -N, --nocreds -m, --machine -u, --user To do this Create or update the IP address (A) and domain name pointer (PTR) records in the DNS server for the local or specified computer hostname. Create new IP address (A) and domain name pointer (PTR) records in the DNS server for the local or specified computer hostname, even if a record already exists for the same hostname. If you update a host s IP addresses by specifying the --update option, current records are deleted when the new record is created. The --add option allows you to add a record with one or more additional IP addresses without deleting current records. If you a specify a hostname and IP address that are identical to an existing entry, addns returns an error. Remove the DNS records for the local or specified computer hostname. List DNS record details. If no additional parameters are specified, this option displays details about the DNS record for the computer on which you execute the command. You can use additional parameters to specify a particular domain (-d), server (-s), host (- n), or IP address (-i). You can use these parameters in combination, for example, the following specifies a specific host and the IP address for a different computer: addns -L -n rhe5.acme.com -i You are not required to supply credentials and are not prompted to do so. This option only works if the DNS server is configured for non-secured updates. Use the local computer account s Active Directory credentials to establish a security context with the DNS server. Specify an Active Directory username with sufficient rights to add, update, and delete records in the relevant DNS zones. You must use the username@domain format to specify the user account if the username is not a member of the joined domain. If you do not specify the --user option, the credentials for the currently logged-on user are used by default. If there are no Kerberos credentials for the current user and you are not using the computer account credentials, the Administrator user account is used to establish the security context. Appendix A Using Centrify UNIX commands 355

356 Using addns Use this option -p, --password userpassword -s, --server servername -d, --domain domainname -n, --name hostname -i, --ipaddr ipaddress -r, --refresh -t, --ttl value -f, --force -V, --verbose -v, --version To do this Specify the password for the Active Directory user account performing the add, update, or delete operation. If you do not provide the password at the command line, you are prompted to enter the password before the command executes. 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. For better security, you should do one of the following instead of specifying the password in the command line: Allow the addns command to prompt for the password. Use kinit to establish a valid credential cache before running the addns command. Use the --machine option to use the computer account credentials to establish the security context. Specify the DNS server to send the DNS update records to. You can use this option more than once to specify multiple DNS servers. If you do not specify this option, the addns program attempts to discover the DNS servers available on its own. Specify the fully qualified domain name of the DNS domain name to be updated. If you do not specify this option, the DNS domain name for the local host is used. Specify the name of the host to update IP records for. If you do not specify this option, the local host name is used. Specify one or more IP addresses to use in the update. You can specify this option multiple times to support multi-homed hosts. If no IP addresses are provided, the addns program attempts to determine the current settings. Update unchanged records to reset TTL to its starting value. Specify a time-to-live value (in seconds) for DNS records. Update DNS records even if they have not changed. Display detailed information about the operation being performed. Display version information for the installed software. Examples of using addns The addns program is intended for Windows-based DNS servers that are configured for integration with Active Directory. If your DNS servers are integrated with the Active Directory infrastructure, they may be configured to allow for unsecured updates or to require secure updates only for DNS records. When you run the addns program, it will first attempt to perform an unsecure update, then retry using a security context if a secure update is required. If your environment is configured to only allow secure DNS updates, addns can use the current user s cached credentials to establish a security context with the Windows DNS server and sign the DNS update packets using GSS methods. Administrator s Guide for Linux and UNIX 356

357 Using addns If secure updates are required and the current user executing the addns program has valid Kerberos credentials in the cache, you only need to specify the operation to perform and the addns program will attempt to determine the rest of the parameters programatically. For example, to perform an update for the local host: addns --update If there are no valid cached credentials or the current user credentials do not have sufficient permissions to perform the update, you can specify a user name and password to use for the establishment of the security context. For example: addns --update --user [email protected] To update the IP addresses for a computer other than the local host, you can specify the host name on the command line. For example, to update the IP addresses in the DNS records for the computer picasso on the DNS server fire.arcade.com using the user rae to establish the security context, you would type a command similar to this: addns --update --user "rae" --server "fire.arcade.com" --domain "arcade.com" --name "picasso" --ipaddr " " --ipaddr " " To remove the DNS record for a local host using the local computer s account credentials to establish the security context, you would type a command similar to this: addns --delete --machine Note To use the --machine option, you must invoke the addns command as the root user and the account principal in Active Directory must have sufficient rights to modify records in the relevant DNS zones. Using the computer account credentials is particularly useful when an automated script, such as /sbin/dhclient-script, is used to keep the DNS records up to date. There are several configuration parameters that can be used to customize the behavior of the addns program. For more information about using configuration parameters and modifying the configuration file /etc/centrifydc.conf, see the Configuration and Tuning Reference Guide. Understanding addns-specific result codes In addition to the common result codes described in Understanding common result codes on page 231, the addns command can generate the following operation-specific result code: Result Error name Indicates 156 ERR_NOT_LOCATE_DC The domain controller could not be located for the domain. If you encounter this problem, you may need to server name and IP address of the domain controller and verify it is properly configured in the DNS server, then rerun the addns command. Appendix A Using Centrify UNIX commands 357

358 Using dzdo Using dzdo The dzdo command enables a user to execute a privileged command as root or another specified user. The basic syntax for using the dzdo program is: dzdo [options] command Note The dzdo command requires a valid, unexpired license for the Centrify agent on the local computer. The dzdo program allows an authorized user to execute a command as the superuser or another user in the Active Directory authorization store. The dzdo program provides functionality that is similar to the UNIX sudo command, except its privileged commands are defined by rights configured using DirectManage Access Manager or ADEdit and stored in an Active Directory authorization store. In addition, only Active Directory users with a profile in the zone where rights and roles are enforced can use dzdo to run commands. You can, however, use dzdo to run privileged commands with either an Active Directory or local user as the target user. If you do not specify a user, dzdo attempts to execute the command as the root user by default. The real and effective UID and GID are set to match those of the target user as specified in the user s UNIX profile. You can configure privileged commands to require that users authenticate themselves by typing their own account password or the target user s account password, or no password at all. For example, if a privileged command right is configured in DirectAuthorize to run as the root user and to authenticate using the target user s password, running the command requires the user to know and enter the root password. Once authenticated, the user may then run dzdo privileged commands without re-entering a password for a short period of time. By default, the password timeout is 5 minutes; you can change this with the dzdo.password_timeout configuration parameter in the centrifydc.conf file. You can use the -v option with dzdo to update the time stamp without running a command. The password prompt itself will also time out if the user s password is not entered within the password timeout interval. The dzdo program determines who is an authorized user by consulting the rights and roles in the authorization store. If a user who is not authorized tries to run a privileged command using dzdo, a warning message is displayed. The lone exception is the case in which an unauthorized user runs dzdo with the -l or -v flags. This allows users to determine for themselves whether or not they are allowed to use dzdo. By default, the dzdo program logs both successful and unsuccessful command execution attempts to the syslog authpriv facility or the auth facility if the authpriv facility is not supported on the platform (typically, /var/log/secure). Unsuccessful command executions are logged as errors and include the name of the user who attempted the execution, the user the unsuccessful execution ran as, and the command the user attempted to run. Administrator s Guide for Linux and UNIX 358

359 Using dzdo In the centrifydc.conf configuration file, set the dzdo.log_good parameter to true (the default) to log both successful and unsuccessful commands; set this parameter to false to log only unsuccessful commands. Customizing dzdo behavior Before dzdo executes the command, it runs the script /usr/share/centrifydc/sbin/ dzcheck. If the script returns success, the command is executed; if it returns failure it does not execute the command. By default there is no dzcheck in the distribution package. If you would like to modify dzdo behavior for example, to prompt the user to enter some information before executing the command write the script, name it dzcheck and put it in /usr/share/centrifydc/ sbin. This script is run every time dzdo is invoked. The script runs synchronously and is run under the current user s Active Directory name. dzdo sets three environment variables you can use in the script DZDO_USER: the Active Directory name of the user invoking dzdo DZDO_COMMAND: the command DZDO_RUNASUSER: the user name that the command will be run as The script should return one of the following values: 0 Success. dzdo will continue and run the command. non-zero Failure: dzdo will not run the command. In this event, dzdo does NOT show a message on the console. If you want to notify the user of the failure, include the message in the script. When the logging level is set to DEBUG, the call to the script and the return value are logged. The distribution includes a sample script named dzcheck.sample in /usr/share/ centrifydc/sbin/. The script prompts the user to enter a change ticket number and then logs the user name, the command that the user wants to run and the change control ticket number in syslog. You can specify a different file or path using the dzdo.validator configuration parameter in centrifydc.conf. You must specify the full path name. For example, if the script was named myvalidator and it was in the /etc/centrifydc directory, your centrifydc.conf parameter entry would be: dzdo.validator: /etc/centrifydc/myvalidator Appendix A Using Centrify UNIX commands 359

360 Using dzdo Setting valid options You can use the following options with the dzdo command: Use this option To do this -A Get the password from a helper program rather than from the terminal. The command will exit with an error if a helper program cannot be found. -b Run the specified command in the background. Note that if you use the -b option, you cannot use shell job controls to manipulate the process. -C filedescriptor Do not close file descriptors before the specified number when dzdo exits. Normally, dzdo closes all open file descriptors except standard input, standard output, and standard error. This option allows you to specify a starting point above standard error (file descriptor 3). Values less than 3 are not allowed. -e file Edit one or more specified files rather than running a command. Note This option is the same as using the dzedit program. -g groupname gid Specify the primary group to set for the specified command. Note The definition for a command right contains a list of valid groups that may be used with this option it could be restricted to certain groups or may include all valid groups. If you aren t sure, or receive an error when running the command, check with your Centrify zone administrator. To specify a group by GID instead of the group s name, use '#gid'. For example, to run adquery as a privileged command and set the primary group as the group with the numeric GID of 101, you could type a command similar to the following: dzdo -g '#101' adquery Note Be certain to put single quotes around #gid. -H Set the HOME environment variable to the home directory of the target user (root by default) as specified in the user's UNIX profile. By default, dzdo does not modify HOME, but you can change the default behavior by setting the dzdo.always_set_home or dzdo.set_home configuration parameters in the centrifydc.conf configuration file. Note This option has no effect if Reset environment variables is set for a privileged or restricted environment command definition (in the Access Manager console or ADEdit). -h host Specify a remote host on which to execute the command. The user must be authorized for the remote computer. For example: dzdo -h qa1.acme.com command You can pass parameters to ssh for the remote connection by using the -W option. -i Run the login shell for the user the command is being run as. This option simulates an initial login by changing to the target user's home directory, invoking a shell, setting the HOME, SHELL, USER, LOGNAME, and PATH environment variables, and un-setting all other environment variables. -K Remove the user's login timestamp entirely. This option does not require a password. After using this option, however, the next time the user attempts to run dzdo, the program will prompt for a password. Administrator s Guide for Linux and UNIX 360

361 Using dzdo Use this option To do this -k Invalidate the user s login timestamp by setting the time on it to the epoch. This option does not require a password. After using this option, however, the next time the user attempts to run dzdo, it will prompt for a password. This option allows a user to revoke dzdo permissions from a.logout file. -l Lists the allowed and forbidden commands for the current user on the local host computer. -n Prevents dzdo from prompting for a password. -o opid The opid (operation ID) used in conjunction with the active role specified with the -R parameter, creates a secret handshake between dzdo and dzsh. -P Preserves the user's group membership unaltered. By default, dzdo will set the group membership to the list of groups the target user is in. The real and effective group IDs, however, are still set to match the target user. Note This option overrides the Preserve group membership setting for a privileged or restricted environment command (defined in the Access Manager console or ADEdit). -p prompt Allows you to override the default password prompt and use a custom one. The following percentage (%) escapes are supported: %u expands to the invoking user's login name. %U expands to the login name of the target user the command will run as, for example, root by default. %h expands to the local computer s host name without its domain name. %H expands to the local computer s host name including the domain name. %% collapses into a single % character. You can use this option with dzdo or dzedit. -r role Causes the new (SELinux) security context to have the role specified by role. -R activerole The activerole, used in conjunction with the operation ID specified with the -O parameter, creates a secret handshake between dzdo and dzsh. -S Reads the password from standard input instead of the terminal device. You can use this option with dzdo or dzedit. -s Runs the shell specified by the SHELL environment variable, if it is set, or the shell as specified in the user s UNIX profile. -t type Causes the new (SE Linux) security context to have the type specified by type. Appendix A Using Centrify UNIX commands 361

362 Using dzdo Use this option To do this -u username uid Runs the specified command as a user other than root. Note The definition for a command right contains a list of valid users that may be used with this option it could be restricted to certain users or may include all valid users. If you aren t sure, or receive an error when running the command, check with your Centrify zone administrator. The dzdo command will recognize any username that is an equivalent of the username specified for the command to be run. For example, if permission is given to bob.smith (the Active Directory name) to run adinfo as a a privileged command, and if bob.smith has a UNIX profile name, for example, bsmith, you can specify bsmith when you use dzdo to run adinfo: dzdo -u bsmith adinfo To specify a user by UID instead of the user s login name, use '#uid'. For example, to run adquery as a privileged command and as the user with the numeric UID of 101, you could type a command similar to the following: Note Be certain to put single quotes around #uid. dzdo -u '#101' adquery You can use this option with dzdo or dzedit. -V Displays version information for the installed software, including the version of the UNIX sudo program that dzdo is based on. -v Validates and updates the user's login timestamp, prompting for the user s password, if necessary. This option extends the dzdo timeout for another 5 minutes or the timeout period set in the centrifydc.conf configuration file. This option does not run a command. -W, sshoption Specify a comma-separated list of parameters to pass to ssh when executing a command on a remote host with the -h option. For example: dzdo -h host-w,-v,-i identifyfile ls -la to show verbose output (-v) and specify an identity file (-i) for ssh while executing the ls -la command on the remote host. -X Start the adclient wait debugger. VAR=value Enables you to pass environment variable values to the command you are running as part of the dzdo command line. Note This option has no effect if you Reset environment variables is set for a privileged or restricted environment command (defined in the Access Manager console or ADEdit). -- Indicates that the dzdo program should stop processing command line arguments. It is most useful when used in conjunction with the -s option. Understanding dzdo return values Upon successful execution of a program, the return value from dzdo will simply be the return value of the program that was executed. If the attempt to execute the program fails, however, dzdo will exit with a return value of 1. A return value of 1 may indicate that there is a configuration issue, permission problem, or that dzdo cannot execute the command as specified. Administrator s Guide for Linux and UNIX 362

363 Using dzdo If dzdo cannot execute the command, an error string is sent to stderr. If dzdo cannot access file system information (stat) for one or more entries in the user s PATH, it prints an error message to stderr. If a listed directory does not exist or is not really a directory, however, the entry is ignored and no error is printed. The most common reason for dzdo to receive a permission denied message is if you are running an auto-mounter and one of the directories in your PATH is on a computer that is currently unreachable. Understanding security issues By default, dzdo executes commands with a minimal set of environment variables that includes TERM, PATH, HOME, SHELL, LOGNAME, USER and USERNAME, and removes environment variables that contain special characters. You can check the default list of environment variables that dzdo checks by running dzdo -V as root. You can modify the default list of environment variables to preserve or remove using the dzdo.env_keep and dzdo.env_delete configuration parameters in the centrifydc.conf configuration file. For security purposes, the dynamic linker on most operating systems will remove variables that can control dynamic linking from the environment for all setuid executables, including dzdo. Depending on the operating system, environment variables such as _RLD*, DYLD_*, LD_*, LDR_*, LIBPATH, SHLIB_PATH, and others are removed from the environment before dzdo begins execution and cannot be preserved. To prevent command spoofing, dzdo checks the current directory last when searching for a command in the user s PATH. You should note, however, that the actual PATH environment variable is not modified and is passed unchanged to the program that dzdo attempts to execute. Checking ownership of the timestamp directory When you run dzdo privileged commands, dzdo checks the ownership of its timestamp directory (/var/run/dzdo by default). If the directory is not owned by root and writable only by the root user, dzdo ignores the directory s contents. If the timestamp directory is located in a directory writable by anyone, it is possible for a user to create the timestamp directory before dzdo runs. However, because dzdo checks the ownership and mode of the directory and its contents, the only damage that can be done is to hide files by putting them in the timestamp dir. This is unlikely to happen since once the timestamp dir is owned by root and not accessible to any other user, the user placing files there would be unable to get them back out. To get around this issue, you can use a directory that is not world-writable for the timestamps (for example, you can use /var/adm/dzdo as the timestamp directory) or create /var/run/dzdo with the appropriate owner (root) and permissions (0700) in the system startup files. You can specify an alternative timestamp directory using the dzdo.timestampdir configuration parameter in the /etc/centrifydc/centrifydc.conf file. Appendix A Using Centrify UNIX commands 363

364 Using dzdo Checking the date of login timestamps Login timestamps are not considered valid if they have a date greater than the current time plus twice the timeout value (current_time + (2 * TIMEOUT)). If a timestamp is invalid, dzdo will not allow it to be used and log the issue in its log file. This timestamp check prevents a user from creating his or her own login timestamp with a bogus date on systems that allow users to change file ownership. Checking the commands that dzdo runs The dzdo program only logs the command it explicitly runs. If a user is allowed to run a privileged command such as dzdo su or dzdo sh, any subsequent commands the user runs from the invoked shell are not logged. In addition, dzdo access controls do not affect which commands the user is allowed to run in the invoked shell. The same limitation is true for programs such as text editors that offer shell escapes. Because of this limitation, you should use caution when giving users access to privileged commands through dzdo to verify that the command does not inadvertently give the user an effective root shell. Setting configuration parameters The following configuration parameters can be set in the centrifydc.conf file to control dzdo operation. The configuration parameters are equivalent to the standard sudo settings. Use this parameter audittrail.dz.command.with.args dzdo.always_set_home dzdo.badpass_message To do this Specify whether to show command parameters in the audit log for dzdo and dzsh or just the command name. The default (false) is to show only the command name. For example, to keep passwords entered on the command line out of the log, leave this parameter set to false. Set to true to show the command parameters as well as the command name. For example: audittrail.dz.command.with.args: true Set the HOME environment variable to the home directory of the target user, for example, root unless the -u option is used. This effectively means that the -H flag is always implied. The parameter value can be true or false. The default value is false. Specify the message displayed if a user enters an incorrect password. The parameter value can be any text string enclosed by quotation marks. The default value is "Sorry, try again." Administrator s Guide for Linux and UNIX 364

365 Using dzdo Use this parameter dzdo.env_check dzdo.env_delete dzdo.env_keep dzdo.lecture dzdo.lecture_file dzdo.log_good dzdo.passwd_timeout To do this List the environment variables to check for the special characters % or / in the value and remove the variables with values that contain those characters from the user s environment. Variables with % or / characters are removed regardless of whether you have selected the Reset environment variables option for the command in the Access Manager console. The default list of variables to check is displayed when you run the dzdo -V command as root. You can customize the list by modifying this configuration parameter in the centrifydc.conf file. The parameter value can be a comma-separated list of environment variable names. Specify the default list of environment variables to be removed from the user s environment. This configuration parameter only applies if you have selected the Remove unsafe environment variables option for the command in the Access Manager console. The variables specified with this parameter are removed in addition to the default list of variables displayed when you run the dzdo -V command as root. The parameter value can be a comma-separated list of environment variable names. Specify the default list of environment variables to preserve in the user s environment. This configuration parameter only applies if you have selected the Reset environment variables option for the command in the Access Manager console. The variables specified with this parameter are preserved in addition to the default list of variables displayed when you run the dzdo -V command as root. The parameter value can be a comma-separated list of environment variable names. Control whether dzdo displays a warning message about using the program before displaying the password prompt. The valid parameter values are: once to display the warning message only the first time the command is run. never to never display a warning message. always to display the warning message every time the program is invoked. The default value is once. Specify the full path to a file containing the warning message you want displayed. If this parameter is not set, a default message is displayed. Specify whether to log messages for successful command execution. By default, dzdo logs both valid and invalid command execution. To only log information about invalid command execution, set this parameter to false. The default value is true. Note that the typical file for dzdo messages is /var/log/secure. Specify the number of minutes before the dzdo password prompt times out. The default parameter value is 5 minutes. Appendix A Using Centrify UNIX commands 365

366 Using dzedit Use this parameter dzdo.path_info dzdo.set_home dzdo.timestampdir dzdo.timestamp_timeout dzdo.tty_tickets dzdo.validator To do this Specify whether the dzdo program should inform the user when it cannot find a command in the user s PATH. By default, the parameter value is true and the program will display an error statement indicating that the command could not be found in the user s PATH. You can set this configuration parameter to false if you want to prevent dzdo from indicating whether a command was not allowed or simply not found. Set the HOME environment variable to the home directory of the target user when the -s option is used. The parameter value can be true or false. The default value is false. Specify the directory where dzdo stores user timestamp files. The default is directory is /var/run/dzdo. Specify the number of minutes between operations during which a user need not re-authenticate. The default parameter value is 5 minutes. Require authentication once per-tty rather than once per user. The parameter value can be true or false. The default value is false. Specify the full path for the script to run every time dzdo is run. The default script is/usr/share/centrifydc/sbin/dzcheck For more information about setting configuration parameters in the centrifydc.conf file, see the Configuration and Tuning Reference Guide. Examples of using dzdo To use a privileged command to get a file listing of an unreadable director, you would type a command similar to the following: % dzdo ls /usr/local/protected To edit the index.html file as the user webmaster: % dzdo -u webmaster vi ~www/htdocs/index.html To shut down a computer, you would type a command similar to the following: % dzdo shutdown -r +15 "quick reboot" To make a usage listing of the directories in the /home partition, you would type a command similar to the following: % dzdo sh -c "cd /home ; du -s * sort -rn > USAGE" Note that this example command line opens a sub-shell (sh) before running the commands that generate the listing. Running the commands in a sub-shell is required to make the cd command and file redirection work. However, allowing the user to open a new shell as a privileged command can inadvertently result in giving the user root access in the invoked shell and is not recommended in most cases. Using dzedit The dzedit program enables you to edit a file as another user. It is similar to using dzdo with the -e option. Administrator s Guide for Linux and UNIX 366

367 Using dzedit The basic syntax for using the dzedit program is: dzedit [options] [-g groupname #gid] [-p prompt] [-u user name #uid] file To use the dzedit program, you must have a role with permission to run dzedit as a privileged command or as an allowed restricted environment command. You can configure the right to run dzedit by using DirectManage Access Manager or ADEdit commands. If a user is granted permission to run dzedit, the program does the following when invoked: Creates temporary copies of the files to be edited with the file owner set to the invoking user. Starts the editor specified by the VISUAL or EDITOR environment variable edit the temporary files. If neither environment variable is set, the dzedit program uses the editor listed in the editor sudoers variable. If the specified file does not exist, it is created. If the files are modified, dzedit copies the temporary files back to their original location and the temporary versions are removed. If dzdo is unable to update a file with its edited version, the user will receive a warning and the edited copy will remain as a temporary file. Note Unlike most dzdo commands, the dzedit program is run with the invoking user s environment unmodified. The dzedit program makes temporary copies of the files to be edited before invoking the editor to prevent users from issuing a shell escape in the editor that would then allow the user to run any command as the target user. By using dzedit to edit the temporary file then replace the original file after editing, users can t use a shell escape in an editor to open a new shell and run any command as the target user. Setting valid options You can use the following options with the dzedit command: Use this option To do this -A Get the password from a helper program rather than from the terminal. The command will exit with an error if a helper program cannot be found. -C filedescriptor Do not close file descriptors before the specified number when dzedit exits. Normally, the program closes all open file descriptors except standard input, standard output, and standard error. This option allows you to specify a starting point above standard error (file descriptor 3). Values less than 3 are not allowed. Appendix A Using Centrify UNIX commands 367

368 Using dzedit Use this option To do this -g groupname gid Specify the primary group name or numeric identifier to set for the specified command. The definition for a command right contains a list of valid groups that may be used with this option it could be restricted to certain groups or may include all valid groups. If you aren t sure, or receive an error when running the command, check with your Centrify zone administrator. To specify a group by GID instead of the group s name, use '#gid' enclosed in single quotes. For example, to run adquery as a privileged command and set the primary group as the group with the numeric GID of 101, you could type a command similar to the following: dzdo -g '#101' adquery -k Invalidate the user s login timestamp by setting the time on it to the epoch. This option does not require a password. After using this option, however, the next time the user attempts to run dzdo, it will prompt for a password. This option allows a user to revoke dzdo permissions from a.logout file. -n Prevents dzedit from prompting for a password. -p prompt Allows you to override the default password prompt and use a custom one. The following percentage (%) escapes are supported: %u expands to the invoking user's login name. %U expands to the login name of the target user the command will run as, for example, root by default. %h expands to the local computer s host name without its domain name. %H expands to the local computer s host name including the domain name. %% collapses into a single % character. -S Reads the password from standard input instead of the terminal device. -u username uid Runs the specified command as a user other than root. The definition for a command right contains a list of valid users that may be used with this option it could be restricted to certain users or may include all valid users. If you aren t sure, or receive an error when running the command, check with your Centrify zone administrator. The dzedit command will recognize any user name that is an equivalent of the username specified for the command to be run. For example, if permission is given to bob.smith (the Active Directory name) to run adinfo as a a privileged command, and if bob.smith has a UNIX profile name, for example, bsmith, you can specify bsmith when you use dzdo to run adinfo: dzdo -u bsmith adinfo To specify a user by UID instead of the user s login name, use '#uid' enclosed in single quotes. For example, to run adquery as a privileged command and as the user with the numeric UID of 101, you could type a command similar to the following: dzdo -u '#101' adquery Administrator s Guide for Linux and UNIX 368

369 Using dzinfo Using dzinfo The dzinfo command displays detailed information about the configuration of rights and roles for one or more specified users on the local computer. If you do not specify a user, dzinfo returns information for the currently logged on user. The basic syntax for the dzinfo command is: dzinfo [username] [--commands] [--diag] [--format] [--pam] [--roles] [-- computer-role] [--test command] [--verbose] [--all] [--version] To specify one or more user names on the command line, you must be logged on as root. The dzinfo command also requires that you are running the agent with a license. By default, the dzinfo command displays all roles and rights for the specified user, including role availability settings, start or expiration times, and audit integration. The --commands, --pam, and --roles options are intended to limit the information displayed to a single set of rights. For example, you can use the --pam option to display only the PAM-enabled applications that the specified user is allowed to access. Similarly, the -- commands option lists only the commands that the user is allowed to run. The commands listed, however, may be privileged commands that can be invoked using dzdo or commands that are allowed in restricted environments. The --roles option lists only the roles the user has been assigned. If you don t specify one of these options to limit the information displayed, the dzinfo command returns information for all three sets of rights. Setting valid options You can use the following options with this command: Use this option username[@domain] -c, --commands -d, --diag -f, --format To do this Specify the Active Directory user by UNIX profile name or Active Directory name that you want to display DirectAuthorize details for. You can specify this option multiple times to retrieve and display the information for multiple users. If you don't specify the username, the command returns information for the currently logged on user. Note You must be logged on as root to specify a user name. Display only information about the privileged or restricted environment commands the user can run. This option displays all of the commands the user is allowed to run as privileged commands or restricted environment commands. Include extended, diagnostic information in the command output. This option is intended for troubleshooting potential problems with the authorization store. Generates formatted output that can be used in scripts. The output separates the properties of each object into a single line with a colon (:) between each field. The basic output format is: user:object;property:value For example, for the user maya, you might see output like this: maya:role:localuser:no maya:role:role Name:dba Appendix A Using Centrify UNIX commands 369

370 Using dzinfo Use this option -p, --pam -C, --computer-role -r, --roles -t, --test command -V, --verbose -A, --all -v, --version To do this Display only information about the PAM-enabled applications the user has permission to access. Display information about the computer roles for users on this computer. This option requires root privilege. Specify a user to show computer roles for that user, or do not specify a user to show all computer roles for this computer. Display only the roles to which the specified user is assigned. Check whether the specified command can be run by the user using dzdo or in a restricted environment. The command argument must be enclosed by quotation marks and be the full path to a specific executable (a binary or a script). The specified command is then tested both as a privileged command using dzdo, and as a restricted environment command for the specified user. You must specify the full path to the command you want to test in order to fully distinguish it from other commands of the same name that may be in your current $PATH. For example, this option enables you to test whether jae_m can run /bin/ls even if root accesses the ls command in /sbin/ls: dzinfo jae_m -t bin/ls The command results are printed to standard output. Provide more complete information about the DirectAuthorize configuration in the command output. Provide the most complete information about the DirectAuthorize configuration in the command output, including information about environment variables. Display version information for the installed software. This option cannot be combined with any other options. Examples of using dzinfo To display complete configuration information for the user molly, you would type a command similar to the following: dzinfo molly If roles and rights have been configured for the user, the command displays information similar to the following: User: molly Forced into restricted environment: No Role Name Avail Restricted Env UNIX Login/HQ Yes None Unix1/seattle Yes None Effective rights: Password login Non password login Ignore user disabled Allow normal shell Administrator s Guide for Linux and UNIX 370

371 Using dzinfo Audit level: AuditIfPossible Always permit login: true PAM Application Avail Source Roles * Yes UNIX Login/HQ sshd Yes Unix1/seattle ssh Yes Unix1/seattle * Yes Unix1/seattle Privileged commands: Name Avail Command Source Roles root_any/hq Yes * Unix1/HQ Commands in restricted environment: Name Avail Command Run As root_any/hq Yes * self To test whether the user sonya is authorized to run the uname command, you could type a command similar to the following: dzinfo sonya --test "/usr/bin/adflush" The command displays information similar to the following: Testing: User = sonya command = /usr/bin/adflush User sonya can run the command as 'root' via dzdo, authentication will not be required, noexec mode is off User sonya is not allowed to run the command in restricted environment To display more detailed information, such as the effective and expiration dates of the available hours for a role, use the --verbose (-V) command line option. Understanding dzinfo result codes The dzinfo command returns the following result codes upon exit: Result code Indicates 0 Command executed successfully. 6 The attempt to execute the command generated unexpected errors. 7 The command line contained a usage error. 9 Root privilege is required to perform the selected operation. Appendix A Using Centrify UNIX commands 371

372 Using dzsh Using dzsh The dzsh restricted environment shell is a customized Bourne shell for DirectAuthorize that provides environment variables, job control, command history, and command access as defined by DirectAuthorize roles. The restricted environment only allows the user to run the specific commands that have been defined in the user s assigned DirectAuthorize roles. Note The dzsh command requires that you are running agent with a license. If a user is assigned to one or more roles with a restricted environment, only one of those roles may be designated as the active role at any point in time and only the commands defined for that active role are allowed to run. Within the restricted environment, however, the user can change the active role or view information about the roles available by running the role command. The role command allows the user to list, change, and query information about the currently active and available roles. Although dzsh can be used as the interpreter for a script (for example, #!/usr/bin/dzsh), this is not the intended, or recommended usage. Instead, the dzsh shell is intended to function as an interactive shell for restricted environment users. Those users can be given the right to run specific scripts as well as commands, where the scripts should be interpreted by an existing system shell application. Commands in a restricted environment can be executed as the current user or a specified user. If a command is configured in DirectAuthorize to be executed as a specific user, the dzsh shell automatically reforms the command and executes it as the specified user, without requiring another command, such as sudo, to be used. Setting valid options You can use the following options with the restricted environment shell: Use this option -c, --command cmd_string To do this Execute the command(s) contained in specified cmd_string. This option is useful for testing a user s authorization to run a specific command. This option is the same as running the standard Bourne shell with the -c option, for example: /bin/sh -c "some command" -v Display version information for the installed software. This option cannot be combined with any other options. Administrator s Guide for Linux and UNIX 372

373 Using dzsh Understanding the limitations of the restricted environment The restricted environment does not enforce rights for commands run outside of the shell. For example, if using a graphical desktop manager, the user can run commands and applications that are launched from menu selections in the graphical user interface. In addition, limiting the user s command set in the dzsh shell does not prevent the user from running built-in shell commands, accessing the file system, or seeing process or system information. For example, even in a restricted environment with no rights to run any commands, a dzsh user could get a process listing using the following script: for i in /proc/[0-9]*; do read PROC < $i/cmdline; echo $PROC; done Because the shell scripting environment allows the operations, the user can effectively access information that the command set defined for his restricted environment does not allow. Using the role command in a dzsh shell The DirectAuthorize restricted environment shell includes the built-in role command. The role command enables the user to change the currently active role or view summary or detailed information about the roles the user has been assigned. Understanding role syntax The basic syntax for using the built-in role command is: role [role_name] [-h] [-l] If no command line options are specified, running the built-in role command displays the name of the currently active role. Setting valid role options You can use the following options with the role command in a DirectAuthorize restricted environment shell: Use this option role_name To do this Change the active role to the role_name specified. -h Display the usage message. -l List the available restricted environment roles for the current user. Running startup and rc scripts The dzsh restricted environment shell executes the following scripts when started: The /etc/dzsh_profile and ~/.dzsh_profile startup scripts are executed automatically by dzsh when a user logs in. The /etc/dzsh_profile script can run any Appendix A Using Centrify UNIX commands 373

374 Using dzsh commands that a normal shell can run without any restrictions from DirectAuthorize. The commands that can be executed in the ~/.dzsh_profile startup script are restricted to the commands allowed by DirectAuthorize to run inside a dzsh shell. The /etc/dzshrc and ~/.dzshrc are executed automatically by dzsh when a user opens a dzsh restricted environment shell. The /etc/dzshrc script can run any commands that a normal shell can run without any restrictions from DirectAuthorize. The commands that can be executed in the ~/.dzshrc startup script are restricted to the commands allowed by DirectAuthorize to run inside a dzsh shell. Understanding dzsh result codes The restricted environment shell returns 0 if command execution is successful, or the return code of the command that failed if command execution is not successful. Examples of using dzsh After logging on as a user assigned to the role test_lab with a restricted environment, the dzsh shell displays the active role. For example: You are in role: test_lab $ To list all of the roles for the current user and their status, you would type a command similar to this: $ role -l test_lab web_maint backup_team $ To change the active role for the user: $ role web_maint Role changed to: web_maint $ If the user attempts to run a command that is not allowed in the current role and restricted environment, the dzsh shell will reject the command. For example: $ clear clear: command not allowed To switch between roles that allow the id command to run as root (in the test_lab role) or the current user (in the backup_team role), you would type the following command to set the active role to test_lab: $ role test_lab Role changed to: test_lab You can then run id in that role and view the results. For example: $ id uid=0(root) gid=0(root) groups=10000(samson) context=user_u:system_r:unconfined_t To change the active role to backup_team, you can type the following command: $ role backup_team Administrator s Guide for Linux and UNIX 374

375 Using nisflush Role changed to: backup_team If you run id in the new active role, you will notice the difference in the results. For example: $ id uid=10000(samson) gid=10000(samson) groups=10000(samson) context=user_u:system_r:unconfined_t $ Using nisflush The nisflush command can be used to clear the Centrify Network Information Service cache on a local computer, or restart the service without flushing the cache. The Network Information Service cache stores the NIS maps for network information that are retrieved from Active Directory. Note The nisflush command requires that you are running the agent with a license. The basic syntax for the nisflush program is: nisflush [option] To run the nisflush command, you must be logged in as the root user. Setting valid options You can use the following options with this command: Use this option -f, --force -r, --restart -h, --help To do this Clear the cache of all data even if the Centrify UNIX agent, adclient, is currently disconnected from Active Directory. Restart the Network Information Service without flushing the cache. Display the usage message. Examples of using nisflush The nisflush command enables you to clear the cache for the Centrify Network Information Service at any time. This command can be useful when you want to force the Centrify UNIX agent to read new information from Active Directory, or when you want to remove obsolete data from the cache. You can also use this command as part of routine housekeeping to free up disc space. To clear the cache of NIS maps for network information from the Active Directory, you would type: nisflush To clear the cache of NIS maps for network information from the Active Directory when the local computer is disconnected from the network, you would type: nisflush --force Appendix A Using Centrify UNIX commands 375

376 Using OpenLDAP commands Using OpenLDAP commands Centrify includes a set of OpenLDAP commands that have been modified to better support the Active Directory environment. The Centrify distribution of OpenLDAP supports all of the standard options and syntax for performing LDAP operations, but the ldap commands in the Centrify distribution of OpenLDAP also support the following options that are not supported in a standard OpenLDAP distribution: Use this option To do this -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 distribution of OpenLDAP also provides extended URL support for Active Directory. With Centrify LDAP commands, you can use the following URLs to connect to Active Directory computers: Use this ldap://domain_name ldap:// gc://[domain_name] To do this Connect to the appropriate domain controller for the specified domain within the Active Directory site. Connect to the joined domain. 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 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. Using LDAP server and adclient to retrieve results In addition to the OpenLDAP commands optimized to work with Active Directory, Centrify provides a separate LDAP server configuration (ldapproxy) that you can use to enable applications that cannot search Active Directory directly, for example, because they Administrator s Guide for Linux and UNIX 376

377 Using OpenLDAP commands don t support Kerberos or GSS, to look up information in Active Directory through the Centrify UNIX agent, adclient. With the ldapproxy configuration, the LDAP server submits LDAP client search requests through adclient s secure connection to Active Directory and returns the results as un-formatted results without any interpretation of the data (search-only mode). Installing the LDAP proxy files The LDAP server configuration (ldapproxy) is available with the Centrify UNIX agent or from the Centrify Download Center as a separate software package. To install the LDAP proxy server file: 1 On the UNIX computer, log in as or switch to the root user. 2 Copy the appropriate package for the local computer s operating environment from the Centrify CD or download directory to a local directory. For example, if the operating environment is Solaris 9 SPARC: cp /tmp/centrifydc-ldapproxy-release-sol8-sparc-local.tgz. If you aren t sure which file to use for the local operating environment, see the releasenotes text file included in the package. 3 If the software package is a compressed file, unzip and extract the contents. For example, on Solaris: gunzip -d centrifydc-ldapproxy-release-sol8-local.tgz tar -xf centrifydc-ldapproxy-release-sol8-sparc-local.tar 4 Run the appropriate command for installing the package based on the local computer s operating environment. For example, on Solaris: pkgadd d CentrifyDC-ldapproxy -a admin If you aren t sure about the command to use for the local operating environment, see the release-notes text file included in the package. If you are using an installation program not described in the release-notes text file, such as SMIT or YAST, see the documentation for that program. Configuring and starting the LDAP proxy To use the LDAP server as a proxy to retrieve information from Active Directory: 1 Verify the local computer is joined to an Active Directory domain and that the adclient process is running. The adjoin command automatically creates the LDAP server configuration file and configures it with Access Manager- and domain-specific information: /etc/centrifydc/openldap/slapd.conf 2 Start the LDAP server process in one of two ways: Appendix A Using Centrify UNIX commands 377

378 Using OpenLDAP commands Directly: /usr/share/centrifydc/libexec/slapd By specifying the configuration file (you can run multiple LDAP proxies with different configurations by specifying different configuration files); for example: /usr/share/centrifydc/libexec/slapd -f /etc/centrifydc/openldap/ slapd.conf You can then use the ldapsearch command to search Active Directory for entries. For example, to search Active Directory for the Administrator account (cn=administrator), you could type a command similar to this: /usr/share/centrifydc/bin/ldapsearch -h localhost -x -b "dc=domain,dc=com" "(cn=administrator)" Searching for users and groups If you want to use ldapsearch to find a user, do not use objectclass=user or objectcategory=person to specify the filter. Instead, you should use objectclass=posixaccount. For example, to find the user with the UNIX name jtr you would enter a command similar to the following: /usr/share/centrifydc/bin/ldapsearch -x -h localhost -D CN=Administrator,CN=Users,DC=pistolas,DC=org -W -b dc=pistolas,dc=org "(&(objectclass=posixaccount)(uid=jtr))" You can also use "(&(objectclass=posixaccount)(uidnumber= ))" to use the UID number instead of the UNIX name. Similarly, use objectclass=posixgroup to retrieve information on a group. This filter supports the following options: cn: Find a group with a given UNIX name gidnumber: Find a group with a given GID memberuid: Search for secondary group membership of given UNIX user. Searching the global catalogs In most cases, you use the Centrify LDAP proxy server to search for information through the domain controller. However, you can also use the Centrify LDAP proxy server to perform searches in the global catalog, if needed. The global catalog search is especially useful if you have a large, multiple-domain forest. To specify that you want the Centrify LDAP proxy server to search the global catalog, you should add "CN=$" to the front of the search base. For example, to search Active Directory for a specific account in the global catalog, you might type a command similar to this: /usr/share/centrifydc/bin/ldapsearch -h localhost -x -b "cn=$,dc=ajax,dc=org" "(cn=amy.adams)" Administrator s Guide for Linux and UNIX 378

379 Appendix B Running managed computers in FIPS mode Federal Information Processing Standard 140-2(FIPS 140-2) describes US Federal government requirements that IT products should meet for sensitive, but unclassified use. The standard was published by the National Institute of Standards and Technology (NIST) and is required by non-military agencies of the United States Government and is used by many other organizations. The standard defines the security requirements that must be satisfied by a cryptographic module used in a security system protecting unclassified information within IT systems. There are four levels of security: from Level 1 (lowest) to Level 4 (highest). These levels are intended to cover the wide range of potential applications and environments in which cryptographic modules may be deployed. The security requirements cover areas related to the secure design and implementation of a cryptographic module. The Centrify agent can be configured to use FIPS-compliant encryption so that a managed computer can successfully join a domain that is FIPS 140-2, Level 1, compliant. Note In this appendix, FIPS compliant means Level 1 compliant. The following topics are covered: Introduction to Centrify FIPS compliance Setting up the Windows environment Configuring the agent for FIPS mode Introduction to Centrify FIPS compliance FIPS mode is implemented using the Centrify Use FIPS compliant algorithms for encryption, hashing and signing policy. Do not use the equivalent Windows policy to configure FIPS-compliant communications to UNIX computers. This policy is implemented by a separate XML or ADM template file (centrifydc_fips.xml or centrifydc_fips.adm) included in the Centrify group policy extension. You must add one of these templates to enable FIPS mode. See the Group Policy Guide for the instructions. After you enable the policy, it takes effect the next group policy update interval. The Centrify FIPS group policy is specifically designed to support Windows environments that are configured for FIPS

380 Setting up the Windows environment Agent requirements for FIPS-compliant encryption You can only configure FIPS mode for Centrify agents if you deploy Centrify agents, version or later. In addition, FIPS mode is only supported on specific distributions of Linux and Mac OS X operating systems. For a complete and up-to-date list of the platforms that Centrify supports in FIPS mode, see the NIST validation entry for Centrify FIPS mode. NTLM authentication The Centrify agent does not support NTLM authentication through SMB or SMB2 when configured to use FIPS-compliant encryption. FIPS mode only allows NTLM pass-through authentication over SChannel. Note that this requires a Windows 2008 R2, or later, domain controller. Non-compliant operations When configured to run in FIPS mode, the agent does not use non-fips compliant encryption algorithms. However, the agent does use non-fips compliant hash and key-hash algorithms, as follows: MD4, MD5 and HMAC-MD5 are used to support NTLM pass-through authentication (including using NLTM for PAM authentication). MD4 is used to generate the managed computer password hash for use in setting up AES NetLogon Secure Channel. AES NetLogon Secure Channel is used for NTLM pass-through authentication as well as for updating operating system version attributes. MD5 is used to generate the UNIX password hash for the login user that is stored in the cache for disconnected login. For information about requirements for the Windows environment, see the next section Setting up the Windows environment. Setting up the Windows environment For a managed computer to join a FIPS domain, the Windows environment must meet the following basic requirements: The domain must be at domain functional level Windows 2008, or above. The forest must have at least one global catalog computer that is running at domain functional level 2008, or above. The domain must have at least one Windows 2008 R2, or above, domain controller. Any trusted domains you plan to access must be at domain functional level Windows 2008, or above. Administrator s Guide for Linux and UNIX 380

381 Setting up the Windows environment Although a managed computer can successfully join a domain that has trust relationships to domains at a lower functional level, it cannot access users in those trusted domains, for example, to add user profiles or roles to a zone. Configuring the encryption types for trusted domains Inter-realm keys for the AES256-CTS and AES128-CTS encryption types must be established between any trusted domains to enable Active Directory users from these domains to log on to the joined computer. You can use the ksetup utility, installed by default on the domain controller, to set up the inter-realm keys. To configure the inter-realm keys 1 On the domain controller, open a Command Prompt window. 2 Type the following commands: C:\>ksetup.exe /SetEncTypeAttr trusteddomain AES256-CTS-HMAC-SHA1-96 C:\>ksetup.exe /SetEncTypeAttr trusteddomain AES128-CTS-HMAC-SHA1-96 If you are using pre-validated Active Directory users, you must enable these users for Kerberos AES 128- and 256-bit encryption. You can do so by editing the users accounts in Active Directory or by setting attributes for the users in ADSI Edit. Manually configuring permissions for a managed computer If the domain that the managed computer is joining does not have at least one Windows 2008 R2 domain controller, you must grant write permission for the Operating System Version and msds-supportedencryptiontypes attributes to the computer account of the joined computer. If the domain does have at least one Windows 2008 R2 domain controller, you can ignore this section. To grant write permission for required attributes to the computer account 1 Open Active Directory Users and Computers or ADSI Edit. 2 Expand the Computers container and select the computer that is joining the domain, then right-click and click Properties. 3 Click the Security tab, then click Advanced. 4 Click Add. 5 In the Enter the object name to select field, type SELF and click OK. 6 Click the Properties tab. 7 Select This object only from the Apply to list, then scroll down and click Allow for Write msds-supportedencryptiontypes and Write Operating System Version attributes. Appendix B Running managed computers in FIPS mode 381

382 Setting up the Windows environment 8 Click OK in each dialog box to close the dialog and save the new permissions. To grant update permission to a user who will join the computer to the domain 1 Open Active Directory Users Computers or ADSI Edit. 2 Expand the Computers container and select the computer that is joining the domain, then right-click and click Properties. 3 Click the Security tab, then click Advanced. 4 Click Add. 5 In the Enter the object name to select field, type the name of the Active Directory user who will join the managed computer to the domain and click OK. 6 Click the Properties tab. 7 Select This object only from the Apply to list, then scroll down and click Allow for Write msds-supportedencryptiontypes and Write Operating System Version attributes. 8 Click OK in each dialog box to close the dialog and save the new permissions. Enabling required encryption types for pre-validated users If you are using pre-validated Active Directory users, you must enable these users for Kerberos AES 128- and 256-bit encryption. You can do so by editing the users accounts in Active Directory Users and Computers or by setting attributes for the users in ADSI Edit. Note If you do not have pre-validated users, you can skip this section. To enable encryption for pre-validated users by using Active Directory Users and Computers 1 On the domain controller, open Active Directory Users and Computers. 2 Navigate to the domain and select Users. 3 Select the pre-validated user, then right-click and select Properties. 4 Click the Account tab. 5 Select both of the following Account options: This account supports Kerberos AES 128 bit encryption. This account supports Kerberos AES 256 bit encryption. 6 Click OK to save the updated account information. To enable encryption for pre-validated users by using ADSI Edit 1 On the domain controller, open ADSI Edit. Administrator s Guide for Linux and UNIX 382

383 Configuring the agent for FIPS mode 2 Navigate to the domain and select CN=Users. 3 Select the user, right-click, then select Properties. 4 In the Attribute Editor tab, select the msds-supportedencryptiontypes attribute and select Edit. 5 Type 0X18 to set the hex value for the attribute and click OK. You should see that the value shows: 0x18=(AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96) 6 Click OK to save the new setting. Configuring the agent for FIPS mode FIPS mode is controlled by the fips.mode.enable parameter in the Centrify configuration file. By default, this parameter is set to false. Setting it to true and restarting adclient enables FIPS mode. Centrify provides the following group policy to set the configuration parameter to enable FIPS mode on all computers to which the policy applies: Computer Configuration > Centrify Settings > DirectControl Settings > Use FIPS compliant algorithms for encryption, hashing and signing Enabling this policy, rather than manually setting the fips.mode.enable parameter manually on individual computers, is the recommended way to enable FIPS mode. Using the group policy template to enable FIPS mode If you use the XML group policy template (but not the ADM template) to enable FIPS mode, the policy verifies that each computer is joined to a domain at domain functional level Windows 2008, or above. If a domain controller does NOT meet this minimum domain functional level, the policy issues a warning that allows you to not enable FIPS mode for that computer. The XML group policy template (but not the ADM template) also verifies all computers to which the policy applies are running a supported operating system. On the computers that are running a supported operating system, the policy sets the fips.mode.enable configuration parameter to true and automatically stops and restarts adclient. After the restart, the computers are in FIPS mode. If the computer is not running a supported platform, the policy leaves the fips.mode.enable configuration parameter set to false, and does not stop and restart adclient. The computer remains joined and the current encryption and hashing algorithms remain in force. Appendix B Running managed computers in FIPS mode 383

384 Recovering from a FIPS-mode error How Centrify FIPS mode affects other encryption settings If you enable FIPS mode, you cannot specify the Data Encryption Standard when joining the domain. The adjoin --des option is not supported. Only AES authentication is supported. If you have specified multiple types of encryption for the computer by setting the adclient.krb5.permitted.encryption.types parameter in the centrifydc.conf configuration file, only aes256-cts and aes128-cts encryption type keys are generated and saved to the keytab file. However, if arcfour-hmac-md5 encryption is specified, the MD4Hash of the machine password will be generated and saved to the keytab file. In addition, depending on how your environment is configured, you can choose whether to remove any non-aes encryption keys for service principal names (SPNs) from the computer's keytab file by setting the adclient.krb5.clean.nonfips.enctypes parameter in the centrifydc.conf configuration file. If you set this parameter to true, adclient scans the keytab file and removes any non-aes encryption keys for SPNs during startup. This parameter is false by default. Checking whether the FIPS is enabled You can determine if the computer is already in FIPS mode by running the adinfo command: # adinfo --fips Enabled Manually configuring FIPS mode If you manually set the fips.mode.enable parameter in the centrifydc.conf configuration file, you must restart adclient to enable FIPS mode: /usr/share/centrifydc/bin/centrifydc restart If the computer is joined to a domain with a functional level below Windows 2008, adclient will not start and will return this error message: Cannot start adclient in FIPS Mode as machine is joined to domain with Pre- Windows 2008 Domain Functional Level! Recovering from a FIPS-mode error The adclient process must be restarted to enable FIPS mode but will fail to start if a computer is joined to a domain with a functional level below Windows If you set FIPS mode by enabling the Use FIPS compliant algorithms for encryption, hashing and signing policy with the XML templates, you should never encounter this situation because the XML implementation of the policy validates the domain functional level. However, if you use the ADM template, which does not perform validation checks, or if you manually enable FIPS mode by setting the fips.mode.enable parameter in the configuration file, adclient will fail to start if the domain functional level is inadequate. Administrator s Guide for Linux and UNIX 384

385 Recovering from a FIPS-mode error To recover from this error, complete one of the following procedures depending on whether you manually enabled FIPS mode or set it with the group policy from the ADM template: To recover from a FIPS mode error when manually setting FIPS mode 1 On each computer that returned the error, open the centrifydc.conf configuration file in a text editor. Find the fips.mode.enable parameter and change its value to false. fips.mode.enable: false 2 On each computer that returned the error, restart adclient: /usr/share/centrifydc/centrifydc restart 3 If necessary, leave the current domain and join a Windows 2008 domain. It is recommended that you apply the Use FIPS compliant algorithms for encryption, hashing and signing group policy to a Windows 2008 domain to enable FIPS mode, rather than enabling FIPS mode manually in the Centrify group policy. If this policy has been applied to the domain, then the computer will be enabled for FIPS mode automatically when it joins the domain. Otherwise, when joining a new domain, you must enable FIPS mode manually by again editing the configuration file and changing fips.mode.enable to true. To recover from a FIPS mode error when setting FIPS mode by ADM group policy 1 In the Group Policy Management Editor, open the policy: Computer Configuration > Centrify Settings > DirectControl Settings > Use FIPS compliant algorithms for encryption, hashing and signing and select Not configured. Save the policy. 2 On each computer that returned the error, leave the domain by using the force option if necessary: adleave --force 3 Rejoin the domain. Appendix B Running managed computers in FIPS mode 385

386 Index A Access Manager console installing 21 prerequisites 29 account mapping groups pending import 95 other local users 125 purpose of 124 Active Directory enabling existing users 109 forest integrity for zones 207 mapping Unix fields 91 role assignments 162 Windows infrastructure 12 Active Directory Users and Computers managing computer properties 75 user properties 109 adcache command reference 348 examples 349 options 348 adcheck command reference 248 adchzone 250 adclient log file 206 starting and stopping 346 addbloader 353 addebug command reference 294 examples 295 options 295 addns examples 356 options 355 adfinddomain command reference 305 examples 306 options 305 adfixid examples 310, 313, 375 options 308 overview 306 adflush command reference 313 options 313 adgpupdate examples 285 options 285 adid command reference 314 examples 314 options 314 adinfo command reference 285 displaying help 230 examples 291 introduction 219 options 286 when to use 230 adjoin command reference 233 displaying help 230 examples 241 operations performed 74 options 234 when to use 230 adkeytab adding service principals 323 deleting accounts 337 deleting service principals 335 encryption types 339 file entries 315 new service accounts 318 overview 315 password changes 331 reset key tables 333 adleave changing a computer s domain 84 command reference 245, 369 displaying help 230 examples 247 options

387 when to use 230 adlicense options 249, 252 adlicense command reference 251 admigrate command reference 296 adobfuscate command reference 299 examples 301 options 251, 297, 300, 351, 353 adpasswd command reference 252 displaying help 230 examples 254 options 253, 372 when to use 230 adquery command reference 274 examples 281 group 279 user 275 when to use 230 adreload examples 353 options 353 adreport 351 adrmlocal examples 304 options 304 adsendaudittrailevent 343 examples 343 options 343 adsetgroups command reference 343 examples 345 options 344 adsmb command reference 341 examples 342 options 341 adupdate add group 267, 269 add user 256 delete group 271, 272 delete user 267 displaying help 230 modify group 269, 271 modify user 261 overview 255 agentless authentication introduction 27 applications access rights 133 authentication issues 12 licenses 181 Audit rights 133 authorization 133 to 135 application names 136 configuring rights 135, 154 privileged commands 133 restricted environments 134 rights defined 133 role definition 133 Auto Zone about 35 C Centrify additional resources available 10 Centrify access control access control summary 17 command line programs 230 daemon 346 diagnostic information 219 managed system 17, 19 optional tools 22 password enforcement 122 platform-dependent components 19 property extensions 21 solution overview 13 to 16 starting the first time 30 support for UNIX services 23 troubleshooting issues 206 updating license keys 181 Centrify UNIX agent architecture 23 key tasks 23 Centrify website 10 command line programs basic usage 230 displaying help 230 location 230 man pages 230 computer account Index 387

388 prepare 76 computer accounts changing the zone 82 domain changes 84 password interval 75 pre-join creation 76 reporting 189 running adjoin 74 secured by password 75 conventions, documentation 9 D daemon enabling logging 206 introduction 346 Data Encryption Standard for keys FIPS mode and 384 setting for computer account 238 specifying for service principals 321, 330 diagnostic information 219, 291 disconnected operation account changes 123 credential storage 123 documentation additional 10 audience 9 conventions 9 installing on Windows 22 domain controllers adding DNS server role 222 setting manually 223 testing connectivity 221 Domain Name Server (DNS) manual setting 221 nameserver entry 221 server role 220, 222 services provided 220 testing connectivity 221 using a forwarder 222 duplicate UNIX users 207 dzdo command reference 358 examples 366 options 360, 367, 369 dzinfo creating a privileged command 169 current user information 170 running for a specified user 169 dzsh shell 134 F FIPS-mode 379 to 385 G glob pattern matching 140 to 141 global catalog, defining manually 223 group policy editor extension 22 groups exporting roles 166 importing roles 166 NIS import 88 to 90 reporting 189 required membership 103 role assignment 161 to 162 H heterogeneous environments 11 I identity management importance 11 multiple mechanisms 12 simplifying 12 importing from Unix accessibility from Windows 88 NIS maps 88 to 90 pending state 91 installation restarting services 33 running setup on Windows 30 J join operation command reference 233 key tasks performed 74 specifying arguments 79 user restrictions 75 K keytab files 315 Administrator s Guide for Linux and UNIX 388

389 L licensing adding keys 186 deleting keys 186 introduction 180 multiple keys 181 permanent keys 181 reports 187 types 180 to 181 updating keys 181 viewing a summary 185 Linux naming convention 9 log files adinfo output 219 location 218 performance impact 218 purpose 206 M man pages displaying 230 managed system 17, 19 Microsoft Services for UNIX (SFU) support for 16 N Network Information Service (NIS) agentless authentication 27 extension for maps 22 importing maps 88 to 90 nisflush command reference 375 example 375 options 375 NSS configuration modification 24 reverting to pre-join state 84 O online help 22 OpenLDAP 376 P PAM configuration access rights 133 agent component 24 application names 136 reverting to pre-join state 84 typical log on process 24 password management changing your own 122 disconnected mode 124 policy definition 122 policy enforcement 18 resetting for other users 123 pattern matching glob 140 to 141 regular expressions 140 to 141 pending import group information 91 manual process 91 NIS information 91 permissions renaming a zone 47 prepare computer account 76 privileged command command reference 358 privileged commands defined 133 running with dzdo 163 property extensions 21 R regular expression pattern matching 140 to 141 rename a UNIX server 85 reporting forest analysis 207 group information 189 privileged command rights 178 purpose of 188 role assignments 179 role privileges 179 saving 195 zone information 190 restricted environments adding shell commands 142 to 145 creating 140 defined 134 limitations 155, 373 rights collected in roles 133 copying 166 exporting 166 Index 389

390 importing 166 operation types 133 PAM access 135 reporting 178 roles assigning users and groups 161 availability 152 copying 166 creating 151 exporting 166 importing 166 job functions 151 making active 164 reporting 178 start and expiration 162 root user adinfo options 219 adleave operation 245 adnisd installation 377 changing the domain 84 enabling logging 217 installation requirement 32 join operation 233 leaving the domain 85 local override account 127 S Setup Wizard creating the Zones container 31 System rights 133 T troubleshooting daemon operation 206 enabling logging 217 forest integrity 207 using adinfo 219 U universal groups 100 UNIX authentication mechanisms 12 command line programs 230 importing local users 88 man pages 230 naming convention 9 restarting services 33 server licenses 181 UNIX computers changing the zone 82 domain changes 84 joining a domain 74 restricting who can join 76 server and workstation licenses 181 UNIX groups duplicate information 207 UNIX users duplicate information 207 enabling in Active Directory 109 local account mapping 124 users account mapping 124 account status report 190 disconnected logins 123 exporting roles 166 importing roles 166 NIS import 88 to 90 password policies 122 reporting 190 role assignment 161 to 162 W web applications licensing 181 webinars 10 Windows reliance on Active Directory 12 workstation licenses 180 Z Zone Delegation Report 190 zones adding computers 50 advantages of using 34 to 35 changing default properties 44 changing for a computer 82 checking integrity 207 closing 42 creating additional 38 to 39 delegating control 42 importance of properties 38 opening 42 parent container 31 reports 190 Administrator s Guide for Linux and UNIX 390

391 understanding the use of 34 to 35 using multiple 35 Index 391