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