Subject: Active Directory question

From: "Schleiff, Marty" <[email-masked]>
Date: Sat, 17 Apr 2004 23:31:39 -0700

Gentlemen,

When using ldapsearch to lookup the membership in an Active Directory group, I got the following (abbreviated) response:

CN=PC Backup Group 1,OU=Groups,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
member;range=0-999=CN=Peterson\, Randy R,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
member;range=0-999=CN=Tatham\, William C,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com
member;range=0-999=CN=Pham\, Steve,OU=End Users,OU=Accounts,DC=sw,DC=nos,DC=boeing,DC=com

I'd never before encountered "range=0-999" and wondered what it meant. A little searching turned up the following URLs:
http://www.hut.fi/cc/docs/kerberos/draft-kashi-incremental-00.txt and http://www.hut.fi/cc/docs/kerberos/nss_ldap.html

From the second URL: "Active directory uses a method called "Incremental Retrieval of Multivalued Properties" which nss_ldap has no support for, at least not yet. Querying groups having more than 1000 members will return the first 1000 members, with the 'member' attribute changed to 'member;range=0-999'. This is not recognized by nss_ldap, so you will not see any members for that group. More information can be found in the (now expired) Internet Draft labeled Incremental Retrieval of Multivalued Attributes <draft-kashi-incremental-00.txt> ."

I was also referred to http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt ; however, I'm not sure that applies to my situation (it seems to describe how a client could request the server to return a partial set of values for a multi-valued attribute -- in my case I didn't request the range, Active Directory just gave it to me when I really wanted the complete set of values).
I'd value the opinions of this list around the following questions:
1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions.
2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering", another client operating on the same entry as my client can add or remove values between my clients operations to retrieve multiple ranges so that my client's "requests may result in overlapping, duplicated, or skipped elements". 
3) Does The Open Group assessment of "LDAP Ready" require a client to understand ranges?
4) Does The Open Group assessment of "LDAP Certified" require a server to return ranges? Or if a server does return ranges (which probably would confuse many clients), can that server be "LDAP Certified".
5) Will common tools like ldapsearch, PerLDAP, LDAP URLs on a browser location box, etc. ever be able to request ranges of multi-values attributes (or do they already have this capability and I'm just unaware)?
Thx,

[email-masked]; CISSP
Associate Technical Fellow - Cyber Identity Specialist
IT Access & Security Services
(425) 957-5667

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 18 Apr 2004 08:19:34 -0700

>1) What do you think of this practice? Being a stranger on this list, I've withheld my editorial opinion of this practice; however, I'd like to hear your opinions.

It is inappropriate for a server to respond in a manner which
requires a client to handle and recognize unsolicited
extension information.  To the client, the searchResultEntry
PDU provided by the server is malformed (see RFC 2251,
Section 3.1).  Likely, most clients (which do not support
this extension) will simply treat the response as indicating
the 'member' attribute has no (visible) values and simply
treat the values as belonging to an unrecognized attribute
type (or, possibly, an unrecognized subtype of the member
attribute type).

Anyways, as I previously noted, extensions to LDAP are suppose
to be truly optional.  This extension is actually truly non-optional
(which is worse than being "not truly optional").

LDAPBIS should, in revising the LDAP technical specification, make
this more clear.

>2) Even if I can get my ldap client apps to learn to deal with the ";range=0-999", I don't know how to teach them to obtain subsequent ranges. Also, as pointed out in section "5.3 Element Ordering",…

I have no idea of how the extension authors expect to consistency to
be maintained.  And I have no idea how the extension authors expect
clients to address obvious security considerations caused by such
inconsistencies.

>3) Does The Open Group...
>4) Does The Open Group...

These are questions for the Open Group to answer.

>5) Will common tools ... ?

That's a question for individual developers to answer.