>>> Howard Chu <[email protected]> schrieb am 14.03.2014 um 10:36 in Nachricht <[email protected]>: > 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 <[email protected]> schrieb am 13.03.2014 um 20:10 in >> Nachricht >> <CAHieY7TFQne1gyGe9-fWH3oYzZy-oBOQSha=klkwowyzv3k...@mail.gmail.com>: >>> On Thu, Mar 13, 2014 at 12:18 PM, Joshua Riffle <[email protected]> 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/
