We also used the flat "person" space under the DC domain name, just
as you describe. We also had another hierarchical context space
that described the firm's physical hierarchy, such as buildings
containing departments containing offices.
To tie the persons to offices, we defined an attribute for each
person called "assignment". This assignment attribute was an RDN
into the hierarchical organization tree. Changed departments? Then
only your assignment attribute needed to be modified.
Stuart Schmuckler did much of the design work on that project.
tim.
> <ldap>
> Traditional LDAP documentation from the X.500 days recommends specifying
> DNs as:
>
> CN=<full name>,OU=<department>,O=<organization>,c=<country>
>
> This scheme worked well in the X.500 days, but organizations now tend to
> perfer a more DNS-based approach which solves problems like, what
> happens if two users have the same name, and how to I map O/C to my
> domain names. And what happens when people stay in the same company but
> change their department.
>
> A new scheme is devised which is documented in an IETF RFC, but not that
> well known:
>
> UID=<unique id>,O=People,DC=<domain>
>
> The assumption is that a unique identifier always exists, e.g. the email
> address (smith.johns.1 or johns1 vs. John Smith) and that the company
> has a domain name. Under the new scheme, my DN would be:
>
> UID=arkin,O=People,DC=exoffice,DC=com
>
> </ldap>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
