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.
David.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
