9:42 a.m.
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=librarie...
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/...
--
Dorian Taylor
http://doriantaylor.com/
11:08 a.m.
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.
2:23 p.m.
On Thu, May 30, 2013 at 11:08 AM, Michael Ströder <michael(a)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/
1:55 a.m.
dorian taylor wrote:
On Thu, May 30, 2013 at 11:08 AM, Michael Ströder
<michael(a)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.
9:47 a.m.
On Fri, May 31, 2013 at 1:55 AM, Michael Ströder <michael(a)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/
3655
days inactive
3658
days old
openldap-technical@openldap.org
4 comments
2 participants
participants (2)
-
dorian taylor -
Michael Ströder