|
Bugzilla – Full Text Bug Listing |
| 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: | Firefox | Assignee: | 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 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
OpenSUSE firefox logs
Downloaded firefox logs |
||
Created attachment 812665 [details]
Downloaded firefox logs
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".
|
Created attachment 812664 [details] OpenSUSE firefox logs Hello, 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.