Re: OpenLDAP enhancements

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 02:47 PM 8/12/99 +1000, David J N Begley wrote:
>> 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?

RFC2251, 3.2.1:
   Some attributes, termed operational attributes, are used by servers
   for administering the directory system itself.  They are not returned
   in search results unless explicitly requested by name.

RFC2251, 4.5.1: (Search)
   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.

"operational", in my opinion, includes all attribute types marked
"directoryOperation", "distributedOperation", or "dsaOperation".

>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:

A number of vendors also return operational attribute types (such
as objectclasses and attributetypes) without them being requested
when searching subschema subentries.

>> 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?

No.   If you are adding an entry, you know it's DN.  Hence, you can
determine which namingContext the entry would be in and discover
subschema specific to that namingContext.

If you want schema for read operations, you are searching within some
context.  You can determine if the context is held by the server
and attempt to obtain subschema rules specific to context. 

The subschemasubentry in the RootDSE is multivalued and none of
the values may apply to the context of your operation.  As
such, you should always attempt to acquire the subschemasubentry
from within the context of the operation, preferably from the
target DN or search base.  If you are doing an add, you can
check look in the intended parent of the entry to be added
or the entry at the root of the namingContext which will hold
the entry.

> Security?

Access controls can apply to most anything.  Servers are only required
to provide schema for entries to which the client can modify.  If
the client cannot modify an entry, it may not be able to obtain
schema for it.

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

In particular, the subschemasubentry for a specific entry may not be
listed in the RootDSE of the contacted server.  However, other subschema
subentries may be listed in the RootDSE.   This can occur when the
entry is not mastered by the contacted server and the master server
did not provid the slave server with the subschema for the entry.

	Kurt