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?

(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!

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

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

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.

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