Forums MyID knowledge base MY0436 User accounts become automatically disabled LDAP Sync Reply To: MY0436 User accounts become automatically disabled LDAP Sync

#4553
MyID Support
Senior Moderator

User not found in directory – Reason 2 – Multiple matches found (non-Active Directory LDAP)

This has been found to occur in LDAP services that are not Active Directory and do not use ObjectGUID which is unique to AD. One example was found with a customer that mapped UniqueID to “uid” in the LDAP Lookup table. Unfortunately “uid” does not have a uniqueness requirement in LDAP V3 so it is possible to create multiple user records in LDAP with the same “uid” value.

Also, unfortunately and up to MyID 12.5.0 (at the time of writing this) this also appears in the Audit report as “User not found in directory”, where what it actually means is that multiple matches were found.

How to identify this is the problem:

Firstly you must ascertain that for the user account in MyID there is definitely a corresponding record in LDAP. If this is so then move to the next step.

Configure MyID to perform tracing against the “eDirectory” component. Details on how to do this can be found here.

When you check the resulting log file you may find the following in amongst the XML that is produced.

<resultcount>x</resultcount><totalcount>x</totalcount>

If x > 1 then MyID found multiple matches in your LDAP based on the LDAPLookup table mapping for UniqueID.

Recovery :

This is best carried out under the guidance of Intercede Customer support, but here are some examples on how to recover.

  • Within your LDAP, remove any records that have the same value that is mapped to UniqueID (e.g. uid).
  • Or change that value in LDAP to be actually unique on all user records, leaving the actual record you want associated with the MyID user account at the value recorded in SystemAccounts.UniqueID. This ensures that MyID will only map to one LDAP record.

Mitigation :

This is best planned from the outset. But you should ensure that your UniqueID mapping in LDAPLookup is mapped to an LDAP Attribute that you guarantee will always be unique. As most fields in non-AD LDAP varieties do not have a uniqueness constraint this may take some internal procedure/process in your company to ensure that it is always unique. In our experience the only LDAP V3 field that needs to be unique is the DistinguishedName (dn).