Hi everyone!
We've been experiencing some issues with our FreeIPA setup for the past few months. First of all:
Our package versions are:
ipa-client-common-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
ipa-common-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
ipa-client-4.9.8-7.module_el8.6.0+1103+a004f6a8.x86_64
ipa-server-4.9.8-7.module_el8.6.0+1103+a004f6a8.x86_64
ipa-client-epn-4.9.8-7.module_el8.6.0+1103+a004f6a8.x86_64
ipa-server-common-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
ipa-server-dns-4.9.8-7.module_el8.6.0+1103+a004f6a8.noarch
We are running a peculiar containerized environment based on the CentOS 8 image.
Specifically, we've been having trouble accessing the FreeIPA API and performing web UI logins, which we suspect is due to the /run/ipa/ccaches directory becoming littered with too many files. For example, on one of the troubled servers, we ran the command:
[root@ipa-server /]# ls -l /run/ipa/ccaches/ | wc -l
174314
We've already tried deleting files in the directory, but the problem persists. The errors we're seeing are something like this:
ipa: ERROR: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (69206018): gss_display_status call returned failure (major 327680, minor 100007). Decoding code: 69206018
Or this:
ipa: ERROR: No valid Negotiate header in server response
I tried looking up the code of mod_auth_gssapi to find the probable cause, but to no effect. I need help with this. First of all, shouldn't the STs in GssapiDelegCcacheDir be deleted by the module? For now the only solution is the container restart which is equivalent to the "ipactl restart" I guess.
I'm interested in learning more about how mod_auth_gssapi is handling ST deletion and what might be causing it to fail in general. If anyone has any insights or suggestions, we would greatly appreciate it.