Issue Summary

When fetching users and groups, embedded crowd will use the configurable group and user DN in user directory settings. If these DN's are a referral, then pagination breaks causing crowd to only sync the first page of results returned from AD.

Steps to Reproduce

1. Create 3 windows servers (in AWS)
2. Setup one with AD and promote to DC with GC (global catalogue) - this will be your base DN (I did test.com)
3. Setup the next two as child AD with no GC - I did one as "apps.test.com" and one as "corp.test.com" - (I had to add test.com into the hosts file on these)
4. Setup an admin user in "test.com" server - giving all the same groups as "Administrator"
5. Setup a regular user in "corp.test.com" server - under Users OU (I did "myuser")
6. Setup a new group OU in "apps.test.com" server - create 7 "Domain local" groups and sort them by alphabetical order.
7. From the "apps.test.com" server, add "CORP\myuser" to the first and last group (in alphabetical order)

Now we set up the MaxPageSize as 5 -

1. Login to the main "test.com" server as the admin user created in step 4 (I used admin@test.com from RDP)
2. Windows + R button -> Ntdsutil.exe
3. Type LDAP policies
4. Type connections
5. Type connect to server "test.com" (substitute with your BaseDN)
6. Type q to go back to "LDAP policies"
7. Type Set MaxPageSize to 5
8. Type commit changes
9. Verify the changes by typing show values
10. In User directory settings - set the page size to 5

Expected Results

All users and groups get synced correctly

Actual Results

Only the first 1000 users or groups that come back from the referral domain is populated due to the paginated result from LDAP.

The User and/or Group update count is constantly limited at 1000 in the application logs:

2020-12-13 16:26:37,065 INFO [Caesium-1-1] c.a.c.d.DbCachingRemoteChangeOperations scanned and compared [ 1000 ] groups for update in DB cache in [ 91ms ]

User directory syncs can also remove groups/users which were populated by the "update when logging in" settings.

Workaround

Due to the behavior being embedded into the java (com.sun.jndi.ldap.AbstractLdapNamingEnumeration has no pagination support), no direct work-around is available. We can mitigate / minimise the issue with the following:

• We can minimise the amount of groups syncing unnecessarily by:
  • Setting up a group filter to exclude unneeded groups. See here. Example, remove all groups that start with aa:

    (&(objectCategory=Group)(!(cn=aa*)))
    

  • Move unnecessary groups to a separate OU, or move Bitbucket groups to a new OU
• We can update the LDAP pagination "MaxPageSize" to accommodate the number of groups using View and set Lightweight Directory Access Protocol (LDAP) policy with Ntdsutil - Windows Server - Microsoft Docs however this might have a performance impact for your AD and will need to be tested (depending on how much higher it goes)
• We can convert the groups to Universal scope and then point the directory to the global catalog.
• If groups are the only dn being referred, we can setup a user directory to only sync groups (and not sync users) to pre-populate our application with all the necessary groups, and permissions can be applied to the groups. After this we then setup a delegated user directory for users and enable "update groups on login". This only works if users have less than 1000 groups attached to their account.