Incorrect matched DN in the bind response (and others depending on the result code)

• Key: DIRSERVER-190
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Trivial
• Assignee: Alex Karasulu
• Reporter: Jérôme Baumgarten
• Fix Version/s: 1.5.0, 1.0-RC4

Description

According to RFC 2251 [1], section "4.1.10. Result Message", the matched DN for a bind response should be a zero length string.

I believe that other handlers should also be reviewed according to the following :

   For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
   aliasDereferencingProblem, the matchedDN field is set to the name of
   the lowest entry (object or alias) in the directory that was matched.
   If no aliases were dereferenced while attempting to locate the entry,
   this will be a truncated form of the name provided, or if aliases
   were dereferenced, of the resulting name, as defined in section 12.5
   of X.511. The matchedDN field is to be set to a zero length
   string with all other result codes.

Jérôme

[1] : http://www.ietf.org/rfc/rfc2251.txt

Comments

[Emmanuel Lecharny]

Jérôme is right.
But I don't know if it is of some importance to keep the DN into the LdapResult. I bet that no client will ever throw an error if this condition is not fulfilled ;)

Twix and Snickers codec will be fixed to handle the resultcodes that should not produce a DN.

A valid test to do is to check what happens when one of the 4 given result code is returned : is the added DN is correct wrt rfc 2251, then ?

[Emmanuel Lecharny]

A little mistake : Twix and Snickers are not the right place to fix this issue.

It should be done before, when generating the response.

[Emmanuel Lecharny]

This bug is related to RFC 2251. It's not any more a bug for http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-32.txt, 4.1.9 :
"For certain result codes (typically, but not restricted to
   noSuchObject, aliasProblem, invalidDNSyntax and
   aliasDereferencingProblem), the matchedDN field is set (subject to
   access controls) to the name of the last entry (object or alias) used
   in finding the target (or base) object. This will be a truncated form
   of the provided name or, if an alias was dereferenced while
   attempting to locate the entry, of the resulting name. Otherwise the
   matchedDN field is empty. "

A flag could be added in configuration to address the possibility to handle ldap-v3 or ldap-bis specific cases.

What's the durability of such a draft ? Is it worth it to invest time ?

Jerome

[Emmanuel Lecharny]

definitively !!!

here is the current status of the draft :
https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1023&filename=draft-ietf-ldapbis-protocol

At this point, its is close to become an offical RFC.

[Jérôme Baumgarten]

So let's o for that draft and you may not need to handle the old (RFC 2251) way.

[Alex Karasulu]

This has been fixed for some time. I confirmed and we do this correctly thanks to DIRSERVER-212 I beleive.