9:40 p.m.
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
3:54 a.m.
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan(a)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(a)ipa.test cachedPassword
# record 1
dn: name=u2(a)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:
>
> 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
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
4:45 a.m.
Jakub Hrozek wrote:
On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan(a)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.
5:09 a.m.
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(a)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
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.
5:49 a.m.
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(a)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
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
7:04 a.m.
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(a)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
>
>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.
--
Simo Sorce * Red Hat, Inc * New York
4:05 p.m.
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.
5:22 p.m.
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
4:47 a.m.
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.
--
Simo Sorce * Red Hat, Inc * New York
5:05 a.m.
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
7:27 a.m.
On Tue, Nov 29, 2016 at 5:45 AM, Michael Ströder <michael(a)stroeder.com>
wrote:
Jakub Hrozek wrote:
> On Tue, Nov 29, 2016 at 03:40:26AM -0000, kevin4sullivan(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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
10:23 a.m.
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(a)stroeder.com
<mailto:michael@stroeder.com>> wrote:
Jakub Hrozek wrote:
> On Tue, Nov 29, 2016 at 03:40:26AM -0000,
kevin4sullivan(a)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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
To unsubscribe send an email to
sssd-users-leave(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
1:47 p.m.
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.
2:21 p.m.
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
1. 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.
2. Make sure everything else works as expected for your users in daily life.
Ciao, Michael.
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
2:29 p.m.
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.
2701
days inactive
2702
days old
sssd-users@lists.fedorahosted.org
14 comments
6 participants
participants (6)
-
Jakub Hrozek -
Kevin Sullivan -
Lukas Slebodnik -
Mario Rossi -
Michael Ströder -
Simo Sorce