De : Jakub Hrozek [mailto:email@example.com]
Envoyé : mercredi 16 janvier 2019 16:03
À : sssd-users(a)lists.fedorahosted.org
Objet : [SSSD-users] Re: Understanding sssd cache
On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote:
> > -----Message d'origine-----
> > De : Jakub Hrozek [mailto:firstname.lastname@example.org]
> > Envoyé : mercredi 16 janvier 2019 15:24
> > À : sssd-users(a)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:email@example.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
> > > > needed as soon as sssd is started.
> > > > >With enumerate = false, the cache holds information about
> > only
> > > > after his first connection.
> > > > >Is that right ?
> > > > >I would like to be sure that user's passwords are stored in
> > > > couldn't find any way to verify this
> > > > >With sssctl user-show I can find if a user is in the cache but
> > details.
> > > > >With sssctl user-checks I get some information about the user
> > nothing
> > > > about the password.
> > > > >By examining directly the cache with ldbsearch I don't find
> > > > information either, only maybe shadowLastChange: with a number
> > I
> > > > don't understand.
> > > > >Is there any documentation about the cache management ?
> > > > >
> > > >
> > > > Hashed password is cached only after successful authentication. It
> > > > rerieved by "getent passwd $user".
> > > >
> > > > sssd cache is internal cache and should not be used directly by
> > > 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
> > 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
> > have a local (shared) account to connect to the console.
> > > A shared account is a nightmare to manage and a sore point for audits,
> > 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
If you're going to orchestrate useradd for each local user, how is that
more difficult than sss_seed for each remote user?
Maybe I am missing something but sss_seed requires a password.
Only the user itself can provide a password for himself , even a temporary one otherwise
he can pretend it was not him who did evil things.
And sss_seed would be needed for all remote users.
I just need one local user (and I have already root) for which I must manage the password
according to the various security standards we are subject to.
Managing the root password is not exactly a piece of cake, I was hoping to get rid of
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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-
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage
exclusif de ses destinataires. Il peut également être protégé par le secret professionnel.
Si vous recevez ce message par erreur, merci d'en avertir immédiatement
l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur
Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce
message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission
exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa
responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus
This e-mail and the documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in error, please notify
the sender immediately and destroy it. As its integrity cannot be secured on the Internet,
the Worldline liability cannot be triggered for the message content. Although the sender
endeavours to maintain a computer virus-free network, the sender does not warrant that
this transmission is virus-free and will not be liable for any damages resulting from any