What is the SSSD approach to allowing a user to only login when its backend if offline?
I currently have an OpenLDAP server that I authenticate against via SSSD and PAM to login. Normally, I can log into my machines with the accounts stored in LDAP, however, I would like to still be able to log into those machines even if my LDAP server is not online. I want to have an emergency user that is able to login when LDAP is not online, but I don't want the emergency user to be able to log in when LDAP is online. I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
What I am currently doing that doesn't work is having a locked account in LDAP for the emergency user. So if someone tries to login as the emergency user it will fail. The emergency user is disabled by the setting `ldap_access_order` to `expire`. Unfortunately, when LDAP is offline, the emergency user still has the locked attribute since the user's attributes are cached. So the emergency user still fails to login.
So my questions are:
1. SSSD is caching my user information (not credentials) when my LDAP server is offline. Is there a way to not cache user information or drop it after a set amount of time? I don't think there is a way, but I want to ask. I also don't think that this is the SSSD mindset, which leads to my next question.
2. What is the SSSD way to allow a user to only login when its backend is offline? Is there a way to do special things when a backend if offline? Instead of locking the account through a client-side 'access' check, should I be doing this through a server-side mechanism? Am I missing something incredibly obvious? Is this just a stupid approach to begin with?
I am sure there is a good way to do this, I just don't know enough to figure it out.
Thanks,
Kevin
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com wrote:
What is the SSSD approach to allowing a user to only login when its backend if offline?
I'm not aware of anything readily available.
I currently have an OpenLDAP server that I authenticate against via SSSD and PAM to login. Normally, I can log into my machines with the accounts stored in LDAP, however, I would like to still be able to log into those machines even if my LDAP server is not online. I want to have an emergency user that is able to login when LDAP is not online, but I don't want the emergency user to be able to log in when LDAP is online. I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
Please note that the credential caching does not actually cache plaintext passwords, but only password hashes. Moreover, the cache is only accessible to the root user.
Here is an example from my test machine: # ldbsearch -H /var/lib/sss/db/cache_ipa.test.ldb name=u2@ipa.test cachedPassword # record 1 dn: name=u2@ipa.test,cn=users,cn=ipa.test,cn=sysdb cachedPassword: $6$l7TwL4n/aPNa1lCE$jkNEiWWVBbUbzjamOGgLSgjKONsIh8hgwrzRbHWKr9uIhmIM9OgNuP3vpAjGE2bHe1g84EKONVjpzmEx.shEX/
What I am currently doing that doesn't work is having a locked account in LDAP for the emergency user. So if someone tries to login as the emergency user it will fail. The emergency user is disabled by the setting `ldap_access_order` to `expire`. Unfortunately, when LDAP is offline, the emergency user still has the locked attribute since the user's attributes are cached. So the emergency user still fails to login.
So my questions are:
- SSSD is caching my user information (not credentials) when my LDAP server is offline. Is there a way to not cache user information or drop it after a set amount of time?
I don't think there is a way, but I want to ask. I also don't think that this is the SSSD mindset, which leads to my next question.
- What is the SSSD way to allow a user to only login when its backend is offline?
Is there a way to do special things when a backend if offline? Instead of locking the account through a client-side 'access' check, should I be doing this through a server-side mechanism? Am I missing something incredibly obvious? Is this just a stupid approach to begin with?
I am sure there is a good way to do this, I just don't know enough to figure it out.
Thanks,
Kevin _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com wrote:
I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
Please note that the credential caching does not actually cache plaintext passwords, but only password hashes. Moreover, the cache is only accessible to the root user.
Very good for the security. But this password caching requires that the user has done a successful login at least once before. That's not true in practice because in the DevOps world admins spin up and configure VMs and containers without even accessing them. Even if one admin used his password during initial setup the admin trying to solve a problem during the night shift likely did not enter his password before.
Pick your poison:
1. securely organize temporary(!) emergency access
2. LDAP deployment has to be available all times
3. sync user account and password hashes to /etc/passwd and /etc/shadow
Ciao, Michael.
On Tue, Nov 29, 2016 at 11:45:27AM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com wrote:
I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
Please note that the credential caching does not actually cache plaintext passwords, but only password hashes. Moreover, the cache is only accessible to the root user.
Very good for the security. But this password caching requires that the user has done a successful login at least once before. That's not true in practice because in the DevOps world admins spin up and configure VMs and containers without even accessing them. Even if one admin used his password during initial setup the admin trying to solve a problem during the night shift likely did not enter his password before.
Pick your poison:
securely organize temporary(!) emergency access
LDAP deployment has to be available all times
sync user account and password hashes to /etc/passwd and /etc/shadow
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
I admit I haven't tested sss_seed in quite some time, though. The user should also exist in the LDAP directory, because the directory is always considered authoritative and if SSSD was online and the user wasn't found with LDAP search, then we would consider the account as removed and remove its entry from the cache as well.
On (29/11/16 12:09), Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 11:45:27AM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com wrote:
I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
Please note that the credential caching does not actually cache plaintext passwords, but only password hashes. Moreover, the cache is only accessible to the root user.
Very good for the security. But this password caching requires that the user has done a successful login at least once before. That's not true in practice because in the DevOps world admins spin up and configure VMs and containers without even accessing them. Even if one admin used his password during initial setup the admin trying to solve a problem during the night shift likely did not enter his password before.
Pick your poison:
securely organize temporary(!) emergency access
LDAP deployment has to be available all times
sync user account and password hashes to /etc/passwd and /etc/shadow
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
sssd_seed works well with master. @see man 8 sss_seed
But it would not solve the requirement to authenticate only in offline mode.
LS
On Tue, 2016-11-29 at 12:49 +0100, Lukas Slebodnik wrote:
On (29/11/16 12:09), Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 11:45:27AM +0100, Michael Ströder wrote:
Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com wrote:
I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
Please note that the credential caching does not actually cache plaintext passwords, but only password hashes. Moreover, the cache is only accessible to the root user.
Very good for the security. But this password caching requires that the user has done a successful login at least once before. That's not true in practice because in the DevOps world admins spin up and configure VMs and containers without even accessing them. Even if one admin used his password during initial setup the admin trying to solve a problem during the night shift likely did not enter his password before.
Pick your poison:
securely organize temporary(!) emergency access
LDAP deployment has to be available all times
sync user account and password hashes to /etc/passwd and /etc/shadow
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
sssd_seed works well with master. @see man 8 sss_seed
But it would not solve the requirement to authenticate only in offline mode.
It would if you remove the password in LDAP and make sure a bind always fail. Then it would work only in offline mode, with the seeded password.
But this "only offline" thing seem a red herring, it is easy to cause a machine to go offline (therefore "unlocking" this account) so it is not clear to me why this is an actual requirement.
Simo.
Jakub Hrozek wrote:
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
AFAICS it needs the password in cleartext. Right?
Ciao, Michael.
On (29/11/16 23:05), Michael Ströder wrote:
Jakub Hrozek wrote:
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
AFAICS it needs the password in cleartext. Right?
man 8 sss_sed says:
-p,--password-file PASS_FILE Specify file to read user's password from. (if not specified password is prompted for)
password in test file need to be in cleartext. But without this option you will be propted in the similar was as with changing password with `passwd`
LS
On Wed, 2016-11-30 at 00:22 +0100, Lukas Slebodnik wrote:
On (29/11/16 23:05), Michael Ströder wrote:
Jakub Hrozek wrote:
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
AFAICS it needs the password in cleartext. Right?
man 8 sss_sed says:
-p,--password-file PASS_FILE Specify file to read user's password from. (if not specified password is prompted for)password in test file need to be in cleartext. But without this option you will be propted in the similar was as with changing password with `passwd`
How hard would it be to allow to pass in a pre-hashed password ? Simo.
On (30/11/16 05:47), Simo Sorce wrote:
On Wed, 2016-11-30 at 00:22 +0100, Lukas Slebodnik wrote:
On (29/11/16 23:05), Michael Ströder wrote:
Jakub Hrozek wrote:
Would "sss_seed" help here to add a temporary password for some 'operator' account even if this operator never logged in? e.g. https://linux.die.net/man/8/sss_seed
AFAICS it needs the password in cleartext. Right?
man 8 sss_sed says:
-p,--password-file PASS_FILE Specify file to read user's password from. (if not specified password is prompted for)password in test file need to be in cleartext. But without this option you will be propted in the similar was as with changing password with `passwd`
How hard would it be to allow to pass in a pre-hashed password ?
ATM, we use sysdb_cache_password in the tool which create sha512 salted hash itself before storing it to cache.
IMHO, it would not be a a problem to pass pre-hashed password We might want to check that it's valid sha512 or we can skip validation and store it to directly as string.
So answer is it will not be hard but also probably not a high priority. Feel free to file a ticket.
LS
On Tue, Nov 29, 2016 at 5:45 AM, Michael Ströder michael@stroeder.com wrote:
Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com
wrote:
I don't want to cache credentials and I can't guarantee that the account will have been used to login before LDAP is offline.
Please note that the credential caching does not actually cache plaintext passwords, but only password hashes. Moreover, the cache is only accessible to the root user.
Very good for the security. But this password caching requires that the user has done a successful login at least once before. That's not true in practice because in the DevOps world admins spin up and configure VMs and containers without even accessing them. Even if one admin used his password during initial setup the admin trying to solve a problem during the night shift likely did not enter his password before.
Pick your poison:
securely organize temporary(!) emergency access
LDAP deployment has to be available all times
sync user account and password hashes to /etc/passwd and /etc/shadow
Ciao, Michael.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Thank you very much for responding so quickly. I always appreciate the intelligent and informative ideas.
I don't think I was clear with my initial message (or I have misunderstood your suggestions). I have no problem authenticating my emergency user when my LDAP backend if offline. Since I am not caching credentials, `pam_sss` will return a special error code (maybe PAM_AUTHINFO_UNAVAIL -- 9) and I am able to use `pam_unix` (`/etc/passwd`) to authenticate.
My problem comes when I try to authorize the user in the `account` section of my PAM configuration file (`/etc/pam.d/system-auth`). In my SSSD configuration (`/etc/sssd/sssd.conf`), I am preventing locked accounts from logging in with the following settings:
ldap_access_order = expire ldap_account_expire_policy = rhds ldap_ns_account_lock = customLockedAttribute
So my emergency account has its customLockedAttribute set to TRUE in LDAP, so the emergency user will be unable to log in when LDAP is online. However, when LDAP is offline, my emergency account is still unable to log in because SSSD caches the value of the customLockedAttribute.
Is this a better way to prevent an account from logging in when my backend is online?
Thanks and sorry for causing an confusion.
Kevin
Kevin,
I understand your pain, I have the same issue. We have a local emargency user in /etc/passwd and initially when we deployed servers everything was good. And then people started to use emergency user on a daily basis instead of their ldap accounts to bypass any ldap restrictions or misconfiguration of the servers. Another way is to 'hide' your user from /etc/passwd by using the local sssd provider but it really does not help. This emergency user comes in handy when you have dual factor authentication and you need to run a command on several servers and one cannot reuse the same token via Ansible for example.
I would love to know if there is a way for me to restrict emergency users when sssd/ldap is online without the pain of talking to each remote manager to enforce the existing policies. I could write a script to 'ping' ldap server and run commands locally but really I am against workarounds.
Thanks
On 11/30/2016 08:27 AM, Kevin Sullivan wrote:
On Tue, Nov 29, 2016 at 5:45 AM, Michael Ströder <michael@stroeder.com mailto:michael@stroeder.com> wrote:
Jakub Hrozek wrote: > On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan@gmail.com <mailto:kevin4sullivan@gmail.com> wrote: >> I don't want to >> cache credentials and I can't guarantee that the account will have been >> used to login before LDAP is offline. > > Please note that the credential caching does not actually cache > plaintext passwords, but only password hashes. Moreover, the cache is > only accessible to the root user. Very good for the security. But this password caching requires that the user has done a successful login at least once before. That's not true in practice because in the DevOps world admins spin up and configure VMs and containers without even accessing them. Even if one admin used his password during initial setup the admin trying to solve a problem during the night shift likely did not enter his password before. Pick your poison: 1. securely organize temporary(!) emergency access 2. LDAP deployment has to be available all times 3. sync user account and password hashes to /etc/passwd and /etc/shadow Ciao, Michael. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org <mailto:sssd-users@lists.fedorahosted.org> To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org <mailto:sssd-users-leave@lists.fedorahosted.org>Thank you very much for responding so quickly. I always appreciate the intelligent and informative ideas.
I don't think I was clear with my initial message (or I have misunderstood your suggestions). I have no problem authenticating my emergency user when my LDAP backend if offline. Since I am not caching credentials, `pam_sss` will return a special error code (maybe PAM_AUTHINFO_UNAVAIL -- 9) and I am able to use `pam_unix` (`/etc/passwd`) to authenticate.
My problem comes when I try to authorize the user in the `account` section of my PAM configuration file (`/etc/pam.d/system-auth`). In my SSSD configuration (`/etc/sssd/sssd.conf`), I am preventing locked accounts from logging in with the following settings:
ldap_access_order = expire ldap_account_expire_policy = rhds ldap_ns_account_lock = customLockedAttribute
So my emergency account has its customLockedAttribute set to TRUE in LDAP, so the emergency user will be unable to log in when LDAP is online. However, when LDAP is offline, my emergency account is still unable to log in because SSSD caches the value of the customLockedAttribute.
Is this a better way to prevent an account from logging in when my backend is online?
Thanks and sorry for causing an confusion.
Kevin
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Mario Rossi wrote:
I understand your pain, I have the same issue. We have a local emargency user in /etc/passwd and initially when we deployed servers everything was good. And then people started to use emergency user on a daily basis
1. Make sure there's an organizational process to provide the credentials needed for the emergency users and revoke the credentials afterwards.
instead of their ldap accounts to bypass any ldap restrictions or misconfiguration of the servers.
2. Make sure everything else works as expected for your users in daily life.
Ciao, Michael.
On 11/30/2016 02:47 PM, Michael Ströder wrote:
Mario Rossi wrote:
I understand your pain, I have the same issue. We have a local emargency user in /etc/passwd and initially when we deployed servers everything was good. And then people started to use emergency user on a daily basis
- Make sure there's an organizational process to provide the credentials needed
for the emergency users and revoke the credentials afterwards.
Emergency users should be used when LDAP fails and there is no other way to get access to the box via ssh. I can recall an incident a few years ago where an admin deleted the bigip_monitoring user thinking that the account is not used. You would think that people would be able to tell what the user is being used for :) In this case the LB took down the ldap farm and emergency user was a savior until the user had been restored.
instead of their ldap accounts to bypass any ldap restrictions or misconfiguration of the servers.
- Make sure everything else works as expected for your users in daily life.
Ciao, Michael.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Mario Rossi wrote:
Emergency users should be used when LDAP fails and there is no other way to get access to the box via ssh.
Yes.
I can recall an incident a few years ago where an admin deleted the bigip_monitoring user thinking that the account is not used. You would think that people would be able to tell what the user is being used for :) In this case the LB took down the ldap farm and emergency user was a savior until the user had been restored.
;-)
My usual recommendation is *not* to use the load-balancer in sssd configuration. Tests showed that sssd with its persistent LDAP connection can cope fairly well with simple DNS round robin.
Ciao, Michael.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Kevin Sullivan -
Lukas Slebodnik -
Mario Rossi -
Michael Ströder -
Simo Sorce