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.
-NGK
>
>
> 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