| Identity Management GuideChapter 2. Installing an IdM ServerThe IdM domain is defined and managed by an IdM server which is essentially a domain controller. There can be multiple domain controllers within a domain for load-balancing and failover tolerance. These additional servers are called replicas of the master IdM server. Both IdM servers and replicas only run on Red Hat Enterprise Linux systems. For both servers and replicas, the necessary packages must be installed and then the IdM server or replica itself is configured through setup scripts, which configure all of the requisite services. 2.1. Supported Server PlatformsIdM 2.2 is supported on these platforms: 2.2. Preparing to Install the IdM ServerBefore you install IdM, ensure that the installation environment is suitably configured. You also need to provide certain information during the installation and configuration procedures, including realm names and certain usernames and passwords. This 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. The most important hardware feature to size properly is RAM. While all deployments are different, depending on the number of users and groups and the type of data stored, there is a rule of thumb to use to help determine how much 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.
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. 2.2.2. Software RequirementsMost of the packages that an IdM server depends on are installed as dependencies when the IdM packages are installed. There are some packages, however, which are required before installing the IdM packages: 2.2.3. Supported Web BrowsersThe only supported browser to access the IdM web UI is Firefox 3.x or 4.x. 2.2.4. System PrerequisitesThe IdM server is set up using a configuration script, and this script makes certain assumption about the host 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 IdM server or external, the server host must have DNS properly configured: The hostname must be a fully-qualified domain name. For example, ipaserver.example.com. This 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. The hostname must be all lower-case. The server's A record must be set and resolve to its public IP address. The fully-qualified domain name cannot resolve to the loopback address. It must resolve to the machine's public IP address, not to 127.0.0.1. The output of the hostname command cannot be localhost or localhost6. The server's hostname and IP address must be in its own /etc/hosts file. It is recommended that a separate DNS domain be allocated for the IdM server. While not required (clients from other domains can still be enrolled in the IdM domain), this is a convenience for overall DNS management.
If the IdM server is configured to host its own DNS server, any previous existing DNS ignored. A records and PTR records do not need to match for the IdM server machine, and the machine can have any configured IP address. 2.2.4.2. Directory ServerThere must not be any instances of 389 Directory Server installed on the host machine. The server script overwrites system files to set up the IdM domain. The system should be clean, without custom configuration for services like DNS and Kerberos, before configuring the IdM server. IdM uses a number of ports to communicate with its services. These ports, listed in Table 2.1, "IdM Ports", must be open and available for IdM to work. They cannot be in use by another service or blocked by a firewall. To make sure that these ports are available, try iptables to list the available ports or nc, telnet, or nmap to connect to a port or run a port scan. To open a port: [root@server ~]# iptables -A INPUT -p tcp --dport 389 -j ACCEPT The iptables man page has more information on opening and closing ports on a system. Table 2.1. IdM Ports | Service | Ports | Type |
|---|
| HTTP/HTTPS | | TCP | | LDAP/LDAPS | | TCP | | Kerberos | | TCP and UDP | | DNS | 53 | TCP and UDP | | NTP | 123 | UDP | | Dogtag Certificate System - LDAP | 7389 | TCP |
If a server is being installed on a virtual machine, that server should not run an NTP server. To disable NTP for IdM, use the --no-ntp option. It is strongly recommended that you avoid or restrict the use of nscd in an IdM deployment. The nscd service 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 through nsswitch, including getent. Because nscd performs both positive and negative caching, if a request determines that a specific IdM user does not exist, it marks this as a negative cache. Values stored in the cache remain until the cache expires, regardless of any changes that may occur on the server. The results of such caching is that new users and memberships may not be visible, and users and memberships 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 3600negative-time-to-live group 60positive-time-to-live hosts 3600negative-time-to-live hosts 20 2.2.5.1. Configuring Networking ServicesThe default networking service used by Red Hat Enterprise Linux is NetworkManager, and due to the way this service works, it can cause problems with IdM and the KDC. Consequently, it is highly recommended that you use the network service to manage the networking requirements in an IdM environment and disable the NetworkManager service. Boot the machine into single-user mode and run the following commands: [root@server ~]# chkconfig NetworkManager off; service NetworkManager stop If NetworkManagerDispatcher is installed, ensure that it is stopped and disabled: [root@server ~]# chkconfig NetworkManagerDispatcher off; service NetworkManagerDispatcher stop Then, make sure that the network service is properly started. [root@server ~]# chkconfig network on; service network start Ensure that static networking is correctly configured. Restart the system.
2.2.5.2. Configuring the /etc/hosts FileYou need to ensure that your /etc/hosts file is configured correctly. A misconfigured file can prevent the IdM command-line tools from functioning correctly and can prevent the IdM web interface from connecting to the IdM server. Configure the /etc/hosts file to list the FQDN for the IdM server before any aliases. Also ensure that the hostname is not part of the localhost entry. The following is an example of a valid hosts file: 127.0.0.1localhost.localdomainlocalhost::1localhost6.localdomain6localhost6192.168.1.1ipaserver.example.comipaserver Do not omit the IPv4 entry in the /etc/hosts file. This entry is required by the IdM web service. 2.3. Installing the IdM Server PackagesInstalling only the IdM server requires a single package, ipa-server. If the IdM server will also manage a DNS server, then it requires two additional packages to set up the DNS. All of these packages can be installed using the yum command: [root@server ~]# yum install ipa-server bind bind-dyndb-ldap Installing the ipa-server also installs a large number of dependencies, such as 389-ds-base for the LDAP service and krb5-server for the Kerberos service, along with IdM tools. 2.4. Creating an IdM Server InstanceThe IdM setup script creates a server instance, which includes configuring all of the required services for the IdM domain: The network time daemon (ntpd) A 389 Directory Server instance A Kerberos key distribution center (KDC) Apache (httpd) An updated SELinux targeted policy The Active Directory WinSync plug-in A certificate authority Optional. A domain name service (DNS) server
The IdM setup process can be minimal, where the administrator only supplies some required information, or it can be very specific, with user-defined settings for many parts of the IdM services. The configuration is passed using arguments with the ipa-server-install script. 2.4.1. About ipa-server-installAn IdM server instance is created by running the ipa-server-install script. This script can accept user-defined settings for services, like DNS and Kerberos, that are used by the IdM instance, or it can supply predefined values for minimal input from the administrator. While ipa-server-install can be run without any options, so that it prompts for the required information, it has numerous arguments which allow the configuration process to be easily scripted or to supply additional information which is not requested during an interactive installation. Table 2.2. ipa-server-install Options | Argument | Description |
|---|
| -a ipa_admin_password | The password for the IdM administrator. This is used for the admin user to authenticate to the Kerberos realm. | | --hostname=hostname | The fully-qualified domain name of the IdM server machine. This 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. Additionally, the hostname must all be lower-case. No capital letters are allowed. | | -n domain_name | The name of the LDAP server domain to use for the IdM domain. This is usually based on the IdM server's hostname. | | -p directory_manager_password | The password for the superuser, cn=Directory Manager, for the LDAP service. | | -r realm_name | The name of the Kerberos realm to create for the IdM domain. | | --subject=subject_DN | Sets the base element for the subject DN of the issued certificates. This defaults to O=realm. | | --forwarder=forwarder | Gives a DNS forwarder to use with the DNS service. To specify more than one forwarder, use this option multiple times. | | --no-forwarders | Uses root servers with the DNS service instead of forwarders. | | --no-reverse | Does not create a reverse DNS zone when the DNS domain is set up. (If a reverse DNS zone is already configured, then that existing reverse DNS zone is used.) If this option is not used, then the default value is true, which assumes that reverse DNS should be configured by the installation script. | | --setup-dns | Tells the installation script to set up a DNS service within the IdM domain. Using an integrated DNS service is optional, so if this option is not passed with the installation script, then no DNS is configured. | | --idmax=number | Sets the upper bound for IDs which can be assigned by the IdM server. The default value is the ID start value plus 199999. | | --idstart=number | Sets the lower bound (starting value) for IDs which can be assigned by the IdM server. The default value is randomly selected. |
2.4.2. Setting up an IdM Server: Basic Interactive InstallationAll that is required to set up an IdM server is to run the ipa-server-install script. This launches the script interactively, which prompts for the required information to set up a server, but without more advanced configuration like DNS and CA options. Run the ipa-server-install script. [root@server ~]# ipa-server-install Enter the hostname. This is determined automatically using reverse DNS. Server host name [ipaserver.example.com]: Enter the domain name. This is determined automatically based on the hostname. Please confirm the domain name [example.com]: The script then reprints the hostname, IP address, and domain name. The IPA Master Server will be configured withHostname: ipaserver.example.comIP address: 192.168.1.1Domain name: example.com Enter the new Kerberos realm name. This is usually based on the domain name. Please provide a realm name [EXAMPLE.COM]: Enter the password for the Directory Server superuser, cn=Directory Manager. There are password strength requirements for this password, including a minimum password length. Directory Manager password:Password (confirm): Enter the password for the IdM system user account, admin. This user is created on the machine. IPA admin password:Password (confirm): After that, the script configures all of the associated services for IdM, with task counts and progress bars. Configuring ntpd [1/4]: stopping ntpd ...done configuring ntpd.Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user...done configuring pkids.Configuring certificate server: Estimated time 6 minutes [1/17]: creating certificate server user....done configuring pki-cad.Configuring directory server: Estimated time 1 minute [1/32]: creating directory server user...done configuring dirsrv.Configuring Kerberos KDC: Estimated time 30 seconds [1/14]: setting KDC account password...done configuring krb5kdc.Configuring kadmin [1/2]: starting kadmin [2/2]: configuring kadmin to start on bootdone configuring kadmin.Configuring the web interface: Estimated time 1 minute [1/12]: disabling mod_ssl in httpd...done configuring httpd.Setting the certificate subject baserestarting certificate serverApplying LDAP updatesRestarting the directory serverRestarting the KDCRestarting the web serverSample zone file for bind has been created in /tmp/sample.zone.ygzij5.db==============================================================================Setup complete Restart the SSH service to retrieve the Kerberos principal and to refresh the name server switch (NSS) configuration file: [root@server ~]# service sshd restart Authenticate to the Kerberos realm using the admin user's credentials to ensure that the user is properly configured and the Kerberos realm is accessible. [root@server ~]# kinit adminPassword for [email protected]: Test the IdM configuration by running a command like ipa user-find. For example: [root@server ~]# ipa user-find admin -------------- 1 user matched -------------- User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash Account disabled: False Member of groups: admins ---------------------------- Number of entries returned 1 ----------------------------
2.4.3. Examples of Creating the IdM ServerThe way that an IdM server is installed can be different depending on the network environment, security requirements within the organization, and the desired topology. These example illustrate some common options when installing the server. These examples are not mutually exclusive; it is entirely possible to use CA options, DNS options, and IdM configuration options in the same server invocation. These are called out separately simply to make it more clear what each configuration area requires. 2.4.3.1. Non-Interactive Basic InstallationThis information can be passed with the ipa-server-install, along with the -U to force it to run without requiring user interaction. Example 2.1. Basic Installation without Interaction [root@server ~]# ipa-server-install -a secret12 --hostname=ipaserver.example.com -r EXAMPLE.COM -p secret12 -n example.com -U The script then prints the submitted values: To accept the default shown in brackets, press the Enter key.The IPA Master Server will be configured withHostname: ipaserver.example.comIP address: 192.168.1.1Domain name: example.com The server name 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. Additionally, the hostname must all be lower-case. No capital letters are allowed. 2.4.3.2. Using Different CA ConfigurationsIdentity Management uses an integrated certificate authority (CA) to create the certificates and keytabs used by users and hosts within the domain. There are three different ways that IdM incorporates the CA into the IdM server: The installation script installs a root Dogtag Certificate System CA. The Dogtag Certificate System CA provides the full range of certificate services, based on policies that are defined in the Dogtag Certificate System configuration. This is the default configuration. Alternatively, the installation script can set up a Dogtag Certificate System CA that is subordinate to an external CA. A subordinate CA is chained to another CA, and it uses the policies and restrictions defined by that external CA. The root CA can be an external CA like Verisign or a corporate CA. A Dogtag Certificate System CA is still installed and configured as part of the IdM server installation, but its CA certificates are issued by the external CA rather than by itself.
The IdM server can use a certificate issued by an external CA. This can be a corporate CA or a third-party CA like Verisign or Thawte. As with a normal setup process, using an external CA still uses a Dogtag Certificate System instance for the IdM server for issuing all of its client and replica certificates; the initial CA certificate is simply issued by a different CA. When using an external CA, there are two additional steps that must be performed: submit the generated certificate request to the external CA and then load the CA certificate and issued server certificate to complete the setup. Example 2.2. Using an External CA Run the ipa-server-install script, using the --external-ca option. [root@server ~]# ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --external-ca The script sets up the NTP and Directory Server services as normal. The script completes the CA setup and returns information about where the certificate signing request (CSR) is located, /root/ipa.csr. This request must be submitted to the external CA. Configuring certificate server: Estimated time 6 minutes [1/4]: creating certificate server user [2/4]: creating pki-ca instance [3/4]: restarting certificate server [4/4]: configuring certificate server instanceThe next step is to get /root/ipa.csr signed by your CA and re-run ipa-server-install. Submit the request to the CA. The process differs for every service. Retrieve the issued certificate and the CA certificate chain for the issuing CA. Again, the process differs for every certificate service, but there is usually a download link on a web page or in the notification email that allows administrators to download all the required certificates. Be sure to get the full certificate chain for the CA, not just the CA certificate. Rerun ipa-server-install, specifying the locations and names of the certificate and CA chain files. For example: [root@server ~]# ipa-server-install --external_cert_file=/tmp/servercert20110601.p12 --external_ca_file=/tmp/cacert.p12
IdM can be configured to manage its own DNS, use an existing DNS, or not use DNS services at all (which is the default). Running the setup script alone does not configure DNS; this requires the --setup-dns option. As with a basic setup, the DNS setup can either prompt for the required information or the DNS information can be passed with the script to allow an automatic or unattended setup process. Example 2.3. Interactive DNS Setup Run the ipa-server-install script, using the --setup-dns option. [root@server ~]# ipa-server-install -a secret12 -r EXAMPLE.COM -P password -p secret12 -n ipaserver.example.com --setup-dns The script configures the hostname and domain name as normal. The script then prompts for DNS forwarders. If forwarders will be used, enter yes, and then supply the list of DNS servers. If IdM will manage its own DNS service, then enter no. Do you want to configure DNS forwarders? [yes]: noNo DNS forwarders configured The script sets up the NTP, Directory Server, Certificate System, Kerberos, and Apache services. Before completing the configuration, the script prompts to ask whether it should configure reverse DNS services. If you select yes, then it configures the named service. Do you want to configure the reverse zone? [yes]: yesConfiguring named: [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselvesdone configuring named.==============================================================================Setup complete
If DNS is used with IdM, then two pieces of information are required: any DNS forwarders that will be used and using (or not) reverse DNS. To perform a non-interactive setup, this information can be passed using the --forwarder or --no-forwarders option and --no-reverse option. Example 2.4. Setting up DNS Non-Interactively To use DNS always requires the --setup-dns. To user forwarders, use the --forwarder option; for multiple forwarders, use multiple invocations of --forwarder. [root@server ~]# ipa-server-install ... --setup-dns --forwarder=1.2.3.0 --forwarder=1.2.255.0 Some kind of forwarder information is required. If no external forwarders will be used with the IdM DNS service, then use the --no-forwarders option to indicate that only root servers will be used. The script always assumes that reverse DNS is configured along with DNS, so it is not necessary to use any options to enable reverse DNS. To disable reverse DNS, use the --no-reverse option; if a reverse DNS zone is already configured, then using the --no-reverse option means that existing reverse DNS zone is used. [root@server ~]# ipa-server-install ... --setup-dns --no-reverse 2.4.4. Troubleshooting Installation Problemsipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('Decrypt integrity check failed', -1765328353)There are two potential causes for this: ipaserver named[6886]: failed to dynamically load driver 'ldap.so': libldap-2.4.so.2: cannot open shared object file: No such file or directory This usually means that the bind-chroot package is installed and is preventing the named service from starting. To resolve this issue, remove the bind-chroot package and then restart the IdM server. [root@server ~]# yum remove bind-chroot 2.5. Setting up IdM ReplicasIn the IdM domain, there are three types of machines: Servers, which manage all of the services used by domain members Replicas, which are essentially copies of servers (and, once copied, are identical to servers) Clients, which belong to the Kerberos domains, receive certificates and tickets issued by the servers, and use other centralized services for authentication and authorization
A replica is a clone of a specific IdM server. The server and replica share the same internal information about users, machines, certificates, and configured policies. These data are copied from the server to the replica in a process called replication. The two Directory Server instances used by an IdM server - the Directory Server instance used by the IdM server as a data store and the Directory Server instance used by the Dogtag Certificate System to store certificate information - are replicated over to corresponding consumer Directory Server instances used by the IdM replica. If you are using a Dogtag Certificate System instance as the CA for the IdM domain, then it is possible to make a replica of a replica. 2.5.1. Prepping and Installing the Replica ServerReplicas are functionally the same as IdM servers, so they have the same installation requirements and packages. The replica must be the same version as the original master server. If the master server is running on Red Hat Enterprise Linux 6.3, IdM version 2.2.x, then the replica must also run on Red Hat Enterprise Linux 6.3 and use the IdM 2.2.x packages. Creating a replica of a different version than the master is not supported. Attempting to create a replica using a different version fails when attempting to configure the 389 Directory Server instance. [root@server ~]# yum install ipa-server bind bind-dyndb-ldap Do not run the ipa-server-install script. The replica and the master server must be running the same version of IdM. If there is an existing Dogtag Certificate System or Red Hat Certificate System instance on the replica machine, make sure that port 7389 is free. This port is used by the master IdM server to communicate with the replica. Make sure the appropriate ports are open on both the server and the replica machine during and after the replica configuration. Servers and replicas connect to each other over ports 9443, 9444, 9445, and 7389 during the replica configuration. Once the replica is set up, the server and replica communicate over port 7389. 2.5.2. Creating the ReplicaOn the master server, create a replica information file. This contains realm and configuration information taken from the master server which will be used to configure the replica server. Run the ipa-replica-prepare command on the master IdM server. The command requires the fully-qualified domain name of the replica machine. Using the --ip-address option automatically creates DNS entries for the replica, including the A and PTR records for the replica to the DNS. [root@server ~]# ipa-replica-prepare ipareplica.example.com --ip-address 192.168.1.2 Determining current realm nameGetting domain name from LDAPPreparing replica for ipareplica.example.com from ipaserver.example.comCreating SSL certificate for the Directory ServerCreating SSL certificate for the Web ServerCopying additional filesFinalizing configurationPackaging the replica into replica-info-ipareplica.example.com This 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. Additionally, the hostname must all be lower-case. No capital letters are allowed. For more options with ipa-replica-prepare, see the ipa-replica-prepare manpage. Each replica information file is created in the /var/lib/ipa/ directory as a GPG-encrypted file. Each file is named specifically for the replica server for which it is intended, such as replica-info-ipareplica.example.com.gpg. A replica information file cannot be used to create multiple replicas. It can only be used for the specific replica and machine for which it was created. Replica information files contain sensitive information. Take appropriate steps to ensure that they are properly protected. Copy the replica information file to the replica server: [root@server ~]# scp /var/lib/ipa/replica-info-ipareplica.example.com.gpg root@ipareplica:/var/lib/ipa/ On the replica server, run the replica installation script, referencing the replication information file. There are other options for setting up DNS, much like the server installation script. Additionally, there is an option to configure a CA for the replica; while CA's are installed by default for servers, they are optional for replicas. For example: [root@ipareplica ~]# ipa-replica-install --setup-ca --setup-dns /var/lib/ipa/replica-info-ipareplica.example.com.gpgDirectory Manager (existing master) password:Warning: Hostname (ipareplica.example.com) not found in DNSRun connection check to masterCheck connection from replica to remote master 'ipareplica. example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OKThe following list of ports use UDP protocol and would need to bechecked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPEDConnection from replica to master is OK.Start listening on required ports for remote master checkGet credentials to log in to remote [email protected] password:Execute check on remote [email protected]'s password:Check connection from master to remote replica 'ipareplica. example.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OKConnection from master to replica is OK.Connection check OK Additional options for the replica installation script are listed in the ipa-replica-install manpage. The replica installation script runs a test to ensure that the replica file being installed matches the current hostname. If they do not match, the script returns a warning message and asks for confirmation. This could occur on a multi-homed machine, for example, where mismatched hostnames may not be an issue. Enter the Directory Manager password when prompted. The script then configures a Directory Server instance based on information in the replica information file and initiates a replication process to copy over data from the master server to the replica, a process called initialization. Verify that the proper DNS entries were created so that IdM clients can discover the new server. DNS entries are required for required domain services: ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp
If the initial IdM server was created with DNS enabled, then the replica is created with the proper DNS entries. For example: [root@ipareplica ~]# DOMAIN=example.com[root@ipareplica ~]# NAMESERVER=ipareplica[root@ipareplica ~]# for i in _ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp _kerberos-master._udp _ntp._udp; do echo ""; dig @${NAMESERVER} ${i}.${DOMAIN} srv +nocmd +noquestion +nocomments +nostats +noaa +noadditional +noauthority; done | egrep -v "^;" | egrep __ldap._tcp.example.com. 86400 IN SRV 0 100 389 ipaserver1.example.com._ldap._tcp.example.com. 86400 IN SRV 0 100 389 ipaserver2.example.com._kerberos._tcp.example.com. 86400 IN SRV 0 100 88 ipaserver1.example.com....8<...If the initial IdM server was created without DNS enabled, then each DNS entry, including both TCP and UPD entries for some services, should be added manually. For example: [root@ipareplica ~]# kinit admin[root@ipareplica ~]# ipa dnsrecord-add example.com _ldap._tcp --srv-rec="0 100 389 ipareplica.example.com." Optional. Set up DNS services for the replica. These are not configured by the setup script, even if the master server uses DNS. Use the ipa-dns-install command to install the DNS manually, then use the ipa dnsrecord-add command to add the required DNS records. For example: [root@ipareplica ~]# ipa-dns-install[root@ipareplica ~]# ipa dnsrecord-add example.com @ --ns-rec ipareplica.example.com. Use the fully-qualified domain name of the replica, including the final period (.), otherwise BIND will treat the hostname as relative to the domain.
2.5.3. Troubleshooting Replica InstallationThe only resolution is to uninstall the replica: [root@ipareplica ~]# ipa-server-install --uninstall After uninstalling the replica, ensure that port 7389 on the replica is available, and retry the replica installation. slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ... The replica is looking for a credentials cache in /tmp/krb5cc_496 (where 496 is the 389 Directory Server user ID) and cannot find it. There may also be messages that the server could not obtain Kerberos credentials for the host principal: set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error) These errors are both related to how and when the 389 Directory Server instance loads its Kerberos credentials cache. While 389 Directory Server itself supports multiple different authentication mechanisms, Identity Management only uses GSS-API for Kerberos connections. The 389 Directory Server instance for Identity Management keeps its Kerberos credentials cache in memory. When the 389 Directory Server process ends - like when the IdM replica is stopped - the credentials cache is destroyed. Also, the 389 Directory Server is used as the backend storage for the principal information for the KDC. When the replica then restarts, the 389 Directory Server instance starts first, since it supplies information for the KDC, and then the KDC server starts. This start order is what causes the GSS-API and Kerberos connection errors. The 389 Directory Server attempts to open a GSS-API connection, but since there is no credentials cache yet and the KDC is not started, the GSS connection fails. Likewise, any attempt to obtain the host credentials also fails. These errors are transient. The 389 Directory Server re-attempts the GSS-API connection after the KDC starts and it has a credentials cache. The 389 Directory Server logs then record a bind resumed message. These startup GSS-API connection failures can be ignored as long as that connection is successfully established. 2.6. Uninstalling IdM Servers and ReplicasTo uninstall both an IdM server and an IdM replica, pass the --uninstall option to the ipa-server-install command: [root@ipareplica ~]# ipa-server-install --uninstall 2.7. Upgrading Identity Management to Red Hat Enterprise Linux 6.4Identity Management is generally updated whenever a system is upgraded to a new release. Upgrades should be transparent and do not require any user or administrative intervention. 2.7.1. Upgrading PackagesThe IdM server packages are updated when the system packages are updated: [root@ipaserver ~]# yum update * This is the easiest way to upgrade the server because it automatically pulls in updates for related services, like SSSD, which provide Identity Management functionality. To upgrade the IdM server packages specifically, run yum on the master server: [root@ipaserver ~]# yum update ipa-server It can take several seconds for the update process to apply all of the changes. The update process automatically updates all schema and LDAP configuration, Apache configuration, and other services configuration, and restarts all IdM-associated services. It is not necessary to update all servers and replicas at precisely the same time; the IdM servers will still work with each other and replicate data successfully. The older IdM servers will simply lack the new features. Schema changes are replicated between servers. So once one master server is updated, all servers and replicas will have the updated schema, even if their packages are not yet updated. This ensures that any new entries which use the new schema can still be replicated among all the servers in the IdM domain. Clients do not need to have new packages installed. The client packages used to configured a Red Hat Enterprise Linux system do not impact the enrollment of the client within the domain. Updating client packages could bring in updated packages for other dependencies, such as certmonger which contain bug fixes, but this is not required to maintain client functionality or behavior within the IdM domain. 2.7.2. Removing Browser Configuration for Ticket Delegation (For Upgrading from 6.2)As part of establishing Kerberos authentication, a principal is given a ticket granting ticket (TGT). Whenever that principal attempts to contact a service or application within the Kerberos domain, the service checks for an active TGT and then requests its own service-specific ticket from the TGT for that principal to access that service. As part of configuring the web browser used to access the IdM web UI (and any other Kerberos-aware web applications), previous versions of Identity Management required that the TGT delegation be forwarded to the IdM server. This required adding the delegation-uris parameter to the about:config setup in Firefox: network.negotiate-auth.delegation-uris .example.com In Red Hat Enterprise Linux 6.3, Identity Management uses the Kerberos Services for User to Proxy (S4U2Proxy), so this additional delegation step is no longer required. There is no need to restart the browser after changing the delegation-uris setting. The preference.html file in configure.jar sets the delegation-uris parameter. The updated preference.html file can be added to configure.jar, and then configure.jar can be re-signed and re-deployed on the IdM servers. Only update the configure.jar file on the initial IdM server. This is the master server, and it is the only server which has a signing certificate. Then propagate the updated file to the other servers and replicas. Update the packages on the initial IdM master server (the first instance). This will bring in the 2.2 UI packages, including the configure.jar file. Back up the existing configure.jar file. [root@ipaserver ~]# mv /usr/share/ipa/html/configure.jar /usr/share/ipa/html/configure.jar.old Create a temporary working directory. [root@ipaserver ~]# mkdir /tmp/sign Copy the updated preference.html file to the working directory. [root@ipaserver ~]# cp /usr/share/ipa/html/preferences.html /tmp/sign Use the signtool command (one of the NSS utilities) to add the new preference.html file and re-sign the configure.jar file. [root@ipaserver ~]# signtool -d /etc/httpd/alias -k Signing-Cert -Z /usr/share/ipa/html/configure.jar -e ".html" -p `cat /etc/httpd/alias/pwdfile.txt` /tmp/sign The -e option tells the tool to sign only files with a .html extension. The -Z option creates a new JAR file. Copy the regenerated configure.jar file to all other IdM servers and replicas.
2.7.3. Testing Before Upgrading the IdM Server (Recommended)It can be beneficial, and safer, to test newer versions of Identity Management before upgrading production systems. There is a relatively simple way to do this by creating a sacrificial replica and testing on that system. Set up a replica based on one of the production servers, with the same version of IdM as is running in production, as described in Section 2.5, "Setting up IdM Replicas". For this example, this is called Test Replica. Make sure that Test Replica can successfully connect to the production server and domain. After verifying that Test Replica has been successfully added to the production domain, disconnect Test Replica from the network. Remove the replication agreements for Test Replica from the original IdM server and from Test Replica. Reconnect Test Replica to the network. Upgrade the packages on Test Replica using yum or whatever package update tool is appropriate for your system. For example: [root@ipareplica ~]# yum update ipa* Test common things on Test Replica, like getting Kerberos credentials, opening the server UI, and running commands.
|
| |
