hello all,
i am working on my first installation of openldap, so please bear with me. i assure you in advance i have been digging through the manual and only resort to the mailing list after exhausting ability to understand how to write the access portion of slapd.conf by reading the administration guide. in particular, if some of the language i use in the email is a bit hazy, im trying my best.
anyway here is the background; i have designed the tree structure as follows beneath the rootdn there are organizationalUnit objects and beneath those there are organizationalPerson objects. im trying to write the access control with the following *general* goal. the goal is authenticated users can only have read access to organizationalPerson objects beneath the organizationalUnit containing the organizationalPerson object the user authenticated against. the authenticated users should not be able to view any organizationalUnits except the one containing the organizationalPerson object they authenticated against.
so now i will come to the problem. there is no way (that ive found in the administration guide) to access the entry a user authenticated against when writing the access control rules. therefore in order to support the above general goal i must hardcode the value of the ou attribute into an access rule for every organizationalUnit in the tree. obviously this is an maintenance nightmare as i would need to support modification of the slapd.conf file if i wanted to create an interface where administrators could add / remove organizationalUnits or modify the value of their ou attribute.
please tell me there is a way to analyze the values of attributes in the entry an authenticated user authenticated against, or that there is some other way to tackle the problem. i am happy to send the relevant portions of slapd.conf.
thanks,
-nathan
--On December 4, 2007 5:52:11 PM -0500 Nathan Nobbe quickshiftin@gmail.com wrote:
hello all,
i am working on my first installation of openldap, so please bear with me. i assure you in advance i have been digging through the manual and only resort to the mailing list after exhausting ability to understand how to write the access portion of slapd.conf by reading the administration guide. in particular, if some of the language i use in the email is a bit hazy, im trying my best.
anyway here is the background; i have designed the tree structure as follows beneath the rootdn there are organizationalUnit objects and beneath those there are organizationalPerson objects.
Just on a general note, I'd say this is a fairly poor design decision. Given the way that people often shift organizations, or work for more then one, I've found that putting organizations in their own tree, and then people in their own tree works a lot better, and makes ACLs easier.
In answer to your question, however, you may find that using sets helps with some of what you want to do.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
thanks for your reply Quanah.
On Dec 5, 2007 1:26 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
Just on a general note, I'd say this is a fairly poor design decision.
i have not read any material on ideal directory layout. can you refer me to good resource? the design i have created is based only on intuition. that, and the schema reference available in phpLdapAdmin. truth be told, ive found the documentation in the openldap administration guide only marginally helpful. at least i havent seen much in there about ldap itself; the guide seems to presume preexisting knowledge of ldap; of which mine is scant :)
Given the way that people often shift organizations, or work for more then
one, I've found that putting organizations in their own tree, and then people in their own tree works a lot better, and makes ACLs easier.
in our circumstance i think it will be rare that people will work for multiple organizations. if there is such a case then we have bad data in our application. however, we will be driving updates of the ldap directory through a proprietary cms. this system will then dispatch the changes in the sql schema behind the app to the ldap directory. synchronization will only be in this direction. my understanding is that this is a common use of ldap. we only want to expose access to some of the data in our sql database through ldap. am i of the wrong impression? if i were to have a tree for organizationalUnit objects and another for organizationalPerson objects, what would the ideal root objectClass of those trees?
In answer to your question, however, you may find that using sets helps
with some of what you want to do.
what are sets in the context of ldap?
thanks,
-nathan
On Wednesday 05 December 2007 00:52:11 Nathan Nobbe wrote:
so now i will come to the problem. there is no way (that ive found in the administration guide) to access the entry a user authenticated against when writing the access control rules.
But the reverse is possible (using a regex based ACL, with dn.regex in the "what", and dn.extact,expand in "who", with positional paramters in the who tat are expanded to the values from the regex groups), which as far as I can tell should be sufficient for you.
therefore in order to support the above general goal i must hardcode the value of the ou attribute into an access rule for every organizationalUnit in the tree. obviously this is an maintenance nightmare as i would need to support modification of the slapd.conf file if i wanted to create an interface where administrators could add /
If you had to update ACLs, writing to slapd.conf is not strictly necessary, as back-config would allow you to do it via LDAP.
remove organizationalUnits or modify the value of their ou attribute.
Regards, Buchan
openldap-software@openldap.org
-
Buchan Milne -
Nathan Nobbe -
Quanah Gibson-Mount