search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
211 stars 93 forks source link

No support for RFC 4530 entryUUID attribute #137

Closed 389-ds-bot closed 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/137

https://bugzilla.redhat.com/show_bug.cgi?id=220222

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:
entryUUID

Additional info:
389-ds-bot commented 4 years ago

Comment from rmeggins (@richm) at 2012-01-10 06:05:49

batch update to FUTURE milestone

389-ds-bot commented 4 years ago

Comment from rmeggins (@richm) at 2012-08-14 19:56:22

set default ticket origin to Community

389-ds-bot commented 4 years ago

Comment from nkinder (@nkinder) at 2012-08-28 04:14:31

Added initial screened field value.

389-ds-bot commented 4 years ago

Comment from johannbg at 2013-09-25 21:48:58

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
389-ds-bot commented 4 years ago

Comment from pspacek at 2015-04-29 13:02:40

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.

389-ds-bot commented 4 years ago

Comment from pspacek at 2015-05-25 14:15:51

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?

389-ds-bot commented 4 years ago

Comment from pspacek at 2015-05-28 18:08:28

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.

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2015-09-29 00:12:46

Per triage.

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

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2016-10-06 04:51:57

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

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-01-23 06:02:34

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.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-02-11 23:05:22

Metadata Update from @Firstyear:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-05-08 22:25:13

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from minfrin at 2017-09-17 16:50:43

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

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-10-18 22:03:53

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-03-10 04:16:17

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

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-03-10 04:16:18

Metadata Update from @Firstyear:

389-ds-bot commented 4 years ago

Comment from abbra at 2020-03-10 07:44:22

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.

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2020-03-10 17:00:53

@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 (#3984) to also record computed attribute taken from config.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-03-11 00:00:33

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.

389-ds-bot commented 4 years ago

Comment from abbra at 2020-03-12 07:28:45

@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.

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2020-03-12 11:39:11

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:

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-03-13 03:43:44

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.

389-ds-bot commented 4 years ago

Comment from abbra at 2020-03-13 07:45:45

@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.

389-ds-bot commented 4 years ago

Comment from tbordaz (@tbordaz) at 2020-03-13 09:42:09

@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.

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-05-20 16:09:26

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2020-06-03 04:25:27

Metadata Update from @Firstyear:

mreynolds389 commented 3 years ago

Backported to 1.4.3

3eeeb1c7f Ticket 51175 - resolve plugin name leaking 90dbb78c2 Issue 4421 - Unable to build with Rust enabled in closed environment 2e8ef650a Issue 4498 - BUG - entryuuid replication may not work (#4503) 5d5835aa6 Ticket 4326 - entryuuid fixup did not work correctly (#4328) 5301b64ea Ticket 137 - Implement EntryUUID plugin