Andrew Bartlett wrote:
At the CIFS plugfest it became clear that Samba3 requires that we complete the implementation of 'extended DN' replies in the Samba4 LDAP server.
This means that a DN in things like memberOf are in the form:
<GUID=0bc11d00-e431-40a0-8767-344a320142fa>;<SID=S-1-2-3-2345>;cn=abartlet,cn=users,dc=abartlet,dc=net
(or so, I've just made this one up)
If the magic 'extended DN' control is specificed, then we have to return this form to the client, and it would work really well to store it in that form on the backend, and if they do not specify the control, only then strip it back to the 'normal' DN.
In the past I've proposed a UUIDAndName syntax for references, instead of just DN-based references. (But SID is still a bit too specific...)
The problem is now particularly how to implement these locally - inside Samba4 it should be pretty easy to have the right triggers in the existing memberOf module, but how to implement this in OpenLDAP and (eventually) FedoraDS.
Currently OpenLDAP uses the refint and memberOf modules, knowing that this attribute is simply a DN, nothing more. These modules (and probably the input validation) will no doubt be unable to cope with the 'extended' DN form.
Is it reasonable to ask that OpenLDAP carry a module so Samba-specific in it's application (reading the objectSid and entryUUID and formatting the link that way)? Should we try to just fill this in with another search as part of the search entry callback? (at great performance cost).
Any thoughts?
We already carry a bunch of Samba-related modules in our contrib branch. I don't see any problem with adding this one. In this case all you need is a module to implement parsing and processing of your magic Extended DN control.
Frankly, I can see this being generally useful, if you define the semantics broadly enough. For example, the request control could take a data argument providing: MagicData ::= SEQUENCE of DerefSpec
DerefSpec ::= SEQUENCE { DerefAttr attributedescription, attributes attrlist }
attrlist ::= SEQUENCE of attr attributedescription So for each DerefAttr, dereference the name and extract the attributes from the target entry, and return them all in the response control.