[389-users] AD sync problem for group with more than 1500 entries

[Nathan Kinder]

On 02/26/2013 08:42 PM, David Baird wrote:
> Hi,
>
> We have been experiencing an intermittent problem with our AD sync, 
> where updates to a group in 389 have resulted in the group being 
> emptied of users.
>
> This has been occurring at various times but not consistently, so was 
> very difficult to track.  Previously, the group would be emptied in 
> the AD, which would then replicate back to 389, resulting in an empty 
> group in both Directories.
>
> Since installing a fresh CentOS 6.3 server and the latest stable 389 
> (at the time, 1.2.10.12-1) the behaviour has only changed slightly, in 
> that now the 389 group gets emptied and the AD group remains intact.  
> When this happens, initiating a full re-sync will not fix the issue.
>
> We have since discovered that this behaviour is, in fact, consistent 
> and repeatable if the group contains more than 1500 members.  Below 
> that threshold, adding or subtracting users from the 389 group 
> replicates perfectly. As soon as you exceed that limit, the group gets 
> emptied.
>
> Turning on replication logging revealed the following.....
> (domain and server names have been made anonymous)
>
> [27/Feb/2013:12:20:33 +1300] - Calling dirsync search request plugin
> [27/Feb/2013:12:20:33 +1300] - Sending dirsync search request
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - received entry 
> from dirsync: CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
> (DC01:636): map_entry_dn_inbound: looking for local entry matching AD 
> entry [CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
> (DC01:636): map_entry_dn_inbound: looking for local entry by guid 
> [919561f60fe49f409afcdf80a63eb089]
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
> (DC01:636): map_entry_dn_inbound: found local entry 
> [CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com]
> [27/Feb/2013:12:20:33 +1300] - Calling windows entry search request 
> plugin
> [27/Feb/2013:12:20:33 +1300] - windows_search_entry: received 2 
> messages, 1 entries, 0 references
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - agmt="cn=DC01" 
> (DC01:636): map_entry_dn_inbound: looking for local entry matching AD 
> entry [CN=students,OU=Groups,OU=Active,OU=People,DC=domain,DC=com]
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
> windows_generate_update_mods: 
> CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
> description : values are equal
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
> windows_generate_update_mods: 
> CN=students,ou=Groups,ou=Active,ou=People,dc=domain,dc=com, 
> ntUserDomainId : values are equal
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
> windows_generate_update_mods: deleting uniquemember attribute from 
> local entry
> [27/Feb/2013:12:20:33 +1300] - smod - windows sync
> [27/Feb/2013:12:20:33 +1300] - smod 0 - delete: uniquemember
>
>
> The particularly interesting line is this
> [27/Feb/2013:12:20:33 +1300] NSMMReplicationPlugin - 
> windows_generate_update_mods: deleting uniquemember attribute from 
> local entry
>
> This only appears to happen when the group contains more than 1500 
> entries.
>
> Surely there must be someone else out there syncing groups with more 
> than 1500 members between 389 and AD?
>
> It wasn't until I used Apache Directory Studio to compare entries 
> between the 389 server and the AD that I noticed the attribute name 
> was represented differently when the group contained over 1500 entries.
>
> This is a result of the range retrieval limit in AD.  When you hit the 
> range limit, the attribute name changes from "member" to 
> "member;range=0-1499", which causes the mismatch that leads to the 
> uniquemember attribute being deleted.
>
> In order to prevent this from happening, we have had to increase the 
> MaxValRange setting in our Active Directory as per 
> http://support.microsoft.com/kb/2009267 and 
> http://support.microsoft.com/kb/315071
>
> The value defaults to 1500 for Windows Server 2003 or 5000 for Windows 
> Server 2008.
>
> Personally I consider this a bug in the AD sync plugin, as it fails to 
> correctly handle range retrieval.  At the very least, the 
> documentation for Windows Sync should contain information about this 
> limit.
This does sound like a bug.  Please open a ticket in our Trac instance here:

     https://fedorahosted.org/389/

The Windows Sync plug-in needs to be modified to understand how to use 
ranged searches.

Thanks,
-NGK
>
> David.
> -- 
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users