On Tue, 2008-10-21 at 00:21 -0700, Howard Chu wrote:

Andrew Bartlett wrote:

...

At the CIFS plugfest it became clear that Samba3 requires that we complete the implementation of 'extended DN' replies in the Samba4 LDAP server.

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.

OK.

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 would really, really love to have someone knock up a module like this for me. (I'm unlikely to do so successfully).

The only comment I have is that these links would need to cross database boundaries (like the refint and memberof modules now do). We should also possibly have some way to work when pointing at targets outside the current directory (which we don't support at the moment, but I'm told we will need to support).

Andrew Bartlett

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

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

Pierangelo Masarati wrote:

Howard Chu wrote:

...

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 you mean adding a response control value made of something like

controlValue ::= SEQUENCE { extended extendedDN }

extendedDN ::= SEQUENCE { attrval attrVal }

attrVal ::= { attrspec attrSpec, value octetString }

where the sequence of attrSpec was specified in the control request. In the case at hand, the control request would contain GUID, SID and entryDN. Is this what you mean? Then, it would be the client's task to use the response to build a string in the format specified by 1.2.840.113556.1.4.529.

Yes, that's what I had in mind. The question is whether that's sufficient for Samba's purposes; the control that I've described is sufficiently general that it would be useful for a lot of other cases.