On 02/26/2013 10:17 PM, Nathan Kinder wrote:
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.
https://fedorahosted.org/389/ticket/472
Thanks,
-NGK
David.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
