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.
Thanks!
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