Hello,
It is my understanding that OpenLDAP keys its entries on UUIDs under the hood. I have a system that makes extensive use of UUIDs as canonical (and sometimes public-facing) identifiers, and would like to tap into the UUIDs generated for the objects in the LDAP directory for certain operations over those objects. The problem is I'm using type 4 (random) UUIDs [1] everywhere, and OpenLDAP uses type 1 (time-based).
It is important to the system to some extent that these identifiers be resistant to sequencing. As such, they really ought to be random. Since it hasn't been deployed in production yet, the sanest course of action seems to be to bend OpenLDAP to comply. (The alternative would be to maintain a dictionary of some kind, which I'm not keen about.)
A survey of the code is as such: OpenLDAP doesn't appear to care which version of UUID it uses save for the generator function itself. The util library is hardcoded [2] to use type 1, and the entryUUID attribute itself is constrained in the schema [3] to not permit modification (where "modification" ostensibly also extends to adding new records). I'm not too familiar with the source but at a glance it appears to accommodate an entryUUID attribute as input [4].
I guess my question is: what's the best strategy?
* Relax NO-USER-MODIFY on the entryUUID schema entry and set it at the application layer (easiest but most prone to problems) * Hack uuid.c to use uuid_generate_random instead of uuid_generate (easy, but introduces a maintenance problem) * Create an overlay (no idea where to start but can figure it out) * Figure out some way to make the UUID version configurable and send a patch upstream (most work and would it even be desirable?)
Links:
1) http://tools.ietf.org/html/rfc4122#section-4.4 2) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/l... 3) http://tools.ietf.org/html/rfc4530#section-2.4 4) http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sla...
-- Dorian Taylor http://doriantaylor.com/
dorian taylor wrote:
[..], and the entryUUID attribute itself is constrained in the schema [3] to not permit modification (where "modification" ostensibly also extends to adding new records).
A client application can set 'entryUUID' by sending the relax rules control along with the add/modify request.
I used this in a migration project deriving OpenLDAP's entryUUID from Novell eDirectory's GUID.
Of course the client app is then responsible for generating proper UUIDs. With random UUIDs you might run out of entropy depending on how many you have to generated within a certain time.
Ciao, Michael.
On Thu, May 30, 2013 at 11:08 AM, Michael Ströder michael@stroeder.com wrote:
A client application can set 'entryUUID' by sending the relax rules control along with the add/modify request.
This is good to know. I wasn't aware such a control existed.
I used this in a migration project deriving OpenLDAP's entryUUID from Novell eDirectory's GUID.
Aside: those and AD's objectGUID have the same semantics, yes? (I'd be floored if they didn't.)
Of course the client app is then responsible for generating proper UUIDs. With random UUIDs you might run out of entropy depending on how many you have to generated within a certain time.
Not too concerned about volume. I ended up writing an overlay anyway which seems to work fine. I'll be sending a patch once I tidy up the makefiles etc.
Thanks for the insight,
-- Dorian Taylor http://doriantaylor.com/
dorian taylor wrote:
On Thu, May 30, 2013 at 11:08 AM, Michael Ströder michael@stroeder.com wrote:
A client application can set 'entryUUID' by sending the relax rules control along with the add/modify request.
This is good to know. I wasn't aware such a control existed.
I used this in a migration project deriving OpenLDAP's entryUUID from Novell eDirectory's GUID.
Aside: those and AD's objectGUID have the same semantics, yes? (I'd be floored if they didn't.)
Hmm, what do you mean with "same semantics"?
In both servers the objectGUID in MS AD and entryUUID in OpenLDAP are created by the server when adding an entry. The LDAPsyntax differs (OctetString vs. UUID). But you should carefully think about the implications converting AD's objectGUID to OpenLDAP's entryUUID though!
During the Novell->OpenLDAP migration we decided to migrate the GUID->entryUUID because of the requirement to correctly sync the data also in the case entries were renamed.
If you need a persistent common primary key between AD and OpenLDAP you should rather think about syncing AD's objectSID and take care of the SID history after using AD domain migration tool.
Ciao, Michael.
On Fri, May 31, 2013 at 1:55 AM, Michael Ströder michael@stroeder.com wrote:
Hmm, what do you mean with "same semantics"?
I mean it's a globally-unique identifier that gets minted once per ("physical") entry (i.e. if you deleted the DN and put it back, it would have a different [GU]UID). But so as long as the entry exists, it will be associated with that identifier.
In both servers the objectGUID in MS AD and entryUUID in OpenLDAP are created by the server when adding an entry. The LDAPsyntax differs (OctetString vs. UUID). But you should carefully think about the implications converting AD's objectGUID to OpenLDAP's entryUUID though!
No interest (per se) in doing so; my interest is actually to borrow the identifiers for RDF subjects (urn:uuid:…) so the contents can be mapped back and forth between RDF statements and LDAP entries. I considered just using LDAP URIs but keeping track of DN changes would be a nightmare.
During the Novell->OpenLDAP migration we decided to migrate the GUID->entryUUID because of the requirement to correctly sync the data also in the case entries were renamed.
So yes, my interest is more similar to this.
If you need a persistent common primary key between AD and OpenLDAP you should rather think about syncing AD's objectSID and take care of the SID history after using AD domain migration tool.
I will definitely keep this in mind. Thanks!
-- Dorian Taylor http://doriantaylor.com/
openldap-technical@openldap.org
-
dorian taylor -
Michael Ströder