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