[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
FW: Active Directory question
- To: <ietf-ldapbis@OpenLDAP.org>
- Subject: FW: Active Directory question
- From: "Schleiff, Marty" <marty.schleiff@boeing.com>
- Date: Thu, 15 Apr 2004 10:50:06 -0700
- Content-class: urn:content-classes:message
- Thread-index: AcQiTZV+rK3aXZICTbKgaHIh4GRABQAxCfRw
- Thread-topic: Active Directory question
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,
Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
IT Access & Security Services
(425) 957-5667
-----Original Message-----
From: Chris Harding [mailto:c.harding@opengroup.org]
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.
Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
IT Access & Security Services
(425) 957-5667
-----Original Message-----
From: Chris Harding [mailto:c.harding@opengroup.org]
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 (ietf-ldapbis@OpenLDAP.org) 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.
Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
IT Access & Security Services
(425) 957-5667
Regards,
Chris
+++++
======================== ========================== ========================<= BR>
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:c.harding@opengroup.org Phone: +44 118 = 902 3018
= WWW: http://www.opengroup.org Mobile: +44 774 063 = 1520
======================== ========================== ========================<= BR>
Boundaryless Information Flow: Managing the Flow
Brussels Hilton Hotel, Brussels, Belgium. April 19-23, = 2004
http://www.opengroup.org/brussels2004/
======================== ========================== ========================<= BR>
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:c.harding@opengroup.org 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/
==== ========================== ========================== ===================
------_=_NextPart_001_01C42312.167D9A28--