Hello Mozilla community
I’m troubleshooting a Kerberos/SPNEGO proxy auth issue and need help understanding whether this is a Firefox bug or a misconfiguration on our sid… (lire la suite)
Hello Mozilla community
I’m troubleshooting a Kerberos/SPNEGO proxy auth issue and need help understanding whether this is a Firefox bug or a misconfiguration on our side.
Environment :
Client OS: Ubuntu 24.04 (GNOME session)
Firefox: 144.0
Other clients on same host: curl (works) and Chrome/Chromium (works)
Proxy (on-prem): swg.test.local:8080 (HTTP proxy performing Negotiate/Kerberos authentication)
AD / Kerberos realm: TEST.LOCAL (users), service SPN: HTTP/swg.test.local registered in AD
Domain trust: one-way trust exists between test.local and test.intra (contextual; but current test is within test.local)
Symptom :
curl --proxy http://swg.test.local:8080 --proxy-negotiate -u : http://example.com
-> negotiates and sends Proxy-Authorization: Negotiate ... and request succeeds.
Chrome also performs Negotiate and the request succeeds.
Firefox never sends Proxy-Authorization: Negotiate and the proxy returns 407 Proxy Authentication Required. No prompt for credentials; negotiation does not start.
What I already validated
Kerberos TGT is present in user cache:
kinit user@test.local
klist
TGT is visible and valid.
curl and Chrome negotiate successfully from the same host (so SPN, AD, keytab, realm mapping are working in general).
Firefox launched from terminal (so it inherits KRB5CCNAME) still does not negotiate.
I enabled KRB5_TRACE and launched Firefox; trace file stays empty (suggesting Firefox did not call into GSSAPI for this request).
Network capture shows proxy challenge Proxy-Authenticate: Negotiate and no corresponding Proxy-Authorization header from Firefox.
Firefox prefs checked / set
(About:config values I validated/changed)
network.negotiate-auth.trusted-uris = swg.test.local,.test.local
→ Ensures Firefox will send Kerberos tokens to that host/domain.
network.negotiate-auth.delegation-uris = .test.local (optional)
network.auth.use-sspi = false (Linux)
network.negotiate-auth.allow-non-fqdn = false
network.automatic-ntlm-auth.trusted-uris left blank or set to .test.local
Despite network.negotiate-auth.trusted-uris containing the exact FQDN and domain, Firefox still does not attempt negotiation.
Diagnostics already captured
tcpdump pcap covering UDP/TCP 88 and proxy port 8080 (shows proxy 407 and absence of Proxy-Authorization from Firefox)
KRB5_TRACE=/tmp/krb5_trace.log for Firefox launch (no GSS calls logged)
Reproduced curl/Chrome flows that do include Proxy-Authorization: Negotiate ...
Hypothesis
Firefox is refusing to attempt Negotiate at all — likely due to either:
a preference that’s still missing or misinterpreted (trusted-uris format, wildcard/domain handling), or
a desktop-launch / environment isolation problem (GUI-launched Firefox not seeing Kerberos credentials or environment), or
a bug/regression in Firefox’s GSSAPI/SPNEGO integration on Linux (e.g., refusing to use a credentials cache inherited from the shell, or ignoring network.negotiate-auth.trusted-uris for proxy authorization specifically).
What I need from the community
Has anyone seen Firefox on Linux behave this way (curl/Chrome work, Firefox never starts Negotiate) with an on-prem proxy using Proxy-Authenticate: Negotiate?
Any additional about:config prefs or hidden flags that affect proxy SPNEGO (not site SPNEGO) that I should check? I already set network.negotiate-auth.trusted-uris.
Any differences in behavior between Firefox launched from GUI vs. launched from terminal that might cause the client not to use the Kerberos ticket cache — and reliable steps to reproduce/diagnose?
If you have a small reproducible test case or a recommended debug build/flags to capture verbose Firefox GSSAPI logs (beyond KRB5_TRACE) please share them.
If this is a known bug/regression, pointer to the bugtracker entry would be appreciated.
Thanks in advance
