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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20071210/c56d3271/attachment.html
