sssd-kcm - SSSD Kerberos Cache Manager
This manual page describes the configuration of the SSSD Kerberos Cache Manager
(KCM). KCM is a process that stores, tracks and manages Kerberos credential
caches. It originates in the Heimdal Kerberos project, although the MIT
Kerberos library also provides client side (more details on that below)
support for the KCM credential cache.
In a setup where Kerberos caches are managed by KCM, the Kerberos library
(typically used through an application, like e.g., kinit
(1), is a
“"KCM client"” and the KCM daemon is being referred to
as a “"KCM server"”. The client and server communicate
over a UNIX socket.
The KCM server keeps track of each credential caches's owner and performs access
check control based on the UID and GID of the KCM client. The root user has
access to all credential caches.
The KCM credential cache has several interesting properties:
•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 the SSSD sssd-secrets(5) secrets store, allowing the ccaches
to survive KCM server restarts or machine reboots.
This allows the system to use a collection-aware credential cache, yet share the
credential cache between some or no containers by bind-mounting the socket.
In order to use KCM credential cache, it must be selected as the default
credential type in krb5.conf
(5), The credentials cache name must be
only “KCM:” without any template expansions. For example:
default_ccache_name = KCM:
Next, make sure the Kerberos client libraries and the KCM server must agree on
the UNIX socket path. By default, both use the same path
. To configure the Kerberos library,
change its “kcm_socket” option which is described in the
(5) manual page.
Finally, make sure the SSSD KCM server can be contacted. The KCM service is
typically socket-activated by systemd
(1). Unlike other SSSD services,
it cannot be started by adding the “kcm” string to the
systemctl start sssd-kcm.socket
systemctl enable sssd-kcm.socket
systemctl enable sssd-kcm.service
Please note your distribution may already configure the units for you.
The credential caches are stored in the SSSD secrets service (see
(5) for more details). Therefore it is important that also
the sssd-secrets service is enabled and its socket is started:
systemctl start sssd-secrets.socket
systemctl enable sssd-secrets.socket
systemctl enable sssd-secrets.service
Your distribution should already set the dependencies between the services.
The KCM service is configured in the “kcm” section of the
sssd.conf file. Please note that currently, is it not sufficient to restart
the sssd-kcm service, because the sssd configuration is only parsed and read
to an internal configuration database by the sssd service. Therefore you must
restart the sssd service if you change anything in the “kcm”
section of sssd.conf. 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
(5) manual page for a complete list. In addition, there are
some KCM-specific options as well.
The socket the KCM service will listen on.
The SSSD upstream - https://pagure.io/SSSD/sssd/