[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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.

- 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().

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/