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

Andrew Bartlett abartlet at samba.org
Tue Oct 21 09:39:58 GMT 2008

On Tue, 2008-10-21 at 11:25 +0200, Pierangelo Masarati wrote:
> Howard Chu wrote:
> >> 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.
> I see a few issues:
> - the resulting values do not conform to RFC4514; this could create 
> interoperability issues with other modules plugged in that receive 
> mucked DN-valued attrs, including the entry's name itself
> - according to the definition of 1.2.840.113556.1.4.529, the GUID and 
> the DN parts must always be present; we do not have any GUID (unless we 
> think of casting entryUUID to GUID or something the like)

I always take entryUUID as the GUID.

> In any case, the module would need to perform a subsearch  anyway for 
> each DN-valued attr that is being returned, in order to gather the 
> required information, possibly with the exception of the entry's DN (in 
> this case, it would suffice to add the attributes needed by the extended 
> DN to the requested attrs).
> We should also implement a call that parses a mucked DN value to support 
>   the extraction of the additional AVAs; something like ldap_str2extdn() 
> (and possibly ldap_extdn2str()?).
> I probably can prototype this in the week-end, with the above caveats.

I look forward to seeing what we can make work.


Andrew Bartlett

Andrew Bartlett
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20081021/15a4db69/attachment.bin

More information about the samba-technical mailing list