Howard Chu hyc@symas.com schrieb am 14.03.2014 um 10:36 in Nachricht
Ulrich Windl wrote:
Hi!
I have a question on "entryUUID": Most (comonly used) group-like structures
use DNs for members. Are there any examples how to use entryUUID for group-like structures?
There are no standard schema that do this. I'd note that your question and Alejandro's recommendation are contrary to the design of LDAP (and the X.500 data model) - LDAP is meant to be a read-optimized hierarchical data store. If you simply use entryUUIDs for all references then you might as well use a flat or relational database instead of a hierarchical one.
Up to here I see no difference.
In particular, listing memberships by DN gives you immediate knowledge of an entry's location in the hierarchy, and clients can use DN's for direct access to any entry of interest. Using entryUUID requires you to do a search, instead of a direct lookup.
I agree here.
There's of course a maintenance cost for using DNs as references - when DNs are changed, you might also need to change every entry that references them, which makes updates more expensive. But again, that's part of the LDAP design: writes can be more expensive, because reads must be as fast as possible.
I tend to disagree: I think the DIT designers mixed up names and IDs right from the beginning. I guess that's why every entry has a DN, and not a DID (Distinquished ID). To me it seems that did not foresee that a DN might change. Maybe it was due to UUIDs not being used at that time. Today you can learn for the web trackers how to manage IDs correctly ;-)
Maybe they new the DIT schema would be less attractive if you had "non-speaking" DIDs instead of DNs rich of semantics. But that virtual attractiveness seems to be a major problem: What happens if "dn: cn=Jane Smith, ou=people, o=example.org" gets married or divorced?
This is also a distinguishing characteristic of M$ AD that differentiates it from true LDAP implementations - in AD, references are stored internally as GUIDs, and the GUID must be mapped to a name on every read operation. Thus they avoid the expense of referential integrity updates when DNs change, but as a consequence, read operations in AD are slower than writes. It's not a tradeoff that makes sense for most LDAP uses, but M$ AD is not a shining example of good design anyway.
"ease of use, not ease of implementation" they say.
(It's all my opinion)
Regards, Ulrich
Regards, Ulrich
Alejandro Imass aimass@yabarana.com schrieb am 13.03.2014 um 20:10 in
Nachricht CAHieY7TFQne1gyGe9-fWH3oYzZy-oBOQSha=kLKWowYzv3KnVA@mail.gmail.com:
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.
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
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/