Usually you should aim towards a DDS (Distributed Directory Service) 
and all nodes sharing some sort of agreement in the DIT structure 
although it's not alway necessary. 

> Specifically for an educational institution if I can share the aches and 
> pains of other directory owners with similar problems. 
> I also am trying to prove / disprove the use of having a person directory 
> object with multiple child account objects as good or bad architecture and 
> understand why. I've never seen this discussed in practice. 

Most LDAP implementations are quite poor and revolve around Posix 
and/or Windows AD management instead of using more elaborate DIT 
modelling , aliasing, and the entryUUID operational attribute (RFC 
4530). The DIT model is unique to every application but I do agree 
with you that we should have some reference models that break the 
traditional People, Computer Group paradigm. 

RDN and DN are actually quite malleable and should never be used as 
unique identifiers of any sort, but rather as temporary 
addresses/names to locate entries, much the same way a person may have 
different addresses throughout his life yet remain the same person 
(aliases to a single entry/entryUUID). By the same token, two people 
may have identical attributes, yet be two distinct individuals 
(distinct entries/entryUUID). This can also happen in an LDAP DIT as 
the LDAP specification purposely makes no effort in preventing or 
controlling this. Moreover, the entryUUID is the perfect "key" to 
integrate your LDAP technology to other data sources that may need to 
"link" with the LDAP. So long as your tools actually use moddn and 
modrdn (as opposed to deleting and re-creating the entry) then the 
entryUUID should never change for the life of the entry regardless on 
where it's located in the DIT. 


> Good and bad ways to relate tree objects with each other. I only know of 
> parent / child tree relationships or more "softly" by using DN's within an 
> attribute like the group-member relationship. 
> 

There are two popular and generic reference models for LDAP DIT 
hierarchies: (a) the more traditional X.500 form, and (b) the more 
modern domain-based around the DNS model. Each one is just a general 
guideline and they are by no means strict models for any LDAP 
implementation. In fact, the whole idea behind X.500 and LDAP is 
precisely that the model is flexible and adaptable over time, meaning 
that you don't have to "get it right" from the start and should be 
able to evolve your DIT over time, provided of course that your 
toolset is adequate. Web-based tools such as LAM for example are 
almost hard-wired into a People, Computer, Group paradigm whereas 
tools like PHPLDAPAdmin are more flexible but less intuitive. The 
latter provides a template mechanism which allows for easy 
customization to a particular implementation, but I think both (as 
almost all popular LDAP browsers/admin tools) are dumb in terms of 
moddn and modrdn so you need to hack them to work correctly with more 
complex implementations. 

Anyway, the point is that your entries should be organized anyway you 
want. I have done implementations where we can actually traverse the 
DIT in a hierarchical manner (e.g. by units and departments with 
people at different levels of the tree) but that can ALSO be queried 
by means of a common attribute(s). So you can actually have it both 
ways. I always prefer to model the DIT to reality and then group the 
entries by attributes to simplify queries. This gives you the best of 
both worlds as you can query at any level/branch and also allows to 
implement a DDS more easily. Actually I encourage mixing the X.500 
with the Domain-based 

We have a very well documented reference implementation for an 
educational institution and we would happily share in a Wiki 
somewhere. Perhaps we can find a place where people can contribute 
reference implementations for different implementations and that 
allows for discussions, etc. Any idea where to post these?? 


Best, 
Alejandro Imass 
Yabarana Corporation