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

Re: OpenLDAP permissions question



Hello Brendan,

If there is no way to grant access to all records across all databases
to cn=config [because it is not a user], I would go for having a
[different] user who can delete records in multiple DITs[, by invoking
LDAPI or whatever].

I will look into slapacl(8C). Did not there a tool for this. Not sure
it will help someone like myself, but I will certainly try.

Thank you,

Igor Shmukler


On Fri, Mar 20, 2015 at 2:07 AM, Brendan Kearney <bpk678@gmail.com> wrote:
> 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
>