Hi,
I have a problem of long and complex ACLs which I need to improve. Therefore, I am thinking of a way to change privilege (access) management.
I have dc=example,dc=com, with branches ou=people, ou=aliases (for email use), ou=dns (dns entries), ou=Groups.
In ou=Groups entries are of the form: dn: cn=TechAdmins,ou=Groups,dc=example,dc=com objectClass: groupOfNames cn: TechAdmins member: uid=jack,ou=people,dc=example,dc=com member: uid=jeff,ou=people,dc=example,dc=com
I would like to be able to control access to any and all entries based on attributes (to be added to the entries) which specify a group to be used for administration.
So, for example, I could add to all entries an AUXiliary objectClass (hypothetical at the moment) "AdminGroupOwnership" with (multi-valued) attributes: AdminGroups and ReadGroups, SearchGroups with values of the form: cn=<groupname>,ou=Groups,dc=example,dc=com. Members of the first would have write access, members of the second would have read access, and members of the third would have search access only.
I would like to ask the list: 1. Can someone demonstrate how we should formulate an ACL which would accomplish the above? The ACL should say: access to <some entries> <some attribute> by {a DN which belongs to a Group specified in the AdminGroups attr of the entry} write by {a DN which belongs to a Group specified in the ReadGroups attr of the entry} read by {a DN which belongs to a Group specified in the SearchGroups attr of the entry} search
2. Is there an existing (included in the distribution or available from a third-party) schema or similar mechanism available (so that I don't re-invent the wheel)?
Thanks in advance, Nick
On 20/2/2012 1:45 μμ, Nick Milas wrote:
I would like to ask the list:
- Can someone demonstrate how we should formulate an ACL which would
accomplish the above? The ACL should say: access to <some entries> <some attribute> by {a DN which belongs to a Group specified in the AdminGroups attr of the entry} write by {a DN which belongs to a Group specified in the ReadGroups attr of the entry} read by {a DN which belongs to a Group specified in the SearchGroups attr of the entry} search
- Is there an existing (included in the distribution or available
from a third-party) schema or similar mechanism available (so that I don't re-invent the wheel)?
Reading through http://www.openldap.org/doc/admin24/access-control.html, I came to the conclusion that this could work if we specify:
access to <some entries> <some attributes> by dnattr=AdminGroups write by dnattr=ReadGroups read by dnattr=SearchGroups search
Will this work if the DNs included in these attributes are, as I have described, of the following form:
cn=<someAdmins>,ou=Groups,dc=example,dc=com
and these are in turn defined as: dn: cn=<someAdmins>,ou=Groups,dc=example,dc=com objectClass: groupOfNames cn: TechAdmins member: uid=<user1>,ou=people,dc=example,dc=com member: uid=<user2>,ou=people,dc=example,dc=com
...??
Please, advise.
Thanks, Nick
Am Mon, 20 Feb 2012 22:21:55 +0200 schrieb Nick Milas nick@eurobjects.com:
On 20/2/2012 1:45 μμ, Nick Milas wrote:
I would like to ask the list:
- Can someone demonstrate how we should formulate an ACL which
would accomplish the above? The ACL should say: access to <some entries> <some attribute> by {a DN which belongs to a Group specified in the AdminGroups attr of the entry} write by {a DN which belongs to a Group specified in the ReadGroups attr of the entry} read by {a DN which belongs to a Group specified in the SearchGroups attr of the entry} search
- Is there an existing (included in the distribution or available
from a third-party) schema or similar mechanism available (so that I don't re-invent the wheel)?
Reading through http://www.openldap.org/doc/admin24/access-control.html, I came to the conclusion that this could work if we specify:
access to <some entries> <some attributes> by dnattr=AdminGroups write by dnattr=ReadGroups read by dnattr=SearchGroups search
Will this work if the DNs included in these attributes are, as I have described, of the following form:
cn=<someAdmins>,ou=Groups,dc=example,dc=comand these are in turn defined as: dn: cn=<someAdmins>,ou=Groups,dc=example,dc=com objectClass: groupOfNames cn: TechAdmins member: uid=<user1>,ou=people,dc=example,dc=com member: uid=<user2>,ou=people,dc=example,dc=com
...??
Please, advise.
The AdminGuide (and slapd.,access(5) clearly say [dnattr=<attrname>] that is, attribute name is commonName or telephoneNumber, but not an attribute value like AdminGroups.
access to <some entries> <some attrs> by group.exact=cn=someAdmins,ou=Group,dc=example,dc=com write by group.exact=cn=ReadGroups,ou=Group,dc=example,dc=com read ...
would be the correct rule set.
-Dieter
On 20/2/2012 11:14 μμ, Dieter Klünter wrote:
The AdminGuide (and slapd.,access(5) clearly say [dnattr=<attrname>] that is, attribute name is commonName or telephoneNumber, but not an attribute value like AdminGroups.
Thanks Dieter,
I guess I was not clear enough?
According to my description, AdminGroups, ReadGroups and SearchGroups are in fact attributes (of a hypothetical to-be-defined objectClass:AdminGroupOwnership) and not values.
We add to each entry the objectClass: AdminGroupOwnership and any needed attributes (AdminGroups, ReadGroups and SearchGroups); these attributes, I repeat, would have values of the form:
cn=<someAdmins>,ou=Groups,dc=example,dc=com
Will it work as expected (to provide access to members of these groups) if we use rules of the form: access to <some entries> <some attributes> by dnattr=AdminGroups write by dnattr=ReadGroups read by dnattr=SearchGroups search ...??
Thanks, Nick
Hi Nick,
Am Mon, 20 Feb 2012 23:57:17 +0200 schrieb Nick Milas nick@eurobjects.com:
On 20/2/2012 11:14 μμ, Dieter Klünter wrote:
The AdminGuide (and slapd.,access(5) clearly say [dnattr=<attrname>] that is, attribute name is commonName or telephoneNumber, but not an attribute value like AdminGroups.
Thanks Dieter,
I guess I was not clear enough?
According to my description, AdminGroups, ReadGroups and SearchGroups are in fact attributes (of a hypothetical to-be-defined objectClass:AdminGroupOwnership) and not values.
We add to each entry the objectClass: AdminGroupOwnership and any needed attributes (AdminGroups, ReadGroups and SearchGroups); these attributes, I repeat, would have values of the form:
cn=<someAdmins>,ou=Groups,dc=example,dc=com
Will it work as expected (to provide access to members of these groups) if we use rules of the form: access to <some entries> <some attributes> by dnattr=AdminGroups write by dnattr=ReadGroups read by dnattr=SearchGroups search ...??
I don't think so, but I haven't tried it. You want access based on a group membership, thus the membership has to be checked.
-Dieter
On Monday, 20 February 2012 23:57:17 Nick Milas wrote:
On 20/2/2012 11:14 μμ, Dieter Klünter wrote:
The AdminGuide (and slapd.,access(5) clearly say [dnattr=<attrname>] that is, attribute name is commonName or telephoneNumber, but not an attribute value like AdminGroups.
Thanks Dieter,
I guess I was not clear enough?
You were clear enough in your requirement, but your approach will not work (and I thought Dieter was clear enough in that regard too).
According to my description, AdminGroups, ReadGroups and SearchGroups are in fact attributes (of a hypothetical to-be-defined objectClass:AdminGroupOwnership) and not values.
And you also want the values of these attributes to be expanded to the members (of some definition) of the groups (of some definitions).
We add to each entry the objectClass: AdminGroupOwnership and any needed attributes (AdminGroups, ReadGroups and SearchGroups); these attributes, I repeat, would have values of the form:
cn=<someAdmins>,ou=Groups,dc=example,dc=comWill it work as expected (to provide access to members of these groups) if we use rules of the form: access to <some entries> <some attributes> by dnattr=AdminGroups write by dnattr=ReadGroups read by dnattr=SearchGroups search ...??
If you were to bind as the 'group' cn=<someAdmins>,ou=Groups,dc=example,dc=com, this would work. But, not if you bind as a 'member' of this group (which I believe is what you want).
What you want to do may be achieveable with sets (http://www.openldap.org/faq/data/cache/1133.html).
Regards, Buchan
On 21/2/2012 12:28 μμ, Buchan Milne wrote:
If you were to bind as the 'group' cn=<someAdmins>,ou=Groups,dc=example,dc=com, this would work. But, not if you bind as a 'member' of this group (which I believe is what you want).
Buchan, Dieter, thank you for your feedback.
Yes, I would like to be able to bind as a user (i.e. a member of the group) and not as the group itself. OK, now it's clear to me that it won't work.
(Note: It seems to me that it would add a GREAT flexibility in privilege management if it would! Could this become a candidate for a feature request for future releases? What are your opinions, as more experienced LDAP admins?)
Could it work if the values of the AdminGroups attribute were not standard groups (as those I have described until now), but a single dynlist, returning user DNs? So, for example, we could define our "AdminGroup" value using e.g. labeledURI of the form: "ldap:///ou=People,dc=example,dc=com?dn?one?(&(employeeType=admin)(ou=tech))" ?
Would this be expanded in ACLs of the form we discuss ("by dnattr=AdminGroups write"), where AdminGroups now contains a single dynlist entry as a value (and we want to bind as a user, not the dynamic "group")?
What you want to do may be achieveable with sets (http://www.openldap.org/faq/data/cache/1133.html).
I'll read about sets, thanks.
Regards, Nick
Am Tue, 21 Feb 2012 15:18:04 +0200 schrieb Nick Milas nick@eurobjects.com:
On 21/2/2012 12:28 μμ, Buchan Milne wrote:
If you were to bind as the 'group' cn=<someAdmins>,ou=Groups,dc=example,dc=com, this would work. But, not if you bind as a 'member' of this group (which I believe is what you want).
Buchan, Dieter, thank you for your feedback.
Yes, I would like to be able to bind as a user (i.e. a member of the group) and not as the group itself. OK, now it's clear to me that it won't work.
(Note: It seems to me that it would add a GREAT flexibility in privilege management if it would! Could this become a candidate for a feature request for future releases? What are your opinions, as more experienced LDAP admins?)
Could it work if the values of the AdminGroups attribute were not standard groups (as those I have described until now), but a single dynlist, returning user DNs? So, for example, we could define our "AdminGroup" value using e.g. labeledURI of the form: "ldap:///ou=People,dc=example,dc=com?dn?one?(&(employeeType=admin)(ou=tech))" ?
slapd.acces(5) expands group to group/groupOfNames/member as default, but allows own definitions of objectclass and attribute, ssomething like
group/adminGroupOwnership/someAttribute=cn=<someAdmins>,ou=Groups,dc=example,dc=com or you may add the dnstyle expand (group.expand=) in order to expand a regular expression.
Would this be expanded in ACLs of the form we discuss ("by dnattr=AdminGroups write"), where AdminGroups now contains a single dynlist entry as a value (and we want to bind as a user, not the dynamic "group")?
What you want to do may be achieveable with sets (http://www.openldap.org/faq/data/cache/1133.html).
I'll read about sets, thanks.
-Dieter
On 21/2/2012 3:18 μμ, Nick Milas wrote:
What you want to do may be achieveable with sets (http://www.openldap.org/faq/data/cache/1133.html).
I'll read about sets, thanks.
As I see in the documentation, what we want to accomplish could be done using sets as follows:
access to <some entries> <some attributes> by set="this/AdminGroups/member* & user" write by set="this/ReadGroups/member* & user" read by set="this/SearchGroups/member* & user" search
Can someone more experienced with sets, please comment on it (confirm or correct it)?
Thanks to all for the help, Nick
On 22/2/2012 6:27 μμ, Nick Milas wrote:
Can someone more experienced with sets, please comment on it (confirm or correct it)?
I have tried to make it more precise. So, assuming the schema is as follows (OIDs are hypothetical), can someone comment on the following (modified accordingly) access list?
Thanks, Nick
============= ACL =======================
access to <some entries> <some attributes> by set="this/writeAccessEntities/member* & user" write by set="this/readAccessEntities/member* & user" read by set="this/searchAccessEntities/member* & user" search
============= Schema ====================
attributetype ( 4.3.6.1.4.1.50000.4.1.11 NAME 'writeAccessEntities' DESC 'DNs of Groups which should be allowed write (full) access to this entry' SUP distinguishedName )
attributetype ( 4.3.6.1.4.1.50000.4.1.12 NAME 'readAccessEntities' DESC 'DNs of Groups which should be allowed read (read-only) accessto this entry' SUP distinguishedName )
attributetype ( 4.3.6.1.4.1.50000.4.1.13 NAME 'searchAccessEntities' DESC 'DNs of Groups which should be allowed search (search-only) accessto this entry' SUP distinguishedName )
objectclass ( 4.3.6.1.4.1.50000.4.2.101 NAME 'entryAccessEntities' DESC 'Allow access to the entry, to which this class is added, to the entities specified as the values (DNs) of this class attributes' SUP top AUXILIARY MAY ( writeAccessEntities$ readAccessEntities$ searchAccessEntities) )
========================================
On 24/2/2012 4:56 μμ, Nick Milas wrote:
I have tried to make it more precise. So, assuming the schema is as follows (OIDs are hypothetical), can someone comment on the following (modified accordingly) access list?
access to <some entries> <some attributes> by set="this/writeAccessEntities/member* & user" write by set="this/readAccessEntities/member* & user" read by set="this/searchAccessEntities/member* & user" search
I tested this (the write and read parts) and it works as expected.
The administrator just has to pay attention to also provide at least read access to "children,entry" attributes for the associated groups.
Nick
openldap-technical@openldap.org
-
Buchan Milne -
Dieter Klünter -
Nick Milas