On Fri, Mar 14, 2014 at 5:36 AM, Howard Chu <[email protected]> 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
