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 KCM > > server will be provided as a socket-activated service of the SSSD > > deamon. > > 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 > sssd? 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' configuration internally. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
