Re: Access Control by Organizational Unit?

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Heather Lockridge writes:
> Is the ssf=128 a "Seecurity Strength Factor" which
> means the same as self write?

Huh.  That needs better documentation.  No, ssf=128 means that the
access is only granted over TLS/SSL connections.  So it doesn't work to
e.g. bind with the correct password over an unencrypted connection.

>> 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.

Write access to _already existing_ entries in the OU.
At least that's what I seem to remember it does; I haven't
actually checked if the "attr=children" rule is necessary.

> I am not clear about what the second one does,
> the one with "attr=children"

Access to add and delete children of the OU.

>> What the first directive should look like depends on who should be
>> able to access userPassword in which manner.  (...)
>
> I certainly do
> want the "Directory Manager" to be able to
> update/change the password after creating it.

OK, then keep it as it is.

> 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.

I meant to delete 'dn.regex="[^,]*,(ou=.*)"' in front of
attr=userPassword, and 'by dn.regex="cn=Directory Manager,$1" ssf=128
write'.  But never mind, you want to keep them.

OTOH, maybe you want to delete 'self ssf=128 write', if _users_ should
not be able to update their passwords:-)

> 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?

I may have missed a way, but the only way I can think of is
to use OpenLDAPACI.

> 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. 

If both Directory Manager,Oregon,Engineering and Directory
Manager,Engineering should have access, use something like

  access to  dn.regex="[^,]*,(ou=.*,(ou=.*))"
         by  dn.regex="cn=Directory Manager,$1"  write
         by  dn.regex="cn=Directory Manager,$2"  write
         by  *                                   read

  access to  dn.regex="[^,]*,(ou=.*)"
         by  dn.regex="cn=Directory Manager,$1"  write
         by  *                                   read

If there is no Directory Manager,Oregon,Engineering, maybe
you want

  access to  dn.regex=".*,(ou=.*)"
         by  dn.regex="cn=Directory Manager,$1"  write
         by  *                                   read

These regexps assume there is no OU above Engineering.  If your
organizational structure is more complicated, such ACLs will quickly get
hairy and error-prone, so maybe the OpenLDAPaci approach is better.

OpenLDAPaci is described in
<http://www.openldap.org/faq/data/cache/634.html>, though that is a bit
outdated.  It does not mention that 'public' grants everyone access,
e.g. 'OpenLDAPaci: 2.0#entry#grant;c,r,s,x;[all],[entry]#public#'.

-- 
Hallvard