Bug 1309041

Summary: Login popup in Windows Chrome and IE browsers to a IPA 4.2 server
Product: Red Hat Enterprise Linux 7 Reporter: Eugene Keck <ekeck>
Component: mod_auth_gssapiAssignee: Robbie Harwood <rharwood>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: aakbar, aheverle, cheimes, ebeaudoi, hsavolai, jacob.block, jpazdziora, jperezve, ksiddiqu, maugusti, minyu, mkosek, optak, pasik, pvoborni, rharwood, spoore, ssorce, tscherf
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: mod_auth_gssapi-1.5.1-5.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: 2018-04-10 14:48:37 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:
Bug Depends On:    
Bug Blocks: 1396494, 1420851, 1473612    

Description Eugene Keck 2016-02-16 17:55:39 UTC
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 14:11:19 UTC
*** Bug 1310834 has been marked as a duplicate of this bug. ***

Comment 3 Simo Sorce 2016-03-22 14:11:58 UTC
*** Bug 1313199 has been marked as a duplicate of this bug. ***

Comment 4 Simo Sorce 2016-03-22 14:13:23 UTC
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 11:24:14 UTC
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 11:40:04 UTC
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 13:17:09 UTC
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 10:46:16 UTC
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 12:42:34 UTC
Martin can we get someone to test chrome 5.8 ?

Comment 15 Martin Kosek 2017-05-25 14:15:00 UTC
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 08:44:56 UTC
Not release in RHEL yet, sorry

Comment 20 Simo Sorce 2017-07-03 10:05:11 UTC
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 11:12:30 UTC
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.

Comment 31 Scott Poore 2018-01-31 13:26:46 UTC
Verified.

Version::

mod_auth_gssapi-1.5.1-5.el7.x86_64

Results::

# Testing with IPA server, add BrowserMatch line to ipa.conf:

[root@ipaserver ~]# vi /etc/httpd/conf.d/ipa.conf
...
<Location "/ipa">
  AuthType GSSAPI
  AuthName "Kerberos Login"
  BrowserMatch MSIE gssapi-no-negotiate
...

[root@ipaserver ~]# systemctl restart httpd

[root@ipaserver ~]# klist
klist: Credentials cache keyring 'persistent:0:0' not found

[root@ipaserver ~]# curl -v --negotiate -u: https://ipaserver.ipa.test/ipa/session/login_kerberos --cacert /etc/ipa/ca.crt 2>&1|grep  "WWW-Authenticate: Negotiate"
< WWW-Authenticate: Negotiate

#^^ with default user-agent, we see Negotiate

[root@ipaserver ~]# curl -A 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/5.0)' -v --negotiate -u: https://ipaserver.ipa.test/ipa/session/login_kerberos --cacert /etc/ipa/ca.crt 2>&1|grep  "WWW-Authenticate: Negotiate"
[root@ipaserver ~]# 

#^^ with MSIE user-agent we do not see negotiate because mod_auth_gssapi skips with gssapi-no-negotiate environment variable set.

Comment 32 Scott Poore 2018-01-31 14:13:43 UTC
Also note, that I did a quick test with the following BrowserMatch line with MSIE and Chrome from Windows :

  BrowserMatch Windows gssapi-no-negotiate

Neither browser showed a popup with that set.

Comment 35 errata-xmlrpc 2018-04-10 14:48:37 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0827