On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote: > > > > -----Message d'origine----- > > De : Jakub Hrozek [mailto:jhro...@redhat.com] > > Envoyé : mercredi 16 janvier 2019 15:24 > > À : sssd-users@lists.fedorahosted.org > > Objet : [SSSD-users] Re: Understanding sssd cache > > > > 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. > If I understand it correctly to have only nominative account in place for > console login, each user would have to put his own password in the cache > before something goes wrong. > Obviously it won't work in a large environment. > So we can't rely on SSSD and its cache for console login, a local user is > mandatory.
If you're going to orchestrate useradd for each local user, how is that more difficult than sss_seed for each remote user? _______________________________________________ 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
