[Freeipa-users] WebUI authentication problems

[Dan Mossor]

On 02/20/2015 03:53 AM, Petr Vobornik wrote:
> On 02/20/2015 09:44 AM, Martin Kosek wrote:
>> On 02/20/2015 02:00 AM, Dan Mossor wrote:
<---snip--->
>>> After approximately 15 minutes, I am kicked out of the active session
>>> - while
>>> in the middle of using it - and cannot log back in.
>
> Default FreeIPA session lifetime is 20mins. Expiration time is extended
> on each request. Session also expires when krb ticket expires. We have
> known issue that Web UI, if SSO is used, does not work if ticket expires
> in 5mins but it produces little bit different output.
>

So, the oddity continues. Firefox was at fault here - once I cleaned up 
FF and configured it with the new certificate, these authentication 
problems cleared up.

>>> Login was
>>> attempted from 4
>>> browsers across two machines, and every time the login screen returns
>>> with
>>> "Your session has expired. Please re-login."
>
> Does it work if you use forms-based authentication or if you use CLI tool?
>

When I attempted to go to use the form based authentication from both 
Firefox and Chrome, it brought up the page to configure the browser - it 
did not present me with a login.

<----snip---->
>>> [Fri Feb 20 00:45:35.603016 2015] [auth_kerb:error] [pid 1173] [client
>>> 10.1.1.17:54157] gss_accept_sec_context() failed: An unsupported
>>> mechanism was
>>> requested (, Unknown error), referer: https://vader.dom.net/ipa/ui/
>
> This looks like a culprit to me, though IDK what's its cause. Simo may
> know more.
>
> In a meantime you could try to enable debugging to get more info from
> /var/log/httpd/error_log by creating /etc/ipa/server.conf and restarting
> httpd.
>
>      # cat /etc/ipa/server.conf
>      [global]
>      debug=True
>
> You could also open browser develeper tools (press F12) and inspect XHR
> communication in network tab [1]. Check especially if some request to
> /ipa/session/json or ipa/session/login_kerberos or
> ipa/session/login_password does not end with 401 Unauthorized status
> code. And then what's the cause of next 401 after series of 200. It
> might contain some pointers. Like session expiration time and such.
>
> [1] https://pvoborni.fedorapeople.org/images/ff-dev-tools-xhr.png
>

I was looking at the console last night, and unfortunately I didn't save 
any of the error messages displayed. I can't recall the exact wording, 
but the one clue I was able to get from the Firefox console was that the 
certificate wasn't trusted - it said it was because it was expired, but 
it was actually due to my not having granted the exception to the 
self-signed cert yet. I was unable to do this due to the Firefox 
glitches mentioned previously.

>>>
>>> Restarting httpd, I can log in, and am immediately logged out again
>>> with the
>>> above errors.
>>>
>>> Restarting ipa.service, I was able to log in with my user account, and
>>> was
>>> notified that my password expires in 0 days - even though it was just
>>> created
>>> less than an hour ago.
>
> Have you modified Kerberos Ticket Policy or any Password Policy?
>

No, it was a default rolekit deployment - the only thing in my
settings.json file was the admin password.

>>>
>>> Is this a known issue, or is there a hidden problem with the rolekit
>>> deployment
>>> that I need to track down?
>
> It's not a known issue.
>
>>
>> CCing Petr for Web UI and Simo for the Kerberos part. We know about
>> several common gotchas related to Web UI auth, having them documented on
>> http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI
>>
>> But this seems as a new case. You can still check the pointers on this
>> page though. If none of them help, it may help to show us:
>>
>> - the Kerberos ticket and default encryptions:
>> $ kinit
>> $ klist -e
>>
>> - any related Kerberos errors from  /var/log/krb5kdc.log
>>
>> Martin

After much deliberation and many reboots, I finally figured out one key 
issue - I was using a Fedora 21 Cloud image to deploy, and converting 
the Cloud product to the Server product after the instance was created. 
For some reason, my original step of issuing 'systemctl disable 
cloud-init.service', while returning a successful message, was undone on 
the next reboot. The cloud-init tools were resetting the hostname on 
every boot to freeipa.localdomain, as that was what was used in the 
seed. This was causing pkinit to fail, so nothing would authenticate.

The cloud-init services are all removed now, and the system is stable. I 
sent this original message out of frustration because I was stymied at 
the problem. I eventually figured it out, and apologize for not 
following up when I figured out the errors were all mine.

Thank you all for the pointers, the help y'all dish out here on the list 
is phenomenal.

Regards,
Dan

-- 
Dan Mossor, RHCSA
Systems Engineer at Large
Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG
Fedora Infrastructure Apprentice
FAS: dmossor IRC: danofsatx
San Antonio, Texas, USA