[Fedora-directory-devel] Re: How to implement Extended DNs for
Samba4?
Pierangelo Masarati
ando at sys-net.it
Tue Oct 21 09:25:39 GMT 2008
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)
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.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando at sys-net.it
-----------------------------------
More information about the samba-technical
mailing list