[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Access Control by Organizational Unit?
Thank you for the suggestion, I have some comments /
questions below
>
> This is untested, but: You can give the manager
> entries below each OU
> the same RDN, e.g. cn=Directory Manager, and use an
> access controls
> like:
>
> access to dn.regex="[^,]*,(ou=.*)"
> attr=userPassword
> by self
> ssf=128 write
> by dn.regex="cn=Directory Manager,$1"
> ssf=128 write
> by *
> ssf=128 auth
>
Is the ssf=128 a "Seecurity Strength Factor" which
means the same as self write?
> access to dn.regex="[^,]*,(ou=.*)"
> by dn.regex="cn=Directory Manager,$1" write
> by * read
>
> access to dn.regex="(ou=.*)" attr=children
> by dn.regex="cn=Directory Manager,$1" write
> by * read
>
> The "[^,]*," says that the directive applies to
> entries directly below
> the ou. It will not work if the OU contains entries
> with "," in their
> RDN. Or if you want to give the manager access to
> subtrees below the
> OU, and you do not have OUs below OUs, use
> 'dn.regex=.*,(ou=.*)'. If
Why are there two "access to" statements? The first
seems to say, "let the person who has the cn of
"Directory Manager" have write access to anything in
the OU of which he is a part, and let others read
only. I am not clear about what the second one does,
the one with "attr=children"
> that does not fit your organizational structure, I
> can probably come up
> with a more complicated regex if you tell me what it
> should match.
>
> The $1 matches the first "()" in the "to" phrase,
> i.e. DN of the OU.
>
> What the first directive should look like depends on
> who should
> be able to access userPassword in which manner. The
> important
> point is to ensure that unauthorized users will not
> see userPassword.
> If the manager does not need to be able to update it
> (after creating
> the entry), you can delete the parts about dn.regex
> for userPassword.
Perhaps this just above has something to do with why
there are two "access to" statements? I certainly do
want the "Directory Manager" to be able to
update/change the password after creating it. I am
not sure what you refer to when you say "delete the
parts about dn.regex for userPassword" as I don't see
those above.
While I could use Directory Manager for the cn of the
empowered person in each OU, is there a way to do all
this with their real name?
Lastly, I am thinking of OU in the context of
department like Engineering, Fabrication, etc. It
might be necessary to have an OU in Engineering for
New Mexico, and one for Oregon. But, in this case,
the one "Directory Manager" fr the Engineering OU
would need to be able to manage all entries in the
Engineering OU as well as the the sub OU of New Mexico
and the sub OU of Oregon.
Thanks for being so helpful.
HeatherL
>
> The Directory Manager entry could be something like
>
> dn: cn=Directory Manager,ou=foobar,dc=urgle,dc=com
> cn: Directory Manager
> objectClass: organizationalRole
> objectClass: simpleSecurityObject
> userPassword: {CRYPT}some-crypt
> # other attributes which you might add for
> informational purposes
> roleOccupant: uid=whoops,ou=foobar,dc=urgle,dc=com
> telephoneNumber: +1 234 5678
> description: Manager of the LDAP directory for
> this department
>
> Another way would be to register in each entry an
> OpenLDAPaci attribute
> which gives access to the manager of the OU, and
> ACIs for the OUs that
> the manager can update the children. But if someone
> else becomes
> directory manager for an OU, you must then change
> all the ACIs for that
> OU - unless you use a special name like Directory
> Manager for the
> manager. Also you need an 'access ... by aci'
> directive in slapd.conf,
> and to configure with '--enable-aci'.
>
> > Does anyone have any examples of how to do this
> while
> > allowing the overall ldap-admin acces to all? Or
> a
> > pointer to some (any) examples?
>
> The DN in a database definition's a 'rootdn' has
> full access to the
> database regardless of access controls. The rootdn
> entry need not
> actually exist in the database, though it must be a
> DN below the
> database's suffix.
>
> --
> Hallvard
__________________________________
Do you Yahoo!?
SBC Yahoo! - Internet access at a great low price.
http://promo.yahoo.com/sbc/