RSS feed

Re: Support for Base64 encoded values

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: Support for Base64 encoded values

On Thu, 2017-06-15 at 17:22 +0000, Ricardo Padilha wrote:
> After a run with maximum log details I can see that the value stored
> in LDAP is jos\00\e9 (I.e., the ISO-8859-1 equivalent e-acute single
> rune), and that the client is sending jose\03\01 (I.e., letter e
> followed by an acute accent).

The value 'jos\xe9' is indeed the ISO-8859-1 encoding of josé. A UTF-8
encoding could be 'jos\xc3\xa9' ('jos\u00e9' in unicode) or
'jose\xcc\x81' ('jose\u0301' in unicode) or maybe something else

> In other words, it seems to me that there is a non unicode-compliant
> string comparison going on somewhere in the authentication stack.
> Does nss-pam-ldap perform any such comparisons internally?

nslcd currently does bytewise comparison but I think so does slapd
which does the bulk of the comparison (use ldapsearch command to
confirm this).

In theory it could be possible to do unicode normalisation in nslcd
before passing strings in search filters to LDAP (patches welcome) but
it would likely not solve all the problems. I expect there are multiple
places in the NSS and PAM stacks that expect usernames to be a subset
of 7-bit clean ASCII.

I would recommend only using the UTF-8 encoding in LDAP (so UTF-8
encode and then BASE64 encode for the LDIF file though you can probably
skip the BASE64 encoding for the modification operation).

-- arthur - - --
To unsubscribe send an email to or see