After executing the LDAP - Synchronize Obsolete Users job, some users were deactivated unexpectedly.
There were two different sets of users who were being inactivated from the job:
1. Users who were no longer part of the LDAP group.
2. Users are part of the group, but our search brings up multiple entries for the same CN. In this case, the extra CN's had no entry under userid which maps to our SAMAccountName. Therefore they were being inactivated.
The CA PPM application is behaving correctly in both scenarios.
If users are not part of the group, they are inactivated and the job is performing as designed. If the group does not contain all needed users, the LDAP administrator must add these users to the correct group.
When the job searches for LDAP users, it searches for their CN (or FullName) and then attempts to match the username in the CA PPM application to the SAMAccountName in LDAP. Because the SAMAccountName came up blank for two out of three of the accounts (with the same CN) found by the search (and thus did not match the userid in Clarity), the user was inactivated. The fix for this was to specify a different root context in the NSA that did not show the extra ldap accounts so that only the ldap account with the correct SAMAccountName was found. An alternative fix would be to have the ldap admin remove the extra accounts with the same CN or to move them to a group not used by the CA PPM application.
This is a search that can be done with the ldifde command that uses the same search parameters that Clarity uses when looking for a user:
ldifde -a "CN=Niku LDAP Bind User,OU=Niku Org Unit,DC=RWCSUPPORT,DC=com" "SearchUserPassword" -f output.txt -s servername.com -d "dc=RWCSUPPORT,dc=com" -l samaccountname -r "(CN=userCNorFullName)"
Where the -a parameter is the distinguished name for the search user and the search user's password and the -d parameter is the root context specified in the NSA.