On 5/10/21 8:31 AM, Alexander Bokovoy wrote:
On su, 09 touko 2021, Harry G. Coin via FreeIPA-users wrote:
> On f34, freeipa-server 4.9.3-2: Upon choosing any action using a
> logged-in UI that has been left idle for some hours, browsers lock a
> display 'internal server error' (at least on firefox) instead of a
> log-in page, or the desired page. No actions on the server side will
> clear it. The only work-around is to delete the browser cookies and
> cached data, and after navigating to the UI the login page appears
> normally.
It looks like the cache entry for user authentication which is stored
encrypted on the server side cannot be decrypted anymore. This might
happen when you have rebooted a server between authenticating the user
and its session's expiration. There are two keys here:
- mod_auth_gssapi uses ipasession.key (in /etc/httpd/alias in Fedora)
for encrypting the cookie session
- GSS-Proxy uses own service keytab or an in-memory key to encrypt
Kerberos credentials in a ccache generated and stored on the server
which corresponds to the content stored in the cookie session
If you'd restart GSS-Proxy or reboot the system, the ccache generated
and stored on the server side by GSS-Proxy would not be possible to
decrypt in case an ephemeral in-memory key was used.
Can you enable IPA server-side debugging in case this happens to see if
we can handle an error from mod_auth_gssapi better?
I think blocking access to the freeipa-ui until all users delete all
browser cookies and cached data every time freeipa is rebooted is
probably not a good thing.
In my test case, freeipa-server is in a VM using a virtio-fs as the
boot/root filesystem. The virtio-fs folks haven't quite managed to
solve SELinux problems when their file system is the root device, so for
the time being I set SELinux to permissive. Serendipity might have
generated a clue, as follows:
# cat /etc/ipa/server.conf
[global]
certmonger_wait_timeout=1200
startup_timeout = 720
startup_traceback = True
debug=True
# journalctl -f
...
May 10 09:33:40
registry1.1.quietfountain.com [1435]: GSSAPI client step 1
May 10 09:33:45
registry1.1.quietfountain.com audit[676]: AVC avc:
denied { lock } for pid=676 comm="gssproxy"
path="/var/lib/ipa/gssproxy/http.keytab" dev="virtiofs" ino=745470
scontext=system_u:system_r:gssproxy_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
permissive=1
May 10 09:33:46
registry1.1.quietfountain.com [1435]: GSSAPI client step 1
May 10 09:33:46
registry1.1.quietfountain.com [1435]: GSSAPI client step 1
...
It's quite repeatable, every refresh on the browser generates the AVC
line above (amid the log being cluttered with 'GSSAPI client step 1'...