Re: Problem with NON-ASCII chars in DNs when using OpenLDAP 2.1.x libs (ITS#1923)

[michael@stroeder.com]

Kurt D. Zeilenga wrote:
> Thanks for the detailed information.  This the same issue
> reported in ITS#1890.
> 
> The ldap_explode_dn() returns string representations of RDNs which
> conform to the syntax detailed in RFC 2253.  Both 2.0 and 2.1 version
> can and will produce strings which included escaped values.  In a
> number of cases, escaping is required by the technical specification.
> 2.1, however, will actively escape values and/or escape values
> differently than presented in its input.  While this is a change
> in behavior from 2.0, it is not expected to cause problems with
> any application which is designed to properly handle the RDN escaping
> (which 2.0 produces in certain cases).  That is, any application which
> has a problem with the change likely has bugs in its design.  This
> change will aggravate those bugs.

My misleading error report was due to ldap_search() returning 
LDAP_NO_SUCH_OBJECT when passing a DN as search root based on the 
output of ldap_explode_dn(). See this python-ldap trace log 
(Python script attached):

*** _ldap.<built-in function is_ldap_url> 
(('ldap://localhost:1389',),{})
=> result: 1
*** ldap.ldapobject.SimpleLDAPObject.initialize 
(('ldap://localhost:1389',),{})
=> result: <LDAP>
*** _ldap.<built-in function explode_dn> (('cn=Michael 
Str\xc3\xb6der+mail=michael@stroeder.com,ou=Testing,dc=stroeder,dc=com', 
0),{})
=> result: ['cn=Michael Str\\C3\\B6der+mail=michael@stroeder.com', 
'ou=Testing', 'dc=stroeder', 'dc=com']
*** ldap.ldapobject.SimpleLDAPObject.search (('cn=Michael 
Str\\C3\\B6der+mail=michael@stroeder.com,ou=Testing,dc=stroeder,dc=com', 
0, '(objectclass=*)', ['cn'], 0),{})
=> result: 1
*** ldap.ldapobject.SimpleLDAPObject.result ((1, 1, -1),{})
=> LDAPError: {'info': '', 'matched': 
'ou=Testing,dc=stroeder,dc=com', 'desc': 'No such object'}

> We, however,
> don't believe the change impacts any properly designed application.
> That is, properly designed applications should expect that RDN
> strings may contain escaped values.

And how should the application handle them? I mostly treat DNs to 
be opaque. But I'm eliminating spaces from DNs because it caused 
problems with some LDAP servers.

E.g. web2ldap transforms
uid=michael, dc=stroeder, dc=com
to
uid=michael,dc=stroeder,dc=com
before passing it back into python-ldap which directly wraps 
ldap_search() and ldap_result() etc.

> I note that any application which wants to get at the value portion
> of the AVAs within the RDNs of a DN, should consider using
> ldap_str2dn(3) and, conversely, ldap_dn2str(3) which provides
> significant control over generation of DN (and RDN and AVA) string
> representations.

I will dig into that.

Ciao, Michael.