Red hat enterprise_linux-6-identity_management_guide-en-us
Red Hat Enterprise Linux 6 Identity Management Guide 1Red Hat Enterprise Linux 6.3 Identity Management Guide Managing Identity and Authorization Policies for Linux-Based Infrastructures Edition 2.2.0 Ella Deon Lackey firstname.lastname@example.org
Red Hat Enterprise Linux 6 Identity Management Guide 3AbstractIdentity and policy management — for both users and machines — is a core function for almost anyenterprise environment. IPA provides a way to create an identity domain that allows machines to enroll toa domain and immediately access identity information required for single sign-on and authenticationservices, as well as policy settings that govern authorization and access. T his manual covers allaspects of installing, configuring, and managing IPA domains, including both servers and clients. T hisguide is intended for IT and systems administrators.
4 Table of ContentsTable of Contents Preface 1. Audience and Purpose 2. Examples and Formatting 2.1. Brackets 2.2. Client T ool Information 2.3. T ext Formatting and Styles 3. Giving Feedback 4. Document Change History Release Information 1. New Features in 6.3 2. Upgrade Notes for IPA 2.2 3. Fixed in 6.3 4. Known Issues in 6.3 4.1. A Note on Internet Explorer Support on Windows 4.2. List of Issues 1. Introduction to Identity Management 1.1. IPA v. LDAP: A More Focused T ype of Service 1.1.1. A Working Definition for Identity Management 1.1.2. Contrasting Identity Management with a Standard LDAP Directory 1.2. Bringing Linux Services T ogether 1.2.1. Authentication: Kerberos KDC 1.2.2. Data Storage: 389 Directory Server 1.2.3. Authentication: Dogtag Certificate System 1.2.4. Server/Client Discovery: DNS 1.2.5. Management: NT P 1.3. Relationships Between Servers and Clients 1.3.1. About IPA Servers and Replicas 1.3.2. About IPA Clients 2. Installing an IPA Server 2.1. Supported Server Platforms 2.2. Preparing to Install the IPA Server 2.2.1. Hardware Recommendations 2.2.2. Software Requirements 2.2.3. Supported Web Browsers 2.2.4. System Prerequisites 126.96.36.199. Hostname and IP Address Requirements 188.8.131.52. Directory Server 184.108.40.206. System Files 220.127.116.11. System Ports 18.104.22.168. NT P 22.214.171.124. NSCD 2.2.5. Networking 126.96.36.199. Configuring Networking Services 188.8.131.52. Configuring the /etc/hosts File 2.3. Installing the IPA Server Packages 2.4. Creating an IPA Server Instance 2.4.1. About ipa-server-install
Red Hat Enterprise Linux 6 Identity Management Guide 5 2.4.2. Setting up an IPA Server: Basic Interactive Installation 2.4.3. Examples of Creating the IPA Server 184.108.40.206. Non-Interactive Basic Installation 220.127.116.11. Using Different CA Configurations 18.104.22.168. Using DNS 2.4.4. T roubleshooting Installation Problems 2.5. Setting up IPA Replicas 2.5.1. Prepping and Installing the Replica Server 2.5.2. Creating the Replica 2.5.3. T roubleshooting Replica Installation 2.6. Uninstalling IPA Servers and Replicas 2.7. Upgrading Identity Management from Red Hat Enterprise Linux 6.2 to 6.3 2.7.1. Upgrading Packages 2.7.2. Removing Browser Configuration for T icket Delegation 2.7.3. T esting Before Upgrading the IPA Server3. Setting up Systems as IPA Clients 3.1. What Happens in Client Setup 3.2. System Ports 3.3. Configuring a Red Hat Enterprise Linux System as an IPA Client 3.4. Manually Configuring a Linux Client 3.5. Setting up a Linux Client T hrough Kickstart 3.6. Configuring a Microsoft Windows System to Join the IPA Realm 3.7. T roubleshooting Client Installations 3.7.1. T he client cant resolve reverse hostnames when using an external DNS. 3.7.2. T he client is not added to the DNS zone. 3.8. Uninstalling an IPA Client4. Basic Usage 4.1. About the IPA Client T ools 4.1.1. About the IPA Command-Line T ools 22.214.171.124. T he Structure of the ipa Command 126.96.36.199. Positional Elements in ipa Commands 188.8.131.52. Managing Entry Attributes with --setattr, --addattr, and --delattr 184.108.40.206. Using Special Characters with IPA T ools 220.127.116.11. Logging into the IPA Domain Before Running 4.1.2. Looking at the IPA UI 18.104.22.168. T he UI Layout 22.214.171.124. Page Elements 126.96.36.199. Showing and Changing Group Members 4.2. Logging into IPA 4.2.1. Logging into IPA 4.2.2. Logging in When an IPA User Is Different T han the System User 4.2.3. Checking the Current Logged in User 4.2.4. Caching User Kerberos T ickets 4.3. Using the IPA Web UI 4.3.1. Supported Web Browsers 4.3.2. Opening the IPA Web UI 4.3.3. Configuring the Browser 4.3.4. Using a Browser on Another System 4.3.5. Logging in with Simple Username/Password Credentials
6 Table of Contents 4.3.6. Using the UI with Proxy Servers 4.3.7. T roubleshooting UI Connection Problems 4.4. Understanding Search Limits and Settings 4.4.1. T ypes of Search Limits and Where T hey Apply 4.4.2. Setting IPA Search Limits 188.8.131.52. With the Web UI 184.108.40.206. With the Command Line 4.4.3. Overriding the Search Defaults 4.4.4. Setting Search Attributes 220.127.116.11. Setting User Search Attributes 18.104.22.168. Setting Group Search Attributes 4.4.5. Attributes Returned in Search Results 5. Identity: Managing Users and User Groups 5.1. Setting up User Home Directories 5.1.1. About Home Directories 5.1.2. Enabling the PAM Home Directory Module 5.1.3. Manually Mounting Home Directories 5.2. Managing User Entries 5.2.1. About Username Formats 5.2.2. Adding Users 22.214.171.124. From the Web UI 126.96.36.199. From the Command Line 5.2.3. Editing Users 188.8.131.52. From the Web UI 184.108.40.206. From the Command Line 5.2.4. Activating and Deactivating User Accounts 220.127.116.11. From the Web UI 18.104.22.168. From the Command Line 5.2.5. Deleting Users 22.214.171.124. With the Web UI 126.96.36.199. From the Command Line 5.3. Managing Public SSH Keys for Users (T ECH PREVIEW) 5.4. Changing Passwords 5.4.1. From the Web UI 5.4.2. From the Command Line 5.5. Unlocking User Accounts After Password Failures 5.6. Managing User Private Groups 5.6.1. Disabling Private Groups for a Specific User 5.6.2. Disabling Private Groups Globally 5.7. Managing Unique UID and GID Number Assignments 5.7.1. About ID Range Assignments During Installation 5.7.2. Adding New Ranges 5.8. Managing User and Group Schema 5.8.1. About Changing the Default User and Group Schema 5.8.2. Applying Custom Object Classes to New User Entries 188.8.131.52. From the Web UI
Red Hat Enterprise Linux 6 Identity Management Guide 7 184.108.40.206. From the Command Line 5.8.3. Applying Custom Object Classes to New Group Entries 220.127.116.11. From the Web UI 18.104.22.168. From the Command Line 5.9. Managing User Groups 5.9.1. Creating User Groups 22.214.171.124. With the Web UI 126.96.36.199. With the Command Line 5.9.2. Adding Group Members 188.8.131.52. With the Web UI (Group Page) 184.108.40.206. With the Web UI (Users Page) 220.127.116.11. With the Command Line 18.104.22.168. Viewing Direct and Indirect Members of a Group 5.9.3. Deleting User Groups 22.214.171.124. With the Web UI 126.96.36.199. With the Command Line 5.10. Searching for Users and Groups 5.10.1. With the UI 5.10.2. With the Command Line 5.11. Specifying Default User and Group Settings 5.11.1. Viewing Settings from the Web UI 5.11.2. Viewing Settings from the Command Line6. Identity: Managing Hosts and Services 6.1. About Hosts, Services, and Machine Identity and Authentication 6.2. Adding Host Entries 6.2.1. Adding Host Entries from the Web UI 6.2.2. Adding Host Entries from the Command Line 6.3. Enrolling Clients Manually 6.3.1. Performing a Split Enrollment 6.4. Manually Unconfiguring Client Machines 6.5. Managing Services 6.5.1. Adding and Editing Service Entries and Keytabs 188.8.131.52. Adding Services and Keytabs from the Web UI 184.108.40.206. Adding Services and Keytabs from the Command Line 6.5.2. Adding Services and Certificates for Services 220.127.116.11. Adding Services and Certificates from the Web UI 18.104.22.168. Adding Services and Certificates from the Command Line 6.5.3. Storing Certificates in NSS Databases 6.5.4. Configuring Clustered Services 6.5.5. Using the Same Service Principal for Multiple Services 6.6. Disabling and Re-enabling Host and Service Entries 6.6.1. Disabling Host and Service Entries 6.6.2. Re-enabling Hosts and Services 6.7. Extending Access Permissions over Other Hosts and Services 6.7.1. Delegating Service Management 6.7.2. Delegating Host Management
8 Table of Contents 6.7.2. Delegating Host Management 6.7.3. Delegating Host or Service Management in the Web UI 6.7.4. Accessing Delegated Services 6.8. Managing Public SSH Keys for Hosts (T ECH PREVIEW) 6.8.1. About IPA Clients and OpenSSH 6.8.2. Adding Host Keys 6.8.3. Removing Host Keys 6.9. Renaming Machines and Reconfiguring IPA Client Configuration 6.10. Managing Host Groups 6.10.1. Creating Host Groups 22.214.171.124. Creating Host Groups from the Web UI 126.96.36.199. Creating Host Groups from the Command Line 6.10.2. Adding Group Members 188.8.131.52. Adding Group Members from the Web UI 184.108.40.206. Adding Group Members from the Command Line 6.11. T roubleshooting Host Problems 6.11.1. Certificate Not Found/Serial Number Not Found Errors 6.11.2. Debugging Client Connection Problems 7. Identity: Integrating with NIS Domains and Netgroups 7.1. About NIS and Identity Management 7.2. Setting the NIS Port for Identity Management 7.3. Creating Netgroups 7.3.1. Adding Netgroups 220.127.116.11. With the Web UI 18.104.22.168. With the Command Line 7.3.2. Adding Netgroup Members 22.214.171.124. With the Web UI 126.96.36.199. With the Command Line 7.4. Exposing Automount Maps to NIS Clients 7.5. Migrating from NIS to IPA 7.5.1. Preparing Netgroup Entries in IPA 7.5.2. Enabling the NIS Listener in Identity Management 7.5.3. Exporting and Importing the Existing NIS Data 188.8.131.52. Importing User Entries 184.108.40.206. Importing Group Entries 220.127.116.11. Importing Host Entries 18.104.22.168. Importing Netgroup Entries 22.214.171.124. Importing Automount Maps 7.5.4. Setting Weak Password Encryption for NIS User Authentication to IPA 8. Identity: Integrating with Microsoft Active Directory 8.1. About Active Directory and Identity Management 8.2. About Synchronized Attributes 8.2.1. User Schema Differences between Identity Management and Active Directory 126.96.36.199. Values for cn Attributes 188.8.131.52. Values for street and streetAddress 184.108.40.206. Constraints on the initials Attribute 220.127.116.11. Requiring the surname (sn) Attribute 8.2.2. Active Directory Entries and RFC 2307 Attributes
Red Hat Enterprise Linux 6 Identity Management Guide 9 8.3. Setting up Active Directory for Synchronization 8.4. Managing Synchronization Agreements 8.4.1. T rusting the Active Directory and IPA CA Certificates 8.4.2. Creating Synchronization Agreements 8.4.3. Changing the Behavior for Syncing User Account Attributes 8.4.4. Changing the Synchronized Windows Subtree 8.4.5. Configuring Uni-Directional Sync 8.4.6. Deleting Synchronization Agreements 8.4.7. Winsync Agreement Failures 8.5. Managing Password Synchronization 8.5.1. Setting up the Windows Server for Password Synchronization 8.5.2. Setting up Password Synchronization 8.5.3. Exempting Active Directory Users from Password Synchronization9. Identity: Managing DNS 9.1. About DNS in IPA 9.2. T he IPA-Generated DNS File 9.3. Setting up DNS After IPA Server Installation 9.4. Managing DNS Z one Entries 9.4.1. Adding DNS Z ones 18.104.22.168. Adding DNS Z ones from the Web UI 22.214.171.124. Adding DNS Z ones from the Command Line 9.4.2. Modifying DNS Z ones 126.96.36.199. Editing the Z one Configuration in the Web UI 188.8.131.52. Editing the Z one Configuration in the Command Line 9.4.3. Enabling and Disabling Z ones 184.108.40.206. Disabling Z ones in the Web UI 220.127.116.11. Disabling Z ones in the Command Line 9.5. Managing DNS Record Entries 9.5.1. Adding Records to DNS Z ones 18.104.22.168. Adding DNS Resource Records from the Web UI 22.214.171.124. Adding DNS Resource Records from the Command Line 9.5.2. Deleting Records from DNS Z ones 126.96.36.199. Deleting Records with the Web UI 188.8.131.52. Deleting Records with the Command Line 9.6. Configuring the bind-dyndb-ldap Plug-in 9.6.1. Changing the DNS Cache Setting 9.6.2. Enabling Z one Refreshes 9.7. Changing Recursive Queries Against Forwarders 9.8. Enabling Dynamic DNS Updates 9.8.1. Enabling Dynamic DNS Updates in the Web UI 9.8.2. Enabling Dynamic DNS Updates in the Command Line 9.9. Configuring Forwarders and Forward Policy 9.9.1. Configuring Global Forwarders 9.9.2. Configuring Z one Forwarders 9.9.3. Configuring Forwarder Policy for a Z one 9.10. Enabling Z one T ransfers 9.11. Defining DNS Queries 9.12. Synchronizing Forward and Reverse Z one Entries
10 Table of Contents 9.13. Setting DNS Access Policies 9.14. Resolving Hostnames in the IPA Domain 9.15. Changing Load Balancing for IPA Servers and Replicas 10. Policy: Using Automount 10.1. About Automount and IPA 10.2. Configuring Automount 10.2.1. Configuring autofs on Red Hat Enterprise Linux 10.3. Setting up a Kerberized NFS Server 10.3.1. Setting up a Kerberized NFS Server 10.3.2. Setting up a Kerberized NFS Client 10.4. Configuring Kerberized CIFS 10.4.1. Setting up Samba Groups in IPA 10.4.2. Configuring the CIFS Client 10.5. Configuring Locations 10.5.1. Configuring Locations through the Web UI 10.5.2. Configuring Locations through the Command Line 10.6. Configuring Maps 10.6.1. Configuring Direct Maps 10.6.1.1. Configuring Direct Maps from the Web UI 10.6.1.2. Configuring Direct Maps from the Command Line 10.6.2. Configuring Indirect Maps 10.6.2.1. Configuring Indirect Maps from the Web UI 10.6.2.2. Configuring Indirect Maps from the Command Line 10.6.3. Importing Automount Maps 11. Policy: Defining Password Policies 11.1. About Password Policies and Policy Attributes 11.2. Viewing Password Policies 11.2.1. Viewing the Global Password Policy 184.108.40.206. With the Web UI 220.127.116.11. With the Command Line 11.2.2. Viewing Group-Level Password Policies 18.104.22.168. With the Web UI 22.214.171.124. With the Command Line 11.2.3. Viewing the Password Policy in Effect for a User 11.3. Creating and Editing Password Policies 11.3.1. Creating Password Policies in the Web UI 11.3.2. Creating Password Policies with the Command Line 11.3.3. Editing Password Policies with the Command Line 11.4. Managing Password Expiration Limits 11.5. Changing the Priority of Group Password Policies 11.6. Setting Account Lockout Policies 11.6.1. In the UI 11.6.2. In the CLI 11.7. Enabling a Password Change Dialog 12. Policy: Managing the Kerberos Domain
Red Hat Enterprise Linux 6 Identity Management Guide 11 12.1. About Kerberos 12.1.1. About Principal Names 12.1.2. About Protecting Keytabs 12.2. Setting Kerberos T icket Policies 12.2.1. Setting Global T icket Policies 126.96.36.199. From the Web UI 188.8.131.52. From the Command Line 12.2.2. Setting User-Level T icket Policies 12.3. Refreshing Kerberos T ickets 12.4. Caching Kerberos Passwords 12.5. Removing Keytabs 12.6. T roubleshooting Kerberos Errors13. Policy: Using sudo 13.1. About sudo and IPA 13.1.1. General sudo Configuration in Identity Management 13.1.2. sudo and Netgroups 13.1.3. Supported sudo Clients 13.2. Setting up sudo Commands and Command Groups 13.2.1. Adding sudo Commands 184.108.40.206. Adding sudo Commands with the Web UI 220.127.116.11. Adding sudo Commands with the Command Line 13.2.2. Adding sudo Command Groups 18.104.22.168. Adding sudo Command Groups with the Web UI 22.214.171.124. Adding sudo Command Groups with the Command Line 13.3. Defining sudo Rules 13.3.1. About External Users and Hosts 13.3.2. About sudo Options Format 13.3.3. Defining sudo Rules in the Web UI 13.3.4. Defining sudo Rules in the Command Line14. Policy: Configuring Host-Based Access Control 14.1. About Host-Based Access Control 14.2. Creating Host-Based Access Control Entries for Services and Service Groups 14.2.1. Adding HBAC Services 126.96.36.199. Adding HBAC Services in the Web UI 188.8.131.52. Adding Services in the Command Line 14.2.2. Adding Service Groups 184.108.40.206. Adding Service Groups in the Web UI 220.127.116.11. Adding Service Groups in the Command Line 14.3. Defining Host-Based Access Control Rules 14.3.1. Setting Host-Based Access Control Rules in the Web UI 14.3.2. Setting Host-Based Access Control Rules in the Command Line 14.4. T esting Host-Based Access Control Rules 14.4.1. T he Limits of Host-Based Access Control Configuration 14.4.2. T est Scenarios for Host-Based Access Control (CLI-Based) 14.4.3. T esting Host-Based Access Control Rules in the UI15. Policy: Defining Automatic Group Membership for Users and Hosts
12 Table of Contents 15.1. About Automembership 15.2. Defining Automembership Rules (Basic Procedure) 15.2.1. From the Web UI 15.2.2. From the CLI 15.3. Examples of Using Automember Groups 15.3.1. Setting an All Users/Hosts Rule 15.3.2. Defining Default Automembership Groups 15.3.3. Using Automembership Groups with Windows Users 16. Configuration: Defining Access Control within IPA 16.1. About Access Controls for IPA Entries 16.1.1. A Brief Look at Access Control Concepts 16.1.2. Access Control Methods in Identity Management 16.2. Defining Self-Service Settings 16.2.1. Creating Self-Service Rules from the Web UI 16.2.2. Creating Self-Service Rules from the Command Line 16.2.3. Editing Self-Service Rules 16.3. Delegating Permissions over Users 16.3.1. Delegating Access to User Groups in the Web UI 16.3.2. Delegating Access to User Groups in the Command Line 16.4. Defining Role-Based Access Controls 16.4.1. Creating Roles 18.104.22.168. Creating Roles in the Web UI 22.214.171.124. Creating Roles in the Command Line 16.4.2. Creating New Permissions 126.96.36.199. Creating New Permissions from the Web UI 188.8.131.52. Creating New Permissions from the Command Line 16.4.3. Creating New Privileges 184.108.40.206. Creating New Privileges from the Web UI 220.127.116.11. Creating New Privileges from the Command Line 17. Configuration: Configuring the IPA Server 17.1. Identity Management Files and Logs 17.1.1. A Reference of IPA Server Configuration Files and Directories 17.1.2. About default.conf and Context Configuration Files 17.1.3. Checking IPA Server Logs 18.104.22.168. Enabling Server Debug Logging 22.214.171.124. Debugging Command-Line Operations 17.2. Disabling Anonymous Binds 17.3. Configuring Alternate Certificate Authorities 17.4. Configuring CRLs and OCSP Responders 17.4.1. Using an OSCP Responder with SELinux 17.4.2. Changing the CRL Update Interval 17.4.3. Changing the OCSP Responder Location 17.5. Setting an IPA Server as an Apache Virtual Host 17.6. Setting DNS Entries for Multi-Homed Servers 17.7. Managing Replication Agreements Between IPA Servers 17.7.1. Listing Replication Agreements 17.7.2. Creating and Removing Replication Agreements 17.7.3. Forcing Replication
Red Hat Enterprise Linux 6 Identity Management Guide 13 17.7.4. Reinitializing IPA Servers 17.7.5. Resolving Replication Conflicts 126.96.36.199. Solving Naming Conflicts 188.8.131.52. Solving Orphan Entry Conflicts 17.8. Removing a Replica 17.9. T roubleshooting 17.9.1. Starting IPA with Expired Certificates 17.9.2. T here are SASL, GSS-API, and Kerberos errors in the 389 Directory Server logs when the replica starts.18. Migrating from an LDAP Directory to IPA 18.1. An Overview of LDAP to IPA Migration 18.1.1. Planning the Client Configuration 184.108.40.206. Initial Client Configuration (Pre-Migration) 220.127.116.11. Recommended Configuration for Red Hat Enterprise Linux Clients 18.104.22.168. Alternative Supported Configuration 18.1.2. Planning Password Migration 22.214.171.124. Method 1: Using T emporary Passwords and Requiring a Change 126.96.36.199. Method 2: Using the Migration Web Page 188.8.131.52. Method 3: Using SSSD (Recommended) 184.108.40.206. Migrating Cleartext LDAP Passwords 220.127.116.11. Automatically Resetting Passwords T hat Do Not Meet Requirements 18.1.3. Migration Considerations and Requirements 18.104.22.168. LDAP Servers Supported for Migration 22.214.171.124. Migration Environment Requirements 126.96.36.199. Migration T ools 188.8.131.52. Migration Sequence 18.2. Examples for Using migrate-ds 18.2.1. Migrating Specific Subtrees 18.2.2. Specifically Including or Excluding Entries 18.2.3. Excluding Entry Attributes 18.2.4. Setting the Schema to Use 18.3. Scenario 1: Using SSSD as Part of Migration 18.4. Scenario 2: Migrating an LDAP Server Directly to Identity ManagementA. Frequently Asked QuestionsB. Working with certmonger B.1. Requesting a Certificate with certmonger B.2. Storing Certificates in NSS Databases B.3. T racking Certificates with certmongerC. IPA T ools Reference C.1. Using Special Characters with IPA T ools C.2. ipa C.2.1. Location C.2.2. Syntax C.2.2.1. Adding, Editing, and Deleting Entries with ipa C.2.2.2. Finding and Displaying Entries with ipa C.2.2.3. Adding Members to Groups and Containers with ipa C.2.2.4. Positional Elements in ipa Commands C.2.3. Help T opics
Red Hat Enterprise Linux 6 Identity Management Guide 15PrefaceIdentity Management is a Red Hat Enterprise Linux-based way to create a security, identity, andauthentication domain. T he different security and authentication protocols available to Linux and Unixsystems (like Kerberos, NIS, DNS, PAM, and sudo) are complex, unrelated, and difficult to managecoherently, especially when combined with different identity stores.Identity Management provides a layer that unifies all of these disparate services and simplifies theadministrative tasks for managing users, systems, and security. IPA breaks management down into twocategories: identity and policy. It centralizes the functions of managing the users and entities within yourIT environment (identity) and then provides a framework to define authentication and authorization for aglobal security framework and user-friendly tools like single sign-on (policy).1. Audience and PurposeWith Identity Management, a Red Hat Enterprise Linux system can easily become the center of anidentity/authentication domain and even provide access to the domain for clients of other operatingsystems. IPA is an integrated system, that builds on existing and reliable technologies like LDAP andcertificate protocols, with a robust yet straightforward set of tools (including a web-based UI). T he key toidentity/policy management with IPA is simplicity and flexibility: Centralized identity stores for authentication and single sign-on using both integrated LDAP services (with 389 Directory Server) and, optionally, NIS services Clear and manageable administrative control over system services like PAM, NT P, and sudo Simplified DNS domains and maintenance Scalable Kerberos realms and cross-realms which clients can easily joinT his guide is written for systems administrators and IT staff who will manage IPA domains, usersystems, and servers. T his assumes a moderate knowledge of Linux-based systems administration andfamiliarity with important concepts like access control, LDAP, and Kerberos.T his guide covers every aspect of using IPA, including preparation and installation processes,administrative tasks, and the IPA tools. T his guide also explains the major concepts behind both identityand policy management, generally, and IPA features specifically. Administrative tasks in this guide arecategorized as either Identity or Policy in the chapter title to help characterize the administrativefunctions.2. Examples and FormattingEach of the examples used in this guide, such as file locations and commands, have certain definedconventions.2.1. BracketsSquare brackets () are used to indicate an alternative element in a name. For example, if a tool isavailable in /usr/lib on 32-bit systems and in /usr/lib64 on 64-bit systems, then the tool locationmay be represented as /usr/lib[64 ].2.2. Client T ool InformationT he tools for IPA are located in the /usr/bin and the /usr/sbin directories.T he LDAP tools used to edit the IPA directory services, such as ldapm odify and ldapsearch, arefrom OpenLDAP. OpenLDAP tools use SASL connections by default. T o perform a simple bind using a
16 Prefaceusername and password, use the -x argument to disable SASL.2.3. T ext Formatting and StylesCertain words are represented in different fonts, styles, and weights. Different character formatting isused to indicate the function or purpose of the phrase being highlighted. Formatting Style Purpose T his type of formatting is used for anything Monospace with a background entered or returned in a command prompt. Italicized text Any text which is italicized is a variable, such as instance_name or hostname. Occasionally, this is also used to emphasize a new term or other phrase. Bolded text Most phrases which are in bold are application names, such as Cygwin, or are fields or options in a user interface, such as a User Nam e Here: field or Save button. T his can also indicate a file, package, or directory name, such as /usr/sbin.Other formatting styles draw attention to important text. NOTE A note provides additional information that can help illustrate the behavior of the system or provide more detail for a specific issue. IMPORTANT Important information is necessary, but possibly unexpected, such as a configuration change that will not persist after a reboot. WARNING A warning indicates potential data loss, as may happen when tuning hardware for maximum performance.3. Giving FeedbackIf there is any error in this book or there is any way to improve the documentation, please let us know.Bugs can be filed against the documentation for IPA through Bugzilla, http://bugzilla.redhat.com/bugzilla.Make the bug report as specific as possible, so we can be more effective in correcting any issues: 1. Select the Red Hat group and the Red Hat Enterprise Linux 6 product. 2. Set the component to doc-Enterprise_Identity_Managem ent_Guide. 3. For errors, give the page number (for the PDF) or URL (for the HT ML), and give a succinct description of the problem, such as incorrect procedure or typo.
Red Hat Enterprise Linux 6 Identity Management Guide 17 For enhancements, put in what information needs to be added and why. 4. Give a clear title for the bug. For example, "Incorrect com m and exam ple for setup script options" is better than "Bad exam ple".We appreciate receiving any feedback — requests for new sections, corrections, improvements,enhancements, even new ways of delivering the documentation or new styles of docs. You are welcometo contact Red Hat Content Services directly at email@example.com. Document Change HistoryRevision 6.3-1 October 18, 2012 Ella Deon Lackey Commenting out sudo configuration example. Removing group sync information from winsync chapter. Commenting out CRL generation section.Revision 6.2-8 December 16, 2011 Ella Deon Lackey Fixing sudoers_debug example in sudo client configuration procedure, Bugzilla #768792. Fixing migration command example, Bugzilla #766089.Revision 6.2-7 December 6, 2011 Ella Deon Lackey Release for GA of Red Hat Enterprise Linux 6.2.
18 Release InformationRelease InformationIdentity Management is part of Red Hat Enterprise Linux 6, so major features, known issues, and bugfixes are covered in the Red Hat Enterprise Linux release notes. T his section is provided as aconvenient reference for significant issues that are in Identity Management 2.2. T he full list of knownissues related to Identity Management is in the Red Hat Enterprise Linux 6.3 T echnical Notes.1. New Features in 6.3Automatic Group Membership for Users and HostsMost of the policies configured in Identity Management are based on group membership, so managinggroup membership is critical as a part of managing the policies for both users and hosts.Automembership allows administrators to set up filters for new users and hosts so that they areassigned, automatically, to the appropriate user groups and host groups. Automembership, includingexamples, is covered in Chapter 15, Policy: Defining Automatic Group Membership for Users and Hosts.Disabling User Private GroupsOn Red Hat Enterprise Linux systems, every time a user is created, a corresponding, secret user groupis automatically created with that new user as its only member. T his is a user private group. T here maybe certain users or types of users which do not require a private group or the environment may alreadyhave those GIDs assigned to NIS groups or other system groups. In that case, user private groupcreation can be disabled. See Section 5.6, “Managing User Private Groups”.Better Web UI PerformanceA number of performance and usability changes have been made in IPA 2.2, including improved sessionhandling and adding support for Services4Unix Proxy. Along with overall better performance, thesechanges have introduced two new features for the web UI: Self-service management supported in Internet Explorer Form-based authentication for the web UI, in addition to KerberosEnhanced DNS Resource Record SupportT he way that IPA handles DNS resource records has been improved to make it easier to create and editrecords. T he UI and CLI tooling have both been enhanced to provide type-specific options for commonresource record types. For more information, see Section 9.5, “Managing DNS Record Entries”.SSH Key Management (T ech Preview)OpenSSH uses public-private key pairs to authenticate hosts. T he machine then stores user and hostpublic keys in a central file, such as the known_hosts file. Clients can simple check that central key fileand then grant access automatically to approved users and hosts. However, since all of those files arecreated locally, it can be difficult to maintain host and user key files across an entire enterprise. T heSystem Security Services Daemon (SSSD) can be configured to cache and retrieve SSH keys so thatapplications and services only have to look in one location for keys. Because SSSD can use IdentityManagement as one of its identity information providers, Identity Management provides a universal andcentralized repository of keys. For more information, see Section 5.3, “Managing Public SSH Keys forUsers (T ECH PREVIEW)”.
Red Hat Enterprise Linux 6 Identity Management Guide 192. Upgrade Notes for IPA 2.2 Upgrade procedures are covered in Section 2.7, “Upgrading Identity Management from Red Hat Enterprise Linux 6.2 to 6.3”. Existing replicas and servers in a domain can use different versions of IPA. However, when creating a new replica, the new replica must be the same version as the master server which it is being created from. Because of UI session enhancements in IPA 2.2, it is no longer necessary to enable ticket-granting ticket (T GT ) creation for browser sessions. For existing IPA servers, a new configure.jar file can be created that no longer enables T GT delegation as part of client browser configuration. For existing IPA clients, T GT delegation can be disabled again in the browser. T his is covered in Section 2.7.2, “Removing Browser Configuration for T icket Delegation”. In IPA 2.1, it was possible to enable password-based authentication by editing the ipa.conf file: vim /etc/httpd/conf.d/ipa.conf KrbMethodNegotiate off KrbMethodK5Passwd on Because of the changes and enhancements to browser authentication mechanisms, this ipa.conf file is updated as part of the upgrade process, and any changes are overwritten. Since IPA 2.2. supports form-based authentication automatically, it is now possible to log in using a username and password without having to modify the ipa.conf file. See Section 4.3.5, “Logging in with Simple Username/Password Credentials”. NOTE Any time a file is replaced during upgrade, a backup is made. If other edits were made to the ipa.conf file, the backup can be used to restore them.3. Fixed in 6.3T hese issues have been resolved in IPA 2.2.
20 Release InformationT able 1. Fixed Bugs in 6.3 Bugzilla Description Bugzilla 736074 In the directory, calling hash_create() with an initial table size of 65536 corrupted memory. With the default parameters, the corruption could occur if the initial table size was larger than 1024. Bugzilla 743680 When an IPA server was installed with a custom hostname that was not resolvable, the ipa- server-install command failed to add a record to the static hostname lookup table in /etc/hosts, which prevented further configuration of Identity Management integrated services. T he record is now properly added to /etc/hosts when an IP address is passed as an CLI option and not interactively. Bugzilla 751776 If a zone entry contained an invalid record, the entire zone failed to load. None of the records in the DNS zone, including root records, were serviced. Now, the DNS zone loads and skips the invalid resource record. All of the other DNS resource entries are served, can be resolved, and respond to requests. Bugzilla 754539 Once a connection between a replica and server was deleted using ipa-replica-m anage del, a new connection could not be created. It failed with this error: unexpected error: list index out of range Bugzilla 759100 T he IPA server could not be installed on a machine with a dual NIC. When two DNS A records existed for the same hostname, the installer failed with this error: Server host name [server1.example.com]: Warning: skipping DNS resolution of host server1.example.com The domain name has been calculated based on the host name. Please confirm the domain name [example]: Unable to resolve IP address for host name Please provide the IP address to be used for this host name:
Red Hat Enterprise Linux 6 Identity Management Guide 214. Known Issues in 6.34 .1. A Note on Internet Explorer Support on WindowsT he enhancements for Services4Unix Proxy support have made steps in adding support to use the IPAweb UI on Internet Explorer on Windows. However, this is still a nascent feature. In IPA 2.2, InternetExplorer can be used for self-service management, such as resetting account details andchanging passwords.When using Internet Explorer to perform other tasks in the IPA web UI, there can be issues with UIperformance and layout or some operations may not be possible.T hese are some of the known issues specifically for Internet Explorer and the web UI: While the browser window is not maximized or many users are logged into the WebUI, scrolling down a page to select a user may not work properly. As soon as the users checkbox is selected, the scroll bar jumps back up without selecting the user. T his error also occurs when a permission is added to a privilege. (Bugzilla 831299) When attempting to edit a service, the edit page for that service may occasionally be blank, or show only labels for Principal or Service without showing their values. When adding a service, under certain conditions, the drop-down menu lists the available services and hosts but users are unable to select any of the entries. (Bugzilla 831227) When adding a permission of type subtree, the text area to specify the subtree is too small and non- resizable making it difficult to enter long subtree entries. (Bugzilla 830817) When adding a delegation, its attributes are separated by disproportionately large vertical spaces. (Bugzilla 829899) When adding a member, the edge of the displayed window suggests it can be resized. However, resizing of the window does not work. When adding a sudo command to a sudo command group, the first group overlays with the column title. (Bugzilla 829746) Adding a new DNS zone causes the window to be incorrectly rendered as text on the existing page. (Bugzilla 827583)4 .2. List of Issues
22 Release InformationT able 2. Known Issues in 6.3 Bugzilla Description Workaround SELinux mapping is not T he SELinux mapping feature working. was intended to be a tech preview feature in Red Hat Enterprise Linux 6.3. T his feature is disabled, pending further development. T he SELinux mapping area in the web UI and the SELinux mapping-related tools are non- functional. Bugzilla 724911 It is not possible to change the If the UID or GID number is ever uidNumber or gidNumber of a changed for an account, then go user when using SSSD. SSSD to each local SSSD client and caches the authentication purge the cache. T he SSSD information; when the user is cache purge tool is described in deleted and re-added with a the Red Hat Enterprise Linux 6 new uidNumber number, then Deployment Guide. SSSD attempts to reuse the cached object for the new user, which fails wit this error: Cache file [/tmp/krb5cc_1866400007 _wPJrHJ] exists, but is owned by  instead of . Bugzilla 726456 SSSD does not support the LDAP password expiration controls, so it does not support password expiration notifications or warnings. T he 389 Directory Server instance used by Identity Management does support these controls. Bugzilla 741264 T he way that Active Directory Set this parameter in performs referrals is different sssd.conf: than the way that the OpenLDAP libraries (used by the 389 ldap_referrals = False Directory Server instance in Identity Management) perform T his disables referral chasing in referrals. Intermittently, Active SSSD. Directory may return a referral during an LDAP bind attempt that is denied by the OpenLDAP libraries. T his can cause performance problems, information loss, or for SSSD to go offline. Bugzilla 741957 When updating the list of object classes for a user or group entry, it is possible to delete
Red Hat Enterprise Linux 6 Identity Management Guide 23 object classes which are required by IPA. T he UI and CLI do not prevent the required object classes from being deleted, but adding a user or group after the change will fail with object class violations.Bugzilla 742263 T he previous and next buttons Increase the number of entries were not displayed in the UI if displayed in a search to a the number of entries returned reasonable level. T his is is larger than the configured described in Section 4.4.2, size limit. “Setting IPA Search Limits”.Bugzilla 743680 When an IPA server is installed T here are two ways to work with a custom hostname that is around this issue: not resolvable, the ipa- server-install command Run the ipa-server- should add a record to the static install without the --ip- hostname lookup table in address option and pass /etc/hosts and enable further the IP address interactively. configuration of Identity Add a record to Management integrated /etc/hosts before the services. However, a record is installation is started. T he not added to /etc/hosts when record should contain the an IP address is passed as an Identity Management server CLI option and not interactively. IP address and its full Consequently, IPA server hostname (the hosts(5) installation fails because man page specifies the integrated services that are record format). being configured expect the IPA server hostname to be resolvable.Bugzilla 743945 Searches can be performed on For more information on setting attributes that are not displayed and changing attributes which in the UI. T his means that are searched, see Section 4.4.4, entries can be returned in a “Setting Search Attributes” and search that do not appear to Section 184.108.40.206, “Setting Group match the given filter. T his is Search Attributes”. especially common if the search information is very short, which increases the likelihood of a match.Bugzilla 745575 On the configuration page of the Identity Management web UI, if the User search field is left blank, and the search button is clicked, an internal error is returned.Bugzilla 749357 and Bugzilla T he IPA information is stored in T he CA replication agreement750596 a separate LDAP directory than can be recreated using the the certificate information, and ipa-csreplica-m anage these two LDAP databases are utility. replicated separately. It is possible for a replication agreement to be broken for one
24 Release Information directory and working for another, which can cause problems with managing clients. For example, an IPA server and replica have a function replication agreement between their IPA databases, but the replication agreement between their CA databases is broken. If a host is created on the server, the host entry is replicated over to the replica — but the certificate for that host is not replicated. T he replica is aware of the client, but any management operations for that client will fail because the replica doesnt have a copy of its certificate.Bugzilla 751694 Installing the IPA client fails if the 32-bit packages are installed on a 64-bit system because required NSS dependencies are not installed.Bugzilla 752181 If any previous version of Red Hat Enterprise IPA or the Identity Management tech preview are installed, they must be uninstalled before the latest version of Identity Management can be installed and configured. Otherwise, there are problems connecting to the Identity Management LDAP server.Bugzilla 754739 When a replica is uninstalled, the ipa-replica-m anage list command still lists the replica as being in the server topology.Bugzilla 754973 T he ipa-replica-m anage script manages both replication agreements between IPA servers and synchronization agreements between an IPA server and an Active Directory server. T he force-sync, del, and re-initialize subcommands with ipa- replica-m anage do not work when managing sync agreements, so these operations fail when run against
Red Hat Enterprise Linux 6 Identity Management Guide 25 an Active Directory server.Bugzilla 755436 T he uidNumber and gidNumber attributes on Active Directory user entries are not synced over to IPA.Bugzilla 783502 T he Identity Management permission plug-in does not verify that the set of attributes specified for a new permission is relevant to the target object type that the permission allows access to. T his means a user is able to create a permission which allows access to attributes that will never be present in the target object type because such attributes are not allowed in its object classes. You must ensure that the chosen set of attributes for which a new permission grants access to is relevant to the chosen target object type.Bugzilla 785201 Active Directory users synced to the IPA server are not added to the global ipausers group.Bugzilla 786629 Because a permission does not T o grant write access to an provide write access to an entry, entry, the list of writable delegation does not work as attributes needs to be provided. expected. T he 389 Directory T he filter, subtree, and other Server distinguishes between options are used to target those access to entries and access to entries which are writable. attributes. For example, an entry Attributes define which parts of can be granted add or delete those entries are writable. As a access, whereas an attribute result, the list of attributes will can be granted read, search, be writable to members of the and write access. permission.Bugzilla 790513 T he ipa-client package does not Install the policycoreutils install the policycoreutils package manually: package as its dependency, which may cause install or ~]# yum install uninstall issues when using the policycoreutils ipa-client-install setup script.Bugzilla 794882 When adding members to netgroups, if a host that is not configured in IPA already, that host is considered to be an external host. T his host can be controlled with netgroups, but the IPA domain has no knowledge of it. Currently, there is no way to use the
26 Release Information netgroup-find command to search for external hosts. When an external host is added to the netgroup coniguration, it is not automatically converted in the netgroup rule.Bugzilla 804605 Identity Management and the Uninstall m od_ssl. m od_ssl module should not be installed on the same system. m od_ssl holds the m od_proxy hooks, which prevents Identity Management from issuing certificates.Bugzilla 813376 Updating the LDAP configuration when the system upgrades, which is done with the ipa- ldap-updater utility, fails with a traceback error when executed by a non-root user. T he SASL EXT ERNAL bind attempt requires root privileges. T o workaround this, update the LDAP configuration as root.Bugzilla 812127 IPA relies on the LDAP schema to know what type of data to expect in a given attribute. If, in certain situations (such as replication), attribute values that do not meet those expectations are inserted for an attribute, IPA will not be able to handle the entry, and LDAP tools must be used to manually clean up that entry.Bugzilla 812122 In IPA, sudo commands are not case sensitive, but on the operating system, commands are treated as different if they are different cases. T his can lead to conflicts in IPA sudo policy. For example, when executing these two commands, the second command fails because IPA treats both commands the same.
Red Hat Enterprise Linux 6 Identity Management Guide 27 ~]$ ipa sudocmd-add /usr/bin/X ? ~]$ ipa sudocmd-add /usr/bin/x ipa: ERROR: sudo command with name "/usr/bin/x" already existsBugzilla 817121 In some circumstances, deleting a DNS record entry in the web UI can leave the DNS zone entry visible in the UI. T his is strictly a display issue; the underlying DNS data are correctly updated and the zone is deleted.Bugzilla 817878 If an invalid value is given for the Seconds Latitude field in the configuration for a DNS location (LOC) record, the server throws this error: [Tue May 01 09:44:59 2012] [error] ipa: ERROR: non-public: InvalidOperation: quantize result has too many digits for current contextBugzilla 822350 When a user is migrated from An administrator can reset the an LDAP directory, the users password of a migrated user entry in the LDAP directory does with the ipa passwd command. not contain Kerberos credentials When reset, the users needed for a Kerberos login. Kerberos credentials are When the user visits the properly generated. password migration page, Kerberos credentials are generated for the user and logging in with Kerberos authentication works as expected. However, Identity Management does not generate the credentials correctly if the migrated password does not follow the password policy set on the Identity Management server. Consequently, when the password migration is done and a user tries to log in with Kerberos authentication, the user is prompted to change the password. However, the password change itself is unsuccessful, so the user is
28 Release Information unable to log into Kerberos.Bugzilla 826731 If configuring the CA fails, the entire server installation fails, but the command output is unclear where or why the installation attempt failed. T o troubleshoot installation failures, check the server installation log, /var/log/ipaserver- install.log, and the CA installation log, /var/log/pki-ca- install.log.Bugzilla 826790 Disabling password expiration (- -maxlife=0 and --minlife=0) in the default global_policy sets users password expiration to 90 days.Bugzilla 826973 When Identity Management is When running the second step installed using an external CA to of the installation, use the -- sign its CA certificate, the subject option to give the installation is processed in two subject nname of the certificate; steps. In the first step, a by default, this is O=REALM, certificate request is generated and REALM is the name of the to be signed by an external CA. new IPA Kerberos realm. If a T he second step submits a file custom subject was used for the with the new signed certificate first stage of the installation, use for the Identity Management CA its value instead. and the certificate of the external CA. During the second step of the installation, a signed Identity Management CA certificate subject is validated. However, the certificate subject validation procedure does not pull the subject of the certificate. T his means that the validation step fails, unless the subject name is manually supplied.
Red Hat Enterprise Linux 6 Identity Management Guide 29Chapter 1. Introduction to Identity ManagementRed Hat Enterprise Linux IPA is a way to create identity stores, centralized authentication, domain controlfor Kerberos and DNS services, and authorization policies — all on Linux systems, using native Linuxtools. While centralized identity/policy/authorization software is hardly new, Identity Management is oneof the only options that supports Linux/Unix domains.Identity Management provides a unifying skin for standards-defined, common network services, includingPAM, LDAP, Kerberos, DNS, NT P, and certificate services, and it allows Red Hat Enterprise Linuxsystems to serve as the domain controllers.Identity Management defines a domain, with servers and clients who share centrally-managed services,like Kerberos and DNS. T his chapter first explains what Identity Management is. T his chapter alsocovers how all of these services work together within the domain and how servers and clients work witheach other.1.1. IPA v. LDAP: A More Focused Type of ServiceAt the most basic level, Red Hat Identity Management is a domain controller for Linux and Unix machines.Identity Management defines the domain, using controlling servers and enrolled client machines. T hisprovides centralized structure that has previously been unavailable to Linux/Unix environments, and itdoes it using native Linux applications and protocols.1.1.1. A Working Definition for Identity ManagementSecurity information frequently relates to identities of users, machines, and services. Once the identity isverified, then access to services and resources can be controlled.For efficiency, risk management, and ease of administration, IT administrators try to manage identities ascentrally as possible and to unite identity management with authentication and authorization policies.Historically, Linux environments have had a very difficult time establishing this centralized management.T here are a number of different protocols (such as NIS and Kerberos) which define domains, while otherapplications store data (such as LDAP) and still others manage access (such as sudo). None of theseapplications talk to each other or use the same management tools. Every application had to beadministered separately and it had to be managed locally. T he only way to get a consistent identitypolicy was to copy configuration files around manually or to try to develop a proprietary application tomanage identities and policies.T he goal of Identity Management is to simplify that administrative overhead. Users, machines, services,and polices are all configured in one place, using the same tools. Because IPA creates a domain,multiple machines can all use the same configuration and the same resources simply by joining thedomain. Users only have to sign into services once, and administrators only have to manage a singleuser account.IPA does three things: Create a Linux-based and Linux-controlled domain. Both IPA servers and IPA clients are Linux or Unix machines. While IPA can synchronize data with an Active Directory domain to allow integration with Windows servers, it is not an administrative tools for Windows machines and it does not support Windows clients. Identity Management is a management tool for Linux domains. Centralize identity management and identity policies. Build on existing, native Linux applications and protocols. While IPA has its own processes and configuration, its underlying technologies are familiar and trusted by Linux administrators and are well established on Linux systems.In a sense, Identity Management isnt making administrators do something new; it is helping them do it
30 Chapter 1. Introduction to Identity Managementbetter. T here are a few ways to illustrate that.On one extreme is the low control environment. Little Example Corp. has several Linux and Unix servers,but each one is administered separately. All passwords are kept on the local machine, so there is nocentral identity or authentication process. T im the IT Guy just has to manage users on every machine,set authentication and authorization policies separately, and maintain local passwords. With IPA, thingscome to order. T here is a simple way to have central user, password, and policy stores, so T im the ITGuy only has to maintain the identities on one machine (the IPA server) and users and policies areuniformly applied to all machines. Using host-based access control, delegation, and other rules, he caneven set different access levels for laptops and remote users.In the middle is the medium control environment. Mid-Example Corp. has several Linux and Unix servers,but Bill the IT Guy has tried to maintain a greater degree of control by creating a NIS domain formachines, an LDAP directory for users, and Kerberos for authentication. While his environment is wellunder control, every application has to be maintained separately, using different tools. He also has toupdate all of the services manually whenever a new machine is added to his infrastructure or when oneis taken offline. In this situation, IPA greatly reduces his administrative overhead because it integrates allof the different applications together seamlessly, using a single and simplified tool set. It also makes itpossible for him to implement single sign-on services for all of the machines in his domain.On the other extreme is the absent control environment. At Big Example Corp., most of the systems areWindows based and are managed in a tightly-knit Active Directory forest. However, development,production, and other teams have many Linux and Unix systems — which are basically excluded fromthe Windows controlled environment. IPA brings native control to the Linux/Unix servers, using theirnative tools and applications — something that is not possible in an Active Directory forest. Additionally,because IPA is Windows-aware, data can be synchronized between Active Directory and IPA, preservinga centralized user store.IPA provides a very simple solution to a very common, very specific problem: identity management.1.1.2. Contrasting Identity Management with a Standard LDAP DirectoryT he closest relative to Identity Management is a standard LDAP directory like 389 Directory Server, butthere are some intrinsic differences between what they do and what theyre intended to do.First, it helps to understand what a directory service is. A directory service is a collection of software,hardware, and processes that stores information. While directory services can be highly specific (forexample, DNS is a directory service because it stores information on hostnames), a generic directoryservice can store and retrieve any kind of information. LDAP directories like 389 Directory Server aregeneric directories. T hey have a flexible schema that supports entries for users, machines, networkentities, physical equipment, and buildings, and that schema can be customized to define entries ofalmost anything. Because of its extensibility, LDAP servers like 389 Directory Server are frequently usedas backends that store data for other applications. 389 Directory Server not only contains information, itorganizes information. LDAP directories uses a hierarchical structure, a directory tree, that organizeentries into root entries (suffixes), intermediate or container entries (subtrees or branches), and leafentries (the actual data). Directory trees can be very complex, with a lot of branch points, or very simple(flat) with few branch points.T he primary feature of an LDAP directory is its generality. It can be made to fit into a variety ofapplications.Identity Management, on the other hand, has a very specific purpose and fits a very specific application.It is not a general LDAP directory, it is not a backend, and it is not a general policy server. It is notgeneric.Identity Management focuses on identities (user and machine) and policies that relate to those identitiesand their interactions. While it uses an LDAP backend to store its data, IPA has a highly-customized and
Red Hat Enterprise Linux 6 Identity Management Guide 31specific set of schema that defines a particular set of identity-related entries and defines them in detail. Ithas a relatively flat and simple directory tree because it has only a handful of entry types andrelationships that are relevant to its purpose. It has rules and limitations on how the IPA server can bedeployed because it can only be deployed for a specific purpose: managing identities.T he restrictions on IPA also give it a great deal of administrative simplicity. It has a simple installationprocess, a unified set of commands, and a clearly defined role in the overall IT infrastructure. An IPAdomain is easy to configure, easy to join, and easy to manage, and the functions that it serves —particularly identity/authentication tasks like enterprise-wide single sign-on — are also easier to do withIPA than with a more general-purpose directory service.T able 1.1. Identity Management Compared to 389 Directory Server 389 Directory Server Identity Management Use General purpose Single domain, focused on identity management Flexibility Highly-customizable Limitations to focus on identity and authentication Schema Default LDAP schema Optimized, special schema for identity management Directory T ree Standard and flexible hierarchy Flat tree with a fixed hierarchy Authentication LDAP Kerberos or Kerberos and LDAP Active Directory Synchronization Bi-directional Unidirectional, Active Directory to Identity Management Password Policies LDAP-based Kerberos-based User T ools Java Console and standard Web-based UI and special LDAP utilities Python command-line toolsLDAP directories like 389 Directory Server have flexibility and adaptability which makes them a perfectbackend to any number of applications. Its primary purpose is to store and retrieve data efficiently.IPA fills a very different niche. It is optimized to perform a single task very effectively. It stores userinformation and authentication and authorization policies, as well as other information related to access,like host information. Its single purpose is to manage identities.1.2. Bringing Linux Services TogetherIdentity Management unifies disparate yet related Linux services into a single management environment.From there, it establishes a simple, easy way to bring host machines into the domain of those services.An IPA server is, at its core, an identity and authentication server. T he primary IPA server, essentially adomain controller, uses a Kerberos server and KDC for authentication. An LDAP backend contains all ofthe domain information, including users, client machines, and domain configuration.
32 Chapter 1. Introduction to Identity ManagementFigure 1.1. T he IPA Server: Unifying ServicesOther services are included to provide support for the core identity/authentication functions. DNS is usedfor machine discovery and for connecting to other clients in the domain. NT P is used to synchronize alldomain clocks so that logging, certificates, and operations can occur as expected. A certificate serviceprovides certificates for Kerberos-aware services. All of these additional services work together underthe control of the IPA server.T he IPA server also has a set of tools which are used to manage all of the IPA-associated services.Rather than managing the LDAP server, KDC, or DNS settings individually, using different tools on localmachines, IPA has a single management toolset (CLI and web UI) that allows centralized and cohesiveadministration of the domain.1.2.1. Authentication: Kerberos KDCKerberos is an authentication protocol. Kerberos uses symmetric key cryptography to generate tickets tousers. Kerberos-aware services check the ticket cache (a keytab) and authenticate users with validtickets.Kerberos authentication is significantly safer than normal password-based authentication becausepasswords are never sent over the network — even when services are accessed on other machines.In Identity Management, the Kerberos administration server is set up on the IPA domain controller, and allof the Kerberos data are stored in IPAs backend Directory Server. T he Directory Server instancedefines and enforces access controls for the Kerberos data. NOTE T he IPA Kerberos server is managed through IPA tools instead of Kerberos tools because all of its data are stored in the Directory Server instance. T he KDC is unaware of the Directory Server, so managing the KDC with Kerberos tools does not effect the IPA configuration.
Red Hat Enterprise Linux 6 Identity Management Guide 331.2.2. Data Storage: 389 Directory ServerIdentity Management contains an internal 389 Directory Server instance. All of the Kerberos information,user accounts, groups, services, policy information, DNS zone and host entries, and all other informationin IPA is stored in this 389 Directory Server instance.When multiple servers are configured, they can talk to each other because 389 Directory Serversupports multi-master replication. Agreements are automatically configured between the initial serverand any additional replicas which are added to the domain.1.2.3. Authentication: Dogtag Certificate SystemKerberos can use certificates along with keytabs for authentication, and some services requirecertificates for secure communication. Identity Management includes a certificate authority, throughDogtag Certificate System, with the server. T his CA issues certificates to the server, replicas, and hostsand services within the IPA domain.T he CA can be a root CA or it can have its policies defined by another, external CA (so that it issubordinate to that CA). Whether the CA is a root or subordinate CA is determined when the IPA serveris set up.1.2.4 . Server/Client Discovery: DNSIdentity Management defines a domain — multiple machines with different users and services, eachaccessing shared resources and using shared identity, authentication, and policy configuration. T heclients need to be able to contact each other, as IPA servers. Additionally, services like Kerberos dependon hostnames to identify their principal identities.Hostnames are associated with IP address using the Domain Name Service (DNS). DNS mapshostnames to IP addresses and IP addresses to hostnames, providing a resource that clients can usewhen they need to look up a host. From the time a client is enrolled in the IPA domain, it uses DNS tolocate the IPA server and then all of the services and clients within the domain.Multiple DNS servers are usually configured, each one working as an authoritative resource formachines within a specific domain. Having the IPA server also be a DNS server is optional, but it isstrongly recommended. When the IPA server also manages DNS, there is tight integration between theDNS zones and the IPA clients and the DNS configuration can be managed using native IPA tools. Evenif an IPA server is a DNS server, other external DNS servers can still be used.1.2.5. Management: NT PMany services require that servers and clients have the same system time, within a certain variance. Forexample, Kerberos tickets use time stamps to determine their validity. If the times between the serverand client skew outside the allowed range, then any Kerberos tickets are invalidated.Clocks are synchronized over a network using Network Time Protocol (NT P). A central server acts asan authoritative clock and all of the clients which reference that NT P server sync their times to match.When the IPA server is the NT P server for the domain, all times and dates are synchronized before anyother operations are performed. T his allows all of the date-related services — including passwordexpirations, ticket and certificate expirations, account lockout settings, and entry create dates — tofunction as expected.T he IPA server, by default, works as the NT P server for the domain. Other NT P servers can also beused for the hosts.
34 Chapter 1. Introduction to Identity Management1.3. Relationships Between Servers and ClientsIdentity Management itself defines a domain, a group of machines that have shared configuration,policies, and identity stores. T his shared configuration allows the machines (and users) within thedomain to be aware of each other and operate together. T his awareness can be used to enable cross-platform compatibility, like unifying Windows and Linux systems, or to enable infrastructure-wide singlesign-on.1.3.1. About IPA Servers and ReplicasIdentity Management works by having identified servers which are the master stores of information foruser and machine identities and domain-wide policies. T hese servers host domain-related servicessuch as certificate authorities, NT P, Kerberos, SSH, and DNS. T he server also acts as a centralrepository of identity and policy information.Clients interact indirectly with IPA servers when they attempt to access domain resources, such asfileshares, services, remote machines, or authentication (through SSSD and Kerberos).As said, an IPA server is a controller for a lot of associated services. While a number of those servicesare support, most of them are not required. For example, a server may have a CA, a DNS server, or anNT P server — or it can be installed without those services.Once an IPA server is set up, its configuration can be copied and used as the basis for another IPAserver. When an IPA server is copied, that copy is called a replica. NOTE T he only real different between an IPA server and an IPA replica is that a server is a new installation and a replica is based on an existing server. Once the instance is configured, servers and replicas are basically identical in functionality and behavior within the IPA domain.T here is a good deal of flexibility in the IPA server (and replica) topology. For example, Server A can beinstalled with a CA and DNS services, while Replica A can be based on Server As configuration but nothost either DNS or CA services. Server B can be added to the domain, also without CA or DNS services.At any time in the future, a CA or DNS service can be created and configured on Replica A or Server B.Servers and replicas both use underlying LDAP directories to store user and host entries, configurationdata, policy configuration, and keytabs, certificates, and keys. Servers and replicas propagate dataamong each other through multi-master replication agreements. Both servers and replicas are mastersin the replication topology.
Red Hat Enterprise Linux 6 Identity Management Guide 35Figure 1.2. Server and Replica Interactions TIP T he replication topology essentially creates a cloud of IPA servers. One benefit of a server domain is automatic load balancing, using the SRV records in DNS. T he SRV record priority sets the order that servers and replicas are contacted, while weight distributed the load between servers/replicas with the same priority. T he server and replica DNS entries can be edited to change the load balancing, which is covered in Example 9.4, “SRV Record” and Section 9.15, “Changing Load Balancing for IPA Servers and Replicas”.1.3.2. About IPA ClientsA client is simply any machine which is configured to operate within the IPA domain, using its Kerberosand DNS services, NT P settings, and certificate services. T hats an important distinction: a client doesnot require a daemon or (necessarily) an installed product. It requires only system configurations whichdirect it to use IPA services.For Red Hat Enterprise Linux systems, a certain number of platform tools are available for IPA to use,such as SSSD. T hese are IPA-enabled platform applications, which is simply a way of saying that theyare aspects of the underlying platform that work with IPA services. Other tools, like certain PAM and NSSmodules and IPA command-line utilities, are provided as IPA-specific packages that must be installed onthe machine. T hese are IPA-related components.
36 Chapter 1. Introduction to Identity ManagementFigure 1.3. Server and Client InteractionsIPA uses the local storage (cache) on a client to improve performance in a few ways: Store IPA information when the machine is offline. Keep information active beyond its normal timeout period if the client cannot access the central server. T he cache is persistent even after rebooting the machine. Reduce the round-trip time of requests by checking information locally before looking at the server.Information is stored either in an LDB database (similar to LDAP) or the local filesystem (as XML files),depending on the type of information. Identity information (about users, machines, and groups) is stored in the LDB database, which uses the same syntax as an LDAP directory. T his identity information is originally stored in the IPA servers 389 Directory Server instance. Because this information changes frequently and is referenced frequently, it is important to be able to call the more current information quickly, which is possible using an LDB database on the client and the Directory Server on the server. Policy information is more static than identity information, and it can include configuration for SELinux or sudo. T hese policies are set globally on the server and then are propagated to the clients. On the client, the policy information is stored in the filesystem in XML files which can be downloaded and converted into a native file for whatever service is being managed.A specific set of services on the IPA server interact with a subset of services and modules on the IPAclient. A client is any machine (a host) which can retrieve a keytab or certificates from the IPA domain.
Red Hat Enterprise Linux 6 Identity Management Guide 37Figure 1.4 . Interactions Between IPA ServicesFigure 1.4, “Interactions Between IPA Services” shows that Red Hat Enterprise Linux uses two nativedaemons to interact with the IPA server: SSSD provides the user authentication for the machine and enforces host-based access control rules. certm onger monitors and renews the certificates on the client. It can request new certificates for the services on the system, including virtual machines.When a Red Hat Enterprise Linux client is added to the domain (enrolled), its SSSD and certm ongerare configured to connect to the IPA server and the required Kerberos keytab and host certificates arecreated. (T he host certificate is not used directly by IPA; it may be used by other services, such as aweb server.)
38 Chapter 2. Installing an IPA ServerChapter 2. Installing an IPA ServerT he IPA domain is defined and managed by an IPA server which is essentially a domain controller. T herecan be multiple domain controllers within a domain for load-balancing and failover tolerance. T heseadditional servers are called replicas of the master IPA server.Both IPA servers and replicas only run on Red Hat Enterprise Linux systems. For both servers andreplicas, the necessary packages must be installed and then the IPA server or replica itself is configuredthrough setup scripts, which configure all of the requisite services.2.1. Supported Server PlatformsIPA 2.2 is supported on these platforms: Red Hat Enterprise Linux 6 i386 Red Hat Enterprise Linux 6 x86_642.2. Preparing to Install the IPA ServerBefore you install IPA, ensure that the installation environment is suitably configured. You also need toprovide certain information during the installation and configuration procedures, including realm namesand certain usernames and passwords. T his section describes the information that you need to provide.2.2.1. Hardware RecommendationsA basic user entry is about 1 KB in size, as is a simple host entry with a certificate. T he most importanthardware feature to size properly is RAM. While all deployments are different, depending on the numberof users and groups and the type of data stored, there is a rule of thumb to use to help determine howmuch RAM to use: For 10,000 users and 100 groups, have at least 2GB of RAM and 1GB swap space. For 100,000 users and 50,000 groups, have at least 16GB of RAM and 4GB of swap space. TIP For larger deployments, it is more effective to increase the RAM than to increase disk space because much of the data are stored in cache.T he underlying Directory Server instance used by the IPA server can be tuned to increase performance.For tuning information, see the Directory Server documentation at http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Performance_T uning_Guide/system-tuning.html.2.2.2. Software RequirementsMost of the packages that an IPA server depends on are installed as dependencies when the IPApackages are installed. T here are some packages, however, which are required before installing the IPApackages: Kerberos 1.9 T he named and bind-dyndb-ldap packages for DNS2.2.3. Supported Web Browsers
Red Hat Enterprise Linux 6 Identity Management Guide 39T he only supported browser to access the IPA web UI is Firefox 3.x or 4.x.2.2.4 . System PrerequisitesT he IPA server is set up using a configuration script, and this script makes certain assumption about thehost system. If the system does not meet these prerequisites, then server configuration may fail.2.2.4 .1. Hostname and IP Address RequirementsRegardless of whether the DNS is within the IPA server or external, the server host must have DNSproperly configured: T he hostname must be a fully-qualified domain name. For example, ipaserver.exam ple.com . IMPORTANT T his must be a valid DNS name, which means only numbers, alphabetic characters, and hyphens (-) are allowed. Other characters, like underscores, in the hostname will cause DNS failures. T he hostname must be all lower-case. T he servers A record must be set and resolve to its public IP address. T he fully-qualified domain name cannot resolve to the loopback address. It must resolve to the machines public IP address, not to 127.0.0.1. T he output of the hostnam e command cannot be localhost or localhost6. T he servers hostname and IP address must be in its own /etc/hosts file. It is recommended that a separate DNS domain be allocated for the IPA server. While not required (clients from other domains can still be enrolled in the IPA domain), this is a convenience for overall DNS management. TIP If the IPA server is configured to host its own DNS server, any previous existing DNS ignored. A records and PT R records do not need to match for the IPA server machine, and the machine can have any configured IP address.2.2.4 .2. Directory ServerT here must not be any instances of 389 Directory Server installed on the host machine.2.2.4 .3. System FilesT he server script overwrites system files to set up the IPA domain. T he system should be clean, withoutcustom configuration for services like DNS and Kerberos, before configuring the IPA server.2.2.4 .4 . System PortsIPA uses a number of ports to communicate with its services. T hese ports, listed in T able 2.1, “IPAPorts”, must be open and available for IPA to work. T hey cannot be in use by another service or blockedby a firewall. T o make sure that these ports are available, try iptables to list the available ports or nc,telnet, or nm ap to connect to a port or run a port scan.T o open a port:
40 Chapter 2. Installing an IPA Server [root@server ~]# iptables -A INPUT -p tcp --dport 389 -j ACCEPTT he iptables man page has more information on opening and closing ports on a system.T able 2.1. IPA Ports Service Ports T ype HT T P/HT T PS T CP 80 443 LDAP/LDAPS T CP 389 636 Kerberos T CP and UDP 88 464 DNS 53 T CP and UDP NT P 123 UDP Dogtag Certificate System - 7389 T CP LDAP2.2.4 .5. NT PIf a server is being installed on a virtual machine, that server should not run an NT P server. T o disableNT P for IPA, use the --no-ntp option.2.2.4 .6. NSCDIt is strongly recommended that you avoid or restrict the use of nscd in an IPA deployment. T he nscdservice is extremely useful for reducing the load on the server, and for making clients more responsive,but there can be problems when a system is also using SSSD, which performs its own caching.nscd caches authentication and identity information for all services that perform queries throughnsswitch, including getent. Because nscd performs both positive and negative caching, if a requestdetermines that a specific IPA user does not exist, it marks this as a negative cache. Values stored inthe cache remain until the cache expires, regardless of any changes that may occur on the server. T heresults of such caching is that new users and memberships may not be visible, and users andmemberships that have been removed may still be visible.Avoid clashes with SSSD caches and to prevent locking out users, avoid using nscd altogether.Alternatively, use a shorter cache time by resetting the time-to-live caching values in the/etc/nscd.conf file: positive-time-to-live group 3600 negative-time-to-live group 60 positive-time-to-live hosts 3600 negative-time-to-live hosts 202.2.5. Networking