Symptoms

When you have an LDAP listener setup and you don't see the recent changes on the LDAP server being imported by the LDAP listener, first enable the below two debug properties to get more information in the logs. If the LDAP server is via the MID server, you would need to add these as MID server properties. You might need to restart the MID server once these are created.

1. glide.ldap.debug
2. glide.ldap.listen.verbose

Once these are enabled, make a change for one user on the LDAP server. In the logs, you may notice that a recent change for a user was received but it was ignored. Logs may show something like this:

07/18/19 23:21:25 (524) glide.ldap.listener-ec6ee88cdb3b6b007f49db184b9619b5 DEBUG: LDAP API - LDAPLogger : Recieved LDAP record from server with DN: CN=LastName\, FirstName,OU=Users,OU=OU1,OU=OU2,DC=global,DC=company,DC=net
07/18/19 23:21:25 (524) glide.ldap.listener-ec6ee88cdb3b6b007f49db184b9619b5 LDAP API - LDAPLogger : LDAP Listener for LDAP Server:Notified of change on DN=CN=LastName\, FirstName,OU=Users,OU=OU1,OU=OU2,OU=Customers,DC=global,DC=company,DC=net
07/18/19 23:21:25 (743) glide.ldap.listener-ec6ee88cdb3b6b007f49db184b9619b5 LDAP API - LDAPLogger : LDAP Listener for LDAP Server:Notified and ignored change on DN=CN=LastName\, FirstName,OU=Users,OU=OU1,OU=OU2,OU=Customers,DC=global,DC=company,DC=net

Release

Applicable to all releases.

Cause

When the LDAP listener is notified of a change for a user, it checks two things:

1. The system first checks if this user is part of an existing valid OU definition. It does so by checking if the user's DN ends with RDN of OU definition + RDN of the LDAP server (Starting search directory). To validate this, copy the RDN of the OU definition the user is part of and append the starting search directory specified on the LDAP server. If the user's DN does not end with this value, the change will be ignored because the user is not part of this OU definition. 
2. If the first check is successful, the system checks if this OU definition is active with the Table set as 'sys_user'. For groups, this should be 'sys_user_group'. If either of these conditions fail, the change will be ignored. 

Resolution

A suggested first step is to restart the LDAP listener. If you still don't see the user/group being imported, you need to check all the below points:

1. The user is part of the expected OU definition by specifying the correct RDN. This can be checked by using the 'Browse' feature on the LDAP OU definition. 
2. The OU definition is active.
3. The OU definition's table is set as sys_user or sys_user_group for users and groups respectively.