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

Andrew Bartlett abartlet at samba.org
Tue Oct 21 10:41:13 GMT 2008

On Tue, 2008-10-21 at 03:35 -0700, Howard Chu wrote:
> 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
> I think you misunderstood my proposal. I'm not suggesting we muck with the 
> returned DNs at all; the extra information will only appear in the response 
> control.

So the response control would contain lists of attribute/value pairs
along with their associated data?  (So I can then fit them back into the
right place for the AD reply)

> > - 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)
> entryUUID == 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).
> Right. But perhaps we should stop referring to it as an "extended DN," since 
> we're not altering the DN at all. Call it something like Subsearch or 
> Dereference control (or something...). We just need to provide 
> ldap_create_subsearch_control() and ldap_parse_subsearchresponse_control().

Well, that's just the Microsoft name for it, that's all.

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/05651449/attachment.bin

More information about the samba-technical mailing list