[Fedora-directory-users] Question about ACI
Chun Tat David Chu
beyonddc.storage at gmail.com
Mon Dec 10 21:53:01 UTC 2007
Thanks for your response Jeff.
I tried with your suggestion and did the following to my LDIF file. I use
the ldapmodify command and logged in as "cn=Directory Manager" to perform
these add operations.
dn: ou=serviceaccounts,dc=test,dc=example,dc=com
changetype: add
objectclass: top
objectclass: organizationalunit
aci:
(targetattr = "*")
(version 3.0;
acl "general user access";
allow (all)
(userdn="ldap:///self")
;)
dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
changetype: add
objectclass: top
objectclass: person
sn: user1
userPassword: testing123
description: This is a test
Now when I use the ldapmodify and logged in as "cn=user1", to perform the
below operation, it failed and gave me an insufficient access (50) error.
Any idea? I think I'm stuck again. :-(
dn: cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
changetype: add
objectclass: top
objectclass: room
Thanks
David
On Dec 10, 2007 3:44 PM, Clowser, Jeff (Contractor) <
jeff_clowser at fanniemae.com> wrote:
> > I think you cleared everything for me. I did misunderstood the
> concept of "ldap:///self", and
> > I agree with you that deny rules should be avoided.
> >
> >ldap:///self refers to the owner of the entry which is the creator of
> the entry. Am I correct on this?
>
> No. ldap:///self means the aci applies to the entry you bind to the
> server as. For example, if you create a rule on ou=serviceaccounts that
> says ldap:///self can change the attribute "userpassword", any user
> under ou=serviceaccounts can change their own password (i.e. if I bind
> as uid=user1,ou=serviceaccounts, I can write to the userpassword
> attribute of user1, and no one elses. If I bind as user2, I can write
> to user2's userpassword attribute, but no one elses). Creator of the
> entry has nothing to do with it. Technically, "owner" is yet something
> else (if an entry has an owner attribute, that typically will contain
> dn's of "owners" of the entry that can manipulate it in some way, but
> that's not automatic - you'd have to create aci's to define that owner
> relationship. LDAP does not otherwise/by default have "owners" of
> entries - Creator != Owner).
>
>
> > After I specified the userdn as
> cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com in my ACI,
> > everything is now working as expected. user1 doesn't have the ability
> to write/add/replace the entry.
> >
> >Below is my new LDIF
> >dn: ou=serviceaccounts,dc=test,dc=example,dc=com
> > changetype: add
> > objectclass: top
> > objectclass: organizationalunit
> >
> >dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
> > changetype: add
> > objectclass: top
> > objectclass: person
> > sn: user1
> > userPassword: testing123
> > description: This is a test
> > aci:
> > (targetattr = "*")
> > (version 3.0;
> > acl "user1";
> > allow (read, search, compare)
> >
> (userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
> > ");)
>
>
> By doing it this way, you are allowing user1 to see it's own account,
> and nothing more - this aci does not allow other users to see user1, and
> does not allow user1 to see other users. Not unreasonable in and of
> itself, but if you create many users where you want identical behavior,
> it's very inefficient - you'll have way to many aci's in the directory
> and maintenance is more difficult.
>
> If you want all users to have these same rights, a better way is to put
> an aci like the following on the ou=serviceaccounts entry (and leave the
> aci off the user):
>
> aci:
> (targetattr = "*")
> (version 3.0;
> acl "user access";
> allow (read, search, compare)
> (userdn="ldap:///self
> ");)
>
> This will allow any user under that branch of the tree that binds to the
> directory to read/search/compare their own entry, in it's entirety,
> without granting them access to anything else, nor granting any other
> user to see their entry. (I'd still recommend that you restrict the
> attribute list further, at least to targetattr!="userpassword" - there's
> usually no need for users to see their password hash, and letting that
> be transmitted over the network so freely is a bit of a security
> concern.)
>
> (Note: if you already have aci's in your tree above this, including the
> default aci's that come with the dir server, you may have other access
> granted that is added to this).
>
> - Jeff
>
>
>
>
> On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) <
> jeff_clowser at fanniemae.com <mailto:jeff_clowser at fanniemae.com> > wrote:
>
>
> Couple things here. First, avoid deny rules if at all possible
> - deny rules always take precedence, so you can *never* override a deny
> rule with something to allow access that has been denied elsewhere.
>
> Second, I think you are misunderstanding how ldap:///self works.
> ldap:///self basically says "These permissions are granted on the
> targetted entry if I bind to the server as that target entry". In your
> case, what your deny rule is saying is that if I bind as user1, I can't
> read, write, or even search for the user1 entry, and as a deny rule, you
> can't create any other rule to ever allow user1 to see his own entry.
>
> So, you've created a rule that says anyone can read/write/search
> to anything under ou=serviceaccounts, *except* user1 can't
> read/write/search on his own entry.
>
> BTW, this seems like a really bad idea. Forget about ACI's and
> implementation for the moment - conceptually, what are you trying to do?
> Who should be able to do what? Are you saying you want anyone except
> user1 to be able to have full access to anything under
> ou=serviceaccounts?
>
> To define your access controls, you should really figure out who
> you want to do what, then define aci's for each thing you want to allow,
> such that they only *allow* just what you need, so you don't need any
> kind of deny rules.
>
> If you want to, for example, allow any user to edit any part of
> just their own record, put something like the following on the
> ou=serviceaccounts entry:
>
> aci:
> (targetattr = "*")
> (version 3.0;
> acl "default aci for service accounts";
> allow (all)
>
> (userdn=ldap:///self)
> ;)
>
> This says that if I bind as a user under ou=serviceaccounts, I
> have full read/write/search access to the entry I bound as (i.e. my
> account).
> However, I'd recommend making even that more restrictive (for
> example, if all they really need to write to is their password, create
> one aci to allow them to read/search all attributes except the
> userpassword, and one to allow write to the userpassword with userdn of
> ldap:///self), etc. If you want all users to read other users entries,
> create another aci that allows search/read access to ldap:///anyone (and
> at least make it targetattr!="userpassword"), and so on..
>
> - Jeff
>
>
> ________________________________
>
> From: fedora-directory-users-bounces at redhat.com
> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Chun Tat
> David Chu
> Sent: Monday, December 10, 2007 11:37 AM
> To: fedora-directory-users at redhat.com
> Subject: Re: [Fedora-directory-users] Question about ACI
>
>
> Hi guys,
>
> Please see below for my original question.
>
> I spend a little more time reading "Chapter 6 - Managing Access
> Control" from the RH Administrator Guide. At first, I thought it was my
> placement of ACI that was wrong, but it seems like that's not the case
> from what I read. The book stated that "The precedence rule that
> applies is that ACIs that deny access take precedence over ACIs that
> allow access." If my root allows everything and then my leaf denies
> everything then I don't see why the add operation that I mentioned below
> should work.
>
> Let me clear up a little more in case there's any confusion.
> The ou=serviceaccounts and cn=user1 entry is created by the
> "cn=Directory Manager" user. In my test, the root (ou=serviceaccounts),
> I specified an ACI that allows all user to do anything. In my leaf
> (cn=user1), I specified an ACI that denies everything for user1 by
> defining the bind rule as (ldap:///self).
>
> When I logged in as user1, I'm able to add entry in the cn=user1
> context. I am not sure why because I thought that user1 shouldn't have
> any privilege to do anything due to my specified ACI.
>
> Any idea? Am I missing some obvious?
>
> Thanks!
>
> David
>
>
> On Dec 7, 2007 6:28 PM, Chun Tat David Chu
> <beyonddc.storage at gmail.com> wrote:
>
>
> Hi guys,
>
> I am trying to create an organizational unit and an user
> with ACI, but it looks like my ACI is not defined correctly.
> Below is my ldif.
>
> dn: ou=serviceaccounts,dc=test,dc=example,dc=com
> changetype: add
> objectclass: top
> objectclass: organizationalunit
> aci:
> (targetattr = "*")
> (version 3.0;
> acl "default aci for service accounts";
> allow (all)
> (userdn="ldap:///anyone")
> ;)
>
> dn:
> cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
> changetype: add
> objectclass: top
> objectclass: person
> sn: user1
> userPassword: testing123
> description: This is a test
> aci:
> (targetattr = "*")
> (version 3.0;
> acl "user1";
> deny (all)
> (userdn="ldap:///self")
> ;)
>
> I create an organizational unit that allows all users to
> modify it, then I create user1 that denies everything.
> I then use the below LDIF to perform a LDAP add
> operation.
>
> dn:
> cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com
> changetype: add
> objectclass: top
> objectclass: room
>
> I use this ldapmodify command to perform the add
> operation
> ldapmodify -h hostname -p 1389 -D
> "cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f
> my_test.ldif -x
>
> The add operation succeeded unexpectedly. The result
> that I'm looking for should be not enough privilege to perform add
> operation.
>
> Anyone knows what's wrong with my ACI setup?
>
> Thanks!
>
> David
>
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20071210/1c9019cc/attachment.htm>
More information about the Fedora-directory-users
mailing list