[389-users] Re: ACI's on DB Linked Directories

Hi William,

Thanks very much for your reply.




On 2016-03-29, 4:23 PM, "William Brown" <wibrown@redhat.com> wrote:

>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?:
>>
>> Dir1:
>> dc=example,dc=com
>> ou=employees
>> uid=alice
>> uid=bob
>>
>> cn=admins
>> member:uid=alice,ou=employees,dc=example,dc=com
>>
>> Dir2:
>> dc=example,dc=com
>> ou=projects
>> 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:
>
>Dir1:
>dc=example,dc=com
> cn=admins
> member:uid=alice,ou=employees,dc=example,dc=com
>
>Dir2:
>dc=example,dc=com
> ou=projects
> aci:(targetattr ="*")(version 3.0;acl "Admins Group";allow (all) (groupdn =
>"ldap:///cn=admins,dc=example,dc=com");)
>
> ou=employees
> uid=alice
> uid=bob

So the aci on Dir2 can refer to a remote group on ACI, but the members of the group have to be local?


>You can easily check this with the get effective rights extension.

Unfortunately, get effective rights only shows the rights if you can get to an entry. If you can't (e.g. aci not letting you/not working) then you don't get anything. I was hoping not to but guess I'll have to get the ACL processing logged.


>
>>
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/
>> Administration_Guide/Configuring_Directory_Databases-
>> Creating_and_Maintaining_Database_Links.html#Creating_and_Maintaining_Database_
>> Links-Database_Links_and_Access_Control_Evaluation
>>
>> 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
>remote server.
>
>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
>was used.
>

Thanks again, I'll up the errorlog level do a log crawl and try to work out what's happening.

Just wondering if other users out there do a similar thing, where they have a central directory chaining to more specialized directories secured with acids? How do you write your ACI's to avoid this kind of situation?

Thanks everyone,
Trev




>
>--
>Sincerely,
>
>William Brown
>Software Engineer
>Red Hat, Brisbane
>
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org