[Fedora-directory-devel] Re: How to implement Extended DNs for Samba4?

[Howard Chu]

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.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/