[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Antw: Re: Regarding LDAP structure
>>> 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.
>
> 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 <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/