On Tue, Jan 31, 2017 at 09:55:41AM +0000, Tom Hughes wrote:
On 31/01/17 09:24, Jan Kurik wrote:
> With KCM, the Kerberos caches are not stored in a "passive" store, but
> managed by a daemon. In this setup, the Kerberos library (typically
> used through an application, like for example, kinit) is a "KCM
> client" and the daemon is being referred to as a "KCM server". The
> server will be provided as a socket-activated service of the SSSD
Given that kerberos is now required for all packagers, what is the impact of
this for people that aren't using sssd?
Is sssd-kcm something that will run and work on it's own without the rest of
Correct, you won't have to configure SSSD[*] or let the users be managed
by SSSD. From a configuration point of view, this change should not even
be visible to the end-user.
krb5-libs would socket-activate the sssd-kcm service which processes the
requests from krb5-libs and might also socket-activate the sssd-secrets
service that manages the persistent store for the ccaches.
In theory, the KCM server could well be a totally separate project
from SSSD (after all, Heimdal has a KCM server as part of their
Kerberos implementation..), but making it a part of SSSD makes it
possible to reuse quite a bit of code that we have for the traditional
SSSD role, where SSSD talks to some remote server for user identity or
authentication. Additionally, the ccaches would be stored in sssd-secrets,
which is already a part of SSSD (but also, as sssd-kcm doesn't depend on
sssd being part of any domain or even serving users to the system
through any of its interfaces..)
[*] there are still some changes pending upstream, but the basic idea is
that SSSD would, if no configuration is provided, generate a 'fallback'