[389-users] Re: RFC 4530 -- entryUUID attribute

[William Brown]

On Wed, 2016-10-05 at 17:03 +0000, Mailvaganam, Hari wrote:
>  W.r.t a vSphere implementation that has a requirement for entryUUID
> -- has it, or plans to, support in 389-DS -- https://fedorahosted.org/389/ticket/137?
>   
Hi,

I've just commented on the ticket, but there is a better explination.

We already have a UUID type on all objects in directory server,
specifically nsUniqueId. It looks like:

nsuniqueid: 0344fb02-703811e5-a62bf7bf-2add969e

Looking at the rfc, we can see:

https://www.ietf.org/rfc/rfc4530.txt

entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14

So if we compare these:

0344fb02-703811e5-a62bf7bf-2add969e
597ae2f6-16a6-1027-98f4-d28b5365dc14

Not quite the same. Turns out that nsuniqueId is displayed in 4 groups
of 8 characters, where as entryUUID is
https://www.ietf.org/rfc/rfc4122.txt displayed.

We could actually write a plugin, that when you request entryUUID, it
actually reads the nsUniqueId and formats it correctly:

before: 0344fb02-703811e5-a62bf7bf-2add969e
after : 0344fb02-7038-11e5-a62b-f7bf2add969e


There would still be some other discussions to be had, but the answer is
"We kind of support it, but not quite".

Sadly, for a feature like this, it won't happen "overnight" for 1.3.5,
and I can't guarantee when it would be ready.

You may be able to "cheat" and in the syntax do something like:

01core389.ldif:

Change line 41 from:

attributeTypes: ( 2.16.840.1.113730.3.1.542 NAME 'nsUniqueId' DESC
'Netscape defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation X-ORIGIN
'Netscape Directory Server' )

TO:

attributeTypes: ( 2.16.840.1.113730.3.1.542 NAME ('nsUniqueId'
'entryUUID') DESC 'Netscape defined attribute type' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE
directoryOperation X-ORIGIN 'Netscape Directory Server' )


ldapsearch -LLL -x -s base -b 'dc=example,dc=com' entryUUID
dn: dc=example,dc=com
entryUUID: 55d3cd25-8b4f11e6-b30bf972-f1241077


The quirk here is that you have to REQUEST entryUUID in the search, else
it will still return as nsUniqueID:

ldapsearch -LLL -x -s base -b 'dc=example,dc=com' +        
dn: dc=example,dc=com
nsUniqueId: 55d3cd25-8b4f11e6-b30bf972-f1241077


So if you could post the access log search query that vmware is
attempting, we can let you know if this work around will work or not. 

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane