Hi,
I am trying to build acls suitable to my setup:
I have posix accounts in ou=people,ou=unix,dc=acme,dc=org and some more information about users (defined in an object class called "acmeUserAccount") in ou=people,ou=useradm,dc=acme,dc=org. Each posix account has a corresponding record in ou=useradm. These record pairs are connected by having the uid attribute defined equally.
Now I want to restrict access to the ou=useradm tree, but not the ou=unix tree. As far as I can understand, there are at least two ways to do so:
1. using something like access to dn.subtree="ou=useradm,dc=acme,dc=org" by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This works as expected - giving write access to members of useradmins, and read access to members of consultants.
2. using something like access to attrs=@acmeUserAccount by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This also works as expected with regards to acmeUserAccount, but has funny side effects on ou=unix.
To my understanding these two methods should have the same effect, as I only have records of type acmeUserAccount underneth ou=useradm. But: if I use 2), users don't have access to their data underneth ou=unix. Only the two groups mentioned have access to ou=unix as defined for acmeUserAccount. I read that using attrs=@someObjectClass affects also attributes that are defined in object classes that someObjectClass inherits from. My object class is defined as follows:
objectclass ( managementOC:1 NAME 'acmeUserAccount' DESC 'Attributes needed for acme user management' SUP top STRUCTURAL MUST ( uid $ email ) MAY ( $ givenName $ surname $ federalState ) )
So it should inherit only from top, which I thought of as some abstract class without any attributes. Can someone explain this behaviour to me?
Regards, Isaac
--On Tuesday, November 16, 2010 6:48 PM +0100 Isaac Hailperin hailperin@zib.de wrote:
Hi,
I am trying to build acls suitable to my setup:
I have posix accounts in ou=people,ou=unix,dc=acme,dc=org and some more information about users (defined in an object class called "acmeUserAccount") in ou=people,ou=useradm,dc=acme,dc=org. Each posix account has a corresponding record in ou=useradm. These record pairs are connected by having the uid attribute defined equally.
Now I want to restrict access to the ou=useradm tree, but not the ou=unix tree. As far as I can understand, there are at least two ways to do so:
- using something like
access to dn.subtree="ou=useradm,dc=acme,dc=org" by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This works as expected - giving write access to members of useradmins, and read access to members of consultants.
- using something like
access to attrs=@acmeUserAccount by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This also works as expected with regards to acmeUserAccount, but has funny side effects on ou=unix.
I would change 2 to be:
access to dn.subtree="ou=useradm,dc=acme,dc=org" attrs=@acmeUserAccount
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On 11/16/2010 07:04 PM, Quanah Gibson-Mount wrote:
--On Tuesday, November 16, 2010 6:48 PM +0100 Isaac Hailperin hailperin@zib.de wrote:
Hi,
I am trying to build acls suitable to my setup:
I have posix accounts in ou=people,ou=unix,dc=acme,dc=org and some more information about users (defined in an object class called "acmeUserAccount") in ou=people,ou=useradm,dc=acme,dc=org. Each posix account has a corresponding record in ou=useradm. These record pairs are connected by having the uid attribute defined equally.
Now I want to restrict access to the ou=useradm tree, but not the ou=unix tree. As far as I can understand, there are at least two ways to do so:
- using something like
access to dn.subtree="ou=useradm,dc=acme,dc=org" by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This works as expected - giving write access to members of useradmins, and read access to members of consultants.
- using something like
access to attrs=@acmeUserAccount by group="cn=useradmins,ou=group,ou=unix,dc=acme,dc=org" write by group="cn=consultants,ou=group,ou=unix,dc=acme,dc=org" read by * none This also works as expected with regards to acmeUserAccount, but has funny side effects on ou=unix.
I would change 2 to be:
access to dn.subtree="ou=useradm,dc=acme,dc=org" attrs=@acmeUserAccount
That works without sideeffects. Thank you :-) But I still don't understand why 2 has side effects.
Isaac
--On Wednesday, November 17, 2010 12:39 PM +0100 Isaac Hailperin hailperin@zib.de wrote:
access to dn.subtree="ou=useradm,dc=acme,dc=org" attrs=@acmeUserAccount
That works without sideeffects. Thank you :-) But I still don't understand why 2 has side effects.
@acmeUserAccount by itself is going to affect access to all the attributes that are in that objectClass. It's really just shorthand for that list of attributes in that objectClass. So if you used the some of the same attributes in your other tree, they would be affected as well. By adding the specific subtree restriction, then you no longer affect those attributes elsewhere.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Ok, I found my problem: I was ldap-searching for uid=username, but did not realise that since uid is also defined in acmeUserAccount, its restricted everywhere. If I would search for cn=username, that would work with access to attrs=@acmeUserAccount. That means I would get results form the unix tree.
So, sorry for bothering you, and thanks a lot for helping me think with this discussion ;-)
Isaac
On 11/17/2010 06:54 PM, Quanah Gibson-Mount wrote:
--On Wednesday, November 17, 2010 12:39 PM +0100 Isaac Hailperin hailperin@zib.de wrote:
access to dn.subtree="ou=useradm,dc=acme,dc=org" attrs=@acmeUserAccount
That works without sideeffects. Thank you :-) But I still don't understand why 2 has side effects.
@acmeUserAccount by itself is going to affect access to all the attributes that are in that objectClass. It's really just shorthand for that list of attributes in that objectClass. So if you used the some of the same attributes in your other tree, they would be affected as well. By adding the specific subtree restriction, then you no longer affect those attributes elsewhere.
--Quanah
openldap-technical@openldap.org
-
Isaac Hailperin -
Quanah Gibson-Mount