1121461 - network.negotiate-auth.trusted-uris stopped working with Update to FF35.0

Status: RESOLVED DUPLICATE of bug 1121843

(Firefox :: Untriaged, defect)

Description

[Michael Kesper]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.3.0
Build ID: 20141203154826

Steps to reproduce:

Commaspace separated values are set for network.negotiate-auth.trusted-uris and work with FF34, making Kerberos authentication possible.
Example values: .example.com, .example2.com
(These sites are accessed via HTTP)
Update to FF35.


Actual results:

Kerberos authentication stops working.


Expected results:

Kerberos authentication continues working as before.

Comment 1

[Brandon Stephens]

I can confirm this issue. 

User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
BuildID	20150108202552

Kerberos auth worked properly in 34. After upgrading to 35, it will only negotiate Basic

I've tried several permutations of the network.negotiate-auth.trusted-uris values

.example.com
site.example.com
https://site.example.com

All negotiate basic.

Comment 2

[:Gijs (he/him)]

(In reply to Brandon Stephens from comment #1)
> I can confirm this issue. 
> 
> User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101
> Firefox/35.0
> BuildID	20150108202552
> 
> Kerberos auth worked properly in 34. After upgrading to 35, it will only
> negotiate Basic
> 
> I've tried several permutations of the network.negotiate-auth.trusted-uris
> values
> 
> .example.com
> site.example.com
> https://site.example.com
> 
> All negotiate basic.

Is this what it ends up as, or have you verified that there are no attempts to use kerberos at all?

I'm asking because someone else filed bug 1121654, which looks like it would explain that it "stops working", but it contains more specifics about what is wrong. Is that plausible, or are you seeing something else?

Comment 3

[Brandon Stephens]

Wireshark shows that firefox is responding with only one negotiate attempt that looks very much like NTLM.

Authorization: Negotiate TXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXw==

This is what I see on the server side logs:

[Wed Jan 14 16:18:47 2015] [debug] src/mod_auth_kerb.c(1496): [client xxx.xxx.xxx.xxx] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Wed Jan 14 16:18:47 2015] [debug] src/mod_auth_kerb.c(1496): [client xxx.xxx.xxx.xxx] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Wed Jan 14 16:18:47 2015] [debug] src/mod_auth_kerb.c(1151): [client xxx.xxx.xxx.xxx] Acquiring creds for [e-mail]
[Wed Jan 14 16:18:47 2015] [debug] src/mod_auth_kerb.c(1270): [client xxx.xxx.xxx.xxx] Verifying client data using KRB5 GSS-API
[Wed Jan 14 16:18:47 2015] [debug] src/mod_auth_kerb.c(1286): [client xxx.xxx.xxx.xxx] Verification returned code 589824
[Wed Jan 14 16:18:47 2015] [debug] src/mod_auth_kerb.c(1313): [client xxx.xxx.xxx.xxx] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Wed Jan 14 16:18:47 2015] [error] [client xxx.xxx.xxx.xxx] gss_accept_sec_context() failed: Invalid token was supplied (No error)

If I remove the server from trusted uri's all I see is:

[Wed Jan 14 16:24:23 2015] [debug] src/mod_auth_kerb.c(1496): [client xxx.xxx.xxx.xxx] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos


Obviously some info is scrubbed. However, it doesn't appear that firefox ever attempts to negotiate kerberos. Browser console shows only the initial GET and then the GET with an NTLM looking Negotiation. 

As an aside, both IE and Chrome are successfully using Kerberos to transparently authenticate to this server form this client. I've tested the upgrade process on another client and the results are the same. Works under 34 stop in 35.

Comment 4

[Michael Kesper]

My issue seems to be the same as in bug1108971, by rechecking I can confirm calling sites directly, not per aliases, work.

Comment 6

[:Gijs (he/him)]

(In reply to Michael Kesper from comment #4)
> My issue seems to be the same as in bug1108971, by rechecking I can confirm
> calling sites directly, not per aliases, work.

Thanks! I've duped to bug 1121843, which is already in the right component and where we're trying to figure out exactly on which changeset this stopped working.

Comment 7

[Dragana Damjanovic [:dragana]]

As Michael suggested in comment 4 it is probably bug 1108971

I made patch and i will have a build that he can try soon


https://treeherder.mozilla.org/#/jobs?repo=try&revision=087449621dfa