Radovan Semancik wrote: > On 02/20/2016 04:17 PM, Michael Ströder wrote: >> The control's OID is listed in my OpenLDAP 2.4.44 instance. > > Thanks. I'll try that once I find Ubuntu packages of recent OpenLDAP version ... > that'll take a bit of time :-) > >> BTW: I'd always recommend to fix the client instead of using this control. > > Actually, that's not really a practical advice. > > LDAP does not have ACID consistency. Adding a value that is already added may > happen even if everything operates correctly and there is no bug in the client > code. > > E.g. imagine that two clients adds user to the same group. What's the rationale for doing that? > If the control is not > present, one of the operations fails even if there is actually no logical error > at all. Reading a value, filtering out the values and writing it again provides > no guarantees, as the value might be changed in the meantime. Yes, the clients > may have special handling for this error and evaluate the case and re-try the > operation. In a way similar to handling of optimistic lock conditions. But that > is at least one extra round-trip. Usually two. And this significantly > complicates the client code as the operation may add a couple of values and > remove other values. It is possible to write a correct code to handle that (we > have done that in midPoint), but it is not easy to develop and (especially) test > it. It is not something that one would expect from an ordinary LDAP client, is it? Sorry, I suspect that such a client would do things wrong. Bear in mind that maintaining group entries has a serious security impact! Many years ago with brand new W2K there was a bug in MMC where the MMC client always replaced all values with a "new" set of values. That re-added group membership which was removed by another client instance before. Therefore my web2ldap does two things: 1. Maintaining group membership is a separate use-case explicitly adding/removing distinct attribute values. 2. Modifying an entry provokes detecting write conflicts by - adding/removing distinct attribute values even when "replacing" values (and looking at subschema for determining whether attribute type has EQUALITY matching rule or not) - using special re-read filter and modify request with Assertion Control BTW: Even when using the permissive modify control you would have to read the old entry for removing attribute values. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature