Bug 1309041 - Login popup in Windows Chrome and IE browsers to a IPA 4.2 server
Login popup in Windows Chrome and IE browsers to a IPA 4.2 server
Status: ON_QA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mod_auth_gssapi (Show other bugs)
7.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Robbie Harwood
ipa-qe
:
: 1310834 1313199 (view as bug list)
Depends On:
Blocks: 1396494 1420851 1473612
  Show dependency treegraph
 
Reported: 2016-02-16 12:55 EST by Eugene Keck
Modified: 2017-10-19 14:29 EDT (History)
16 users (show)

See Also:
Fixed In Version: mod_auth_gssapi-1.5.1-3.el7
Doc Type: Bug Fix
Doc Text:
Cause: Windows (IE, Chrome, and Edge but not Firefox) incorrectly handle negotiate requests and fall back to (insecure) NTLM. Consequence: These clients unexpectedly display a login popup when trying to connect to an IPA server, or any other mod_auth_gssapi instance that specifies more than one mech. Fix: Added a configuration directive to suppress sending negotiate requests based on user agent if more than one mech is configured. Result: Deployments can set `BrowserMatch Windows gssapi-no-negotiate` and no login prompt will be displayed for the problematic clients.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eugene Keck 2016-02-16 12:55:39 EST
Description of problem:
Login popup in Windows Chrome and IE browsers to a IPA 4.2 server

Version-Release number of selected component (if applicable):
mod_auth_gssapi.1.3.1-1.el7

How reproducible:
always

Steps to Reproduce:
1. Login to a IPA 4.2 using Chrome/IE on a Windows client

Actual results:
popup

Expected results:
no popup

Additional info:
upstream ticket https://fedorahosted.org/freeipa/ticket/5614
Comment 2 Simo Sorce 2016-03-22 10:11:19 EDT
*** Bug 1310834 has been marked as a duplicate of this bug. ***
Comment 3 Simo Sorce 2016-03-22 10:11:58 EDT
*** Bug 1313199 has been marked as a duplicate of this bug. ***
Comment 4 Simo Sorce 2016-03-22 10:13:23 EDT
It is still not clear that we have a fully working solution, so proposing to move to 7.4 for now.
Comment 6 Martin Kosek 2017-01-02 06:24:14 EST
Related information from Bug 1310834:

(In reply to Petr Vobornik from comment #0)
> This bug is created as a clone of upstream ticket:
> https://fedorahosted.org/freeipa/ticket/5614
> 
> Users are reporting a browser login popup in Windows Chrome (and IE?)
> browsers when attempting to log in to the IPA web UI.
> 
> According to Simo this is Chrome attempting to do NTLM auth by prompting the
> user for credentials.
> 
> An option is being worked on in upstream mod_auth_gssapi to not send
> additional WWW-Authenticate: negotiate requests:
> https://github.com/modauthgssapi/mod_auth_gssapi/pull/65
> 
> The pull request has more gory details on what is happening and why this
> wasn't seen in mod_auth_kerb.

(In reply to Simo Sorce from comment #2)
> Not that the upstream feature only prevents a second request if negotiate
> fails.
> But it will not prevent sending the initial negotiate option.
> 
> So I am not sure that Chrome behavior will see any change in this case.
> People should probably configure chrome to not do ntlm auth by default, it
> is a security issue anyway to allow default ntlm auth to random websites.
Comment 7 Christian Heimes 2017-01-06 06:40:04 EST
I performed a couple of tests on Windows 10 with multiple browsers and multiple installations of FreeIPA

Browser:

* Microsoft Edge 38.14393
* Internet Explorer
* Chrome 55.0.2883

Installations:

* IPA 3.0.0 on RHEL 6.9 with mod_auth_kerb
* IPA 4.4.2 https://ipa.demo1.freeipa.org/ with mod_auth_gssapi

All combinations showed the login pop-up window. The issue was not caused by the transition to mod_auth_gssapi. In fact I'm able to reproduce the issue with a very simple Python script. All browsers show the login pop-up when the server returns a 401 with response header "WWW-Authenticate: Negotiate".
Comment 11 Simo Sorce 2017-05-04 09:17:09 EDT
We added now an option upstream that allow admins to blacklist certain browsers/clients/etc... so that negotiate auth is not offered.

We haven't found any other way to deal with this on our side.
Comment 12 Martin Kosek 2017-05-10 06:46:16 EDT
Great! Can you please point this Bugzilla to respective article or documentation that would help people configure it for typical use case (Chrome/Firefox/IE on Windows)?
Comment 14 Simo Sorce 2017-05-23 08:42:34 EDT
Martin can we get someone to test chrome 5.8 ?
Comment 15 Martin Kosek 2017-05-25 10:15:00 EDT
I assume this should be Chrome 58. I think Petr Vobornik had someone doing these tests, I do not have a Windows machine handy right now.
Comment 18 Simo Sorce 2017-06-23 04:44:56 EDT
Not release in RHEL yet, sorry
Comment 20 Simo Sorce 2017-07-03 06:05:11 EDT
We do not have the means to do this via mod_auth_gssapi options at this point in RHEL.
A possible way to work around this in the interim is to use apache mod_headers to remove the WWW-Authorize headers, so the broewsers never see the negotiat headers and do not try to authenticate that way.

The problem is that authorize headers should act only when the specific browsers having problems are used, so removal must hapeen ONLY when IE or Chrome are being used.

Removing in all cases would break client tools and joining process.
Comment 24 Martin Kosek 2017-08-11 07:12:30 EDT
Info from Christian Heimes: it's a problem in IE, Edge, and Chrome on Windows. They both use the same library to handle authenticate. HTTP Status Code 401 + "WWW-Authenticate: Negotiate" header cause the log-in prompt to pop up.  I was even able to reproduce it with a very simple Python server that just emits the status code and header.

Until this issue is fixed by Microsoft, there is only one workaround: use some sort of browser detection and don't return "WWW-Authenticate: Negotiate" HTTP header for any IE, Edge, and Chrome on Windows.

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