Antw: Re: Regarding LDAP structure

["Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>]

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