On Tue, 2016-03-29 at 22:49 +0000, Fong, Trevor wrote:
> Hi Everyone,
> A question about how to best go about doing access control on db-linked
> directories. Given the below 2-directory setup (Dir1 has a db link set up to
> Dir2, and vice versa), is the shown ACI setup possible/advisable? If not,
> what's the best way to make it work?:
> aci:(targetattr ="*")(version 3.0;acl "Admins Group";allow (all) (groupdn
> = "ldap:///cn=admins,dc=example,dc=com");)
> I ask because section 2.3.6. Database Links and Access Control Evaluation, of
> the RHDS Admin Guide says:
> "ACIs must be located with any groups they use. If the groups are dynamic, all
> users in the group must be located with the ACI and the group. If the group is
> static, it may refer to remote users."
My interpretation is that dir2 has the aci, and only the data of ou=projects, it
is un-able to back query to dir1. In this case the aci will not work.
You however, this might work:
aci:(targetattr ="*")(version 3.0;acl "Admins Group";allow (all) (groupdn =
You can easily check this with the get effective rights extension.
> I'm afraid the phrasing is a little opaque to my understanding. Does it mean
> that "Admin Groups" act on Dir2 is not allowed to refer to
> cn=admins,dc=example,dc=com on Dir1?
> If so, then what is the best way of maintaining groups centrally but allowing
> them to be used on remote directories?
> *Bonus Question:
> Say Alice only has access to Dir1, she can issue a search to ou=projects
> because of the DB link from Dir1 —> Dir2. When the aci on ou=projects is
> processed, which user is used? uid=alice or the proxy user of the db
> link? Will the aci work at all in this case?
I believe that the db link uses the proxy control to impersonate alice on the
Again, this can easily be validated by doing a search on dir1 as alice, then
checking the access log of dir2 to see who was bound, whether the proxy control
Red Hat, Brisbane
Post a Comment