On Thu, 2016-03-31 at 17:06 +0000, Fong, Trevor wrote:
> Hi William,
>
> Thanks very much for your reply.
>
>
You're welcome.
>
>
> 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.
You actually do the get effective rights check as Directory Manager, and you say
"from bind dn to target". This will work better for you.
You need the mozldap tools for this of course.
An example is:
ldapsearch -p 389 -h localhost -D 'cn=Directory Manager' -w - -b <search base>
-J 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:<bind dn you want to chec> (filter)
attributes.
Where filter and attributes is whene you want to see what bind dn can do the the
objects of filter / attr.
>
>
> >
> >
> > >
> > >
> > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/h
> > > tml/
> > > Administration_Guide/Configuring_Directory_Databases-
> > > Creating_and_Maintaining_Database_Links.html#Creating_and_Maintaining_Datab
> > > ase_
> > > 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.
Access log in this case. You see the proxy attempts in the access log.
>
> 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?
>
>
I think that it's about the design of the directory. You need the groups for
permissions in the same place as the permission.
So say you had this layout:
Dir1:
dc=example,dc=com
ou=employees
uid=alice
uid=bob
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");)
Dir2:
dc=example,dc=com
ou=applications
aci:(targetattr ="*")(version
3.0;acl "Admins Group";allow (all) (groupdn =
"ldap:///cn=admins,dc=example,dc=com");)
I think that if this was my system, I would probably make it like this:
Dir1:
dc=example,dc=com
ou=employees
uid=alice
uid=bob
ou=groups
cn=admins
cn=staff
Dir2:
dc=example,dc=com
ou=projects
aci:(targetattr ="*")(version 3.0;acl "Admins Group";allow (all) (groupdn = "ldap:///cn=project admins,cn=project permissions,dc=example,dc=com");)
ou=project permissions
cn=project admins
member:uid=alice ...
Dir3:
dc=example,dc=com
ou=applications
aci:(targetattr ="*")(version 3.0;acl "Admins Group";allow (all) (groupdn = "ldap:///cn=application admins,cn=application permissions,dc=example,dc=com");)
ou =application permissions
cn=application admins
member:uid=bob ...
This way, you have to the front end applications you have groups and member of plugin working in directory 1.
Then for dir 2 and dir 3, you have the permissions attached to the ou in the same directory, with the groups there. This allows the aci management and expansion.
You want "general" data in dir 1, and more specific data in the chained dbs. But of course, you need the *related* specific data in the chained databases.
Personally, I would probably actually just do away with the chaining db. It adds *a lot* of complexity. It's good for certain things, and I don't think this is it.
It's probably easier here to have a rw master, and ro consumers. That way you can have the data in a single tree, and you really can take advantage of all the plugins and their power. Plus, you gain more read capacity for clients, and you don't have to mess about with lots of ou's for groups etc.
I think I would need to know more about why you want to try and do chaining db, because I think your scenario is the wrong one to use it in.
--
Have a magical day,
William Brown
VP of Powerful Wizardary
Red Hat, Brisvenice
No comments:
Post a Comment