MY0436 User accounts become automatically disabled LDAP Sync

[MyID Support]

There are a number of circumstances under which users can become automatically disabled during some sort of synchronisation of the user account in MyID with it’s corresponding account in your directory service (LDAP). Users in MyID will become disabled if :

• The user account is disabled in LDAP. This is controlled by the configuration flag “Background Update”.
• The user account is removed from LDAP. This is controlled by the configuration flag “Disable on removal from directory”.

These flags are in the Configuration Menu – Operation Settings – LDAP tab.

Additionally, the utility “BatchLDAPSync.exe” will also disable users in MyID if they are disabled in LDAP or removed from it. Please refer to your documentation on how to use this utility. Here is the relevant section from the MyID 12.5.0 Enterprise documentation.

How does this work?

By default, at installation MyID will automatically configure for whichever domain the Application server is joined to. This is represented by “Default ADS” in the “Directory Management” workflow in the Configuration menu. As the name suggests this automatically configures MyID to use Active Directory as it’s default directory service. Information from the 12.5.0 Enterprise documentation on how to configure this can be viewed here.

That said, MyID will support the use of any LDAP V3 compliant service. Examples include OpenDS and OpenLDAP. Please refer to your preferred LDAP vendor documentation on how to use this.

Within the “SystemAccounts” table there is a value called “UniqueID”. As it suggests this value must be unique for each user in MyID. Additionally there is a value called “ExternalServerCredentialID”. This links to whichever LDAP service your MyID implementation is connected to.

Next there is a table called “LDAPLookup” which is intended to be user configurable, but only using a SQL query. This provides the mappings between the LDAP attributes and the fields within MyID that are populated by those attributes. The relevant one in this case is the mapping for “UniqueID”. By default this maps to the AD attribute “objectGUID” and this value is created automatically by Active Directory. But for non-AD LDAP services this can be mapped to a different LDAP attribute based on your company’s own requirements. The only stipulation for this is that the LDAP attribute MUST contain a unique value within LDAP.

[MyID Support]

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.

 

[MyID Support]

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

[Author]

Posts