Am 20.05.2014 00:33, schrieb Bill MacAllister:
--On Monday, May 19, 2014 10:14:38 AM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On September 25, 2013 at 9:46:44 AM +0530 Shali 9846303531 shalib2@gmail.com wrote:
Dear All,
I am new to these LDAP concepts , i have prepared a DIT for our organization with two academic institutions with each institution having different branches of study and also there is staff and students . i have attached the DIT , if am going through a wrong way kindly guide me.
Generally, I would recommend something like
dc=example,dc=com
below that:
cn=people,dc=example,dc=com cn=groups,dc=example,dc=com cn=orgs,dc=example,dc=com
etc
If you want to track people's affiliation (staff, student, etc), you should do that IN the person entry itself. It is not uncommon, particularly in educational institutions, for people to be both staff & student, etc.
You can also store organizational affiliations for the person within the person object. You may want to take a look at how Stanford University organized its ldap server.
The one issue that we are struggling with is that a single user can have more than one affiliation. The way this was handled before the existence of value sorting was to create attributes of the form affiliation1, affiliation2, etc. This works, but from a data design standpoint it drives me nuts. Using this scheme we support 5 affiliations per person which might seem like it should be sufficient, but with Stanford affiliated organizations there are cases that just don't fit. (The doctors and students at the Stanford Hospitals and Medical School cause the most problems.) And this method means that we also have attributes like suAffilPhone1, suAffilPhone2, ... suAffilPhone5. The affiliation attributes ending in 1 form a set of related attributes, etc.
With value sorting it is possible to do away with the limit on the number of affiliations associated with a cn=people entry, but there is still the implicit set definition associated with the affiliation{1}, suAffilPhone{1}, etc. attributes.
I have been playing around with alternate structures that have DNs of the form:
cn=some-affiliation,suregid=unique,cn=people,dc=stanford,dc=edu
I like this design best. No limits on the number of affiliations, and attribute sets are clearly defined. But, practically this is a problem for many applications. General applications that use person information expect to query the directory for person attributes and get a single entry back, and none that I know of are willing to use the results of the first search to perform a second search.
This very much reminds me of a very old discussion we had in the last century on family of entries (http://tools.ietf.org/id/draft-ietf-ldapext-families-00.txt). I think it was a nice idea, the proposal was may be a little over complex and there was no market and thus no implementation, except some very experimental code IIRC.
The nearest we have that can be called a standard is Howards already mentioned value ordering (http://tools.ietf.org/html/draft-chu-ldap-xordered-00), although I think its only implemented in OpenLDAP, or is anyone aware of another implementation?
Since such discussions keep on popping up, may be we should reconsider trying to standardize something that addresses such problems, so that in ca. 10 years from now one could have a better answer than now.
Cheers,
Peter
Certainly the LDAP application used the most on campus, WebAuthLDAP, does not do this.
https://itservices.stanford.edu/service/directory
--Quanah
The web site describes the custom attributes that Stanford uses, but does not hold the schema definitions. I have not done as good a job as Quanah when he was here at making the Stanford schema definitions available on the web. If you want to see them let me know and I will send them to you. (The web site that I need to add the files to I don't own, but this note has spurred me into action and I will get them there sometime this week.)
Bill