SSSD-KCM(8)

πŸ’… SSSD-KCM β€” the manual page, but make it make sense

okay bestie, so this is the sssd-kcm(8) page from the File Formats and Conventions manual, and it's literally all about the SSSD Kerberos Cache Manager. grab a strawberry πŸ“ drink and let's go, because this one actually slaps once you get it.


✨ NAME ✨

sssd-kcm β€” the SSSD Kerberos Cache Manager. yes that's the whole name, she's mysterious, she's iconic πŸ’…


🌸 DESCRIPTION 🌸

this page is your tour guide through configuring the SSSD Kerberos Cache Manager (aka KCM, say it with your chest). KCM is a process whose whole job is to store, track and manage Kerberos credential caches. she originated in the Heimdal Kerberos project, though the MIT Kerberos library also gives you client-side support for the KCM credential cache (more on that below, iykyk).

so here's the vibe: in a setup where Kerberos caches are managed by KCM, the Kerberos library β€” which you're usually touching through an app, like, say, kinit(1) β€” is what we call a "KCM client", and the KCM daemon is the "KCM server". these two communicate over a UNIX socket. periodt.

the KCM server keeps track of every credential cache's owner and does access check control based on the UID and GID of the KCM client. no cap.

and the KCM credential cache has some genuinely interesting properties, no notes:

  • since the process runs in userspace, it is subject to UID namespacing β€” unlike the kernel keyring πŸ‘€
  • unlike the kernel keyring-based cache, which is shared between all containers, the KCM server is a separate process whose entry point is a UNIX socket
  • the SSSD implementation stores the ccaches in a database, typically located at /var/lib/sss/secrets, which means the ccaches can survive KCM server restarts or machine reboots. obsessed.

this lets the system use a collection-aware credential cache while still sharing the credential cache between some or no containers by bind-mounting the socket. cute AND functional 🌈

the KCM default client idle timeout is 5 minutes, which buys you more time for user interaction with command line tools such as kinit. thank u, next. πŸ™


πŸŽ€ USING THE KCM CREDENTIAL CACHE πŸŽ€

first things first: to use the KCM credential cache, it has to be selected as the default credential type in krb5.conf(5). and the credentials cache name must be only KCM: β€” no template expansions, bestie, we keep it simple. like so:

[libdefaults]
    default_ccache_name = KCM:

next up: the Kerberos client libraries and the KCM server have to agree on the UNIX socket path. by default, both use the same path /var/run/.heim_org.h5l.kcm-socket. to configure the Kerberos library, change its kcm_socket option, which is described in the krb5.conf(5) manual page. ✨

finally, make sure the SSSD KCM server can be contacted. the KCM service is typically socket-activated by systemd(1). and here's the important part β€” unlike other SSSD services, it cannot be started by adding the "kcm" string to the "service" directive. so instead:

systemctl start sssd-kcm.socket
systemctl enable sssd-kcm.socket

also, heads up: your distribution may already configure the units for you. don't come for me if it's already done 🫢


πŸ¦‹ THE CREDENTIAL CACHE STORAGE πŸ¦‹

the credential caches are stored in a database, much like SSSD caches user or group entries. the database is typically located at /var/lib/sss/secrets. she lives there. πŸ’œ


πŸ”₯ OBTAINING DEBUG LOGS πŸ”₯

the sssd-kcm service is typically socket-activated by systemd(1). to generate debug logs, add the following either to the /etc/sssd/sssd.conf file directly, or as a configuration snippet to the /etc/sssd/conf.d/ directory:

[kcm]
debug_level = 10

then, restart the sssd-kcm service:

systemctl restart sssd-kcm.service

finally, go run whatever use-case isn't working for you. the KCM logs will be generated at /var/log/sssd/sssd_kcm.log. and bestie, please β€” it is recommended to disable the debug logs when you no longer need debugging enabled, because the sssd-kcm service can generate quite a large amount of debugging information. it's giving chatterbox 😭

please note that configuration snippets are, at the moment, only processed if the main configuration file at /etc/sssd/sssd.conf exists at all. like, it has to exist. non-negotiable.

⭐ RENEWALS ⭐

the sssd-kcm service can be configured to attempt TGT renewal for renewable TGTs stored in the KCM ccache. renewals are only attempted when half of the ticket lifetime has been reached. KCM renewals are configured when the following options are set in the [kcm] section:

tgt_renewal = true
krb5_renew_interval = 60m

SSSD can also inherit krb5 options for renewals from an existing domain:

tgt_renewal = true
tgt_renewal_inherit = domain-name

the following krb5 options can be configured in the [kcm] section to control renewal behavior β€” these options are described in detail below, don't worry, we got you:

krb5_renew_interval
krb5_renewable_lifetime
krb5_lifetime
krb5_validate
krb5_canonicalize
krb5_auth_timeout

πŸ‘‘ CONFIGURATION OPTIONS πŸ‘‘

the KCM service is configured in the "kcm" section of the sssd.conf file. and because the KCM service is typically socket-activated, it's enough to just restart the "sssd-kcm" service after changing options in the "kcm" section of sssd.conf:

systemctl restart sssd-kcm.service

the KCM service is configured in the "kcm". for a detailed syntax reference, refer to the "FILE FORMAT" section of the sssd.conf(5) manual page. πŸ“–

the generic SSSD service options such as "debug_level" or "fd_limit" are accepted by the kcm service. please refer to the sssd.conf(5) manual page for a complete list. and in addition, there are some KCM-specific options as well. let's go through them one by one, no skipping, we're thorough here πŸ’…

  • socket_path (string) β€” the socket the KCM service will listen on.
    • Default: /var/run/.heim_org.h5l.kcm-socket
    • Note: on platforms where systemd is supported, the socket path is overwritten by the one defined in the sssd-kcm.socket unit file.
  • max_ccaches (integer) β€” how many credential caches the KCM database allows for all users.
    • Default: 0 (unlimited, only the per-UID quota is enforced)
  • max_uid_ccaches (integer) β€” how many credential caches the KCM database allows per UID. this is equivalent to "with how many principals you can kinit".
    • Default: 64
  • max_ccache_size (integer) β€” how big a credential cache can be, per ccache. every service ticket accounts into this quota.
    • Default: 65536
  • tgt_renewal (bool) β€” enables TGT renewals functionality.
    • Default: False (automatic renewals disabled)
  • tgt_renewal_inherit (string) β€” domain to inherit krb5_* options from, for use with TGT renewals.
    • Default: NULL
  • krb5_auth_timeout (integer) β€” timeout in seconds after which an online authentication request or change password request is aborted. if possible, the authentication request is continued offline.
    • Default: 6
  • krb5_validate (boolean) β€” verify, with the help of krb5_keytab, that the TGT obtained has not been spoofed. the keytab is checked for entries sequentially, and the first entry with a matching realm is used for validation. if no entry matches the realm, the last entry in the keytab is used. this process can be used to validate environments using cross-realm trust by placing the appropriate keytab entry as the last entry, or the only entry, in the keytab file.
    • Default: false (IPA and AD provider: true)
    • > please note that ticket validation is the first step when checking the PAC (see 'pac_check' in the sssd.conf(5) manual page for details). if ticket validation is disabled, the PAC checks will be skipped as well. so like, don't turn it off and then act surprised, bestie 😭
  • krb5_renewable_lifetime (string) β€” request a renewable ticket with a total lifetime, given as an integer immediately followed by a time unit:
    • s for seconds
    • m for minutes
    • h for hours
    • d for days.
    • if there is no unit given, s is assumed.
    • > NOTE: it is not possible to mix units. to set the renewable lifetime to one and a half hours, use '90m' instead of '1h30m'.
    • Default: not set, i.e. the TGT is not renewable
  • krb5_lifetime (string) β€” request ticket with a lifetime, given as an integer immediately followed by a time unit:
    • s for seconds
    • m for minutes
    • h for hours
    • d for days.
    • if there is no unit given, s is assumed.
    • > NOTE: it is not possible to mix units. to set the lifetime to one and a half hours please use '90m' instead of '1h30m'.
    • Default: not set, i.e. the default ticket lifetime configured on the KDC.
  • krb5_renew_interval (string) β€” the time in seconds between two checks on whether the TGT should be renewed. TGTs are renewed if about half of their lifetime is exceeded, given as an integer immediately followed by a time unit:
    • s for seconds
    • m for minutes
    • h for hours
    • d for days.
    • if there is no unit given, s is assumed.
    • > NOTE: it is not possible to mix units. to set the renewable lifetime to one and a half hours, use '90m' instead of '1h30m'.
    • if this option is not set, or is 0, the automatic renewal is disabled.
    • Default: not set
  • krb5_canonicalize (boolean) β€” specifies if the host and user principal should be canonicalized. this feature is available with MIT Kerberos 1.7 and later versions.
    • Default: false

🌈 SEE ALSO 🌈

sssd(8), sssd.conf(5), β€” go read those too, they're the supporting cast and they ate πŸ’–


🧚 AUTHORS 🧚

the SSSD upstream β€” https://github.com/SSSD/sssd/ β€” icons only, no cap πŸ‘‘


and that's the whole page, bestie!! this was the SSSD page, dated 07/08/2026, served up with love by the fine folks at SSSD. now go configure your credential cache and be the main character of your own Kerberos setup πŸ’œβœ¨πŸ¦‹

πŸ“¦ where this page comes from