Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

B.2. Identity Management Replicas

This guide describes common replication problems for Identity Management in Red Hat Enterprise Linux.
Additional resources:

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:
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)) ...
Additionally, other messages can occur stating 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)

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:
Replication bind with GSSAPI auth resumed

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.
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

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:

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:
Certificate operation cannot be completed: EXCEPTION (Certificate serial number 0x2d not found)

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:
  1. Replica A issues a certificate to a host.
  2. The certificate is not replicated to replica B, because the replicas have no certificate replication agreement established.
  3. A user attempts to use replica B to manage the host.
  4. 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:

  1. 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”.
  2. 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:

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.
  1. List the details about the obsolete RUVs using the ipa-replica-manage list-ruv command. The command displays the replica IDs:
    # 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
  2. 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:
    # ipa-replica-manage clean-ruv 6
    # ipa-replica-manage clean-ruv 5
    # ipa-replica-manage clean-ruv 4
    # ipa-replica-manage clean-ruv 12
    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”.
  3. 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:
      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
If you are not sure on which replica to clean the RUVs:
  1. 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:
    # ldapsearch -p 389 -h IdM_node -D "cn=directory manager" -W -b "cn=config" "(objectclass=nsds5replica)" nsDS5ReplicaId
  2. Run ipa-replica-manage list-ruv on every server. Note any replica IDs that are not on the list of uncorrupted replica IDs.
  3. 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.
  1. Recover the CA server from backup. See Section 9.2, “Restoring a Backup” for details.
    This makes the CA server available to the replica.
  2. 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”.
  3. 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.