B.2. Identity Management Replicas This guide describes common replication problems for Identity Management in Red Hat Enterprise Linux. Additional resources: For advice on how to test that replication is working, see Section 4.6, "Testing the New Replica" . For advice on how to solve replication conflicts, see Section D.3.3, "Creating and Removing Replication Agreements" and for details, see Section 15.26, "Solving Common Replication Conflicts" in the Directory Server Administration Guide . The Directory Server repl-monitor script shows in-progress status of replication, which can help you troubleshoot replication problems. For more information, see Section 15.24, "Monitoring Replication Status" in the Directory Server Administration Guide . To verify if two Directory Server instances are synchronized, see Section 15.25, "Comparing Two Directory Server Instances" in the Directory Server Administration Guide . B.2.1. Authenticating AD Users Against a New Replica Fails After installing a new replica in an Identity Management - Active Directory trust setup, attempts to authenticate Active Directory (AD) users against the IdM replica fail. What this means: The replica is neither a trust controller nor trust agent. Because of this, it cannot serve information from the AD trust. To fix the problem: Configure the replica as a trust agent. See Trust Controllers and Trust Agents in the Windows Integration Guide . B.2.2. Replica Starts with SASL, GSS-API, and Kerberos Errors in the Directory Server Logs When the replica starts, a series of SASL bind errors are recorded in the Directory Server (DS) logs. The errors state the GSS-API connection failed because it could not find a credentials cache: Additionally, other messages can occur stating that the server could not obtain Kerberos credentials for the host principal: What this means: IdM uses GSS-API for Kerberos connections. The DS instance keeps the Kerberos credentials cache in memory. When the DS process ends, such as when the IdM replica stops, the credentials cache is destroyed. When the replica restarts, DS starts before the KDC server starts. Because of this start order, the Kerberos credentials are not yet saved in the credentials cache when DS starts, which is what causes the errors. After the initial failure, DS re-attempts to establish the GSS-API connection after the KDC starts. This second attempt is successful and ensures that the replica works as expected. You can ignore the described startup errors as long as the GSS-API connection is successfully established and the replica works as expected. The following message shows that the connection was successful: B.2.3. The DNS Forward Record Does Not Match the Reverse Address When configuring a new replica, installation fails with a series of certificate errors, followed by a DNS error stating the DNS forward record does not match the reverse address. What this means: Multiple host names are used for a single PTR record. The DNS standard allows such configuration, but it causes an IdM replica installation to fail. To fix the problem: Verify the DNS configuration, as described in the section called "Verifying the Forward and Reverse DNS Configuration" . B.2.4. Serial Numbers Not Found Errors Note This solution is applicable at domain level 0 . See Chapter 7, Displaying and Raising the Domain Level for details. An error stating that a certificate serial number was not found appears on a replicated server: What this means: A certificate replication agreement between two replicas has been removed but a data replication agreement is still in place. Both replicas are still issuing certificates, but information about the certificates is no longer replicated. Example situation: Replica A issues a certificate to a host. The certificate is not replicated to replica B, because the replicas have no certificate replication agreement established. A user attempts to use replica B to manage the host. Replica B returns an error that it cannot verify the host's certificate serial number. This is because replica B has information about the host in its data directory, but it does not have the host certificate in its certificate directory. To fix the problem: Enable certificate server replication between the two replicas using the ipa-csreplica-manage connect command. See Section D.3.3, "Creating and Removing Replication Agreements" . Re-initialize one of the replicas from the other to synchronize them. See Section D.3.5, "Re-initializing a Replica" . Warning Re-initializing overwrites data on the re-initialized replica with the data from the other replica. Some information might be lost. B.2.5. Cleaning Replica Update Vector (RUV) Errors Note This solution is applicable at domain level 0 . See Chapter 7, Displaying and Raising the Domain Level for details. After a replica has been removed from the IdM topology, obsolete RUV records are now present on one or more remaining replicas. Possible causes: The replica has been removed without properly removing its replication agreements first, as described in the section called "Removing Replication Agreements" . The replica has been removed when another replica was offline. What this means: The other replicas still expect to receive updates from the removed replica. Note The correct procedure for removing a replica is described in Section D.3.6, "Removing a Replica" . To fix the problem: Clean the RUV records on the replica that expects to receive the updates. List the details about the obsolete RUVs using the ipa-replica-manage list-ruv command. The command displays the replica IDs: Clear the corrupt RUVs using the ipa-replica-manage clean-ruv replica_ID command. The command removes any RUVs associated with the specified replica. Repeat the command for every replica with obsolete RUVs. For example: Warning Proceed with extreme caution when using ipa-replica-manage clean-ruv . Running the command against a valid replica ID will corrupt all the data associated with that replica in the replication database. If this happens, re-initialize the replica from another replica as described in Section D.3.5, "Re-initializing a Replica" . Run ipa-replica-manage list-ruv again. If the command no longer displays any corrupt RUVs, the records have been successfully cleaned. If the command still displays corrupt RUVs, clear them manually using this task: If you are not sure on which replica to clean the RUVs: Search all your servers for active replica IDs. Make a list of uncorrupted and reliable replica IDs. To find the IDs of valid replicas, run this LDAP query for all the nodes in your topology: Run ipa-replica-manage list-ruv on every server. Note any replica IDs that are not on the list of uncorrupted replica IDs. Run ipa-replica-manage clean-ruv replica_ID for every corrupted replica ID. B.2.6. Recovering a Lost CA Server Note This solution is applicable at domain level 0 . See Chapter 7, Displaying and Raising the Domain Level for details. You only had one server with CA installed. This server failed and is now lost. What this means: The CA configuration for your IdM domain is no longer available. To fix the problem: If you have a backup of the original CA server available, you can restore the server and install the CA on a replica. Recover the CA server from backup. See Section 9.2, "Restoring a Backup" for details. This makes the CA server available to the replica. Delete the replication agreements between the initial server and the replica to avoid replication conflicts. See Section D.3.3, "Creating and Removing Replication Agreements" . Install the CA on the replica. See Section 6.5.2, "Promoting a Replica to a Master CA Server" . Decommission the original CA server. See Section D.3.6, "Removing a Replica" . If you do not have a backup of the original CA server, the CA configuration was lost when the server failed and cannot be recovered.

Commands:
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))
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
Replication bind with GSSAPI auth resumed
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=replica.example.com,O=EXAMPLE.COM" ipa: DEBUG: handshake complete, peer = 192.0.2.2:9444 Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) ipa: DEBUG: Created connection context.ldap2_21534032 ipa: DEBUG: Destroyed connection context.ldap2_21534032 The DNS forward record replica.example.com. does not match the reverse address replica.example.org
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)
ipa-replica-manage list-ruv server1.example.com:389: 6 server2.example.com:389: 5 server3.example.com:389: 4 server4.example.com:389: 12
ipa-replica-manage clean-ruv 6 ipa-replica-manage clean-ruv 5 ipa-replica-manage clean-ruv 4 ipa-replica-manage clean-ruv 12
dn: cn=clean replica_ID , cn=cleanallruv, cn=tasks, cn=config objectclass: extensibleObject replica-base-dn: dc= example ,dc= com replica-id: replica_ID replica-force-cleaning: no cn: clean replica_ID
ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId