fix(nslcd): handle RDNs containing umlauts in nss-pam-ldapd

[spaceone]

During tests, we found that account pam_unix.so doesn't work with nss-pam-ldapd if a user contains umlauts, because the username gotten from LDAP was escaped and the following LDAP searches yielded no results.

Therefore the pam module came to the conclusion that there was no user with that username.

Logs:

slapd[52188]: conn=1004 op=0 RESULT oid= err=0 qtime=0.000014 etime=0.000056 text=
slapd[52188]: conn=1004 fd=26 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
nslcd[51684]: [e87ccd] <authc="testäö"> DEBUG: ldap_simple_bind_s("cn=master090,cn=dc,cn=computers,dc=autotest090,dc=test","***") (uri="ldap://master090.autotest090.test:7389")
slapd[52188]: conn=1004 op=1 BIND dn="cn=master090,cn=dc,cn=computers,dc=autotest090,dc=test" method=128
slapd[52188]: conn=1004 op=1 BIND dn="cn=master090,cn=dc,cn=computers,dc=autotest090,dc=test" mech=SIMPLE bind_ssf=0 ssf=256
slapd[52188]: conn=1004 op=1 RESULT tag=97 err=0 qtime=0.000011 etime=0.003510 text=
slapd[52188]: conn=1004 op=2 SRCH base="dc=autotest090,dc=test" scope=2 deref=0 filter="(&(objectClass=person)(uid=test\C3\A4\C3\B6))"
slapd[52188]: conn=1004 op=2 SRCH attr=uid uidNumber
nslcd[51684]: [e87ccd] <authc="testäö"> DEBUG: ldap_result(): uid=testäö,dc=autotest090,dc=test
nslcd[51684]: [e87ccd] <authc="testäö"> username changed from "testäö" to "test\C3\A4\C3\B6"

So it looks up the user and gets its username (in our case this is unnecessary because we already use uid as identifier in this case).
But gets back an escaped value that doesn't work in the following ldap searches.

slapd[52188]: conn=1004 op=6 SRCH base="dc=autotest090,dc=test" scope=2 deref=0 filter="(&(objectClass=person)(uid=test\5Cc3\5Ca4\5Cc3\5Cb6))"
slapd[52188]: conn=1004 op=6 SRCH attr=uidNumber cn gecos uid objectClass homeDirectory gidNumber loginShell
nslcd[51684]: [200854] <passwd="test\C3\A4\C3\B6"> DEBUG: ldap_result(): end of results (0 total)

[arthurdejong]

According to the manual page the extra argument is notypes which may be 0 or 1 to indicate whether only the values of the parts of the DN are returned (e.g. {"Bob", "US", NULL}) or whether the types are included (e.g. { "cn=Bob", "c=US", NULL}).

It seems that the LDAP_DN_FORMAT_LDAPV3 option is only available to ldap_str2dn().

[arthurdejong]

Hi @spaceone,

Thanks for reporting this. I've been looking into this and have been able to reproduce it in my test set-up. Having non-ASCII characters in user names may be problematic because not all software may be able to handle those. This is one of the reasons that the validnames option by default will reject these kind of user names.

A big reason for that is that the encoding of the values is not well defined.

I've been looking into a few solutions for this. I've been looking into using ldap_str2dn() instead of ldap_explode_dn() and ldap_explode_rdn() but the return value is much uglier, it is not available on all supported LDAP client library versions and some other implementations suggest that the return type has changed in the past. Another option would be to unescape values returned form ldap_explode_rdn() but that also requires some code changes.