[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Access Control by Organizational Unit?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Heather Lockridge wrote:
| 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?

Sure. Change the "by dn=" to "by group=", and add the "real name" DNs to
the group you have "empowered", and those DNs will be empowered.

A slightly different example, that should at least show the concept is
what I am using:

# ACL allowing samba domain controllers to add user accounts
access to dn="^(.*,)?ou=People,(dc=.+,?)+$$"
~~        attrs=entry,children,posixAccount,sambaAccount,sambaSamAccount
~~        by dn="uid=root,ou=People,$2" write
~~        by group="cn=Domain Controllers,ou=Group,$2" write
~~        by * read

(there is of course a previous ACL protecting the passwords)

And:
# ldapsearch -x "cn=Domain Controllers" member -LLL
dn: cn=Domain Controllers,ou=Group,dc=ranger,dc=dnsalias,dc=com
member: cn=kiowa.ranger.dnsalias.com,ou=Hosts,dc=ranger,dc=dnsalias,dc=com

So, my host kiowa.ranger.dnsalias.com (which uses DN
cn=kiowa.ranger.dnsalias.com,ou=Hosts,dc=ranger,dc=dnsalias,dc=com, at
least for access via samba) is able to create user accounts).

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

IMHO, it's best to have your DIT follow your administrative structure
rather than anything else (eg. geographical location). BTW, most AD
guides recommend the same.


- --
Buchan Milne                      Senior Support Technician
Obsidian Systems                  http://www.obsidian.co.za
B.Eng                                RHCE (803004789010797)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAq47srJK6UGDSBKcRAg1HAJwKr/WYPHenZlYfiNFflCz9lnWRXwCgqQ1y
fKSblMxH95y0l8HwOxA0deM=
=k4mL
-----END PGP SIGNATURE-----