serialNumber=43255 + cn=J Smith, o=NSN, c=CA
If I use dish to search for and view this entry, it doesn't matter
whether I specify the DN as
@c=CA@o=NSN@cn=j smith%serialNumber=43255
or
@c=CA@o=NSN@serialNumber=43255%cn=j smith
In other words, the ordering of components in the RDN doesn't matter,
which is correct behavior.
However, my 3.1 ldapd does care: if I specify the DN as
serialNumber=43255 + cn=J Smith, o=NSN, c=CA
everythign is fine, but if specify it as
cn=J Smith + serialNumber=43255, o=NSN, c=CA
the DSA reports "no such object, matched c=CA@o=NSN".
My working assumption is that ldapd thinks that the entry's RDN is
actually
cn="J Smith+serialNumber=43255"
In other words, ldapd took everything between "cn=" and "," and assumed
it was the commonName. The DSA translates this into
@c=CA@o=NSN@cn=J Smith+serialNumber=43255
and, not surprisingly, returns an error.
Has anyone else run into this problem? If so, where did you go to apply
the fix?
If you haven't run into the problem, any ideas on where the fix goes?
I've looked some, haven't found it, and have other pressing problems to
solve, so any help or hints would be welcome.
pww
ps AFAIK, there is no mandated way to sort components of an RDN when
returning them to a user, either in X.500(1996), or in RFC 177[789].
QUIPU and dish present them in decreasing order of OID, both in
display and in logs, while ldapd seems to do the same. If not,
should there be?