User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150108202552 Steps to reproduce: Access a local (same PC as Firefox) virtual host website that requires SPNEGO authentication and is defined in your hosts file (so doesn't have a DNS server record). Actual results: HTTP status code "401 Authorization Required" is returned. Expected results: The single sign-on should work and the web page should be displayed. Further information ============== We use SPNEGO authentication (via Apache with mod_auth_sspi on Windows [Active Directory]) for single sign-on to intranet applications. Each application is accessed like so: abc.company.net 123.company.net ... To enable single sign-on we modify Firefox installations as follows: network.automatic-ntlm-auth.trusted-uris = .company.net network.negotiate-auth.trusted-uris = .company.net For live website addresses (those with a DNS server record) everything works as expected. The problem seems to be directly related to entries defined in the local hosts file. Developers have a web server installed locally. Aliases are added to the hosts file like this: 127.0.0.1 localhost dev-abc.company.net dev-123.company.net ... This works as expected with Firefox 34.0.5 and fails with Firefox 35.0.
since you have aliases this is duplicate of 1108971
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1108971
Also make sure you have filled HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames with your local host alias if you (the Apache instance) are (is) using the SSPI provider on the local machine.
(In reply to Honza Bambas (:mayhemer) from comment #2) > Also make sure you have filled > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnection > HostNames with your local host alias if you (the Apache instance) are (is) > using the SSPI provider on the local machine. That only seems to apply to IIS and NTLM. We are using Apache and Kerberos (NTLM is explicitly disabled). In the interest of thoroughness I did try it (using instructions gleaned from http://support.microsoft.com/kb/896861); it did not resolve the problem.
You need to log in before you can comment on or make changes to this bug.