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