Thanks Jeff! 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? 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 ");) Thanks, David On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) < 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: 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: tscei.obs > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20071210/05124168/attachment.html
