User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E; InfoPath.3; rv:11.0) like Gecko Steps to reproduce: Updated from Firefox 34 to Version 35. Actual results: Kerberos-Authentication on all Intranet-Sites is broken. Comparing the debug-output (nspr_log_modules=negotiateauth:5) there is one big difference between 34 and 35. The latter for uses the cname (intranet.mydomain.at) instead of the (reverse lookup) hostname (myintraserver05). 0: service = stp-linz 0: using negotiate-sspi 0: nsAuthSSPI::Init 0: InitSSPI 0: Using SPN of [HTTP/intranet.mydomain.at] 0: AcquireCredentialsHandle() succeeded. 0: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] 0: entering nsAuthSSPI::GetNextToken() 0: InitializeSecurityContext: continue. 0: Sending a token of length 40 Expected results: I didn't find an entry in changelog concerning this issue, so I think it is an bug of Version 35. In IE and Chrome the configuration works, as it did in Firefox up to Version 34.
sorry, I made a mistake: in line one of the debug output should be written "service = intranet.mydomain.at", because I replaced that in line five.
Confirming per bug 1121461, but this seems to have more specific info about what's wrong. Patrick, do you know what could have broken this for 35?
I almost wonder if this is due to bug 1048468... Hans Peter, do your systems use a pac file?
Yes, we do use a PAC file. Other than described in https://bugzilla.mozilla.org/show_bug.cgi?id=1048468 we had no performance-isses with Firefox at our sites. Intranet sites are listed not to use proxy our PAC file, the Internet proxy should not be involved with DNS resolution, I guess.
I think it is the same as 1108971