<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3199" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2><A href="ldap:///self">ldap:///self</A> 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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>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?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>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).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>If user1 is the only user you want to do this (i.e. user1
is an admin), I would recommend the following:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>- Create an ldap group (groupofnames/groupofuniquenames)
somewhere outside of the ou=serviceaccounts branch.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>- 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).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>- add user1 to that group to make it
admin.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2>One final word - use the error log - it will often tell you
more about why something fails when it fails.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2> - Jeff</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=738274115-11122007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV><!-- Converted from text/rtf format -->
<P align=left><SPAN lang=en-us><FONT face=Arial size=1>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. <U><B></B></U></FONT><U><B><BR></P></B></U><B></B></SPAN>
<DIV> </DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> fedora-directory-users-bounces@redhat.com
[mailto:fedora-directory-users-bounces@redhat.com] <B>On Behalf Of </B>Chun Tat
David Chu<BR><B>Sent:</B> Monday, December 10, 2007 4:53 PM<BR><B>To:</B>
General discussion list for the Fedora Directory server
project.<BR><B>Subject:</B> Re: [Fedora-directory-users] Question about
ACI<BR></FONT><BR></DIV>
<DIV></DIV>Thanks for your response Jeff.<BR><BR>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.<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 "general user access"; <BR> allow
(all)<BR> (userdn="ldap:///self")<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: user1<BR>userPassword:
testing123 <BR>description: This is a test<BR><BR>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. :-( <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>Thanks<BR><BR>David<BR><BR>
<DIV class=gmail_quote>On Dec 10, 2007 3:44 PM, Clowser, Jeff (Contractor) <
<A href="mailto:jeff_clowser@fanniemae.com">jeff_clowser@fanniemae.com</A>>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV class=Ih2E3d>> I think you cleared everything for me. I did
misunderstood the<BR>concept of "ldap:///self", and<BR>> 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 <BR>the entry. Am I correct
on this?<BR><BR></DIV>No. ldap:///self means the aci applies to the
entry you bind to the<BR>server as. For example, if you create a rule on
ou=serviceaccounts that<BR>says ldap:///self can change the attribute
"userpassword", any user <BR>under ou=serviceaccounts can change their own
password (i.e. if I bind<BR>as uid=user1,ou=serviceaccounts, I can write to
the userpassword<BR>attribute of user1, and no one elses. If I bind as
user2, I can write<BR>to user2's userpassword attribute, but no one elses).
Creator of the <BR>entry has nothing to do with it. Technically,
"owner" is yet something<BR>else (if an entry has an owner attribute, that
typically will contain<BR>dn's of "owners" of the entry that can manipulate it
in some way, but <BR>that's not automatic - you'd have to create aci's to
define that owner<BR>relationship. LDAP does not otherwise/by default
have "owners" of<BR>entries - Creator != Owner).<BR>
<DIV class=Ih2E3d><BR><BR>> After I specified the userdn
as<BR>cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com in my ACI,<BR>>
everything is now working as expected. user1 doesn't have the
ability<BR>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>><BR>(userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com<BR>>
");)<BR><BR><BR></DIV>By doing it this way, you are allowing user1 to
see it's own account, <BR>and nothing more - this aci does not allow other
users to see user1, and<BR>does not allow user1 to see other users. Not
unreasonable in and of<BR>itself, but if you create many users where you want
identical behavior, <BR>it's very inefficient - you'll have way to many aci's
in the directory<BR>and maintenance is more difficult.<BR><BR>If you want all
users to have these same rights, a better way is to put<BR>an aci like the
following on the ou=serviceaccounts entry (and leave the <BR>aci off the
user):<BR>
<DIV class=Ih2E3d><BR> aci:<BR> (targetattr = "*")<BR> (version
3.0;<BR></DIV> acl "user access";<BR> allow (read, search,
compare)<BR> (userdn="ldap:///self<BR> ");) <BR><BR>This will allow
any user under that branch of the tree that binds to the<BR>directory to
read/search/compare their own entry, in it's entirety,<BR>without
granting them access to anything else, nor granting any other <BR>user to see
their entry. (I'd still recommend that you restrict the<BR>attribute list
further, at least to targetattr!="userpassword" - there's<BR>usually no need
for users to see their password hash, and letting that <BR>be transmitted over
the network so freely is a bit of a security<BR>concern.)<BR><BR>(Note: if you
already have aci's in your tree above this, including the<BR>default aci's
that come with the dir server, you may have other access <BR>granted that is
added to this).<BR><FONT color=#888888><BR> - Jeff<BR></FONT>
<DIV class=Ih2E3d><BR><BR><BR><BR>On Dec 10, 2007 12:48 PM, Clowser, Jeff
(Contractor) <<BR></DIV>
<DIV>
<DIV></DIV>
<DIV class=Wj3C7c><A
href="mailto:jeff_clowser@fanniemae.com">jeff_clowser@fanniemae.com</A>
<mailto:<A
href="mailto:jeff_clowser@fanniemae.com">jeff_clowser@fanniemae.com</A>>
> wrote:<BR><BR><BR> Couple things here.
First, avoid deny rules if at all possible <BR>- deny rules always take
precedence, so you can *never* override a deny<BR>rule with something to allow
access that has been denied elsewhere.<BR><BR>
Second, I think you are misunderstanding how ldap:///self works.
<BR>ldap:///self basically says "These permissions are granted on
the<BR>targetted entry if I bind to the server as that target entry". In
your<BR>case, what your deny rule is saying is that if I bind as user1, I
can't <BR>read, write, or even search for the user1 entry, and as a deny rule,
you<BR>can't create any other rule to ever allow user1 to see his own
entry.<BR><BR> So, you've created a rule that says
anyone can read/write/search <BR>to anything under ou=serviceaccounts,
*except* user1 can't<BR>read/write/search on his own entry.<BR><BR>
BTW, this seems like a really bad idea. Forget about
ACI's and<BR>implementation for the moment - conceptually, what are you trying
to do? <BR>Who should be able to do what? Are you saying you want anyone
except<BR>user1 to be able to have full access to anything
under<BR>ou=serviceaccounts?<BR><BR> To define your
access controls, you should really figure out who <BR>you want to do what,
then define aci's for each thing you want to allow,<BR>such that they only
*allow* just what you need, so you don't need any<BR>kind of deny
rules.<BR><BR> If you want to, for example, allow
any user to edit any part of <BR>just their own record, put something like the
following on the<BR>ou=serviceaccounts entry:<BR><BR>
aci:<BR>
(targetattr = "*")<BR> (version 3.0;<BR>
acl "default aci for service accounts"; <BR>
allow (all)<BR><BR>
(userdn=ldap:///self)<BR> ;)<BR><BR>
This says that if I bind as a user under ou=serviceaccounts,
I<BR>have full read/write/search access to the entry I bound as (i.e .
my<BR>account).<BR> However, I'd recommend making
even that more restrictive (for<BR>example, if all they really need to write
to is their password, create<BR>one aci to allow them to read/search all
attributes except the <BR>userpassword, and one to allow write to the
userpassword with userdn of<BR>ldap:///self), etc. If you want all users
to read other users entries,<BR>create another aci that allows search/read
access to ldap:///anyone (and <BR>at least make it
targetattr!="userpassword"), and so on..<BR><BR> -
Jeff<BR><BR><BR>________________________________<BR><BR>
From: <A
href="mailto:fedora-directory-users-bounces@redhat.com">fedora-directory-users-bounces@redhat.com
</A><BR>[mailto:<A
href="mailto:fedora-directory-users-bounces@redhat.com">fedora-directory-users-bounces@redhat.com</A>]
On Behalf Of Chun Tat<BR>David Chu<BR> Sent: Monday,
December 10, 2007 11:37 AM<BR> To: <A
href="mailto:fedora-directory-users@redhat.com">fedora-directory-users@redhat.com</A><BR>
Subject: Re: [Fedora-directory-users] Question about
ACI<BR><BR><BR> Hi guys,<BR><BR>
Please see below for my original question. <BR><BR>
I spend a little more time reading "Chapter 6 - Managing
Access<BR>Control" from the RH Administrator Guide. At first, I thought
it was my<BR>placement of ACI that was wrong, but it seems like that's not the
case <BR>from what I read. The book stated that "The precedence rule
that<BR>applies is that ACIs that deny access take precedence over ACIs
that<BR>allow access." If my root allows everything and then my leaf
denies <BR>everything then I don't see why the add operation that I mentioned
below<BR>should work.<BR><BR> Let me clear up a
little more in case there's any confusion.<BR>The ou=serviceaccounts and
cn=user1 entry is created by the <BR>"cn=Directory Manager" user. In my
test, the root (ou=serviceaccounts),<BR>I specified an ACI that allows all
user to do anything. In my leaf<BR>(cn=user1), I specified an ACI that
denies everything for user1 by <BR>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<BR>context. I am not sure why
because I thought that user1 shouldn't have<BR>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><BR>
On Dec 7, 2007 6:28 PM, Chun Tat David Chu<BR><<A
href="mailto:beyonddc.storage@gmail.com">beyonddc.storage@gmail.com </A>>
wrote:<BR><BR><BR> Hi
guys,<BR><BR> I am
trying to create an organizational unit and an user<BR>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:<BR>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>
deny (all)<BR>
(userdn="ldap:///self")<BR>
;)<BR><BR>
I create an organizational unit that allows
all users to <BR>modify it, then I create user1 that denies
everything.<BR> I then
use the below LDIF to perform a LDAP add<BR>operation.<BR><BR>
dn:<BR>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<BR>operation<BR>
ldapmodify -h hostname -p 1389 -D
<BR>"cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123
-f<BR>my_test.ldif -x<BR><BR>
The add operation succeeded unexpectedly. The result<BR>that I'm
looking for should be not enough privilege to perform add
<BR>operation.<BR><BR>
Anyone knows what's wrong with my ACI setup?<BR><BR>
Thanks!<BR><BR>
David<BR><BR><BR><BR><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><BR><BR><BR><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></DIV></DIV></BLOCKQUOTE></DIV><BR></BODY></HTML>