[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP enhancements


That would be great if OpenLDAP supports mods to the schema. I haven't groked all of the source for slapd yet, so I don't know how much is there. Certainly this seems the right approach if it has not been done this way already.

What I am most interested in, however, is making the ACLs available via the directory. I need to be able to add/change/delete access controls dynamically and programmatically.

A related change that I'd like to make is the addition of "secure" permissions. For example, I'd like to be able to do something like this:

    access to attr=privateAttr by * secureread

What secureread (and securewrite, etc.) means is that the connection over which the reading (writing) is happening is secure (via SASL/TLS SSL). What I'm looking for is on-the-wire security enforced for certain attributes.

Doing secureread/securewrite seems really easy, from my current understanding of the source. Also, adding dynamic configuration of ACLs though LDAP seems pretty straightforward. I want to do it right, though, and comments like David's are right on the mark (as are others that I have received in private e-mail).

Regards,

Mark.

On Mon, 9 Aug 1999, Mark Valence wrote:

> The basic idea is to expose the Schema and ACLs via LDAP, and eventually
> to allow these configs to be changed via LDAP.

I don't know about the ACLs part, but isn't exposing the schema via LDAP just
the implementation of the "subschemasubentry" from LDAPv3?  If OpenLDAP 2.x is
going to support LDAPv3 then presumably this would already be implemented (or
at least, on the drawing board).  Particularly allowing the schema to be
changed via LDAP is a writable RootDSE.

> If the schema and acls are to be part of an LDAP directory, then
> where would they go?

The subschemasubentry.  To locate this, query the RootDSE:

% ldapsearch -L -h ldapv3-server -b "" -s base "objectclass=*"
[...]
namingcontexts: cn=schema
subschemasubentry: cn=schema
[...]

Now query the subschemasubentry to learn the LDAP server's schema:

% ldapsearch -L -h ldapv3-server -b "cn=schema" -s base "objectclass=*"
dn: cn=schema
objectclass: top
objectclass: subschema
objectclasses: ( 2.5.6.0 NAME 'top' [...]
[...]
attributetypes: ( abstract-oid NAME 'abstract' [...]
[...]

Note, this is LDAPv3 - won't work with an LDAPv2 server.

> What would their DNs look like, and what attributes would they have?

As above - all object classes and attribute types are attributes of the
subschemasubentry.