LDAP SASL Bind DIGEST-MD5 with non-ASCII chars in SAM-Account-Name
Michael Ströder
in general LDAP SASL Bind with mechanism DIGEST-MD5 works with AD
(tested with W2K3SP2). But if the SAM-Account-Name contains non-ASCII
chars (like german umlauts) it does not work.
My test script written in Python correctly encodes the SASL username as
UTF-8 before passing it to the python-ldap module (which uses OpenLDAP C
client libs which in turn use Cyrus-SASL libs). Another developer has
the same problem with Java/JNDI.
Is it supported at all?
Ciao, Michael.
Joe Kaplan
forum. There isn't much product group traffic here anymore.
My guess is that the method that precomputes the various DIGEST auth
username + password hash values does not properly handle correct binary
encoding of these characters, so no match is performed. It may be the case
that it is using UTF-16 encoding internally instead of UTF-8 as well, but
who knows.
To get a proper answer, you'll need to get better attention. I'll send a
note to some folks internally and see if I can coax a response. :)
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Michael Ströder" <mic...@stroeder.com> wrote in message
news:v9gd06-...@nb2.stroeder.com...
Michael Ströder
> My guess is that the method that precomputes the various DIGEST auth
> username + password hash values does not properly handle correct binary
> encoding of these characters, so no match is performed.
Note that the password in the test did *not* contain non-ASCII chars.
Only the username.
> It may be the
> case that it is using UTF-16 encoding internally instead of UTF-8 as
> well, but who knows.
This is unlikely since it wouldn't work with a pure-ASCII username
without converting it to UTF-16 because UTF-16 encodes a single char
*always* in 2 bytes whereas UTF-8 being ASCII backwards compatible
encodes all single ASCII chars as a single byte representing the ASCII
char. (Also note that with UTF-16 one has always to specify whether
low-endian or big-endian to make spec complete.)
FWIW: It works with OpenLDAP with the non-ASCII username encoded as UTF-8.
Further tests showed that it works with AD with the username encoded as
ISO-8859-1 (AKA Latin 1). This test was inspired by RFC 2831, section
2.1.1, description of 'charset':
------------------------------ snip ------------------------------
charset
This directive, if present, specifies that the server supports
UTF-8 encoding for the username and password. If not present, the
username and password must be encoded in ISO 8859-1 (of which
US-ASCII is a subset). The directive is needed for backwards
compatibility with HTTP Digest, which only supports ISO 8859-1.
This directive may appear at most once; if multiple instances are
present, the client should abort the authentication exchange.
------------------------------ snip ------------------------------
I've looked at the LDAP messages exchanged with wireshark:
MS AD (W2K3 SP2) sends charset=utf-8 in the
bindResponse::serverSaslCreds with resultCode saslBindInProgress. So the
client-side SASL libs simply follows this advice but AD seems to decode
usernames with non-ASCII chars as ISO-8859-1. I consider this to be a
bug in MS AD.
Now to passwords with non-ASCII chars:
It works with both simple and SASL/DIGEST-MD5 bind requests with the
password being encoded as UTF-8 or ISO-8859-1. That's strange!
Maybe that's even a (minor) security problem.
> To get a proper answer, you'll need to get better attention. I'll send
> a note to some folks internally and see if I can coax a response. :)
Thanks a lot! Seems this is a bug leading to interop issues.
Ciao, Michael.
Joe Kaplan
not actually followed, that can't be right. Perhaps there is a disagreement
somewhere regarding interpretation of the specification, but it appears to
be in conflict right now. I'll follow up with your more detailed analysis.
Hopefully I get a response.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
"Michael Ströder" <mic...@stroeder.com> wrote in message
news:9r6g06-...@nb2.stroeder.com...