Bug 1144105

Summary: Firefox fails and give up NTLM proxy authentication without asking the user for password
Product: [openSUSE] openSUSE Tumbleweed Reporter: Luiz Angelo Daros de Luca <luizluca>
Component: FirefoxAssignee: Mozilla Bugs <mozilla-bugs>
Status: NEW --- QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None    
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: OpenSUSE firefox logs
Downloaded firefox logs

Description Luiz Angelo Daros de Luca 2019-08-02 21:26:04 UTC
Created attachment 812664 [details]
OpenSUSE firefox logs


We have a squid4 using auth BASIC, NTML, NEGO (SPNEGO, Kerberos) against an Win Active Directory.

Windows clients work both for local and domain users, firefox and google-chrome.

OpenSUSE clients work for all methods for curl and google-chrome. Firefox works with kerberos. When Kerberos TGT is not available, chrome asks user for password and do a NTLM auth. Firefox, however, simply returns an access denied page without asking for a password.

If I disable NTLM auth in squid, both google-chrome and firefox uses BASIC when Kerberos is not usable (as expected).

I noticed that firefox starts the NTLM challenge but it aborts after squid answer the first request with an NTLM header field. It never asked user for a password and there is no easy way to skip NTLM for firefox but to disable it in squid.

I downloaded firefox from firefox.org and it worked as expected. When kerberos is not available, it asks user for password and authenticate using NTLM.

I'll attach some debug logs from opensuse firefox and download firefox. It looks like with the opensuse one, it thinks it gets user/password from "somewhere":

 D/nsHttp Resuming the transaction, we got credentials from user

But it never sent it to squid (as it might not actually have a password).

The downloaded firefox fails to use sys-ntlm and uses its internal auth:

[Parent PID: Main Thread]: V/nsHttp Native sys-ntlm auth module not found.
[Parent PID: Main Thread]: V/nsHttp Trying to fall back on internal ntlm auth.

Our machines normally does not use winbind as sssd provides everything for domain login. I did started winbindd just to give "a try", but it still does not work nor it asks for password.

If there is some kind of SSO authentication with NTLM in Linux (is it?), it should fallback to user-provided password if it fails. Or, in the worst case scenario, firefox should skip to BASIC auth.

I'm reluctant to disable NTLM in squid only because OpenSUSE firefox is failing, which represents just a fraction of our clients.
Comment 1 Luiz Angelo Daros de Luca 2019-08-02 21:26:24 UTC
Created attachment 812665 [details]
Downloaded firefox logs
Comment 2 Luiz Angelo Daros de Luca 2019-08-09 19:50:07 UTC
If I set:

 user_pref("network.auth.force-generic-ntlm", true);

It skips Samba integration and it works as expected. Instead of asking for a password and do a "Generic NTLM" or "BASIC", it is bailing out.

I can authenticate manually with ntlm_auth:

 ntlm_auth --use-cached-creds --username $USER
 Password: **********
 NT_STATUS_OK: The operation completed successfully. (0x0)

I did a strace in ntlm_auth called by firefox:

 read(0, "YR\n", 4096)                   = 3
 write(1, "YR TlRMTVNTUAABAAAABYIIYgAAAAAoA"..., 60) = 60
 read(0, "TT TlRMTVNTUAACAAAAEgASADgAAAAFg"..., 4096) = 332
 write(1, "PW", 2)                       = 2

According to this https://github.com/samba-team/samba/blob/master/source3/utils/ntlm_auth.c#L251, ntlm_auth is asking the caller for a password. So, firefox now should popup now a password dialog. It did not and it returned the "access denied" page.

Firefox was expecting KK or AF, not PW (https://github.com/mozilla/gecko-dev/blob/master/extensions/auth/nsAuthSambaNTLM.cpp#L234). I don't know where that "password" should be.

It is OK for firefox to try some kind of SSO integration with NTLM (does NTLM SSO really exist in Linux?) but it is not OK to simply abort without alternatives if it does not work.

I can also workaround this issue by removing /usr/bin/ntlm_auth, forcing it to fallback to "Generic NTLM".