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