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
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
Attachment:
signature.asc
Description: This is a digitally signed message part