On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote:
-----Message d'origine----- De : Lukas Slebodnik [mailto:lslebodn@redhat.com] Envoyé : mercredi 16 janvier 2019 12:47 À : End-user discussions about the System Security Services Daemon Objet : [SSSD-users] Re: Understanding sssd cache
On (16/01/19 09:14), Maupertuis Philippe wrote:
Hi I am trying to find out how th sssd cache is being populated. I couldn't find much about it so I did some tests. It seems that with enumerate = true, the cache holds all the information
needed as soon as sssd is started.
With enumerate = false, the cache holds information about someone only
after his first connection.
Is that right ? I would like to be sure that user's passwords are stored in the cache but
couldn't find any way to verify this
With sssctl user-show I can find if a user is in the cache but with no details. With sssctl user-checks I get some information about the user but nothing
about the password.
By examining directly the cache with ldbsearch I don't find any password
information either, only maybe shadowLastChange: with a number which I don't understand.
Is there any documentation about the cache management ?
Hashed password is cached only after successful authentication. It is not rerieved by "getent passwd $user".
sssd cache is internal cache and should not be used directly by user.
I understand that and was looking at it only to try to understand how it works.
May I know what do you want to achieve?
When using regular ssh access the the ssh publickey is in the cache if needed. A user who had not connected previously is able to connect even if the backend is unreachable When using the console, we have to rely on the password. When something goes wrong (sshd down or network issue), there is a high probability that the user would connect to the console for the first time. So if there is no guarantee the login could be successful offline we need to have a local (shared) account to connect to the console. A shared account is a nightmare to manage and a sore point for audits, we would like to remove it.
The sss_seed tool was meant as a way to mitigate this.