jspωiki
LDAP_SERVER_RANGE_OPTION_OID

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

Clearly an Anomaly
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 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 Ldapwiki 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.

Ldapwiki 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

Ldapwiki did create some Example Java code to make the process easier.

More Information#

There might be more information for this subject on one of the following: