Re: OpenLDAP enhancements

[David J N Begley <david@avarice.nepean.uws.edu.au>]

On Mon, 9 Aug 1999, Kurt D. Zeilenga wrote:

> >% ldapsearch -L -h ldapv3-server -b "" -s base "objectclass=*"
> >[...]
> >namingcontexts: cn=schema
> >subschemasubentry: cn=schema
> >[...]
[...]
> Note: namingcontexts is an operational attribute type and should be
> explicitly listed if desired.

Thanks for the correction (in this case, the focus was really
"subschemasubentry" but I know what you meant).

> Some LDAPv3 servers may provide some or all operational attribute types in
> the RootDSE without requiring it being listed, but some (like OpenLDAP)
> require that you explicitly request it.

Question - why?  Security?  A quick check around a few LDAPv3(-ish) servers
shows them all returning a fair few operational attributes for the Root DSE
without those attributes being explicitly listed:

- Microsoft Exchange 5.5
- Netscape Calendar (v?)
- Netscape Directory 4.x
- Novell NetWare 5 (NDS 8)

"namingcontexts" is included in all these.

> Second, you should always get the subschema for a specific entry's
> subschemasubentry.

This of course assumes you already know the DN of an entry - if you're try to
see what the server supports (before either adding an entry, or at the very
least trying to find entries of certain object classes) then shouldn't you be
looking in the Root DSE?

> In particular, the subschemasubentry for a specific entry may not be
> listed (but is not available to the replica) while other subschema is
> available.

Sorry, I don't follow this - the subentry for a specific object entry may NOT
be listed (in the directory being queried?) BUT is NOT available to the
replica (which replica - the directory being queried?).  Maybe it's the
addition of the word "but" that's thrown me...

> When search the subschemasubentry, be sure to use a search filter of
> "(objectclass=subschema)" (see RFC2251 for details).

Just noticed, thanks.


dave