857483 - Kerberos authentication doesn't work after FF 20 update

Status: RESOLVED DUPLICATE of bug 857291

(Core :: Networking: HTTP, defect)

Description

[Krzysztof Witkowski]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130326150557

Steps to reproduce:

I have update FF to version 20 (automatic update) and go to one of my commonly used intranet services.


Actual results:

Integrated authentication via Kerberos does'n work (request for user and password)
Client: Windows 7 64bit Pro 
Server: linux, apache 2.2.3, mod_auth_kerb-5.1-5.el5
Active Directory (DC on 2008R2)
network.negotiate-auth.trusted-uris = set to name of my server


Expected results:

FF should automatically log me in to intranet service.

Comment 1

[Kaarlo Mäkelä]

I'm having this same issue, please fix this asap.

Comment 2

[Steven Singer]

I'm having the same problems after an upgrade from SeaMonkey 2.16 to SeaMonkey 2.17. Downgrading resolved the problem.

Wireshark traces show that authentication is being handled differently before and after the upgrade.

The server in question responds saying it will accept either negotiate or basic authentication.

In both cases, SeaMonkey correctly tries to perform negotiate authentication.

However, in the 2.16 case, decoding the authentication token shows that it's using GSS-API SPNEGO (OID: 1.3.6.1.5.5.2) whereas in the 2.17 case it shows it's using NTLMSSP.

In the 2.16 case, the SPNEGO mechanisms sent by SeaMonkey are Microsoft Kerberos 5 (1.2.840.48010.1.2.2), Kerberos 5 (1.2.840.113554.1.2.2), 1.3.6.1.4.1.311.2.2.30 (whatever that is) and NTLMSSP (1.3.6.1.4.1.311.2.2.10).

I suspect the server in question wants Kerberos authentication.

I'm on Windows 7 64 bit.

network.negotiate-auth.using-native-gsslib is set to true.

The URIs in question do not use FQDNs. Using alternate URIs with FQDNs doesn't help.

This has pretty much broken single sign on to a wide variety of intranet sites and badly affected day-to-day usability of SeaMonkey.

Nothing in the changes listed from the release notes (http://www.seamonkey-project.org/releases/seamonkey2.17/changes, http://www.mozilla.org/security/known-vulnerabilities/seamonkey.html) seems to have been deliberately changing this.

SeaMonkey 2.16
==============

SeaMonkey->Server
-----------------

GET / HTTP/1.1
Host: wiki
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

Server->SeaMonkey
-----------------

HTTP/1.1 401 Authorization Required
Date: Wed, 03 Apr 2013 13:57:18 GMT
Server: Apache/2.2.3 (CentOS)
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Wiki"
X-Powered-By: PHP/5.1.6
Content-Length: 205
Connection: close
Content-Type: text/html; charset=UTF-8
[... document contents removed as they're not relevant ...]

SeaMonkey->Server
-----------------

GET / HTTP/1.1
Host: wiki
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Authorization: Negotiate YIILMAY[...rest removed for security reasons, see decode above...]

SeaMonkey 2.17
==============

SeaMonkey->Server
-----------------

GET / HTTP/1.1
Host: wiki
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

Server->SeaMonkey
-----------------

HTTP/1.1 401 Authorization Required
Date: Wed, 03 Apr 2013 13:47:24 GMT
Server: Apache/2.2.3 (CentOS)
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Wiki"
X-Powered-By: PHP/5.1.6
Content-Length: 205
Connection: close
Content-Type: text/html; charset=UTF-8
[... document contents removed as they're not relevant ...]

SeaMonkey->Server
-----------------

GET / HTTP/1.1
Host: wiki
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Authorization: Negotiate TlRMTVN[...rest removed for security reasons, see decode above...]

Comment 3

[Loic]

Maybe a dupe of bug 804605.

Comment 4

[Steven Singer]

> I'm on Windows 7 64 bit.

Correction: 32 bit (Professional SP1). But I don't think it matters.

Comment 5

[Krzysztof Witkowski]

(In reply to Loic from comment #3)
> Maybe a dupe of bug 804605.

I don't think so. I have changed CNAME record to A and problem still exists.

Comment 6

[Andriy Syrovenko]

(In reply to Krzysztof Witkowski from comment #5)
> (In reply to Loic from comment #3)
> > Maybe a dupe of bug 804605.
> 
> I don't think so. I have changed CNAME record to A and problem still exists.

Have you registered an SPN for your new A record as well?

Comment 7

[Krzysztof Witkowski]

(In reply to Andriy Syrovenko from comment #6)
> (In reply to Krzysztof Witkowski from comment #5)
> > (In reply to Loic from comment #3)
> > > Maybe a dupe of bug 804605.
> > 
> > I don't think so. I have changed CNAME record to A and problem still exists.
> 
> Have you registered an SPN for your new A record as well?

No, but Google Chrome after this change (CNAME -> A) cannot authenticate too. Reverse change (A->CNAME) solved problem with Google Chrome (not FF)

Comment 9

[Steven Singer]

I can confirm that this has been resolved in SeaMonkey 2.17.1 (which contains the fix for bug 857291).