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