A few comments inline...
Ludovic Poitou

From: Alejandro Imass aimass@yabarana.com
Reply: Alejandro Imass aimass@yabarana.com
Date: March 13, 2014 at 20:25:49
To: Joshua Riffle jriffle@apu.edu
Cc: openldap-technical@openldap.org openldap-technical@openldap.org
Subject:  Re: Regarding LDAP structure

On Thu, Mar 13, 2014 at 12:18 PM, Joshua Riffle <jriffle@apu.edu> wrote:
> I'm aware this may not be the best mailing list to discuss something as
> generalized as best practices for LDAP structuring within OpenLDAP, but
> would anyone be able to direct me to a mailing list that would be better
> suited for this kind of conversation?

I think it's an excellent discussion and I don't see why this list
cannot accommodate it. After all, OpenLDAP is currently a reference
model in the OSS world for LDAP so it could very well house discussion
around reference models for DITs.

> I'm looking for any or all of these kinds of communications within a mailing
> list:
> Designing a person, account, group LDAP tree directory that would be
> scalable and flexible enough to grow to large sizes (millions) and still
> have a grip on best practices for identity management on an enterprise
> level.

I’m not sure I understand the issue here. Directories like OpenLDAP or OpenDJ are already capable of handling millions of entries, and I know several of our customers that have services with tens of millions, and even beyond  a hundred millions of entries.

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. 

I guess that the point of view will differ whether your building a directory service to support your network (which revolves around Posix users and/or AD) or a directory service to support portals and user facing applications, in which case the directory is like any other generic database technology and you have some freedom of implementing the model you want for your applications.



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

Alejandro Imass 
Yabarana Corporation