[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
complex ACLs without groups (OpenLDAP 1.2.11)
- To: openldap-software@OpenLDAP.org
- Subject: complex ACLs without groups (OpenLDAP 1.2.11)
- From: "Kyle F. Downey" <kdowney@amberarcher.com>
- Date: Fri, 23 Mar 2001 16:34:03 -0500
- Organization: Amber Archer Consulting Co., Inc.
- User-agent: Mozilla/5.0 (X11; U; Linux 2.4.2 i686; en-US; 0.8) Gecko/20010217
Hello,
I've been tearing out my hair over this for hours. I think I just don't
understand ACLs well enough to tackle more than the basic case that I've
found in examples all over the Web.
I am setting up a directory that has information about our employees as
well as information about our clients. We want the clients to be able to
edit their own information on-line, read information about us, but not
see the
other clients. Basically, it's an LDAP extranet. The structure looks
like this:
dc=amberarcher, dc=com
cn=Directory Manager
ou=People
cn=Kyle Downey
ou=Clients
dc=com
dc=foosystems
cn=Directory Manager
ou=People
cn=An Employee 1
cn=An Employee 2
dc=barsystems
cn=Directory Manager
ou=People
cn=An Employee 1
cn=An Employee 2
Here are the rules:
* we want An Employee 1 and 2 at foosystems to be able to see each other
and edit their own entries
* we want don't want any employees of clients to see each other, or even
the company names
* we want any employee of any company to be able to see the People of
our company, and we
want our employees to be able to see all employees of all
companies--ours and as well as clients
* we want Directory Managers of clients to be able to edit anything
under their subtree, and
our top-level Directory Manager to be able to edit anybody
Phew. So here's my start:
defaultaccess none
# anyone can edit their own password
access to attr=userpassword
by self write
by * none
# anyone logged in can read information in the
# Amber Archer tree (eventually we'll have to
# restrict some attributes)
access to dn="ou=People,dc=amberarcher,dc=com"
by dn=".+" read
by * none
# client Directory Managers can edit anything under their
# tree, and client users can read any entry in their company
# and edit themselves
access to
dn="cn=[^,]+,dc=([^,]+),dc=([^,]+),ou=Clients,dc=amberarcher,dc=com"
by dn="cn=[^,]+,dc=$1,dc=$2,ou=Clients,dc=amberarcher,dc=com" read
by self write
by dn="cn=Directory
Manager,dc=$1,dc=$2,ou=Clients,dc=amberarcher,dc=com" write
(I realize this isn't the full set of rules, but I think if I can figure
out what's wrong with this
primary one, then I can fix the rest myself.)
When I run the LDAP browser, all I see is the People subtree for Amber
Archer--so at least one
rule works--if I'm logged in as an employee or Directory Manager of a
client. If I add a rule like
this below the last rule
access to dn="ou=Clients,dc=amberarcher,dc=com"
by dn=".+" read
then I give they can see the Client subtree...but I also see all other
client.
One potential helpful route was that I managed to get someone logged in
as a ".com" not
able to see a ".org" subtree by writing a rule just up to the first dc.
I am thinking I might be
able to solve this by doing it one component at a time, but I am
wondering if there's a way to
do it with a single rule like the above.
I know the OpenLDAP FAQ has an example of using groups, but I would
rather do this
without groups. Until OpenLDAP supports editing ACLs "on-line," I don't
want to use
any security mechanism that might require a change to slapd.conf every
time we add a new
client, say.
Thanks in advance.
--kd