#137 No support for RFC 4530 entryUUID attribute
Closed: wontfix 2 years ago by firstyear. Opened 10 years ago by mkosek.


Description of problem:
There is no support RFC 4530 entryUUID.
The nsuniqueid could serve this pourpose if properly aliased.

How reproducible: Always

Steps to Reproduce:
1.Create an entry
2.Retrieve the entry

Actual results:
No entryUUID

Expected results:

Additional info:

batch update to FUTURE milestone

set default ticket origin to Community

Added initial screened field value.

jira 6.1 ( finally ) started to support to changing usernames in LDAP and from the looks of it [1], it's using that entryUUID ( rfc 4530 ) doing so.

Not sure if Jira as well as all the entire atlassian product line that uses crowd or embedded crowd works as an motivating factor enough to change from "FUTURE" to "NEAR FUTURE" ;)

  1. https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory#ConnectingtoanLDAPDirectory-useruniqueid

Scheduling for re-triage.

Missing proper support for entryUUID is actually causing problems to standard-compliant clients using SyncRepl. The protocol carries entryUUID values in its messages and clients are expected to use that in filters like entryUUID = <value from SyncRepl>.

Unfortunatelly, simply aliasing entryUUID and nsUniqueID does not work because nsUniqueID has different string format (dashes at different offsets) and thus even UUIDs which are equal at binary level are not matched by the filter (which seemingly compares the string representation).

Maybe proper [[https://tools.ietf.org/html/rfc4530#section-2.2|matching rule for UUID]] + alias could help?

I just noticed this while working on bind-dyndb-ldap for the next release, I will try to find a workaround for in in meanwhile.

Ping, guys, I just found out that this is actually causing problems for bind-dyndb-ldap:ticket:128.

Can we get this ticket re-triaged, please?

I have implemented an ugly workaround for purpose of [[https://fedorahosted.org/bind-dyndb-ldap/ticket/128|bind-dyndb-ldap:ticket:128]]. It is not pressing now but it would improve effeciency of the synchronization significantly if entryUUID attribute was provided.

Currently bind-dyndb-ldap uses unfiltered sub-tree search (SyncRepl refresh phase with no cookie) to get all the entries along with their UUIDs. This is quite ineffective for cases where cookie is known and can be used for reconnection - this case needs explicit entryUUID attribute in the entry because SyncRepl does not provide the entryUUID in this case.

Per triage.

Possible... Let's evaluate/design so we can see if it fits in our scope.

Couldn't we just return the nsUniqueId here? Maybe a plugin to just remap attribute name so not to confuse the client when requested.

I think that to do this we can use either a specific plugin, or a generic transformation one. The best way to proceed here is to just transform and present nsUniqueId as an entryUUID here.

Metadata Update from @firstyear:
- Issue set to the milestone:

5 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: None
- Issue set to the milestone: 1.4 backlog (was:

5 years ago

Just bumped into this issue configuring JIRA and Bitbucket - RFC compliance should ideally be a priority on this one.

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Custom field version adjusted to None
- Issue tagged with: RFE

4 years ago

This is probably going to be a priority for me shortly :)

Metadata Update from @firstyear:
- Issue unmarked as blocking: #50544

2 years ago

I wonder if we can handle this with filter rewrite to nsUniqueID and do the same logic we are going to do with objectSID handling -- by allowing a plugin to convert the value in a filter to expected format so that nsUniqueID would match?

Fundamentally, this is pretty much like objectSID checks work.

@abbra, I think it can be done with a mix of filter rewriter and computed attribute.
To be flexible I suggest to extend generic rewrite plugin (https://pagure.io/389-ds-base/issue/50931) to also record computed attribute taken from config.

Absolutely not @abbra. This is an over complex idea to a problem that requires only a simple solution. nsUniqueID is part of the replication machinery of the server, and it shouldn't be treated the same way as entryUUID. Having filter rewrite, and virtual attributes, and all this other stuff is obscenely complex, and misses a fundamental use case - people importing entries with existing entryUUID's that they want to remain stable from a different directory.

Because people may want to import these, entryUUID must be disconnected from nsUniqueID, and should be generated seperately. Being a real attribute means it will be replicated, has minimal cost at search (compared to a virtual attr), requires no changes to filter (an extremely sensitive part of the code), and no changes to indexing to be extremely fast.

I will be making this a plugin that simply generates entryUUIDs and has a fixup task to create them if they are not present. I will not approve of your suggested solution, and I think you need to stop confusing "complex" with "good" due to the potentially huge maintenance burdens of complex ideas.

@firstyear while I agree with you on a general approach you expressed, I was thinking not about nsUniqueID but rather about ipaUniqueID, apologies for that. For the purpose of entryUUID, ipaUniqueID in FreeIPA is effectively the same thing, just expressed in a different format. That's why I was thinking we could apply the same logic as with objectSID.

Hopefully, this clarifies my proposal.

The ticket is about having support of RFC 4530 to creates entryUUID operational attribute and define syntax and matchingRules. Support of this RFC means it could be used in filter and returned if requested.

The value of entryUUID being nsuniqueID or ipaUniqueID depends on the application need but should not change the implementation.

The implementation can be done with:
- MEP + COS, have a mep entry where entryUUID being filled from the source attribute (nsuniqueId and ipauniqueID). Not sure if entryUUID SRCH can be indexed.
- filter rewriter/computed attribute using either specific plugin or a generic plugin discussed in https://pagure.io/389-ds-base/issue/50931

I think having ipaUniqueID extract to an objectSID is also a bad idea, because objectSID's have specific and very different structures to a UUID.

Either way, that's not my problem, that's a freeipa problem.

@tbordaz MEP and COS should never be the solution to any problem, neither is filter rewriting. Again, we should be making simple designs in the write path, not overcomplicating it.

@firstyear I think you are misunderstanding what I tried to say. I did not ask to extract objectSID out of ipaUniqueID. I pointed out that objectSID in Active Directory accepts both directoryString and a binary searches and normalizes those internally to compare with the stored (binary) value.
What I meant is that entryUUID and ipaUniqueID situation is similar -- despite different textual representation they are mapped onto same binary sequence. Thus, at least in FreeIPA, entryUUID searches can be produced on top of existing ipaUniqueID.

@firstyear, it is all about generic vs specific plugins.

It already exists specific plugins (like referential integrity and memberof or roles) that are doing very similar things but to achieve slightly different results. At the end, those plugins are simpler because they focus on a single problem to resolve. But have a QA/Doc cost and also a maintenance cost because code is partially duplicated.

Generic plugin like COS or slapi-nis can contribute to resolve a variety of problem around virtual attributes. But being generic, they are less simpler.

I have no strong opinion if a plugin need to be generic or specific. What I know it that there is are needs to present/access data in different views/method. Slapi-nis, COS, filter rewrite, computed attributes, views and mep are all around this need. That likely means we have to sit down and see if we can address some needs in a common (e.g. generic) way.

Metadata Update from @mreynolds:
- Issue assigned to firstyear
- Issue set to the milestone: 1.4.4 (was: 1.4 backlog)

2 years ago

Metadata Update from @firstyear:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

2 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/137

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

2 years ago

Login to comment on this ticket.