On Wed, Jan 16, 2019 at 01:45:35PM +0100, Maupertuis Philippe wrote: > > > > -----Message d'origine----- > > De : Lukas Slebodnik [mailto:lsleb...@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. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
