On Mon, 2019-09-23 at 14:39 -0500, Spike White wrote:
All,
Our cybersecurity team doesn’t allow Linux sysadmins to directly log in as
root. (violates accountability, auditability and traceability). We log in
with an ADM account, which is then eligible to become root via ‘sudo su –‘.
That is, all members of a particular group are allowed to sudo to root.
This is preferred because with modern sudo versions all sudo sessions are
session-logged.
Anyway, if I log in with my ADM account and someone shuts down sssd, it no
longer knows what groups I’m in. That is, the session is still there – but
it cannot look up the group names.
[admspike_white@zzzdmsdev06 ~]$ id
uid=2025431 gid=1002 groups=1002,2284295
Because the sudo privs are based on group name, it doesn’t allow Linux
sysadmins to become root and thus start sssd.
Is there a way to cache those group names and memberships? Say with nscd?
So that if sssd is (temporarily) shut down, we can become root and start up?
sssd already caches user and group tables for fast lookup, but those
caches are not very big, so if you have very many groups you may need
to increase the size.
Also these caches have somewhat strict timeouts, I forget if they stop
returning anything at all if the timeout is expired.
Obviously, we can go look up the root password for the particular
server –
but that’s a painful portal. It’d be better if we could cache group names
and memberships, if sssd is temporarily down or offline.
Perhaps an RFE to return whatever was in cachi, even if expired, if
sssd daemons are unresponsive may be opened, should that be the
behavior when caches timed out.
(We have other AD integration products that have this “offline
caching”
feature that can enabled or disabled.)
SSSD has it too, I guess it is just a matter of tuning and/or "fixing"
the behavior when the daemon is unresponsive.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc