Bug 1110291

Summary:	browsers fail to login to IIS sites after update
Product:	[Fedora] Fedora	Reporter:	Samo Dadela <samo_dadela>
Component:	firefox	Assignee:	Martin Stransky <stransky>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	20	CC:	fweimer, gecko-bugs-nobody, kengert, stransky
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-17 16:18:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Samo Dadela 2014-06-17 11:31:57 UTC

Description of problem:

After yum update firefox and midori fail to authenticate to IIS sites. Chrome works OK. Must be some lib used by both ff and midori (update component accordingly). I tried also deleting .mozilla and creating a fresh user (su- to it) - nothing helps.

Version-Release number of selected component (if applicable):
ff 30 (fc 20 updated fully on 17.6.2014), ask for addl component versions

How reproducible:
Log in to a IIS based site. You will get just 401 or the site won't work (blank page). 

On one site I get:

You are not authorized to view this page
You do not have permission to view this directory or page using the credentials that you supplied because your Web browser is sending a WWW-Authenticate header field that the Web server is not configured to accept. 

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Martin Stransky 2014-06-17 11:37:21 UTC

Kaie, any idea here?

Comment 2 Kai Engert (:kaie) (inactive account) 2014-06-17 12:43:10 UTC

I need more details. Can you point us to a public URL where we can see the problem?

Is this a password-popup authentication (basic auth)? Is https involved?

Comment 3 Samo Dadela 2014-06-17 14:13:01 UTC

All the sites I tried use windows authentication. A pop-up opens asking for a username/password. The username I enter is in the format: DOMAIN\me 

I don't know of any public systems that use this auth. However as said all IIS based sites in my company stopped working. You can try some SharePoint sites if you have any.

What happens is that the pop-up does not appear (as it does from other machines (linux/windows) and fc20 google-chrome).

No https.

Is there some component used by both ff and midori that handles the auth? 
Was it updated recently?

Comment 4 Samo Dadela 2014-06-17 14:33:46 UTC

By comparing ff and chrome, I found that both get first a:
"HTTP/1.1 401 Unauthorized"

... ff stops there, but chrome continues with:
GET / HTTP/1.1
Host: xxxxxxxxx
Connection: keep-alive
Authorization: NTLM

Comment 5 Kai Engert (:kaie) (inactive account) 2014-06-17 16:17:52 UTC

Thanks for the details.

I see that upstream Firefox has disabled support for insecure NTLMv1 in Firefox 30.
See https://bugzilla.mozilla.org/show_bug.cgi?id=828183

I also see, they have introduced a pref for users who really really want to continue using the insecure mechanism (see: https://bugzilla.mozilla.org/show_bug.cgi?id=999306 )

I found this page with info:
http://www.janbambas.cz/ntlm-v1-and-firefox/

Use at your own risk.

Comment 6 Samo Dadela 2014-06-18 07:46:53 UTC

OK, so by setting (at my own risk): 
network.negotiate-auth.allow-insecure-ntlm-v1 in about:config to true.

FF 30 works. I get the credentials dialog as before and I can access the site.

What about midori? Should I open a new bug?

Comment 7 Martin Stransky 2014-06-18 07:50:07 UTC

(In reply to Samo Dadela from comment #6)
> What about midori? Should I open a new bug?

Yes please.

Comment 8 Samo Dadela 2014-06-18 10:59:32 UTC

Bug 1110734 - midori fails to login to IIS sites after update 
https://bugzilla.redhat.com/show_bug.cgi?id=1110734

Thanks.