Forum Replies Created
-
Posts
-
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).
User not found in directory – Reason 1 – User removed from LDAP then re-added (AD)
This reason is unique to Active Directory with a mapping of ObjectGUID <> UniqueID. The use case goes something like this;
- User is created in Active Directory.
- User is imported into MyID (e.g. Add Person, Edit Person).
- User is removed from Active Directory. The next action triggering the background update disables the user in MyID. (e.g. using View Person, Edit Person).
- User is re-added into Active Directory. But the background update does not re-enable the user.
This is because Active Directory creates a new objectGUID each time a user is created, even if the rest of the user details are exactly the same as before. Because the objectGUID is now unknown to MyID, MyID cannot synchronise with the new user account in Active Directory.
Recovery :
Should be carried out under the guidance of Intercede Customer Support. But the recovery is basically to set the “UniqueID field in SystemAccounts to NULL for the associated user. MyID will then fall back to a secondary means of synchronising, which is to use the users DistinguishedName (DN) in LDAP. If a unique match can be found then MyID will re-populuate the UniqueID field with the new ObjectGUID value. After that, MyID should then be able to successfully synchronise the user account with its corresponding user record in LDAP.
Intercede Support have received a number of queries in respect of other operating systems and what to do if the update has already been installed. The general advice is as follows.
- If the update has not yet been installed then hold off installing it until we have investigated it and formulated a solution/workaround to the problems it can create.
- If the update HAS been installed but there are no apparent problems then we see no need to uninstall it. We do however suggest that you maintain increased vigilance and watch out for any problems with DCOM / MSDTC.
- If the update HAS been installed and problems are occurring as a result then raise a support case via the normal means by sending an email via the normal channel.
To be clear, where this problem has arisen it has been catastrophic and rendered MyID inoperative. This is why we have chosen to alert everyone about this problem proactively. The main bullet point here is that the problem will not be subtle or intermittent.
Conversely, we’ve had a couple of reports of customers that do have this installed and have not seen any problems. We are investigating what the differences might be.
Other operating systems;
- For Windows 2016, we have been made aware of KB5005573. However we have had no reports of any issues with this update. The general advice as above stands for this operating system.
- For Windows 2008 we are not aware of any equivalent update since this operating system is now End of Life since January 14th 2020.
Once we have a workaround or solution it will be published on the Intercede Customer Portal. You can subscribe to MyID Announcements via our Customer Portal when you sign in with your Rapid ID. Simply go to the Announcement page and click on “Subscribe” next to the SEARCH button.
