I am facing the following problem (with v2.4.31 on CentOS 5.8).
I am using a - recently added - custom schema with one AUX objectclass and 3 optional attrs; I am trying to use an ACL of the form:
access to dn.subtree="ou=people,dc=example,dc=com" attrs=@entryAccessEntities by group/groupOfNames/member.exact="cn=Admins,ou=groups,dc=example,dc=com" read
but strangely this ALSO changes the privileges for the objectClass attribute of the entry!
If I list the attrs of that object class instead, there is no problem:
access to dn.subtree="ou=people,dc=example,dc=com" attrs=writeAccessEntities,readAccessEntities,searchAccessEntities by group/groupOfNames/member.exact="cn=Admins,ou=groups,dc=example,dc=com" read
Now, the ACL works correctly, and it does not affect the entry objectClass attribute.
Surprisingly, this does not happen with other object classes. If I use, for example:
access to dn.subtree="ou=people,dc=example,dc=com" attrs=@eduPerson by group/groupOfNames/member.exact="cn=Admins,ou=groups,dc=example,dc=com" read
then, it correctly assigns privileges to only the attrs of eduPerson object class (also an AUX class with only optional attrs), without affecting the entry objectclass attribute.
Does anyone have an idea what is happening? Am I doing anything wrong?
Any help will be appreciated.
For reference I include the schema below.
Note: I am using dynamic config, but I have listed schema and ACLs in their "standard" form, for better readability.
Thanks, Nick
===================================================== entryaccess.schema =====================================================
attributetype ( 1.3.6.1.4.1.39349.4.1.11 NAME 'writeAccessEntities' DESC 'DNs of Groups which should be allowed write (full) access to this entry' SUP distinguishedName ) attributetype ( 1.3.6.1.4.1.39349.4.1.12 NAME 'readAccessEntities' DESC 'DNs of Groups which should be allowed read (read-only) access to this entry' SUP distinguishedName ) attributetype ( 1.3.6.1.4.1.39349.4.1.13 NAME 'searchAccessEntities' DESC 'DNs of Groups which should be allowed search (search-only) access to this entry' SUP distinguishedName )
objectclass ( 1.3.6.1.4.1.39349.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 ) )
=====================================================
access to dn.subtree="ou=people,dc=example,dc=com" attrs=@entryAccessEntities
but strangely this ALSO changes the privileges for the objectClass attribute of the entry!
I can confirm that's happening here with same OpenLDAP version. I've been banging my head all afternoon trying to find my own typo...
My ACL looks like this:
access to attrs=userPassword,userPKCS12,shadowLastChange,@krbPrincipalAux,@krbTicketPolicyAux by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write by group="cn=LDAPadmins,ou=Groups,dc=mens,dc=de" write by anonymous auth by self none by * none
That hides the objectClass type.
$ ldapsearch -x -LLL uid=f2 dn: uid=f2,ou=Users,dc=mens,dc=de uid: f2 cn: Joe Guest gecos: Joe Guest gidNumber: 4 homeDirectory: /home/f2 loginShell: /bin/bash sn: Guest uidNumber: 902
If I list the attrs of that object class instead, there is no problem:
ACK. If I replace @krbPrincipalAux,@krbTicketPolicyAux by their list of attributes, the objectclass type reappears.
-JP
Jan-Piet Mens wrote:
access to dn.subtree="ou=people,dc=example,dc=com" attrs=@entryAccessEntities
but strangely this ALSO changes the privileges for the objectClass attribute of the entry!
I can confirm that's happening here with same OpenLDAP version. I've been banging my head all afternoon trying to find my own typo...
Don't inherit from top.
My ACL looks like this:
access to attrs=userPassword,userPKCS12,shadowLastChange,@krbPrincipalAux,@krbTicketPolicyAux by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write by group="cn=LDAPadmins,ou=Groups,dc=mens,dc=de" write by anonymous auth by self none by * none
That hides the objectClass type.
$ ldapsearch -x -LLL uid=f2 dn: uid=f2,ou=Users,dc=mens,dc=de uid: f2 cn: Joe Guest gecos: Joe Guest gidNumber: 4 homeDirectory: /home/f2 loginShell: /bin/bash sn: Guest uidNumber: 902If I list the attrs of that object class instead, there is no problem:
ACK. If I replace @krbPrincipalAux,@krbTicketPolicyAux by their list of attributes, the objectclass type reappears.
-JP
On 6/6/2012 6:36 μμ, Howard Chu wrote:
Don't inherit from top.
In my case, removing top ObjectClass from an entry does not change behavior.
Here is the entry, after removing top:
DN: uid=tester,ou=people,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: eduPerson objectClass: schacContactLocation objectClass: entryAccessEntities cn: Tester eduPersonAffiliation: staff eduPersonOrgDN: dc=example,dc=com eduPersonOrgUnitDN: ou=people,dc=example,dc=com eduPersonPrimaryAffiliation: staff eduPersonPrimaryOrgUnitDN: ou=people,dc=example,dc=com eduPersonPrincipalName: tester@example.com eduPersonScopedAffiliation: staff@example.com employeeType: unl givenName: Tester mail: tester@example.com o: example ou: research schacHomeOrganization: example.com sn: Tester title: Scientific Technical Staff uid: tester userPassword:: secret writeAccessEntities: cn=Admins,ou=Groups,dc=example,dc=com
When I use:
{xx}to dn.subtree="ou=people,dc=example,dc=com" attrs=@entryAccessEntities by group/groupOfNames/member.exact="cn=admins,ou=groups,dc=example,dc=com" read
*NOTE:* The DN should have write access to all other attrs, based on other ACLs
then:
# slapacl -b "uid=tester,ou=people,dc=example,dc=com" -D "uid=admin1,ou=people,dc=example,dc=com" authcDN: "uid=admin1,ou=people,dc=example,dc=com" entry: write(=wrscxd) children: write(=wrscxd) ... objectClass=person: read(=rscxd) objectClass=organizationalPerson: read(=rscxd) objectClass=inetOrgPerson: read(=rscxd) objectClass=eduPerson: read(=rscxd) objectClass=schacContactLocation: read(=rscxd) objectClass=entryAccessEntities: read(=rscxd) ... writeAccessEntities=cn=Admins,ou=Groups,dc=example,dc=com: read(=rscxd)
but when:
{xx}to dn.subtree="ou=people,dc=example,dc=com" attrs=writeAccessEntities,readAccessEntities,searchAccessEntitiesby group/groupOfNames/member.exact="cn=admins,ou=groups,dc=example,dc=com" read
then:
# slapacl -b "uid=tester,ou=people,dc=example,dc=com" -D "uid=admin1,ou=people,dc=example,dc=com" authcDN: "uid=admin1,ou=people,dc=example,dc=com" entry: write(=wrscxd) children: write(=wrscxd) ... objectClass=person: write(=wrscxd) objectClass=organizationalPerson: write(=wrscxd) objectClass=inetOrgPerson: write(=wrscxd) objectClass=eduPerson: write(=wrscxd) objectClass=schacContactLocation: write(=wrscxd) objectClass=entryAccessEntities: write(=wrscxd) ... writeAccessEntities=cn=Admins,ou=Groups,dc=example,dc=com: read(=rscxd)
Please advise.
Thanks, Nick
Nick Milas wrote:
On 6/6/2012 6:36 μμ, Howard Chu wrote:
Don't inherit from top.
In my case, removing top ObjectClass from an entry does not change behavior.
Howard meant don't derive your custom object class from 'top' since this is declared as:
( 2.5.6.0 NAME 'top' DESC 'top of the superclass chain' ABSTRACT MUST objectClass )
Ciao, Michael.
Howard Chu wrote:
Jan-Piet Mens wrote:
access to dn.subtree="ou=people,dc=example,dc=com" attrs=@entryAccessEntities
but strangely this ALSO changes the privileges for the objectClass attribute of the entry!
I can confirm that's happening here with same OpenLDAP version. I've been banging my head all afternoon trying to find my own typo...
Don't inherit from top.
This does not work for standard STRUCTURAL object classes.
Hmm, another work-around could be to place an appropriate ACL for attribute 'objectClass' before the ACL using @objectClassName catching all possible access right cases.
Ciao, Michael.
Don't inherit from top.
This entry doesn't have objectClass=top:
dn: uid=f2,ou=Users,dc=mens,dc=de uid: f2 objectClass: inetOrgPerson objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux objectClass: posixAccount structuralObjectClass: inetOrgPerson entryUUID: 18698832-4269-1031-8660-0d2f1640f9c2 creatorsName: cn=Manager,dc=mens,dc=de createTimestamp: 20120604081448Z krbPrincipalName: f2@MENS.DE cn: Joe Guest gecos: Joe Guest gidNumber: 4 homeDirectory: /home/f2 loginShell: /bin/bash ...
-JP
--On Wednesday, June 06, 2012 7:06 PM +0200 Jan-Piet Mens jpmens.dns@gmail.com wrote:
Don't inherit from top.
This entry doesn't have objectClass=top:
Howard is talking about the *schema definition*. Not the entry.
However, I don't think his response is quite valid. AUXILIARY OC's traditionally inherit from top. If you look at the standard track schema items included with OpenLDAP, this is quite apparent.
There are a ton of examples in core.schema/core.ldif of this very same usage.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, June 06, 2012 7:06 PM +0200 Jan-Piet Mens jpmens.dns@gmail.com wrote:
Don't inherit from top.
This entry doesn't have objectClass=top:
Howard is talking about the *schema definition*. Not the entry.
However, I don't think his response is quite valid. AUXILIARY OC's traditionally inherit from top. If you look at the standard track schema items included with OpenLDAP, this is quite apparent.
There are a ton of examples in core.schema/core.ldif of this very same usage.
Yes.
That's why I suggested to work around this by adding an ACL for attribute 'objectClass' *before* all other ACLs containing attrs=@objectClassName.
Ciao, Michael.
--On Wednesday, June 06, 2012 10:38 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Wednesday, June 06, 2012 7:06 PM +0200 Jan-Piet Mens jpmens.dns@gmail.com wrote:
Don't inherit from top.
This entry doesn't have objectClass=top:
Howard is talking about the *schema definition*. Not the entry.
However, I don't think his response is quite valid. AUXILIARY OC's traditionally inherit from top. If you look at the standard track schema items included with OpenLDAP, this is quite apparent.
There are a ton of examples in core.schema/core.ldif of this very same usage.
Discussed with Howard. That is how the standard track RFCs define those objectClasses, but in general, you don't want to do this with your custom AUX objectClasses. Really the RFC defined oc's should be fixed via another RFC, but fat chance of that happening.
If you truly want to inherit from top for your AUX objectClases in the schema definition, then add an ACL granting access to the objectClass attribute as one of your first ACL entries.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 6/6/2012 9:03 μμ, Quanah Gibson-Mount wrote:
Discussed with Howard. That is how the standard track RFCs define those objectClasses, but in general, you don't want to do this with your custom AUX objectClasses. Really the RFC defined oc's should be fixed via another RFC, but fat chance of that happening.
If you truly want to inherit from top for your AUX objectClases in the schema definition, then add an ACL granting access to the objectClass attribute as one of your first ACL entries.
OK, I removed "SUP top" from the schema definition (following above recommendation and hoping that I am not going to drive into any issue down the road), and now it works as expected.
Since it is not uncommon for admins to create/use custom schemas (even not being experts in LDAP RFCs), it might be useful to put together (at the project's convenience) a short list of such considerations for us poor LDAP men. :-)
Thank you for all the help.
Regards, Nick
Nick Milas wrote:
Since it is not uncommon for admins to create/use custom schemas (even not being experts in LDAP RFCs), it might be useful to put together (at the project's convenience) a short list of such considerations for us poor LDAP men. :-)
In this case simply use a decent schema browser which displays everything affected by object class inheritance and point it to your custom object class.
Ciao, Michael.
On Wed, Jun 06, 2012 at 10:25:14PM +0300, Nick Milas wrote:
Since it is not uncommon for admins to create/use custom schemas (even not being experts in LDAP RFCs), it might be useful to put together (at the project's convenience) a short list of such considerations for us poor LDAP men. :-)
I have added a page on object classes to the LDAP Best Practices Wiki:
http://www.ldap-best.org/bin/view/LDAP/ObjectClasses
Comments and corrections are invited :-)
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
Howard Chu -
Jan-Piet Mens -
Michael Ströder -
Nick Milas -
Quanah Gibson-Mount