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

OpenLDAP enhancements


I would like to make some changes to OpenLDAP, and I'd like some feedback on my planned enhancements and my approach.

The basic idea is to expose the Schema and ACLs via LDAP, and eventually to allow these configs to be changed via LDAP. I think that this would be a very useful feature for sites that need to delegate management of an LDAP server to multiple people. This would also allow programmatic (and dynamic) changes to the schema and ACLs (other than editing the conf files and restarting slapd).

There are a few ways to do this while limiting the amount of code that needs to be changed in slapd. In fact, one primary goal would be to make these enhancements without modifying the existing source. My idea about doing this is to make a new backend that looks at internal lists and structures within slapd, and then present these as entities in the directory (and eventually modifies the internal lists, too).

Another way to so this is to change acl_parse.c, etc. to read from "the directory". In other words, schema and acl info would be accessed through backend.c, as real objects in the directory, stored wherever the (now minimal) conf file specified. This would require mods to existing code, but would be more flexible than writing a "slapd.conf" backend. (One benefit, for example, is that you could have a schema/acl server for a bunch of distributed LDAP servers, and you'd only have to maintain one "master" schema/acl by using the ldap backend as the source for your schema/acl).

If the schema and acls are to be part of an LDAP directory, then where would they go? What would their DNs look like, and what attributes would they have? How would you manage global vs. backend-specific acls? Would you maintain the order in which acls are applied, or change the rules from first-match to a big OR of all acls? I have a few thoughts on how to do this, but I want to hear back from anyone about the concept of directory-based schema/ACLs first.

Thanks for any comments,

Mark Valence