PingDirectory

Troubleshooting "Entry Already Exists" failures

About this task

If there is a count for the EntryAlready Exists statistic using the status tool, verify the problem in the sync log. For example, the status tool displays the following information:

           --- Ops Completed for 'DS1 to DS2' Sync Pipe ---
Op Result              : Count
-----------------------:------
Success                : 0
Out Of Scope           : 0
Op Type Not Synced     : 0
No Change Needed       : 0
Entry Already Exists   : 1
No Match Found         : 1
Multiple Matches Found : 0
Failed During Mapping  : 0
Failed At Resource     : 0
Unexpected Exception   : 0
Total                  : 2

Verify the change by viewing the <server-root>/logs/sync file to see the specific operation, which could be caused by someone manually adding the entry on the target server:

op=2 changeNumber=529277 replicationCSN=00000128AD0D9BA01E960008137D
replicaID=7830
pipe="DS1 to DS2" class="DEFAULT" msg="Detected ADD of
uid=user.1001,ou=People,
dc=example,dc=com at ldap://server1.example.com:1389, but cannot create this
entry at the destination because an equivalent entry already exists at
ldap://server3.
example.com:3389. Details: Search using [search-criteria dn:
uid=user.1001,ou=People,
dc=example,dc=com attrsToGet: [*, dn]] returned results;
[uid=user.1001,ou=People,
dc=example,dc=com]. "

Perform the following steps to troubleshoot this type of problem:

Steps

  1. Assuming that a possible distinguished name (DN) mapping is ill-formed, first run the ldap-diff utility to compare the entries on the source and destination servers. Then look at the ldap-diff results with the mapping rules to determine shy the original search did not find a match.

    $ bin/ldap-diff \
  --outputLDIF config-difference.ldif \
  --baseDN "dc=example,dc=com" \
  --sourceHost server1.example.com \
  --targetHost server2.example.com \
  --sourcePort 1389 \
  --targetPort 3389 \
  --sourceBindDN "cn=Directory Manager" \
  --sourceBindPassword password \
  --searchFilter "(uid=1234)"

  2. Review the destination server access logs to verify the search and filters used to find the entry. Typically, the key correlation attributes are not synchronized.

  3. If the mapping rule attributes are not synchronized, review the Sync Classes and mapping rules, and use the information from the ldap-diff results to determine why a specific attribute might not be getting updated. Some questions to answer are as follows:

    • Is there more than one Sync Class that the operation could match?

    • If using an include-base-dn or include-filter in the mapping rules, does this exclude this operation by mistake?

    • If using an attribute map, are the mappings correct? Usually, the cause of this error is in the destination mapping attribute settings. For example, if a set of correlation attributes is defined as: dn, mobile, accountNumber, and the accountNumber changes for some reason, future operations on this entry will fail. To resolve this, either remove accountNumber from the rule, or add a second rule as: dn,mobile. The second rule is used only if the search using the first set of attributes fails. In this case, the entry is found and the accountNumber information is updated.

  4. If deletes are being synchronized, check to see if there was a previous delete of this entry that was not synchronized properly. In some cases, simpler logic should be used for deletes because of the available attributes in the change logs. This scenario could cause an entry to not be deleted for some reason, which would cause an issue when a new entry with the same DN is added later. Use this information for mapping rules to see why the original search did not find a match.

  5. Look at the destination directory server access logs to verify the search and filters it used to find the entry. Typically, the key attribute mappings are not synchronized.