On Thu, 2015-03-19 at 23:35 +0200, Igor Shmukler wrote:
Hello Dan and Michael,
I have a server with a config database and a few DIT databases. I use online configuration. A little white ago, I knew nothing about OpenLDAP. Now, your help, I understand a lot more, yet still little and able to achieve even less..
I want individual administrators [those from within each DIT] to be able to browse within their tree, and cn=config administrator to be able to search through all records on the server, across DITs. If this is too difficult, I would go for LDAPI. As a temporary workaround, LDAPI would be amazing.
None of it working, yet. I tried a bunch of suggestions, many of which I don't fully understand. Nothing worked so far.
Specifically, I cannot understand why should not the below applied to the config database does not work, if I did set the password. olcAccess: {0}to * by dn="cn=config" manage
Sincerely,
Igor Shmukler
On Thu, Mar 19, 2015 at 11:16 PM, Dan White dwhite@cafedemocracy.org wrote:
On 03/19/15 23:05 +0200, Igor Shmukler wrote:
Hello Dan,
I must have done something wrong, yet this thing did not work either. One: the delete still failed with the usual error, and second - I got an error concerning my olcs:
550b380f /etc/ldap/slapd.d: line 1: rootdn is always granted unlimited privileges. 550b380f olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix
You don't need to set olcRootPW in this case. See slapd-config(5).
-- Dan White
i think you are missing a key notion about cn=config. it is not a user object. you do not grant it access to anything. you grant someone/something access to *it*.
i have an acl granting a group in my directory manage access to my cn=config instance (mind the wrap):
{0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by group.exact="cn=ldapEngineers,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage by * none
so the root user on the local machine, and members of the ldapEngineers group are allowed to manage the cn=config instance.
then i have an acl granting a group in my directory manage access to my dc=bpk2,dc=con instance (mind the wrap):
{0}to dn.subtree="dc=bpk2,dc=com" by group.exact="cn=ldapAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage by dn="cn=kadmin,dc=bpk2,dc=com" write by dn="cn=kdc,dc=bpk2,dc=com" read by users read by anonymous auth by * none
members of the ldapAdmins group are allowed manage access to the directory, kerberos process id's are allowed read or write access, users can read, etc.
it took me a while to figure the above out, and i still dont have a great grip on acls, but you can always try slapacl to test your acls.
hope that helps.
brendan