Subject: [ldapext] Re: FW: Active Directory question

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 16 Apr 2004 10:46:42 -0600

Implementors wishing to do this should help update and progress
draft-haripriya-partial-entry (expired but available at
http://www.dfn-pca.de/bibliothek/standards/ietf/none/internet-drafts/draft-haripriya-partial-entry-00.txt)

>>> "Kurt D. Zeilenga" <[email-masked]> 4/15/04 9:07:27 PM >>>
Marty,

I've adjusted the cc/bcc lists to move this discussion
towards the LDAPEXT mailing list. That's the usual
forum for discussing the Internet engineering of LDAP
extensions.

This is an example of, amongst other things, a horribly
designed LDAP extension. It's most serious flaw is that
the extension is truly non-optional. If the server
elects to implement this extension, so must its clients
(if they want to get all available values).

Kurt

At 10:50 AM 4/15/2004, Schleiff, Marty wrote:
>Gentlemen,
>
>Can you please let me know your impressions about the MS Active
>Directory response with ranges of multi-valued attribute values?
>Also, using tools lke ldapsearch, how could I retrieve subsequent
>ranges?
> 
>Thx,
>
> [email-masked] ; CISSP 
>Associate Technical Fellow - Cyber Identity Specialist 
>IT Access & Security Services 
>(425) 957-5667 
>-----Original Message-----
>From: Chris Harding [mailto:[email-masked]] 
>Sent: Wednesday, April 14, 2004 11:20 AM
>To: Schleiff, Marty
>Subject: RE: Active Directory question
>
>Hi, Marty -
>
>Thanks - sounds like this is definitely one for the IETF experts!
>
>At 18:52 14/04/2004, you wrote:
>Hi Dr. harding,
>
>Thanks for your response. I'd like to point out that this issue is
>not about a server limiting the number of entries to return; instead
>it's about the number of values within a single multi-valued
>attribute to return. The entry gets returned, but not all its
>attribute values.
>
> [email-masked] ; CISSP 
>Associate Technical Fellow - Cyber Identity Specialist 
>IT Access & Security Services 
>(425) 957-5667 
>-----Original Message-----
>From: Chris Harding [mailto:[email-masked]] 
>Sent: Wednesday, April 14, 2004 9:32 AM
>To: Schleiff, Marty
>Subject: Re: Active Directory question
>
>Hi, Marty -
>
>Our Product Standard is based on the IETF RFCs, so I think this
>would be legal behavior for an LDAP Certified server only if it
>is legal according to RFC 2251. Now the RFC says that "Servers may
>enforce a maximum number of entries to return" (section 4.5.1 under
>"sizelimit") so it looks to me as though the behavior may be legal.
>However, I have got my fingers burnt before trying to interpret
>this RFC, and I suggest you send mail to the ldapbis list
> ([email-masked] ) if you want to find out what the IETF
>experts think.
>
>At 22:57 13/04/2004, you wrote:
>Hi Dr. Harding,
>
>Microsoft Active Directory responds to queries on groups having
>more than 1024 members with the first 1000 members, with the
>'member' attribute changed to 'member;range=0-999'. See:
> http://www.hut.fi/cc/docs/kerberos/nss_ldap.html In TOG's efforts
>to brand "ldap-compliant" servers and applications, is this practice
>condoned? So far I've not been able to figure out how to get the
>next batch of members; I'm not sure it's possible via LDAP.
>
> [email-masked] ; CISSP
>Associate Technical Fellow - Cyber Identity Specialist
>IT Access & Security Services
>(425) 957-5667
>
>
>
>Regards,
>
>Chris
>+++++
>
>===========================================================================
> Dr. Christopher J. Harding
> T H E Executive Director for the Directory Interoperability Forum
> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK
>G R O U P Mailto:[email-masked] Phone: +44 118 902 3018
> WWW: http://www.opengroup.org Mobile: +44 774 063 1520
>===========================================================================
>Boundaryless Information Flow: Managing the Flow
>Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004
> http://www.opengroup.org/brussels2004/ 
>===========================================================================
>
>
>
>Regards,
>
>Chris
>+++++
>
>===========================================================================
> Dr. Christopher J. Harding
> T H E Executive Director for the Directory Interoperability Forum
> O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK
>G R O U P Mailto:[email-masked] Phone: +44 118 902 3018
> WWW: http://www.opengroup.org Mobile: +44 774 063 1520
>=======================
==================================================== 
>Boundaryless Information Flow: Managing the Flow
>Brussels Hilton Hotel, Brussels, Belgium. April 19-23, 2004
> http://www.opengroup.org/brussels2004/ 
>===========================================================================

---

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

At 11:31 PM 4/17/2004, Schleiff, Marty wrote:
>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.

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

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.

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext