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