Re: Antw: Re: Regarding LDAP structure

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

>>> Howard Chu <hyc@symas.com> schrieb am 14.03.2014 um 11:55 in Nachricht
<5322E00A.7020904@symas.com>:
> Ulrich Windl wrote:
>>>>> Howard Chu <hyc@symas.com> schrieb am 14.03.2014 um 10:36 in Nachricht
>> <5322CD84.4080903@symas.com>:
>>> 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.
> 
> Then you don't understand the difference between hierarchical namespaces and 
> 
> flat namespaces. I suppose you're not using any Unix filesystems very much 
> either.

It seems you know. Isn't it that openLDAP stores every entry in a linear database, assigning an entry number to each entry and then use an index to convert an arbitrary attribute like DN to an entry number? I fail to see the difference in a non-partitioned tree between hierarchical and flat here.

> 
>>> 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?
> 
> Your entire question is negated by the fact that X.500 provided a ModifyDN 
> operation from the very beginning. The point you're failing to realize is 
> that 
> nobody said that "cn" must be the distinguished naming attribute of an 
> entry.

I did not say the problem is that a DN cannot be changed; I said the problem is that the DN changes if you follow the typical LDAP recommandations how to name your entries.

>>
>>>
>>> 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.
> 
> Nonsense. Read optimization vs write optimization. AD chose to favor writes 
> over reads, LDAP/X.500 is intended to favor reads over writes. M$ AD chose 
> the 
> wrong option.
>>
>> (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/