[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: RFC 2251 Root DSE non-standard
I took the USAGE specifications out of the core.schema for
namingContext, subschemaSubEntry, supportedLDAPVersions,
supportedControl and supportedExtensions. This fixed my buggy client
behavior. I know why this is not the default (and technically not
correct), but it is now noted as a workaround for buggy clients that
require it.
Thanks for all the help. I have a much better understanding now.
Kevin
-----Original Message-----
From: Kevin J. McCarthy
Sent: Sunday, September 02, 2001 2:36 AM
To: 'Howard Chu'; 'openldap-software@openldap.org'
Subject: RE: RFC 2251 Root DSE non-standard
Tell IBM, Microsoft, and all the ISVs who are being lazy! :^) Honestly,
I will do so. I know they are the ones who are at fault. They need to
ask for what they want, those buggers!
I can understand your argument, since the more important attributes are
explicitly defined (supportedSASLMechanisms, namingContexts,
supportedLDAPVersion, subschemaSubentry, etc.). Makes sense to me. The
problem is that this 3rd party sofware has already been written and I
can not change any of it. It simply does not work with OpenLDAP because
of this.
I agree with you philosophically, but I see more value in making a
change that does not break any rules and provides much greater utility.
I am thinking a patch would be minimal and would fix many annoying
problems.
Kevin
-----Original Message-----
From: Howard Chu [mailto:hyc@highlandsun.com]
Sent: Sunday, September 02, 2001 2:19 AM
To: Kevin J. McCarthy; Kurt D. Zeilenga (E-mail)
Subject: RE: RFC 2251 Root DSE non-standard
Any clients that behave this way are relying on non-standard behavior.
The only safe approach that obeys the spec and is guaranteed to work is
to explicitly specify a list of the attributes that you're interested
in.
All in all that makes the most sense - you're not going to pay attention
to any attributes that you didn't ask for anyway, so why bother getting
all of them?
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
> -----Original Message-----
> From: Kevin J. McCarthy [mailto:kevin@kogz.com]
> I see that the + is an attribute wildcard and not the filter. That
makes
> sense.
>
> However, OpenLDAP REQUIRES the "+" and all others REJECT it.
>
> If you look at generic clients, they do not supply an attribute list.
> They expect some valid result from a NULL list. I see that this is not
> explicitly required, but it is a de facto standard that appears to be
> expected.
>
> Kevin
>
> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]
> Sent: Sunday, September 02, 2001 2:04 AM
> To: Kevin J. McCarthy
> Cc: openldap-software@OpenLDAP.org
> Subject: RE: RFC 2251 Root DSE non-standard
>
>
> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Kevin J.
> > McCarthy
>
> > Kurt,
>
> Excuse me for butting in here...
>
> > Regarding:
> >
> > ldapsearch -x -h localhost -b "" -s base +
>
> This is an invalid search. I'm surprised you get a response from it.
> >
> > That is non-standard behavior. I am not saying it is WRONG; not at
> all.
> > What I am saying is that every other server I have access to (Active
> > Directory, iPlanet, and IBM secureWay) all provide rootDSE stuff
with:
> >
> > ldapsearch -x -h <hostname> -b "" -s base "(objectClass=*)"
> >
> > While OpenLDAP returns this:
> >
> > dn:
> > objectClass: top
> > objectClass: OpenLDAProotDSE
> >
> > Which is totally useless. When I replace the "(objectClass=*)" with
> "+"
> > as you indicate, I get what I want from OpenLDAP. However, the "+"
> > breaks EVERY OTHER server so that they produce no results (or
> > referrals).
>
> You should not be replacing "(objectclass=*)", that is the search
> filter.
> You
> are required to provide a filter with your search request. The "+"
> specifies
> the attribute list, i.e., the list of attributes you're interested in.
> In
> this
> case, "+" is a wildcard that stands for all of the operational
> attributes.
> Your request should have been
> ldapsearch -x -h <hostname> -b "" -s base "(objectClass=*)" +
>
> > According to RFC 2251:
> >
> > An LDAP server MUST provide information about itself and other
> > information that is specific to each server. This is represented as
a
> > group of attributes located in the root DSE (DSA-Specific Entry),
> which
> > is named with the zero-length LDAPDN. These attributes are
retrievable
> > if a client performs a base object search of the root with filter
> > "(objectClass=*)", however they are subject to access control
> > restrictions. The root DSE MUST NOT be included if the client
performs
> a
> > subtree search starting from the root.
> >
> > Doing that search DOES NOT tell a client anything about the server,
so
> > as far as I can tell requiring the "+" does not adhere to the RFC.
> >
> > Kevin
> The "+" is not *required*, it's just a convenient shorthand, simpler
> than
> typing
> out "namingcontexts supportedLDAPversion ..." But, an attribute list
of
> some
> form
> or another *is* required.
>
> The information in the root DSE that you are looking for consists of
> operational attributes. A server that returns operational attributes
> when
> they have not been requested is violating the LDAP protocol. See
RFC2251
> the end of section 4.5.1. It's also stated in section 3.2.1.
>
> Client implementors should note that even if all user attributes
> are
> requested, some attributes of the entry may not be included in
> search results due to access control or other restrictions.
> *** Furthermore, servers will not return operational attributes, such
> as objectClasses or attributeTypes, unless they are listed by
name,
> since there may be extremely large number of values for certain
> operational attributes. (A list of operational attributes for use
> in LDAP is given in [5].)
>
> ps: [5] above is RFC2252, LDAPv3 Attributes...
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
>