Re: Antw: Re: Regarding LDAP structure

[Alejandro Imass <aimass@yabarana.com>]

On Fri, Mar 14, 2014 at 5:36 AM, Howard Chu <hyc@symas.com> wrote:
> 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.
>

Just to clarify: I did not recommend to use the entryUUID as a primary
LDAP lookup but rather as a means to identify a unique entry and as a
token to correctly associate __unique__ LDAP entries to other data
sources. When you have millions of users you will most likely have
cases of entries with identical attributes yet be 2 different people.
Anyway the spirit of my comment is that most LDAP implementations
ignore some advanced features like operational attributes and aliases.


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

Agreed.

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

Agreed. Moreover, many tools ignore moddn and modrdn altogether and
just delete and recreate.

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

+1

Best,

Alejandro Imass