Overcoming the ADLDS MaxValRange Hard Limit
Introduction
Microsoft Active Directory Lightweight Directory Services (AD LDS), formerly known as Active Directory Application Mode (ADAM), is a directory server application. Some companies use it to store a stripped-down ldap directory of the full AD environment. Whether you need just certain OUs, or just certain attributes available, using ADLDS might solve your problem. Lots of places online can show you how to use userProxy objects to allow ldap simple binds to the AD LDS instance. LDS, when using userProxy objects, takes the sAMAccountName, finds the object with that attribute, and passes its objectSid and the user-supplied password to the real AD for authentication. So you can accomplish a ldap simple bind. You can even configure ldaps! I have it down to a science now that I've done it several times. But the point of the post today is to show you how to exceed the hard-coded limit for ADLDS in Windows Server 2008 or 2012/2012R2 on the number of multi-value attributes returned for a query. So AD groups are directory objects of objectClass=group. Group membership is defined by the member attribute of a group. Incidentally, AD (and LDS) provide a derived attribute, "memberof," on the user (or userProxy) objects that are members of that group. Some applications check either one, but since the memberof is calculated, it doesn't really matter anyway. So with a group of your entire userbase, say, "Wiki-Users_Grp," you might have more than 5000 members.
Adjusting MaxValRange
You probably are already aware of the MaxValRange=5000 value for the
attribute lDAPAdminLimits on CN=Default Query Policy,CN=Query-
Policies,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN=X
You can adjust it to whatever number you want. This attribute affects how many
attributes will be returned on an object, such as how many members will be
returned on the very large group. ADSI Edit is the application to use to
modify this. Make a connection to the configuration context, and navigate to
the dn and you can modify its attributes. If you have more members than the
MaxValRange, you will get an attribute returned like this:
member;range=0-4999 (5000): CN=user1,OU=Users,DC=example,DC=com;
CN=user2,OU=Users,DC=example,DC=com; [...]
The applications I've worked with
don't like that "member;range=" nomenclature. So you have to make the
MaxValRange higher so it returns just "member:" for each member. Well,
apparently Windows Server 2008 introduced a hard limit on the number of
returned attributes. The MaxValRange will not take effect any higher than
5000.
Changing the hard limit
Qasim Zaidi at TechNet demonstrated how to change the limit:
https://blogs.technet.microsoft.com/qzaidi/2010/09/01/override-the-hardcoded-
ldap-query-limits-introduced-in-windows-server-2008-and-windows-
server-2008-r2/ Use ADSI Edit (adsiedit.msc) and navigate to this DN:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN=X
The
attribute that should be modified is dSHeuristics. If the value is blank,
enter this value: 000000000100000001
Straight from the TechNet article:
If a value has already been set for this attribute, incorporate the existing settings into the new value. When you do this, note the following: The tenth character from the left must be 1. Twentieth bit must be 2, and so on. The eighteenth character from the left must be 1. None of the other characters of the existing value should be changed. For instance, if the existing value is 0000002 then the new value should be 000000200100000001
To ensure this change takes effect, restart the LDS service. Run an ldap search, and see if the result is what you want for a large group!
References
Weblinks
- Overriding default hard limit in Windows Server 2008 https://blogs.technet.microsoft.com/qzaidi/2010/09/01/override-the-hardcoded-ldap-query-limits-introduced-in-windows-server-2008-and-windows-server-2008-r2/
- MaxValRange official source https://msdn.microsoft.com/en-us/library/cc223376.aspx
- MaxValRange original source from 2014 doc http://support.microsoft.com/en-us/kb/315071
Comments