A few comments inline... -- Ludovic Poitou http://ludopoitou.wordpress.com
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.
Regards,
Ludovic.
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