Hello all, In a previous email, I was told that we can implement *DIT* *structure* rules with openldap using ACL (http://www.openldap.org/lists/openldap-technical/200811/msg00152.html). Did any one have any success implementing these rules with ACL. I have searched the net for an example, but out of luck. Possibly a simple example will help a lot, just to give me an idea about the syntax for a DIT structure rule using ACL.
Thank you.
On Mon, Dec 01, 2008 at 05:17:28PM -0400, Mansour Al Akeel wrote:
In a previous email, I was told that we can implement *DIT* *structure* rules with openldap using ACL (http://www.openldap.org/lists/openldap-technical/200811/msg00152.html). Did any one have any success implementing these rules with ACL. I have searched the net for an example, but out of luck. Possibly a simple example will help a lot, just to give me an idea about the syntax for a DIT structure rule using ACL.
The basic idea is to restrict what can be created in each part of the DIT. Suppose you have a node called cn=people,dc=example,dc=org and you want to make sure that all nodes under it describe people. You might write rules like this:
access to dn.exact="cn=people,dc=example,dc=org" attrs=children by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
access to dn.onelevel="cn=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
The first rule allows the admin to create entries under the "cn=people,dc=example,dc=org" node.
The second rule says that the admin is allowed to write entries that are exactly one level below "cn=people,dc=example,dc=org" and that have objectClass=inetOrgPerson.
If no other rules give the admin user write permissions in this part of the DIT then you effectively have a structure rule. The admin only has write permission if the entry has the correct objectclass, so they cannot add something different.
I have used rules of this sort in the past, but ITS#4556 suggests that there are cases where they do not work. See recent discussion: http://www.openldap.org/lists/openldap-devel/200811/msg00014.html I have rules very similar to the example above which I have just tested on 2.3.27 and they work OK.... My actual rules use regex but I simplified them for this message.
Andrew
Andrew, thank you for your reply. It make sense. I will try this sometime soon, and will report the results.
Andrew Findlay wrote:
On Mon, Dec 01, 2008 at 05:17:28PM -0400, Mansour Al Akeel wrote:
In a previous email, I was told that we can implement *DIT* *structure* rules with openldap using ACL (http://www.openldap.org/lists/openldap-technical/200811/msg00152.html). Did any one have any success implementing these rules with ACL. I have searched the net for an example, but out of luck. Possibly a simple example will help a lot, just to give me an idea about the syntax for a DIT structure rule using ACL.
The basic idea is to restrict what can be created in each part of the DIT. Suppose you have a node called cn=people,dc=example,dc=org and you want to make sure that all nodes under it describe people. You might write rules like this:
access to dn.exact="cn=people,dc=example,dc=org" attrs=children by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
access to dn.onelevel="cn=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
The first rule allows the admin to create entries under the "cn=people,dc=example,dc=org" node.
The second rule says that the admin is allowed to write entries that are exactly one level below "cn=people,dc=example,dc=org" and that have objectClass=inetOrgPerson.
If no other rules give the admin user write permissions in this part of the DIT then you effectively have a structure rule. The admin only has write permission if the entry has the correct objectclass, so they cannot add something different.
I have used rules of this sort in the past, but ITS#4556 suggests that there are cases where they do not work. See recent discussion: http://www.openldap.org/lists/openldap-devel/200811/msg00014.html I have rules very similar to the example above which I have just tested on 2.3.27 and they work OK.... My actual rules use regex but I simplified them for this message.
Andrew
On Tue, Dec 02, 2008 at 03:30:27PM +0000, Andrew Findlay wrote:
The basic idea is to restrict what can be created in each part of the DIT. Suppose you have a node called cn=people,dc=example,dc=org and you want to make sure that all nodes under it describe people. You might write rules like this:
access to dn.exact="cn=people,dc=example,dc=org" attrs=children by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
access to dn.onelevel="cn=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
I have used rules of this sort in the past, but ITS#4556 suggests that there are cases where they do not work. See recent discussion: http://www.openldap.org/lists/openldap-devel/200811/msg00014.html
I have now done some more testing on this. Every version of OpenLDAP that I tested (2.3.27 2.4.11 and some recent versions of HEAD) will work with the rules above.
The problem mentioned in ITS#4556 comes up if you grant write access to the 'entry' pseudo-attribute separately. All versions up to 2.4.12 will allow *any* entry to be created by a user that has write permission on the 'entry' pseudo-attribute of the entry being created and also the 'children' pseudo-attribute of the parent entry.
From 2.4.13 onwards there is a per-database flag to enable full ACL
checking on added entries: add_content_acl yes
I would suggest always enabling that option. Here is an example that does not work as expected without it:
# 1: access to dn.exact="dc=people,dc=example,dc=org" attrs="children" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break # 2: access to dn.onelevel="dc=people,dc=example,dc=org" attrs="entry" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break # 3: access to dn.onelevel="dc=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="uid=admin,dc=people,dc=example,dc=org" write by * break
The only difference is that write access to attrs="entry" is granted separately before the rule that applies to real attributes. Without "add_content_acl yes" this masks the effect of rule 3 on add operations.
Summary:
Using ACLs for structure control is possible, but for all versions before 2.4.13 it is necessary to apply all the control via the "entry" pseudo-attribute.
From 2.4.13 onwards you should enable "add_content_acl yes".
I hope this will become the default in a future version.
Andrew
On Fri, Dec 05, 2008 at 12:37:36PM +0000, Andrew Findlay wrote:
On Tue, Dec 02, 2008 at 03:30:27PM +0000, Andrew Findlay wrote:
The basic idea is to restrict what can be created in each part of the DIT. Suppose you have a node called cn=people,dc=example,dc=org and you want to make sure that all nodes under it describe people. You might write rules like this:
access to dn.exact="cn=people,dc=example,dc=org" attrs=children by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
access to dn.onelevel="cn=people,dc=example,dc=org" filter="(objectClass=inetOrgPerson)" by dn.exact="cn=admin,cn=people,dc=example,dc=org" write by * read
I have now done some more testing on this. Every version of OpenLDAP that I tested (2.3.27 2.4.11 and some recent versions of HEAD) will work with the rules above.
The problem mentioned in ITS#4556 comes up if you grant write access to the 'entry' pseudo-attribute separately. All versions up to 2.4.12 will allow *any* entry to be created by a user that has write permission on the 'entry' pseudo-attribute of the entry being created and also the 'children' pseudo-attribute of the parent entry.
I should also point out that while the rules above do force every new entry to have objectClass=inetOrgPerson they do not prevent other auxiliary objectclasses from being added to the entry. Thus if your structure rules are there to enforce security you may still have a problem. You may be able to mitigate the problem by denying write access to attrs="entry" if certain sensitive attributes exist in the entry, but it is clumsy.
From 2.4.13 onwards there is a per-database flag to enable full ACL checking on added entries: add_content_acl yes
That is the proper fix for the problem, as it allows you to grant write access to just those attributes you want to appear in the entry.
Andrew
Andrew Findlay wrote:
I should also point out that while the rules above do force every new entry to have objectClass=inetOrgPerson they do not prevent other auxiliary objectclasses from being added to the entry.
Limiting the AUXILIARY object classes could be covered by DIT content rules which are supported by OpenLDAP. Well, not exactly, since DIT content rules apply to the whole DIT of a single slapd instance since OpenLDAP does not have the capability of defining separate subschema subentries for subtrees (leaving proxy configurations aside).
Andrew, I think this would be a nice recipe for the FAQ-O-MATIC. Do you have some spare time to add an article in section "Access Control"? (see http://www.openldap.org/faq/data/cache/189.html)
Ciao, Michael.
On Fri, Dec 12, 2008 at 11:57:37AM +0100, Michael Ströder wrote:
I should also point out that while the rules above do force every new entry to have objectClass=inetOrgPerson they do not prevent other auxiliary objectclasses from being added to the entry.
Limiting the AUXILIARY object classes could be covered by DIT content rules which are supported by OpenLDAP.
Good point. I suspect these are not used much as people are not aware of the possibilities.
Well, not exactly, since DIT content rules apply to the whole DIT of a single slapd instance since OpenLDAP does not have the capability of defining separate subschema subentries for subtrees (leaving proxy configurations aside).
True, but there are still cases where a global content rule could be useful. Some care may be needed to avoid confusing schema-aware user interfaces though...
Andrew, I think this would be a nice recipe for the FAQ-O-MATIC. Do you have some spare time to add an article in section "Access Control"? (see http://www.openldap.org/faq/data/cache/189.html)
As it happens, I am working on a paper on ACL design so I may well be able to generate a suitable FAQ entry along the way.
Andrew
On Fri, Dec 12, 2008 at 03:51:06PM +0000, Andrew Findlay wrote:
On Fri, Dec 12, 2008 at 11:57:37AM +0100, Michael Ströder wrote:
Andrew, I think this would be a nice recipe for the FAQ-O-MATIC. Do you have some spare time to add an article in section "Access Control"? (see http://www.openldap.org/faq/data/cache/189.html)
As it happens, I am working on a paper on ACL design so I may well be able to generate a suitable FAQ entry along the way.
Done:
http://www.openldap.org/faq/data/cache/1473.html
Andrew
Andrew Findlay wrote:
Andrew,
thanks for taking the time to contribute to the FAQ-O-MATIC.
But my suggestion was rather that you write up something about how to emulate DIT structure rules with ACLs as you already did in this thread here:
http://www.openldap.org/lists/openldap-technical/200812/msg00016.html
My hint about DIT content rules was my response to the limitation of your approach you mentioned here:
http://www.openldap.org/lists/openldap-technical/200812/msg00038.html).
Ciao, Michael.
On Mon, Dec 15, 2008 at 07:40:15PM +0100, Michael Ströder wrote:
But my suggestion was rather that you write up something about how to emulate DIT structure rules with ACLs as you already did in this thread here:
http://www.openldap.org/lists/openldap-technical/200812/msg00016.html
My hint about DIT content rules was my response to the limitation of your approach you mentioned here:
http://www.openldap.org/lists/openldap-technical/200812/msg00038.html).
For complete control you need content rules as well as ACLs, though setting add_content_acl helps a lot. Even then it could be awkward to selectively delegate the ability to use a particular aux class.
I have written up the structure control example here:
http://www.openldap.org/faq/data/cache/1474.html
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Mansour Al Akeel -
Michael Ströder