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: 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://lists.fedoraproject.org/pipermail/389-users/attachments/20071210/1c9019cc/attachment.html
