GNOME Bugzilla – Bug 576571
Login with non-ASCII chars fails
Last modified: 2013-07-23 14:32:31 UTC
Please describe the problem: At this particular site, there are users with non-ASCII-characters in their AD and Exchange user names (ä,ö,ü). Evolution can not log in (authentication fails), while for example Firefox can use the OWA. Some debugging revealed that Firefox encodes user names as latin1 (at least when possible), while evolution passes through the system encoding unmodified, which happens to be UTF-8 here. The RFCs are not very clear here. RFC 2617 (HTTP Auth) only specified that the user name should be TEXT, which is defined in RFC 2616 (HTTP 1.1): The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. RFC 2047 is MIME encoding. Some references in the Internet although indicate that Outlook would use something like "Passw<0xABCD>rd" when there is a non latin1 character, where the 0xABCD is from some specific codepage. But at least for latin1-characters, this is a clear bug. This is a show-stopper for this deployment here. I’m trying to cook up a patch, but I’ll he thankful for pointers or maybe a patch :-) Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
This might be a libsoap bug. This patch allows me to press the "Legitimation" button in the account setup wizard, but it does not work afterwards. Even more, it makes the debugging output (E2K_DEBUG=4) crash with segmentation fault – it seems something does not grok the latin1 chars there. --- libsoup2.4-2.25.91.orig/libsoup/soup-auth-basic.c +++ libsoup2.4-2.25.91/libsoup/soup-auth-basic.c @@ -106,13 +106,19 @@ char *user_pass; int len; - user_pass = g_strdup_printf ("%s:%s", username, password); + const gchar *charset; + g_get_charset (&charset); + gchar *username_conv = g_convert (username, -1, "ISO-8859-1", charset, NULL, NULL, NULL); + + user_pass = g_strdup_printf ("%s:%s", username_conv, password); len = strlen (user_pass); + printf("Before: %s After: %s\n", username, username_conv); priv->token = g_base64_encode ((guchar *)user_pass, len); memset (user_pass, 0, len); g_free (user_pass); + g_free (username_conv); } static gboolean
I tried to make the NTLM code use Unicode instead of OEM, by setting the right flags and converting the data, according to http://davenport.sourceforge.net/ntlm.html#theType3Message. The result actually works for only-ascii-usernames, so there is no regression. Unfortunately, it still does not work for usernames with an umlaut. Can anyone help me out here? --- evolution-data-server-2.24.5.orig/servers/exchange/xntlm/xntlm.c +++ evolution-data-server-2.24.5/servers/exchange/xntlm/xntlm.c @@ -31,7 +31,7 @@ static unsigned char NTLM_NEGOTIATE_MESSAGE[] = { 'N', 'T', 'L', 'M', 'S', 'S', 'P', 0x00, - 0x01, 0x00, 0x00, 0x00, 0x06, 0x82, 0x00, 0x00, + 0x01, 0x00, 0x00, 0x00, 0x05, 0x82, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0x00, 0x00, 0x00, @@ -169,7 +169,7 @@ static unsigned char NTLM_RESPONSE_MESSAGE_HEADER[] = { 'N', 'T', 'L', 'M', 'S', 'S', 'P', 0x00, - 0x03, 0x00, 0x00, 0x00, 0x02, 0x82, 0x00, 0x00 + 0x03, 0x00, 0x00, 0x00, 0x01, 0x82, 0x00, 0x00 }; #define NTLM_RESPONSE_BASE_SIZE 64 @@ -207,6 +207,19 @@ message = g_byte_array_new (); + const gchar *charset; + g_get_charset (&charset); + + gsize user_len; + gchar *user_conv = g_convert (user, -1, "UCS-2LE", charset, NULL, &user_len, NULL); + + gsize domain_len; + gchar *domain_conv = g_convert (domain, -1, "UCS-2LE", charset, NULL, &domain_len, NULL); + + gsize workstation_len; + gchar *workstation_conv = g_convert (workstation, -1, "UCS-2LE", charset, NULL, &workstation_len, NULL); + printf("Before: %s,%s,%s length %d,%d,%d\n", domain, user, workstation, domain_len, user_len, workstation_len); + ntlm_lanmanager_hash (password, hash); ntlm_calc_response (hash, nonce, lm_resp); ntlm_nt_hash (password, hash); @@ -218,16 +231,19 @@ sizeof (NTLM_RESPONSE_MESSAGE_HEADER)); ntlm_set_string (message, NTLM_RESPONSE_DOMAIN_OFFSET, - domain, strlen (domain)); + domain_conv, domain_len); ntlm_set_string (message, NTLM_RESPONSE_USER_OFFSET, - user, strlen (user)); + user_conv, user_len); ntlm_set_string (message, NTLM_RESPONSE_WORKSTATION_OFFSET, - workstation, strlen (workstation)); + workstation_conv, workstation_len); ntlm_set_string (message, NTLM_RESPONSE_LM_RESP_OFFSET, lm_resp, sizeof (lm_resp)); ntlm_set_string (message, NTLM_RESPONSE_NT_RESP_OFFSET, nt_resp, sizeof (nt_resp)); + g_free (domain_conv); + g_free (user_conv); + g_free (workstation_conv); return message; }
Eh, nevermind, it does work. :-) Please consider applying the latter patch for Unicode-aware NTLM.
Hmm, there are two NTLM implementations in evolution-data-server, and one in libsoup. Quite some code duplication... I didn’t get around to implement NTLM unicode support in libsoup now. If this would happen, then the umlaut user names would work direclty with NTLM, without resorting to Basic authentication. Any problems with this approach?
Just for the record, here is my change to the ntlm implementation in camal in e-d-s. I thought this was used for the OWA-access, so I did it, but it turned to to be libsoup doing that, so the following code is not tested. What is using the NTLM support in libcamel, then? --- evolution-data-server-2.24.5.orig/camel/camel-sasl-ntlm.c +++ evolution-data-server-2.24.5/camel/camel-sasl-ntlm.c @@ -72,7 +72,7 @@ return type; } -#define NTLM_REQUEST "NTLMSSP\x00\x01\x00\x00\x00\x06\x82\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00" +#define NTLM_REQUEST "NTLMSSP\x00\x01\x00\x00\x00\x05\x82\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00\x00\x00\x00\x00\x30\x00\x00\x00" #define NTLM_CHALLENGE_NONCE_OFFSET 24 #define NTLM_CHALLENGE_DOMAIN_OFFSET 48 @@ -124,20 +124,33 @@ memcpy (ret->data + NTLM_RESPONSE_FLAGS_OFFSET, NTLM_RESPONSE_FLAGS, sizeof (NTLM_RESPONSE_FLAGS) - 1); + const gchar *charset; + g_get_charset (&charset); + + gsize user_len; + gchar *user_conv = g_convert (sasl->service->url->user, -1, "UCS-2LE", charset, NULL, &user_len, NULL); + + gsize domain_len; + gchar *domain_conv = g_convert ((const char *) token->data + NTLM_CHALLENGE_DOMAIN_OFFSET, -1, "UCS-2LE", charset, NULL, &domain_len, NULL); + + printf("Before: %s,%s length %d,%d\n", (const char *) token->data + NTLM_CHALLENGE_DOMAIN_OFFSET, sasl->service->url->user, domain_len, user_len); + + ntlm_set_string (ret, NTLM_RESPONSE_DOMAIN_OFFSET, - (const char *) token->data + NTLM_CHALLENGE_DOMAIN_OFFSET, - atoi ((char *) token->data + NTLM_CHALLENGE_DOMAIN_LEN_OFFSET)); + domain_conv, domain_len); ntlm_set_string (ret, NTLM_RESPONSE_USER_OFFSET, - sasl->service->url->user, - strlen (sasl->service->url->user)); + user_conv, user_len); ntlm_set_string (ret, NTLM_RESPONSE_HOST_OFFSET, - "UNKNOWN", sizeof ("UNKNOWN") - 1); + "", 0); ntlm_set_string (ret, NTLM_RESPONSE_LM_RESP_OFFSET, (const char *) lm_resp, sizeof (lm_resp)); ntlm_set_string (ret, NTLM_RESPONSE_NT_RESP_OFFSET, (const char *) nt_resp, sizeof (nt_resp)); sasl->authenticated = TRUE; + + g_free (domain_conv); + g_free (user_conv); return ret; }
I have improved the libsoup patches, and submitted them in a separate bug report, see http://bugzilla.gnome.org/show_bug.cgi?id=576838.
Created attachment 131425 [details] [review] Final patch in use here
Matt/Milan: Could one of you do a review of it ?
I believe Matt has better overview on NTLM these days. What about waiting on bug #576838 and then do the same? As I believe Dan has there also quite good knowledge, and if something will be required to change, then it can be done only once, not couple times on both sides.
*** Bug 583215 has been marked as a duplicate of this bug. ***
The "evolution-exchange" package only supports Exchange 2000 and 2003 servers. Newer versions such as Exchange 2007 and 2010 are not supported by "evolution-exchange". It is required to use the package "evolution-ews" (or to some extend "evolution-mapi") for newer version fo Exchange servers. If the problem/request described in this report still happens with a recent version of "evolution-ews" or "evolution-mapi", please add a comment to this report (and update the "product" setting accordingly if possible). There are currently no plans to continue the development of the package "evolution-exchange", so this report will soon be closed as WONTFIX. Thanks for your understanding and sorry that the reported problem was not solved in time in the package "evolution-exchange".
evolution-exchange only supports the older Microsoft Exchange server versions 2000 and 2003. The last stable release of evolution-exchange was 3.4.4 which took place a year ago. evolution-exchange is now deprecated and not under active development anymore. It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping. Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again. Also feel free to reopen this ticket and change the "Product" field accordingly if the reported issue still happens with a recent version (newer than version 3.6) of one of those Exchange backends that are still supported. Please see https://help.gnome.org/users/evolution/3.8/exchange-connectors-overview.html for more information on available backends.