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 ?
Regards Philippe
!!!************************************************************************************* "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 transmis.
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 virus transmitted.!!!"
Ijcni
----- Původní zpráva ----- Od:"Maupertuis Philippe" philippe.maupertuis@equensworldline.com Odesláno:16. 1. 2019 9:15 Komu:"sssd-users@lists.fedorahosted.org" sssd-users@lists.fedorahosted.org Předmět:[SSSD-users] Understanding sssd cache
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 ?
Regards Philippe
!!!************************************************************************************* "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 transmis.
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 virus transmitted.!!!"
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. May I know what do you want to achieve?
LS
-----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.
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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
!!!************************************************************************************* "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 transmis.
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 virus transmitted.!!!"
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.
-----Message d'origine----- De : Jakub Hrozek [mailto:jhrozek@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: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.
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.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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
!!!************************************************************************************* "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 transmis.
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 virus transmitted.!!!"
On Wed, Jan 16, 2019 at 03:50:59PM +0100, Maupertuis Philippe wrote:
-----Message d'origine----- De : Jakub Hrozek [mailto:jhrozek@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: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.
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?
-----Message d'origine----- De : Jakub Hrozek [mailto:jhrozek@redhat.com] Envoyé : mercredi 16 janvier 2019 16:03 À : sssd-users@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:jhrozek@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: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.
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?
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 it.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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
!!!************************************************************************************* "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 transmis.
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 virus transmitted.!!!"
On 1/16/19 1:45 PM, Maupertuis Philippe wrote:
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.
I've been through these discussions already in large environments.
After all it turned out that this console use-case is not relevant (besides a very rare niche use-case with manually reloading a network driver kernel module due to a very specific hardware issue).
Ask yourself: Can the admin do any reasonable action on a machine in case the network is down? The answer is generally no. The admin will simply wait for the network guys to fix things on their side.
If you have network you can use emergency SSH keys to get root access if user management is broken. Some well-defined process for getting access to the private keys will also work even for strict auditors - YMMV. In my case the admins removed the emergency keys because the LDAP user management is available (dozens of replicas).
A shared account is a nightmare to manage and a sore point for audits, we would like to remove it.
Yes, one should try to avoid that.
Ciao, Michael.
-----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : vendredi 25 janvier 2019 07:30 À : End-user discussions about the System Security Services Daemon; Maupertuis Philippe Objet : ** SPAM scored: High **Re: [SSSD-users] Re: Understanding sssd cache
On 1/16/19 1:45 PM, Maupertuis Philippe wrote:
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.
I've been through these discussions already in large environments.
After all it turned out that this console use-case is not relevant (besides a very rare niche use-case with manually reloading a network driver kernel module due to a very specific hardware issue).
Ask yourself: Can the admin do any reasonable action on a machine in case the network is down? The answer is generally no. The admin will simply wait for the network guys to fix things on their side.
We do have a very common use case where we need console access. When either SSH or the network inside the server need to be restarted. For sshd (and sssd) that can be mitigated by using the restart on failure feature of systemd. SSHD is sometimes in a stale state, not working but not dead either. I failed to find something similar for the network layer. If I missed something there I would be glad to know what should we do.
If you have network you can use emergency SSH keys to get root access if user management is broken. Some well-defined process for getting access to the private keys will also work even for strict auditors - YMMV. In my case the admins removed the emergency keys because the LDAP user management is available (dozens of replicas).
A shared account is a nightmare to manage and a sore point for audits, we would like to remove it.
Yes, one should try to avoid that.
Ciao, Michael.
!!!************************************************************************************* "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 transmis.
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 virus transmitted.!!!"
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Maupertuis Philippe -
Michael Ströder -
Pavel Arnošt