[Fedora-directory-users] Question about ACI
Clowser, Jeff (Contractor)
jeff_clowser at fanniemae.com
Tue Dec 11 15:58:28 UTC 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20071211/b763f9cc/attachment.htm>
More information about the Fedora-directory-users
mailing list