Bug 1900973
| Summary: | sssd-kcm does not appear to expire Kerberos tickets (RFE: sssd_kcm should have the option to automatically delete the expired tickets) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | adam winberg <adam.winberg> |
| Component: | sssd | Assignee: | Alejandro López <allopez> |
| Status: | ASSIGNED --- | QA Contact: | Jakub Vavra <jvavra> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 9.2 | CC: | abokovoy, aboscatt, amessina, asakure, atikhono, ddas, djast, eric.laflamme, extras-qa, fweimer, gerard, grajaiya, jstephen, ldelouw, lslebodn, mzidek, oholy, orion, pasik, pbrezina, riehecky, sam, sbose, sgadekar, ssorce, striker, tscherf |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | sync-to-jira | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1669607 | Environment: | |
| Last Closed: | Type: | Story | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
adam winberg
2020-11-24 06:22:45 UTC
> The keyring has a nice feature wherby you can make it forget keys automatically, and it also has a limitation on the quantity of data a user can store, so we used that feature. The fact old tickets were removed was just a nice side-effect, but the absence of that behavior is not a bug.
Is it not a bit odd to incorporate the quota feature from keyring but not the automatic purging? Does this not just inevitably lead to quota being full when old credentials are never removed?
At least that's what I'm running into, I think. Suddenly a user can no longer get any new kerberos credentials and therefore cant access the nfs homedir. A 'klist' shows a long list of expired credentials, purging with 'kdestroy -A' and the user gets new creds on login again.
To remedy this we have built a cron script which refreshes and purges users kerberos credentials. Feels crazy though that we should have to do that.
However, users with keytabs which get credentials via gssproxy cant make use of that workaround. Credentials from gssproxy are obscured with klist:
[user.u@lxserv2114 ~]$ klist
Ticket cache: KCM:17098:66803
Default principal: user.u@AD
Valid starting Expires Service principal
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
01/01/1970 00:00:00 01/01/1970 00:00:00 Encrypted/Credentials/v1@X-GSSPROXY:
So there's no way to purge expired credentials for this user other than 'kdestroy -A' which of course also removes active credentials.
The klist output above is from a user which suddenly no longer can log in because no new credentials are given. After a 'kdestroy -A' it works again.
There are no logs in sssd_kcm.log when this happens. I will try to reproduce with a higher debug_level though. If the problem is 'max_ccache_size' I could of course increase this, but that would just delay the problem since the credentials are never removed, just added.
So i recreated the error which is not hard to do: 1. Log in to remote server. A new credential is issued 2. Log out. 3. Log in to remote server. A new credential is issued 4. Repeat When the number of credential caches for my user hits ~64 I no longer get any new credentials on login. sssd_kcm.log (with debug_level=8) shows: (2020-11-24 6:54:17): [kcm] [local_decrypt] (0x2000): Decrypting with masterkey (2020-11-24 6:54:17): [kcm] [sss_sec_update] (0x0400): Adding a secret to [persistent/61526/default] (2020-11-24 6:54:17): [kcm] [local_db_check_peruid_number_of_secrets] (0x0040): Cannot store any more secrets for this client (basedn cn=61526,cn=persistent,cn=kcm) as the maximum allowed limit (66) has been reached (2020-11-24 6:54:17): [kcm] [sss_sec_update] (0x0040): local_db_check_number_of_secrets failed [1432158287]: The maximum number of stored secrets has been reached (2020-11-24 6:54:17): [kcm] [sec_update_b64] (0x0040): Cannot write the secret [1432158287]: The maximum number of stored secrets has been reached (2020-11-24 6:54:17): [kcm] [kcm_ccdb_set_default_done] (0x0040): Failed to set the default ccache [1432158287]: The maximum number of stored secrets has been reached (2020-11-24 6:54:17): [kcm] [kcm_op_set_default_done] (0x0040): Cannot set default ccache 1432158287: The maximum number of stored secrets has been reached (2020-11-24 6:54:17): [kcm] [kcm_cmd_done] (0x0040): op receive function failed [1432158287]: The maximum number of stored secrets has been reached (2020-11-24 6:54:17): [kcm] [kcm_cmd_request_done] (0x0040): KCM operation failed [1432158287]: The maximum number of stored secrets has been reached (2020-11-24 6:54:17): [kcm] [kcm_reply_error] (0x0040): KCM operation returs failure [1432158287]: The maximum number of stored secrets has been reached Increasing the 'max_uid_ccaches' parameter allows me to once again get new credentials. But since the credentials are never removed this is not a solution. Our workaround right now, as I said, is a cron script purging active users credentials. But that does not work for the keytab users getting credentials via gssproxy. To be able to reproduce the log entries, add the following to /etc/sssd/sssd.conf: [kcm] debug_level = 9 *** Bug 2088901 has been marked as a duplicate of this bug. *** The fix we decided to implement is to remove the oldest expired ticket whenever a new ticker is to be stored and there is no more free space. |