Bug 1110291 - browsers fail to login to IIS sites after update
Summary: browsers fail to login to IIS sites after update
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-17 11:31 UTC by Samo Dadela
Modified: 2014-06-18 10:59 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-06-17 16:18:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.