Dear all,
I have a question regarding my openldap DIT design. My design so far is based on the model: ou=people,dc=example,dc=com. It is very possible that I'll have to be able to find attributes of people belonging to some specific group (eg, student, postgrad, etc). The easiest way to address this issue for me would be to branch my DIT like this:
ou=undergrads,ou=people,dc=example,dc=com and ou=postgrads,ou=people,dc=example,dc=com. On the other hand, I have several classes that I would like to distinguish my users to apart from this (like stuff, student, professors, etc.) but further sub-brunching shows to me that there's something wrong with my design (since those classes may dynamically change in the future).
As a second solution I thought that it would be very easy to make my users in ou=people,dc=example,dc=com belong to some group located in ou=groups,dc=example,dc=com. This way I feel much more flexible in making such classifications, but my problem is how to formulate ldapsearch filters so as to return an attribute of some user only if the specific user belongs to one or more of my groups (for example to find all email accounts from my people that belong to the undergrads group).
Thank you all for your time in advance,
kind regards,
George Mamalakis.
PS. In the case that this is not the right place to ask questions regarding ldap programming, please address me to some related resource. The truth is that I haven't found such a place by googling, meaning that the places I've found did not seem to be maintained well.
--On Sunday, April 17, 2011 1:07 PM +0300 George Mamalakis mamalos@eng.auth.gr wrote:
Dear all,
I have a question regarding my openldap DIT design. My design so far is based on the model: ou=people,dc=example,dc=com. It is very possible that I'll have to be able to find attributes of people belonging to some specific group (eg, student, postgrad, etc). The easiest way to address this issue for me would be to branch my DIT like this:
ou=undergrads,ou=people,dc=example,dc=com and ou=postgrads,ou=people,dc=example,dc=com. On the other hand, I have several classes that I would like to distinguish my users to apart from this (like stuff, student, professors, etc.) but further sub-brunching shows to me that there's something wrong with my design (since those classes may dynamically change in the future).
This is a terrible way to organize things. Just use an attribute to store group membership in the actual persons entries. It is quite common for people to end up in more than one group. By using an attribute in the user entry, then you can also easily create dynamic groups as well.
You may want to look at:
http://www.stanford.edu/services/directory/trees/people.html
particularly things like "suAffiliation", "suDisplayAffiliation", "suPrimaryOrganizationID", "suPrivilegeGroup", etc. EduPerson has some useful attributes as well, but doesn't necessarily cover the full scope of things you might want.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 17/04/2011 21:23, Quanah Gibson-Mount wrote:
--On Sunday, April 17, 2011 1:07 PM +0300 George Mamalakis mamalos@eng.auth.gr wrote:
Dear all,
I have a question regarding my openldap DIT design. My design so far is based on the model: ou=people,dc=example,dc=com. It is very possible that I'll have to be able to find attributes of people belonging to some specific group (eg, student, postgrad, etc). The easiest way to address this issue for me would be to branch my DIT like this:
ou=undergrads,ou=people,dc=example,dc=com and ou=postgrads,ou=people,dc=example,dc=com. On the other hand, I have several classes that I would like to distinguish my users to apart from this (like stuff, student, professors, etc.) but further sub-brunching shows to me that there's something wrong with my design (since those classes may dynamically change in the future).
This is a terrible way to organize things. Just use an attribute to store group membership in the actual persons entries. It is quite common for people to end up in more than one group. By using an attribute in the user entry, then you can also easily create dynamic groups as well.
You may want to look at:
http://www.stanford.edu/services/directory/trees/people.html
particularly things like "suAffiliation", "suDisplayAffiliation", "suPrimaryOrganizationID", "suPrivilegeGroup", etc. EduPerson has some useful attributes as well, but doesn't necessarily cover the full scope of things you might want.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
Quanah,
thanks a lot for your directions. I will consider them thoroughly in my design.
openldap-technical@openldap.org
-
George Mamalakis -
Quanah Gibson-Mount