On 02/27/2013 08:48 AM, Nathan Kinder wrote:
On 02/27/2013 06:57 AM, Rich Megginson wrote:
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
This ticket is for simple paged results, which is different. Paged
results is used for returning a large number of entries. Range
retrieval is used for a large number of values for a multi-valued
attributes. Even when using paged results, AD will trim a
multi-valued attribute whose values pass the range retrieval limit.
Do we even need to use simple paged results for AD sync? We are
simply searching for one entry at a time as we process through the
Dirsync results, so I don't think that we have a case where we expect
to receive a large number of entries as the result of a search
operation. We do need to deal with receiving a large number of values
for a multi-valued attribute (like member). Is there a case I'm not
thinking of that would require simple paged results? If not, I propose
we change ticket 472 to be used to add range retrieval support and
re-triage it.
For the initial sync search request, we can retrieve a large number of
entries, so we need to at least support paged searches in that case.
-NGK
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
