Re: OpenLDAP enhancements

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

At 04:30 AM 8/10/99 +1000, David J N Begley wrote:
>The subschemasubentry.  To locate this, query the RootDSE:
>
>% ldapsearch -L -h ldapv3-server -b "" -s base "objectclass=*"
>[...]
>namingcontexts: cn=schema
>subschemasubentry: cn=schema
>[...]

First, to get namingcontexts, use:
%ldapsearch -L -h ldapv3-server -b "" -s base \
  "(objectclass=*)" namingcontexts

Note: namingcontexts is an operational attribute type and should be
explicitly listed if desired.  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.

Second, you should always get the subschema for a specific entry's
subschemasubentry.  server may have multiple subschemas.  A server
have multiple or no subschemasubentry values listed in the RootDSE.
In particular, the subschemasubentry for a specific entry may
not be listed (but is not available to the replica) while other
subschema is available.

Hence, always ask for the subschemasubentry of the entry to which
you indend to modify.  (Always refresh schema information after
binds as well... ACLs can apply to subschemasubentries).

ldapsearch -L -h ldapv3-server -b <targetDN> -s base
	"(objectclass=*)" subschemasubentry
dn: <targetDN>
subschemasubentry: <subentryDN>

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

ldapsearch -L -h ldapv3-server -b <subentryDN> -s base
  "(objectclass=subschema)" objectclasses attributetypes

Note: objectclasses and attributetypes are operational and
hence you should explicitly list them if you want them
returned.

If you don't list them, you may get something like:

dn: CN=SCHEMA
cn: SCHEMA
objectclass: top
objectclass: subschema
objectclass: extensibleObject