Yeah sorry, the debug logs were not included originally. Re to RPMs, I have 
removed all dupes, they were many. All is clean now and the system is up to 
date.

Attached is the ipa.conf file.



-----Original Message-----
From: Alexander Bokovoy [mailto:aboko...@redhat.com] 
Sent: 18 August 2017 12:24
To: FreeIPA users list
Cc: Troels Hansen; Fraser Tweedale; Stefan Uygur
Subject: Re: [Freeipa-users] Re: web UI - login failed after updates on server

On pe, 18 elo 2017, Stefan Uygur via FreeIPA-users wrote:
>Well, I posted the httpd error.log in the very beginning; that is how I 
>started the conversation.
It did not have enough details I was looking for. Now it does but you didn't 
provide corresponding non-abbreviated gssproxy logs, sorry. 


>
>But here are the fresh logs with debugging enabled in /etc/ipa/server.conf:
>
>[Fri Aug 18 10:53:39.123660 2017] [:error] [pid 20477] ipa: DEBUG: WSGI 
>wsgi_dispatch.__call__:
>[Fri Aug 18 10:53:39.123755 2017] [:error] [pid 20477] ipa: DEBUG: WSGI 
>jsonserver_session.__call__:
>[Fri Aug 18 10:53:39.123805 2017] [:error] [pid 20477] ipa: DEBUG: no 
>ccache, need login [Fri Aug 18 10:53:39.123845 2017] [:error] [pid 
>20477] ipa: DEBUG: 401 Unauthorized need login [Fri Aug 18 
>10:53:39.152712 2017] [auth_gssapi:error] [pid 20479] [client 
>80.169.143.197:56017] NO AUTH DATA Client did not send any authentication 
>headers, referer:
>https://aws-ipa1.example.com.com/ipa/ui/
>[Fri Aug 18 10:53:39.206898 2017] [auth_gssapi:error] [pid 20479] 
>[client 80.169.143.197:56017] GSS ERROR In Negotiate Auth:
>gss_accept_sec_context() failed: [An unsupported mechanism was 
>requested (Unknown error)], referer:
>https://aws-ipa1.example.com.com/ipa/ui/
This corresponds to GSS_S_BAD_MECH error. If client never sent any actual 
GSSAPI credentials, that should not be a problem.

>[Fri Aug 18 10:53:46.693783 2017] [:error] [pid 20478] ipa: DEBUG: WSGI 
>wsgi_dispatch.__call__:
>[Fri Aug 18 10:53:46.693876 2017] [:error] [pid 20478] ipa: DEBUG: WSGI 
>login_password.__call__:
>[Fri Aug 18 10:53:46.694584 2017] [:error] [pid 20478] ipa: DEBUG: 
>Obtaining armor in ccache /var/run/ipa/ccaches/armor_20478 [Fri Aug 18 
>10:53:46.694656 2017] [:error] [pid 20478] ipa: DEBUG: Initializing 
>anonymous ccache [Fri Aug 18 10:53:46.694754 2017] [:error] [pid 20478] 
>ipa: DEBUG: Starting external process [Fri Aug 18 10:53:46.694802 2017] 
>[:error] [pid 20478] ipa: DEBUG: args=/usr/bin/kinit -n -c 
>/var/run/ipa/ccaches/armor_20478 -X 
>X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X 
>X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
>[Fri Aug 18 10:53:46.761498 2017] [:error] [pid 20478] ipa: DEBUG: 
>Process finished, return code=0 [Fri Aug 18 10:53:46.761590 2017] 
>[:error] [pid 20478] ipa: DEBUG: stdout= [Fri Aug 18 10:53:46.761635 
>2017] [:error] [pid 20478] ipa: DEBUG: stderr= [Fri Aug 18 
>10:53:46.761830 2017] [:error] [pid 20478] ipa: DEBUG: Initializing 
>principal suygur using password [Fri Aug 18 10:53:46.761897 2017] 
>[:error] [pid 20478] ipa: DEBUG: Using armor ccache 
>/var/run/ipa/ccaches/armor_20478 for FAST webauth [Fri Aug 18 
>10:53:46.761953 2017] [:error] [pid 20478] ipa: DEBUG: Using enterprise 
>principal [Fri Aug 18 10:53:46.762060 2017] [:error] [pid 20478] ipa: DEBUG: 
>Starting external process [Fri Aug 18 10:53:46.762108 2017] [:error] [pid 
>20478] ipa: DEBUG: args=/usr/bin/kinit suygur -c 
>/var/run/ipa/ccaches/kinit_20478 -T /var/run/ipa/ccaches/armor_20478 -E [Fri 
>Aug 18 10:53:46.793682 2017] [:error] [pid 20478] ipa: DEBUG: Process 
>finished, return code=0 [Fri Aug 18 10:53:46.793767 2017] [:error] [pid 20478] 
>ipa: DEBUG: stdout=Password for suy...@example.com.com:
>[Fri Aug 18 10:53:46.793778 2017] [:error] [pid 20478] [Fri Aug 18 
>10:53:46.793818 2017] [:error] [pid 20478] ipa: DEBUG: stderr= [Fri Aug 
>18 10:53:46.793906 2017] [:error] [pid 20478] ipa: DEBUG: Cleanup the 
>armor ccache [Fri Aug 18 10:53:46.794007 2017] [:error] [pid 20478] 
>ipa: DEBUG: Starting external process [Fri Aug 18 10:53:46.794053 2017] 
>[:error] [pid 20478] ipa: DEBUG: args=/usr/bin/kdestroy -A -c 
>/var/run/ipa/ccaches/armor_20478 [Fri Aug 18 10:53:46.799950 2017] 
>[:error] [pid 20478] ipa: DEBUG: Process finished, return code=0 [Fri 
>Aug 18 10:53:46.800024 2017] [:error] [pid 20478] ipa: DEBUG: stdout= 
>[Fri Aug 18 10:53:46.800072 2017] [:error] [pid 20478] ipa: DEBUG: 
>stderr=
As no GSSAPI authentication happened, password authentication was done and it 
was successful. That should have produced a valid cookie.

>/usr/lib/python2.7/site-packages/urllib3/connection.py:251: 
>SecurityWarning: Certificate has no `subjectAltName`, falling back to 
>check for a `commonName` for now. This feature is being removed by 
>major browsers and deprecated by RFC 2818. (See 
>https://github.com/shazow/urllib3/issues/497 for details.)
>  SecurityWarning
>[Fri Aug 18 10:53:46.829869 2017] [:error] [pid 20477] ipa: DEBUG: WSGI 
>wsgi_dispatch.__call__:
>[Fri Aug 18 10:53:46.829955 2017] [:error] [pid 20477] ipa: INFO: 404 
>Not Found: URL="/ipa/session/cookie", URL fragment "/session/cookie" 
>does not have a handler [Fri Aug 18 10:53:46.831059 2017] [:error] [pid 
>20478] ipa: INFO: 401 Unauthorized: No session cookie found
But this is the part where something wrong happens.

This handler, ipa/session/cookie, is done by mod_auth_gssapi. It is added in 
/etc/httpd/conf.d/ipa.conf as an alias:

Alias /ipa/session/cookie "/usr/share/ipa/gssapi.login"

Anything under /ipa/ is handled by mod_auth_gssapi, so this URL should be 
handled by it too. But the fact that it comes back to IPA as 
/ipa/session/cookie means mod_auth_gssapi wasn't triggered for internal 
subrequest IPA framework did, so we've got no session cookie generated by the 
mod_auth_gssapi.

Can you check /etc/httpd/conf.d/ipa.conf? How does it look like?

>And yes, I have noticed the dups and removed the following packages, thanks:
>
>Removing:
> krb5-libs                   x86_64            1.14.1-27.el7_3            
> @rhui-REGION-rhel-server-releases            1.9 M
>Removing for dependencies:
> krb5-pkinit                 x86_64            1.14.1-27.el7_3            
> @rhui-REGION-rhel-server-releases            124 k
> krb5-workstation            x86_64            1.14.1-27.el7_3            
> @rhui-REGION-rhel-server-releases            2.4 M
> libkadm5                    x86_64            1.14.1-27.el7_3            
> @rhui-REGION-rhel-server-releases            208 k
>
>
>yum update shows no updates so it is at latest of update.
Same was for cyrus-sasl packages.

>
>Thanks
>
>-----Original Message-----
>From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>Sent: 18 August 2017 11:48
>To: FreeIPA users list
>Cc: Troels Hansen; Fraser Tweedale; Stefan Uygur
>Subject: Re: [Freeipa-users] Re: web UI - login failed after updates on 
>server
>
>On pe, 18 elo 2017, Stefan Uygur via FreeIPA-users wrote:
>>I have reproduced what you requested below. Each line where you see 
>>Client connected is my attempt to login via web UI.
>>
>>As you can see there are no issues, at least from what I read/see. 
>>Just to repeat what I said at the beginning of my post, the IPA itself 
>>is fully functional, it is the web part that is not working. I can do 
>>all operation normally via the command line on the shell side.
>It would have helped to have actual logs attached, not cut off.
>
>If you have IPA CLI working fine, then looking into browser's developer tools' 
>network traffic pane would be helpful too. There are very few operations where 
>web UI differs from the IPA CLI and they are mostly in the initial requests 
>and password authentication.
>
>So if IPA CLI is working fine, we can concentrate on password auth part as IPA 
>CLI uses Kerberos authentication. Web UI, when using username/password will 
>request IPA framework to do Kerberos auth for you on the server side and then 
>store that as a cookie.
>
>For debugging password auth, please add a file called
>/etc/ipa/server.conf:
>
>[global]
>debug=True
>
>and restart httpd (systemctl restart httpd). Then connect with a browser and 
>you'll get a detailed trace of how IPA framework performs its operations in 
>/var/log/httpd/error_log. Please attach that one.
>
>Can you also show sssd.conf?
>
>Also, you seem to have an issue with upgrade process -- the packages are 
>duplicated with old and new version. This is particularly worrying for 
>krb5-libs as 1.15.1 has new APIs we use. Same with cyrus-sasl.
>
>Any chance you can complete upgrade transaction and get rid of older packages?
>
>>
>>-- Logs begin at Thu 2017-08-17 14:26:42 UTC, end at Fri 2017-08-18
>>10:28:06 UTC. -- Aug 17 14:26:47 ipa.example.com systemd[1]: Starting GSSAPI 
>>Proxy Daemon...
>>Aug 17 14:26:47 ipa.example.com systemd[1]: Started GSSAPI Proxy Daemon.
>>Aug 18 10:26:54 ipa.example.com systemd[1]: Stopping GSSAPI Proxy Daemon...
>>Aug 18 10:26:54 ipa.example.com systemd[1]: Starting GSSAPI Proxy Daemon...
>>Aug 18 10:26:54 ipa.example.com gssproxy[19280]: [2017/08/18 10:26:54]:
>>Debug Enabled (level: 2) Aug 18 10:26:54 ipa.example.com
>>gssproxy[19280]: [2017/08/18 10:26:54]: Problem with kernel 
>>communication!  NFS Aug 18 10:26:54 ipa.example.com gssproxy[19280]: 
>>[2017/08/18 10:26:54]: Client connected (fd = 10)[2017/08/18 1 Aug 18 
>>10:26:54 ipa.example.com systemd[1]: Started GSSAPI Proxy Daemon.
>>Aug 18 10:27:45 ipa.example.com gssproxy[19280]: [2017/08/18 10:27:45]:
>>Client connected (fd = 11)[2017/08/18 1 Aug 18 10:27:45 
>>ipa.example.com
>>gssproxy[19280]: [2017/08/18 10:27:45]: gp_rpc_execute: executing 6 
>>(GSSX_ACQUI Aug 18 10:27:45 ipa.example.com gssproxy[19280]:
>>GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  ] } input_cred_handle Aug 18
>>10:27:45 ipa.example.com gssproxy[19280]: GSSX_RES_ACQUIRE_CRED(
>>status: { 0 { 1 2 840 113554 1 2 2 } 0 Aug 18 10:27:45 ipa.example.com
>>gssproxy[19280]: [2017/08/18 10:27:45]: gp_rpc_execute: executing 6 
>>(GSSX_ACQUI Aug 18 10:27:45 ipa.example.com gssproxy[19280]:
>>GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  ] } input_cred_handle Aug 18
>>10:27:45 ipa.example.com gssproxy[19280]: GSSX_RES_ACQUIRE_CRED(
>>status: { 0 { 1 2 840 113554 1 2 2 } 0 Aug 18 10:28:06 ipa.example.com
>>gssproxy[19280]: [2017/08/18 10:28:06]: Client connected (fd =
>>11)[2017/08/18 1 Aug 18 10:28:06 ipa.example.com gssproxy[19280]:
>>[2017/08/18 10:28:06]: gp_rpc_execute: executing 6 (GSSX_ACQUI Aug 18
>>10:28:06 ipa.example.com gssproxy[19280]: GSSX_ARG_ACQUIRE_CRED(
>>call_ctx: { "" [  ] } input_cred_handle Aug 18 10:28:06 
>>ipa.example.com
>>gssproxy[19280]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1
>>2 2 } 0 Aug 18 10:28:06 ipa.example.com gssproxy[19280]: [2017/08/18
>>10:28:06]: gp_rpc_execute: executing 6 (GSSX_ACQUI Aug 18 10:28:06 
>>ipa.example.com gssproxy[19280]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { ""
>>[  ] } input_cred_handle Aug 18 10:28:06 ipa.example.com
>>gssproxy[19280]: GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1
>>2 2 } 0 Aug 18 10:28:06 ipa.example.com gssproxy[19280]: [2017/08/18
>>10:28:06]: gp_rpc_execute: executing 9 (GSSX_ACCEP Aug 18 10:28:06 
>>ipa.example.com gssproxy[19280]: GSSX_ARG_ACCEPT_SEC_CONTEXT( call_ctx:
>>{ "" [  ] } context_han Aug 18 10:28:06 ipa.example.com
>>gssproxy[19280]: GSSX_RES_ACCEPT_SEC_CONTEXT( status: { 0 { 1 2 840
>>113554 1 2 Aug 18 10:30:02 ipa.example.com gssproxy[19280]: 
>>[2017/08/18
>>10:30:02]: Client connected (fd = 12)[2017/08/18 1 Aug 18 10:30:02 
>>ipa.example.com gssproxy[19280]: [2017/08/18 10:30:02]: gp_rpc_execute:
>>executing 6 (GSSX_ACQUI Aug 18 10:30:02 ipa.example.com
>>gssproxy[19280]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  ] } 
>>input_cred_handle Aug 18 10:30:02 ipa.example.com gssproxy[19280]:
>>GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 Aug 18
>>10:30:02 ipa.example.com gssproxy[19280]: [2017/08/18 10:30:02]:
>>gp_rpc_execute: executing 6 (GSSX_ACQUI Aug 18 10:30:02 
>>ipa.example.com
>>gssproxy[19280]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" [  ] } 
>>input_cred_handle Aug 18 10:30:02 ipa.example.com gssproxy[19280]:
>>GSSX_RES_ACQUIRE_CRED( status: { 0 { 1 2 840 113554 1 2 2 } 0 Aug 18
>>10:30:02 ipa.example.com gssproxy[19280]: [2017/08/18 10:30:02]:
>>gp_rpc_execute: executing 9 (GSSX_ACCEP Aug 18 10:30:02 
>>ipa.example.com
>>gssproxy[19280]: GSSX_ARG_ACCEPT_SEC_CONTEXT( call_ctx: { "" [  ] } 
>>context_han Aug 18 10:30:02 ipa.example.com gssproxy[19280]:
>>GSSX_RES_ACCEPT_SEC_CONTEXT( status: { 0 { 1 2 840 113554 1 2 lines
>>1-36/36 (END)
>>
>>
>>RPMs:
>>krb5-libs-1.15.1-8.el7.x86_64
>>krb5-libs-1.14.1-27.el7_3.x86_64
>>cyrus-sasl-md5-2.1.26-21.el7.x86_64
>>cyrus-sasl-lib-2.1.26-21.el7.x86_64
>>cyrus-sasl-lib-2.1.26-20.el7_2.x86_64
>>cyrus-sasl-gssapi-2.1.26-20.el7_2.x86_64
>>cyrus-sasl-2.1.26-21.el7.x86_64
>>cyrus-sasl-plain-2.1.26-21.el7.x86_64
>>cyrus-sasl-gssapi-2.1.26-21.el7.x86_64
>>cyrus-sasl-md5-2.1.26-20.el7_2.x86_64
>>
>>-----Original Message-----
>>From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>>Sent: 18 August 2017 11:24
>>To: FreeIPA users list
>>Cc: Troels Hansen; Fraser Tweedale; Stefan Uygur
>>Subject: Re: [Freeipa-users] Re: web UI - login failed after updates 
>>on server
>>
>>On pe, 18 elo 2017, Stefan Uygur via FreeIPA-users wrote:
>>>Your assumptions is correct Alexander, I did accept the server cert 
>>>otherwise the browser won't open the login page at all. Beside, that 
>>>log was there even before when it was working...before the update.
>>>
>>>Re to gssproxy, all my attempts were also followed by a full server 
>>>reboot.
>>>
>>>I will take a look at your article but I can certainly confirm the 
>>>issue is upgrade related. I am not the only one who is experiencing 
>>>this from what I read on internet.
>>If you can produce a set of logs (error_log, gssproxy) for an attempt to 
>>connect, we can look at them. gssproxy logs are important now to see what's 
>>wrong in your case.
>>
>>Also please provide list of rpm with their versions for krb5-libs, freeipa, 
>>cyrus-sasl-*.
>>
>>
>>>
>>>Thanks
>>>
>>>-----Original Message-----
>>>From: Alexander Bokovoy [mailto:aboko...@redhat.com]
>>>Sent: 18 August 2017 10:53
>>>To: FreeIPA users list
>>>Cc: Fraser Tweedale; Troels Hansen; Stefan Uygur
>>>Subject: Re: [Freeipa-users] Re: web UI - login failed after updates 
>>>on server
>>>
>>>On pe, 18 elo 2017, Stefan Uygur via FreeIPA-users wrote:
>>>>Hi Fraser,
>>>>Thanks for the tips.
>>>>
>>>>I did put SELinux in permissive mode and of course I have restarted 
>>>>the IPA after that to makes sure the new setting picked up by IPA.
>>>>
>>>>All certs including CA sanitized and they are correct with the trust 
>>>>flags, so it is not matter with certs either. I read about the 
>>>>SubjAltName warning and indeed I was ignoring that part.
>>>>
>>>>I have raised the case with RedHat but no joy with them either.
>>>>Usually the community is the best way to solve this sort of issues 
>>>>as I never have had good experience with redhat support to be honest.
>>>>
>>>>So if anyone else has further suggestions pls fire up.
>>>Your httpd's error_log says your _client_ does not trust the certificate. 
>>>Can you check the client browser actually trusts your CA?
>>>
>>>I assume you did accept the server cert trust when Firefox or Chrome asked 
>>>you, did you?
>>>
>>>At least in Fedora and RHEL we configure Firefox to only allow GSSAPI 
>>>negotiate over https:// links with trusted certificates.
>>>
>>>Another component to look at is gssproxy. You might want to restart gssproxy 
>>>too when you restarted IPA.
>>>
>>>I have written an article how to debug FreeIPA 4.5.0:
>>>https://vda.li/en/docs/freeipa-debug-privsep/
>>>
>>>>
>>>>Thanks a lot.
>>>>
>>>>Stefan
>>>>
>>>>-----Original Message-----
>>>>From: Fraser Tweedale [mailto:ftwee...@redhat.com]
>>>>Sent: 18 August 2017 08:32
>>>>To: Stefan Uygur
>>>>Cc: FreeIPA users list; Troels Hansen
>>>>Subject: Re: [Freeipa-users] Re: web UI - login failed after updates 
>>>>on server
>>>>
>>>>On Fri, Aug 18, 2017 at 05:28:12PM +1000, Fraser Tweedale wrote:
>>>>> Hi Stefan et al,
>>>>>
>>>>> It's hard to work out exactly what's going on.
>>>>>
>>>>> First make sure that all certificates including the IPA CA 
>>>>> certificate are within their validity period.  Make sure that CA
>>>>> certificate(s) have the correct trust flags in the 
>>>>> /etc/httpd/alias
>>>>> NSSDB:
>>>>>
>>>>>     certutil -d /etc/httpd/alias -L
>>>>>
>>>>> Check /var/log/ipaupgrade.log for any errors that may have 
>>>>> occurred during upgrade.
>>>>>
>>>>> If you put SELinux into permissive mode, do run `ipactl restart` 
>>>>> afterwards, before attempting to log in.
>>>>>
>>>>> Finally, the log message:
>>>>>
>>>>>   /usr/lib/python2.7/site-packages/urllib3/connection.py:251: 
>>>>> SecurityWarning:
>>>>>   Certificate has no `subjectAltName`, falling back to check for a 
>>>>> `commonName`
>>>>>   for now. This feature is being removed by major browsers and deprecated 
>>>>> by RFC
>>>>>   2818. (See https://github.com/shazow/urllib3/issues/497 for
>>>>> details.)
>>>>>
>>>>> ... is not the cause, and can be ignored for the purposes of 
>>>>> diagnosing the current problem.
>>>>>
>>>>> Cheers,
>>>>> Fraser
>>>>>
>>>>One more thing; one the affected master try putting `debug = True` in 
>>>>/etc/ipa/default.conf and restarting FreeIPA.  You will get a lot more 
>>>>debug output in the httpd logs which could help narrow down the problem.
>>>>
>>>>>
>>>>>
>>>>> On Fri, Aug 18, 2017 at 08:16:19AM +0200, Troels Hansen via FreeIPA-users 
>>>>> wrote:
>>>>> > Hi Jason
>>>>> >
>>>>> > You aren't the only one having weird problems after updating to 
>>>>> > IPA
>>>>> > 4.5 on RHEL 7.4 We are also facing problems accessing the web-ui and 
>>>>> > having a support case open with Red Hat and can see from the linked 
>>>>> > (private) Red Hat bugzilla that others are facing the same or other 
>>>>> > problems.
>>>>> >
>>>>> > My best shot would be to raise the issue with Red Hat. After 
>>>>> > all, that what you pay them for :-) Also, for Red Hat to get a full 
>>>>> > picture of the problems I guess it they need all the corner-cases...
>>>>> >
>>>>> > ----- On Aug 17, 2017, at 6:12 PM, Stefan Uygur via FreeIPA-users 
>>>>> > <freeipa-users@lists.fedorahosted.org> wrote:
>>>>> >
>>>>> > > Hi Jason,
>>>>> >
>>>>> > > Thanks for the reply, but I did try that already, setting 
>>>>> > > selinux in permissive mode rather than enforcing and it didn’t help.
>>>>> >
>>>>> > > However, I didn’t see anything in audit logs that would 
>>>>> > > indicate selinux as culprit.
>>>>> >
>>>>> > > I just tried one more time right now with no joy, exact same result.
>>>>> >
>>>>> > > Stefan
>>>>> >
>>>>> > > From: Jason Sherrill via FreeIPA-users 
>>>>> > > [mailto:freeipa-users@lists.fedorahosted.org]
>>>>> > > Sent: 17 August 2017 17:07
>>>>> > > To: FreeIPA users list
>>>>> > > Cc: Jason Sherrill
>>>>> > > Subject: [Freeipa-users] Re: web UI - login failed after 
>>>>> > > updates on server
>>>>> >
>>>>> > > Stefan,
>>>>> >
>>>>> > > I resolved a similar issue on a Fedora host by setting selinux 
>>>>> > > to permissive instead of enforcing. The setting is located in
>>>>> >
>>>>> > > /etc/selinux/config
>>>>> >
>>>>> > > On Thu, Aug 17, 2017 at 10:37 AM, Stefan Uygur via 
>>>>> > > FreeIPA-users < freeipa-users@lists.fedorahosted.org > wrote:
>>>>> >
>>>>> > > Hi everyone,
>>>>> >
>>>>> > > I have an IPA instance installed and working for the last 6 
>>>>> > > months but after the patching yesterday the Web UI login has stopped 
>>>>> > > to work.
>>>>> >
>>>>> > > To be clear the IPA server is fully functional at the backend, 
>>>>> > > the problem is when I try to login via web UI I get the following 
>>>>> > > error:
>>>>> >
>>>>> > > Login failed due to an unknown reason.
>>>>> >
>>>>> > > The server is a Red Hat Enterprise Linux Server release 7.4
>>>>> > > (Maipo) with the IPA
>>>>> > > VERSION: 4.5.0, API_VERSION: 2.228
>>>>> >
>>>>> > > Furthermore, this is what I get from apache error logs while 
>>>>> > > trying to login using web UI:
>>>>> >
>>>>> > > [Thu Aug 17 11:58:40.727456 2017] [:error] [pid 20879] ipa: INFO:
>>>>> > > *** PROCESS START ***
>>>>> >
>>>>> > > [Thu Aug 17 11:58:40.911349 2017] [:error] [pid 20878] ipa: INFO:
>>>>> > > *** PROCESS START ***
>>>>> >
>>>>> > > [Thu Aug 17 11:58:57.224594 2017] [auth_gssapi:error] [pid 
>>>>> > > 20884] [client IPADDR:54323] NO AUTH DATA Client did not send 
>>>>> > > any authentication headers,
>>>>> > > referer: https://-ipa1.example.com/ipa/ui/
>>>>> >
>>>>> > > [Thu Aug 17 11:58:57.266259 2017] [auth_gssapi:error] [pid 
>>>>> > > 20884] [client IPADDR:54323] GSS ERROR In Negotiate Auth:
>>>>> > > gss_accept_sec_context() failed: [An unsupported mechanism was 
>>>>> > > requested (Unknown error)], referer:
>>>>> > > https://ipa1.example.com/ipa/ui/
>>>>> >
>>>>> > > /usr/lib/python2.7/site-packages/urllib3/connection.py:251: 
>>>>> > > SecurityWarning:
>>>>> > > Certificate has no `subjectAltName`, falling back to check for 
>>>>> > > a `commonName` for now. This feature is being removed by major 
>>>>> > > browsers and deprecated by RFC 2818. (See
>>>>> > > https://github.com/shazow/urllib3/issues/497 for details.)
>>>>> >
>>>>> > > SecurityWarning
>>>>> >
>>>>> > > [Thu Aug 17 11:59:03.637157 2017] [:error] [pid 20878] ipa: INFO: 404 
>>>>> > > Not Found:
>>>>> > > URL="/ipa/session/cookie", URL fragment "/session/cookie" does 
>>>>> > > not have a handler
>>>>> >
>>>>> > > [Thu Aug 17 11:59:03.638346 2017] [:error] [pid 20879] ipa: INFO:
>>>>> > > 401
>>>>> > > Unauthorized: No session cookie found
>>>>> >
>>>>> > > [Thu Aug 17 12:00:01.567042 2017] [:error] [pid 20882] SSL 
>>>>> > > Library
>>>>> > > Error: -12195 Peer does not recognize and trust the CA that 
>>>>> > > issued your certificate
>>>>> >
>>>>> > > [Thu Aug 17 12:00:01.617683 2017] [:error] [pid 21225] SSL 
>>>>> > > Library
>>>>> > > Error: -12195 Peer does not recognize and trust the CA that 
>>>>> > > issued your certificate
>>>>> >
>>>>> > > [Thu Aug 17 12:00:09.967173 2017] [auth_gssapi:error] [pid 
>>>>> > > 20881] [client IPADDR:54377] NO AUTH DATA Client did not send 
>>>>> > > any authentication headers,
>>>>> > > referer: https://-ipa1.example.com/ipa/ui/
>>>>> >
>>>>> > > /usr/lib/python2.7/site-packages/urllib3/connection.py:251: 
>>>>> > > SecurityWarning:
>>>>> > > Certificate has no `subjectAltName`, falling back to check for 
>>>>> > > a `commonName` for now. This feature is being removed by major 
>>>>> > > browsers and deprecated by RFC 2818. (See
>>>>> > > https://github.com/shazow/urllib3/issues/497 for details.)
>>>>> >
>>>>> > > SecurityWarning
>>>>> >
>>>>> > > [Thu Aug 17 12:00:17.495782 2017] [:error] [pid 20879] ipa: INFO: 404 
>>>>> > > Not Found:
>>>>> > > URL="/ipa/session/cookie", URL fragment "/session/cookie" does 
>>>>> > > not have a handler
>>>>> >
>>>>> > > [Thu Aug 17 12:00:17.497067 2017] [:error] [pid 20878] ipa: INFO:
>>>>> > > 401
>>>>> > > Unauthorized: No session cookie found
>>>>> >
>>>>> > > I know it is complaining about the new mod_gssapi but never 
>>>>> > > seen this sort of problem before on IPA.
>>>>> >
>>>>> > > Any help would be greatly appreciated.
>>>>> >
>>>>> > > Stefan
>>>>> >
>>>>> > > __________________________________________ __________ Stefan 
>>>>> > > Uygur
>>>>> > > | First Derivatives Ireland Ltd | +353 16307761 |
>>>>> > > suy...@firstderivatives.com
>>>>> >
>>>>> > > **************************************************************
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *************************************************************
>>>>> >
>>>>> > > This email, its contents and any files attached are a 
>>>>> > > confidential communication and are intended only for the named 
>>>>> > > addressees indicated in the message.
>>>>> >
>>>>> > > If you are not the named addressee or if you have received 
>>>>> > > this email in error, you may not, without the consent of First 
>>>>> > > Derivatives, copy, use or rely on any information or 
>>>>> > > attachments in any way. Please notify the sender by return email and 
>>>>> > > delete it from your email system.
>>>>> >
>>>>> > > Unless separately agreed, First Derivatives does not accept 
>>>>> > > any responsibility for the accuracy or completeness of the 
>>>>> > > contents of this email or its attachments. Please note that 
>>>>> > > any views, opinion or advice contained in this communication 
>>>>> > > are those of the sending individual and not those of First 
>>>>> > > Derivatives and First Derivatives shall have no liability whatsoever 
>>>>> > > in relation to this communication (or its content) unless separately 
>>>>> > > agreed.
>>>>> >
>>>>> > > **************************************************************
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *************************************************************
>>>>> >
>>>>> > > **************************************************************
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *************************************************************
>>>>> >
>>>>> > > This email, its contents and any files attached are a 
>>>>> > > confidential communication and are intended only for the named 
>>>>> > > addressees indicated in the message.
>>>>> >
>>>>> > > If you are not the named addressee or if you have received 
>>>>> > > this email in error, you may not, without the consent of First 
>>>>> > > Derivatives, copy, use or rely on any information or 
>>>>> > > attachments in any way. Please notify the sender by return email and 
>>>>> > > delete it from your email system.
>>>>> >
>>>>> > > Unless separately agreed, First Derivatives does not accept 
>>>>> > > any responsibility for the accuracy or completeness of the 
>>>>> > > contents of this email or its attachments. Please note that 
>>>>> > > any views, opinion or advice contained in this communication 
>>>>> > > are those of the sending individual and not those of First 
>>>>> > > Derivatives and First Derivatives shall have no liability whatsoever 
>>>>> > > in relation to this communication (or its content) unless separately 
>>>>> > > agreed.
>>>>> >
>>>>> > > **************************************************************
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *
>>>>> > > *************************************************************
>>>>> >
>>>>> > > _______________________________________________
>>>>> > > FreeIPA-users mailing list --
>>>>> > > freeipa-users@lists.fedorahosted.org
>>>>> > > To unsubscribe send an email to 
>>>>> > > freeipa-users-le...@lists.fedorahosted.org
>>>>> >
>>>>> > > --
>>>>> >
>>>>> > > Jason Sherrill
>>>>> >
>>>>> > > IT Specialist
>>>>> >
>>>>> > > Deeplocal Inc.
>>>>> >
>>>>> > > mobile: 412-636-2073
>>>>> >
>>>>> > > office: 412-362-0201
>>>>> >
>>>>> > > _______________________________________________
>>>>> > > FreeIPA-users mailing list --
>>>>> > > freeipa-users@lists.fedorahosted.org
>>>>> > > To unsubscribe send an email to 
>>>>> > > freeipa-users-le...@lists.fedorahosted.org
>>>>> >
>>>>> > --
>>>>> >
>>>>> > Med venlig hilsen
>>>>> >
>>>>> > Troels Hansen
>>>>> >
>>>>> > Systemkonsulent
>>>>> >
>>>>> > Casalogic A/S
>>>>> >
>>>>> > T (+45) 70 20 10 63
>>>>> >
>>>>> > M (+45) 22 43 71 57
>>>>> >
>>>>> > Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, 
>>>>> > Sophos og meget mere.
>>>>>
>>>>> > _______________________________________________
>>>>> > FreeIPA-users mailing list --
>>>>> > freeipa-users@lists.fedorahosted.org
>>>>> > To unsubscribe send an email to
>>>>> > freeipa-users-le...@lists.fedorahosted.org
>>>>>
>>>>_______________________________________________
>>>>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>>>To unsubscribe send an email to
>>>>freeipa-users-le...@lists.fedorahosted.org
>>>
>>>--
>>>/ Alexander Bokovoy
>>>_______________________________________________
>>>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>>To unsubscribe send an email to
>>>freeipa-users-le...@lists.fedorahosted.org
>>
>>--
>>/ Alexander Bokovoy
>>_______________________________________________
>>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>To unsubscribe send an email to
>>freeipa-users-le...@lists.fedorahosted.org
>
>--
>/ Alexander Bokovoy
>_______________________________________________
>FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>To unsubscribe send an email to 
>freeipa-users-le...@lists.fedorahosted.org

--
/ Alexander Bokovoy

Attachment: ipa.conf
Description: ipa.conf

_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to