[Fedora-directory-users] Question about ACI
Chun Tat David Chu
beyonddc.storage at gmail.com
Wed Dec 12 02:16:32 UTC 2007
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: [Fedora-directory-users] 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: [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
> >
>
>
> --
> 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>
More information about the 389-users
mailing list