Groups, Nesting and Access

[Brendan Kearney <bpk678@gmail.com>]

list members,

i am looking to have a group "LDAP Engineers" and "LDAP Admins"
configured, with the engineers group a member of the admin group.   i
have a feeling ACLs will need to be adjusted for this.

the engineer role will have full read/write access to cn=config.  the
access granted to cn=config should not include access to the DIT by
default.  the membership in the admin group should be used to grant this
access.  think more than one database, and not every engineer will be an
admin for every database.  essentially, engineers can modify base level
configs in slapd, add/load schemas, add/load modules, create new
databases, add/modify/delete ACLs, etc.  these will be the ldap gurus.

the admin roll will have full read/write access to the database the
dc=bpk2,dc=com tree is in, only.  essentially, admins can
add/modify/delete the objects in the DIT.  these will be the ldap
support staff.  because the engineers can be members of this group, they
will inherit the access to the DIT.

acls will need to be constructed for this separation of duty.  the
default access granted to the root id by the below might need to be
modified or additions made to the ACL list:

olcAccess: {0}to *  by dn.base="gidNumber=0
+uidNumber=0,cn=peercred,cn=external,cn=auth" manage  by * none

since this applies to the base, the engineer role should get this
access, too.  does the above ACL grant access to more than just the
cn=config?  how can the engineer role be limited to only the cn=config,
and not the database(s) that would have DITs in them?

the database for the DIT, where dc=bpk2,dc=com resides has the below
ACLs.  what ACLs are needed to give the admin role full read/write
access to the database only?  i would imagine those ACLs need to be
above the ones listed, so that the admins can modify the same settings
the users are allowed to modify.

olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth
by * none
olcAccess: {1}to attrs=loginShell by self write by * none
olcAccess: {2}to dn.base="" by * read
olcAccess: {3}to dn.subtree="dc=bpk2,dc=com" by
dn="cn=adm-srv,dc=bpk2,dc=com" write by dn="cn=kdc-srv,dc=bpk2,dc=com"
read by * none

also,  i have read that users should not be able to modify their own uid
and gid attributes.  how does one construct ACLs that grant users the
ability to modify specific attributes, but not others?  what are the
attributes that users should not be able to modify?  i would think those
are fewer in total #s than the ones that the users should be able to
modify.  with that theory, how is an ACL constructed so that all
attributes, except for those few, can be modified by the user?  is there
some "negated" logic that can be used in ACLs?  i have read the "man
slapd.access" page, and ACLs are still a bit of voodoo for me.  i have
to get more comfortable with them, but would like some pointers to get
me going.

thanks in advance,

brendan