Bug 1044149 - [RFE] Winsync should support range retrieval
Summary: [RFE] Winsync should support range retrieval
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On: 1172037
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 21:27 UTC by Nathan Kinder
Modified: 2015-03-05 09:30 UTC (History)
2 users (show)

Fixed In Version: 389-ds-base-1.3.3.1-1.el7
Doc Type: Enhancement
Doc Text:
Feature: AD returns up to MaxValRange number of multi-valued attribute values in one search. If more attribute values exist, subtype ";range=0-(MaxValRange?-1)" is added to the type. AD Client (DS in this case) has to repeat the search with ";range=MaxValRange?-*" then ";range=(2*MaxValRange?)-*" and so on until the values with the subtype ";range=low-*" are returned. This feature has been implemented to the Windows Sync plugin. Thus, even if there are mroe than MaxValRange number of attribute values exist per attribute, all of them are successfully synchronized to the DS.
Clone Of:
Environment:
Last Closed: 2015-03-05 09:30:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0416 normal SHIPPED_LIVE Important: 389-ds-base security, bug fix, and enhancement update 2015-03-05 14:26:33 UTC

Description Nathan Kinder 2013-12-17 21:27:45 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47314

When an entry in AD has a large number of values for a multi-valued attribute, AD will break the values up into chunks.  If we want to get all of the values, we need to use a "range retrieval" mechanism.  This is described here:

    http://msdn.microsoft.com/en-us/library/cc223242.aspx

Right now, we currently have problems if you try to sync a group with a large number of members (>1500 IIRC).

Comment 3 Sankar Ramalingam 2014-10-27 13:52:38 UTC
To verify this, we need to create a group in AD with more than 1500 members and sync it over to DS and check if all group/user information synced correctly. Is that correct?

Are there any other multi-valued attributes need to tested?

Comment 4 Noriko Hosoi 2014-10-28 19:16:40 UTC
(In reply to Sankar Ramalingam from comment #3)
> To verify this, we need to create a group in AD with more than 1500 members
> and sync it over to DS and check if all group/user information synced
> correctly. Is that correct?

That's correct.

> Are there any other multi-valued attributes need to tested?

I think testing with the "member" attribute would be good enough.  I'd like you to test with ...
1. 1500 members
2. 1501 members
3. 3000 members
4. 3001 members
5. any large number like 25000 members
and check if the members are all successfully synchronized.

Thanks!

Comment 5 Milan Kubík 2014-12-07 15:27:23 UTC
I have checked the results in the cases you have suggested.
Up until 5000 members the feature works. Though, when the group has more than 5000 members, only 5000 members are synchronized in full replica refresh/initialization.

I am getting this behaviour consistently in the tests i have executed up until now with different number of entries (25k, 15k, 6k).

When I did another refresh on the replica, the remaining members were synchronized. I don't have the results around, but I if I recall correctly this holds even for setups where I had more than 10 000 users (so it didn't just got another 5000 entries as a diff).

Comment 6 Noriko Hosoi 2014-12-08 02:02:52 UTC
Milan,

Do you see any error messages in the error log?

So, what you observed was ...
1) if there are multivalued attribute which count larger than 5000, they only synchronized 5000 values per one refresh,
2) if you repeat the refresh, the rest is synchronized, eventually?
or
2') it never successfully synchronize all of the attribute values?

Also, could you run ldapsearch against this entry on your AD?
dn: CN=Default Query Policy,CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,<suffix>

I'd like to know the values of lDAPAdminLimits.  (I cannot find "5000" in our code as well as in the AD config params...)

Thanks,
--noriko

Comment 7 Milan Kubík 2014-12-09 09:35:03 UTC
Altering the state of this bugzilla after the discussion with developers.
A new bugzilla has been opened for the issue reported here. https://bugzilla.redhat.com/show_bug.cgi?id=1172037

Since the server is able to retrieve and act upon range information given by Active Directory, I'm marking this RFE bugzilla as verified.

Comment 9 errata-xmlrpc 2015-03-05 09:30:01 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html


Note You need to log in before you can comment on or make changes to this bug.