The server does not accept DN with type like OID.x.y.z (RFC 1779)

• Key: DIRSERVER-229
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Blocker
• Assignee: Emmanuel Lecharny
• Reporter: Emmanuel Lecharny
• Component/s: ldap
• Affects Version/s: pre-1.0
• Fix Version/s: pre-1.0

Description

if we try to parse DN like :

dn: oid.2.5.4.11=blah

we get an error.

This DN is valid regarding RFC 1179, but isn't regarding rfc 2253.

Comments

[Emmanuel Lecharny]

There is another bug hidden by the first bug :

when we are trying to find an entry which dn contains a ComponentName which use an OID, this OID is not compared to its textual equivalent.

Here 2.5.3.11 = 'ou'. Even if an ou=blah exists, it won't be equivalent, so the entry won't be found.

The solution will be to replace the name by its OID when comparing the entry.

Worst, if we use searches like this one :

CommonName=blah

instead of

cn=blah

we get no answer, even if cn=blah exists.

[Emmanuel Lecharny]

Raised to blocker, as the way lookup are done in the database is not good. We should find an entry using every names it has (cn, commonName or 2.5.4.3, for instance)

[Trustin Lee]

We have to store everything that can be converted to an OID as an OID, and to provide an interceptor which translates any names in the request into OIDs, and any OIDs in the response into the translated names. Would this approach work?

[Emmanuel Lecharny]

A fix has been submitted in january (a huge one). It solves both errors. The solution is to transform the Names as soon as possible to use an alias instead of the OID.

[Emmanuel Lecharny]

Fixed, tested, so closed.