I have been working with a client recently who had some interesting questions about the AEM Forms JEE LDAP connector and how it actually worked. Other than how to configure it, most of the internal workings are a mystery. So I thought I would share some of the (edited) responses on how the LDAP connector actually processes directories internally and how parts of it works.
Shout out goes to Neerav at Adobe Engineering for the great answers.
Filtering LDAP Attributes
LDAP query clients allow for the ability to specify which attributes are searched and also which attributes are returned in the search results. Some complex directories return many attributes by default, thus slowing down performance and creating unnecessary network overhead.
Q: Is there a way to filter out the attributes that LDAP returns when it tries to search for users in AEM Forms JEE?
A: The LDAP sync process fetches only those attributes which are configured in User/Group synchronization screen. There are many attributes which are optional on that screen and those can be set blank. If any attribute is blank on that screen, then it is not fetched from LDAP.
Moving User around Forests
Q: If a user is Active in Forest A and moves to Forest B, they will be made inactive in the first and active in the second. They will be granted the exact same idmGUID [LDAP unique identifier]. Will the LDAP Import Process simply recognise this as the same user and update their details in the Adobe Database with the details from the new forest?
A: As long as its unique fields like canonicalName (i.e. idmGUID) and userid (i.e. samAccountName or uid) remain the same, the user identity would be same.
Q: The Delta Sync process in AEM Forms, is only a Delta in terms of the Adobe product. A Full import against the LDAP backend occurs, before a comparison of modifyTimeStamp fields in the new Full Import is carried out against the current list in Adobe. Hence, would the [network] impact of a Full Sync v.s. a Delta be identical on the LDAP Infrastructure?
A. Delta sync would have less load on LDAP infrastructure. We do not fetch details of groups (and group members) if a particular group is unchanged. modifyTimeStamp is an operational attribute and is not fetched unless it is part of requested attributes. It is present in all standard LDAPs (including Active Directory). This attribute is used to determine if a User or Group record has changed since last synchronization. If delta sync is enabled, users and groups which have not changed since last synchronization are not updated during synchronization.
A note on modifiedTimeStamp
modifiedTimeStamp and delta sync presented an interesting challenge since each server in the IAM farm updated the modifiedTimeStamp when it received the user update from the IAM master. This could possibly be a second or two after the master was updated. Since the LDAP queries were load balanced between the LDAP servers and each server (potentially) had a slightly different modifiedTimeStamp, it made it impossible to reliably do a delta sync with the LDAP directory. This is potentially a large overhead with a large LDAP population.