Thanks Jeff!<br><br>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.<br><br>ldap:///self refers to the owner of the entry which is the creator of the entry.  Am I correct on this?
<br><br>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.<br><br>Below is my new LDIF
<br>dn: ou=serviceaccounts,dc=test,dc=example,dc=com<br> changetype: add<br> objectclass: top<br> objectclass: organizationalunit<br><br>dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<br> changetype: add<br> objectclass: top
<br> objectclass: person<br> sn: user1<br> userPassword: testing123<br> description: This is a test<br> aci:<br>  (targetattr = "*")<br>  (version 3.0;<br>  acl "user1";<br>  allow (read, search, compare)
<br>  (userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<br>  ");)<br><br>Thanks,<br><br>David<br><br><div class="gmail_quote">On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) <<a href="mailto:jeff_clowser@fanniemae.com">
jeff_clowser@fanniemae.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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.</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">Second, I think 
you are misunderstanding how <a>ldap:///self</a> 
works.  <a>ldap:///self</a> 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.</font> </span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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.</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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?  
</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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.</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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:</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"><font color="#000000" face="Times New Roman" size="3"><div class="Ih2E3d">aci:<br> (targetattr = 
"*")<br> (version 3.0;<br> acl "default aci for service 
accounts";<br> allow (all)<br></div> (userdn=<a>ldap:///self</a>) 
<br> ;)</font><br></font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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).</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2">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 <a>ldap:///self</a>), etc.  
If you want all users to read other users entries, create another aci that 
allows search/read access to <a>ldap:///anyone</a> (and at least make it 
targetattr!="userpassword"), and so on..</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"> - 
Jeff</font></span></div>
<div dir="ltr" align="left" lang="en-us"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left" lang="en-us"><span> </span></div>
<div dir="ltr" align="left" lang="en-us">
<hr>
</div>
<div dir="ltr" align="left" lang="en-us"><font face="Tahoma" size="2"><b>From:</b> <a href="mailto:fedora-directory-users-bounces@redhat.com" target="_blank">fedora-directory-users-bounces@redhat.com</a> 
[mailto:<a href="mailto:fedora-directory-users-bounces@redhat.com" target="_blank">fedora-directory-users-bounces@redhat.com</a>] <b>On Behalf Of </b>Chun Tat 
David Chu<br><b>Sent:</b> Monday, December 10, 2007 11:37 AM<br><b>To:</b> 
<a href="mailto:fedora-directory-users@redhat.com" target="_blank">fedora-directory-users@redhat.com</a><br><b>Subject:</b> Re: 
[Fedora-directory-users] Question about ACI<br></font><br></div><div><div></div><div class="Wj3C7c">
<div></div>Hi guys,<br><br>Please see below for my original question.<br><br>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. <br><br>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). <br><br>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.<br><br>Any idea?  Am I missing some obvious? 
<br><br>Thanks!<br><br>David<br><br>
<div class="gmail_quote">On Dec 7, 2007 6:28 PM, Chun Tat David Chu <<a href="mailto:beyonddc.storage@gmail.com" target="_blank">beyonddc.storage@gmail.com</a>> 
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi 
  guys,<br><br>I am trying to create an organizational unit and an user with 
  ACI, but it looks like my ACI is not defined correctly.<br>Below is my 
  ldif.<br><br>dn: ou=serviceaccounts,dc=test,dc=example,dc=com<br>changetype: 
  add <br>objectclass: top<br>objectclass: 
  organizationalunit<br>aci:<br> (targetattr = "*")<br> (version 
  3.0;<br> acl "default aci for service accounts";<br> allow 
  (all)<br> (userdn="ldap:///anyone") <br> ;)<br><br>dn: 
  cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<br>changetype: 
  add<br>objectclass: top<br>objectclass: person<br>sn: 
  tscei.obs<br>userPassword: testing123<br>description: This is a 
  test<br>aci:<br> (targetattr = "*")<br> (version 3.0;<br> acl 
  "user1";<br> deny 
  (all)<br> (userdn="ldap:///self")<br> ;)<br><br>I create an 
  organizational unit that allows all users to modify it, then I create user1 
  that denies everything. <br>I then use the below LDIF to perform a LDAP add 
  operation.<br><br>dn: 
  cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<br>changetype: 
  add<br>objectclass: top<br>objectclass: room<br><br>I use this ldapmodify 
  command to perform the add operation <br>ldapmodify -h hostname -p 1389 -D 
  "cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f 
  my_test.ldif -x<br><br>The add operation succeeded unexpectedly.  The 
  result that I'm looking for should be not enough privilege to perform add 
  operation. <br><br>Anyone knows what's wrong with my ACI 
  setup?<br><br>Thanks!<br><font color="#888888"><br>David<br></font></blockquote></div><br></div></div></div>
<br>--<br>Fedora-directory-users mailing list<br><a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users" target="_blank">
https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br><br></blockquote></div><br>