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):
Steps to Reproduce:
1. Login to a IPA 4.2 using Chrome/IE on a Windows client
upstream ticket https://fedorahosted.org/freeipa/ticket/5614
*** Bug 1310834 has been marked as a duplicate of this bug. ***
*** Bug 1313199 has been marked as a duplicate of this bug. ***
It is still not clear that we have a fully working solution, so proposing to move to 7.4 for now.
Related information from Bug 1310834:
(In reply to Petr Vobornik from comment #0)
> This bug is created as a clone of upstream ticket:
> 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:
> 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
> 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.
I performed a couple of tests on Windows 10 with multiple browsers and multiple installations of FreeIPA
* Microsoft Edge 38.14393
* Internet Explorer
* Chrome 55.0.2883
* 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".
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.
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)?
Martin can we get someone to test chrome 5.8 ?
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.
Not release in RHEL yet, sorry
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.
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.
# Testing with IPA server, add BrowserMatch line to ipa.conf:
[root@ipaserver ~]# vi /etc/httpd/conf.d/ipa.conf
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"
#^^ with MSIE user-agent we do not see negotiate because mod_auth_gssapi skips with gssapi-no-negotiate environment variable set.
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.
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.