!!! Overview
When using LDAP to view the [RootDSE], for [Microsoft Active Directory] we observe in the [supportedControl] listing:[2]
{{{
supportedControl: 1.2.840.113556.1.4.802 LDAP_SERVER_RANGE_OPTION_OID
}}}

The [supportedControl] uses an [OID] of [1.2.840.113556.1.4.802].

!! From Microsoft
{{"LDAP_SERVER_RANGE_OPTION_OID, unlike the other controls discussed in this section, does not actually designate an LDAP extended control. \\Nonetheless, it is included in this discussion because its OID is found in the supportedControl attribute of the DC's rootDSE. The presence of this OID indicates that the DC supports range retrieval of multivalued attributes. \\Range retrieval is a mechanism that permits attributes that have too many values to be retrieved in a single LDAP search request to be retrieved via multiple LDAP search requests. Range retrieval is documented in [section 3.1.1.3.1.3.2.|http://msdn.microsoft.com/en-us/library/cc223242.aspx|target='_blank']"}}
\\ Clearly an [Anomaly]

%%information
Note that although this OID is not present in the supportedControl attribute of Microsoft Windows® 2000 operating system DCs, such DCs nonetheless support range retrieval.:definition text
%%
\\ Clearly an [Anomaly]


!! [Java] [Example]
We did create some [Example] [Java code to make the process easier|LDAP_SERVER_RANGE_OPTION_OID_CODE_SAMPLE].

!! [{$pagename}] [Microsoft Active Directory Anomalies]
[Microsoft Active Directory] [Domain Controllers] set a limit on the maximum number of [Attribute Values] returned. The version of the server that supplies the requested data determines the maximum number of values that can be retrieved in a single query is defined in the [MaxValRange] within the [LDAP policy in Active Directory].

The [LDAP_SERVER_RANGE_OPTION_OID], which is listed as a [supportedControl], to get around the hard coded limits is a hack at best.

What [{$applicationname}] discovered was worse than expected. The only proper method we could determine to perform operations was to
* first query the entry and request all attributes with no values. 
* To determine if [MaxValRange] was in use, check to see if our desired attribute also had a returned attribute of <desiredattribute>;range=<startOfRange>-<enfOfRange>.
** In our case member;range0-1499 was returned.
* then you query the entry for the current range based attribute.
** The first query is for the attribute "member;range=0-1499"
** This got you the values from 0-1499 
* Then the next query would be for 1499-1499+1499
* repeat until the range was less than the first endOfRange at which point you had retrieved all values.

Now realise that most people would assume that if they did an [LDAP] query for an attribute and they got 1,500 entries and a Successful return code they could assume that all was well. That is not the case with [Microsoft Active Directory].

These conditions could happen with any attribute you were performing a query on and the __ONLY__ way you would know would be if you first queried as we stated above. And yes there is a method to query for the [MaxValRange] in effect for the Domain, but even if you know the limits you can not determine the number of values of an attribute without performing performing the process outlined above.

[{$applicationname}] is usually pretty tolerant of [LDAP] non-conformance as no [LDAP Server Implementation] provides complete support for every aspect of the [LDAP] specifications. However, [LDAP_SERVER_RANGE_OPTION_OID] being advertised as a control __when it is not__, is, in our humble opinion, not acceptable.

The whole scheme [Microsoft Active Directory] has used surrounding the [LDAP_SERVER_RANGE_OPTION_OID] and the [MaxValRange] is a "hack" and that is being kind.\\ Clearly an [Anomaly]

[{$applicationname}] did create some [Example] [Java code to make the process easier|LDAP_SERVER_RANGE_OPTION_OID_CODE_SAMPLE].



!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]

----
* [#1] [http://msdn.microsoft.com/en-us/library/cc223322.aspx|http://msdn.microsoft.com/en-us/library/cc223322.aspx|target='_blank'] - 2013-05-08 Retrieved
* [#2] We have observed this in the [RootDSE] this in:
** Windows 2003
** Windows 2008