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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users