Jeff, I think I understood now. Thanks for your help, I very appreciated. I think look at the error log next time to check on error. :-) On Dec 11, 2007 10:58 AM, Clowser, Jeff (Contractor) < jeff_clowser at fanniemae.com> wrote: > ldap:///self allows user1 to modify it's own entry, not it's own entry > plus subentries, so that aci does not allow you to create subentries like > that. > > I don't really recommend allowing all users to be able to create entries > like this - they can literally create anything (other users, groups, etc) > that may have undesirable effects (security loopholes, duplicate email > addresses, etc). Do you really need to allow this? > > If you really realy do want to do this, you probably will have to create > an aci on each users entry allowing access by that userdn (something like > like your previous aci on the user but with write access to allow what you > want (but again, I really don't think what you want to do is a good idea). > > If user1 is the only user you want to do this (i.e. user1 is an admin), I > would recommend the following: > - Create an ldap group (groupofnames/groupofuniquenames) somewhere outside > of the ou=serviceaccounts branch. > - put an aci on ou=serviceaccounts that allows all access to the > ou=serviceaccounts branch (actually, it would be best if it allowed all > access to uid=*,ou=serviceaccounts,... to avoid members of that group > editing the actual ou=serviceaccounts entry and changing the aci, for > example) if they are a member of that admin group (actually, you should set > targetattr to something like !="aci" and maybe other attributes, so members > of this group can't redefne aci's within that subtree). > - add user1 to that group to make it admin. > > This is assuming you want a subset of users to be able to create entries, > rather than every user. If you must allow all users to create entries, you > should still make targetattr!="aci" at least, so that users can't set random > access controls of the stuff they create. > > One final word - use the error log - it will often tell you more about why > something fails when it fails. > > - Jeff > > > > The electronic mail message you have received and any files transmitted > with it are confidential and solely for the intended addressee(s) attention. > Do not divulge, copy, forward, or use the contents, attachments, or > information without permission of Fannie Mae. Information contained in this > message is provided solely for the purpose stated in the message or its > attachment(s) and must not be disclosed to any third party or used for any > other purpose without consent of Fannie Mae. If you have received this > message and/or any files transmitted with it in error, please delete them > from your system, destroy any hard copies of them, and contact the > sender. *** > * > ** > > ------------------------------ > *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 4:53 PM > *To:* General discussion list for the Fedora Directory server project. > > *Subject:* Re: Question about ACI > > 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 > > > > > -- > 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/20071211/f0649bad/attachment.html
