Thanks William -- very much appreciated!
We are reviewing options and will post back here.
________________________________________
From: William Brown [wibrown(a)redhat.com]
Sent: Wednesday, October 05, 2016 16:03
To: General discussion list for the 389 Directory server project.
Subject: [389-users] Re: RFC 4530 -- entryUUID attribute
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