On 09/25/2014 01:19 PM, Nordgren, Bryce L -FS wrote:
A novel approach used in rocks clusters is to manage ssh keys for all
users including root. Clearly this isn't a solution which allows you to login from
anywhere to anywhere (their architecture is that one logs into a headnode, then from there
you log into the compute node of your choice.) It also manages users by sync-ing
/etc/passwd + shadow across the cluster, giving central management of local accounts.
That said, "syncing things" really isn't sssd's job. There's other
tools designed to do that.
Wouldn't using constrained delegation (s4u2proxy) + HBAC would be a
better solution for this use case?
Then you do not need to manage SSH keys. You would need to define which
hosts are allowed to be "gateways" and make sure it is complemented by
corresponding HBAC policies.
IdM allows to do it now and latest Fedora/RHEL/CentOS should be able to
do it now.
IdM does not expose the management of the delegation yet (but it can be
done using LDAP modify, ugly but possible) but this is being added in 4.1.
> -----Original Message-----
> From: sssd-users-bounces(a)lists.fedorahosted.org [mailto:sssd-users-
> bounces(a)lists.fedorahosted.org] On Behalf Of Stephen Gallagher
> Sent: Thursday, September 25, 2014 9:36 AM
> To: End-user discussions about the System Security Services Daemon
> Cc: Joakim Tjernlund
> Subject: Re: [SSSD-users] root login with domain passwd
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 09/25/2014 11:01 AM, John Hodrien wrote:
>> On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
>>> Yes, it is "my" job, not sssd's. Currently sssd dictate that
>>> system ever should be allowed to login as root, no matter what.
>> SSSD dictates that no system should be allowed to login as root via
>> SSSD, and that's not quite the same. You're a corner case where
>> you're working against standard practice, but I can see why you think
>> it should be possible to configure SSSD to allow it, given that you
>> can strip away these sanity checks from PAM.
> Just to reiterate what I said elsewhere in this thread (without CCing Joakim,
> There are two reasons why SSSD refuses to handle root:
> 1) If SSSD was to crash, only root is capable of restarting it, debugging it or
> otherwise fixing the problem. So if you hit a bug and SSSD was the
> mechanism you used to log in as root, it cannot be fixed short of a reboot
> (and if the bug happens on every run because there was a regression in an
> update, your system is hosed.)
> 2) Without root in /etc/passwd and /etc/shadow, it's impossible to boot into
> single-user mode to fix any issues with the early boot process.
> These are the reasons that SSSD doesn't handle the root user. It's not a
> matter of a default, it's a matter of protecting users from an inevitable
> catastrophe. No matter how hard we try, bugs will always creep in. If you
> can't get in to fix them, then a bug becomes a disaster.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> -----END PGP SIGNATURE-----
> sssd-users mailing list
This electronic message contains information generated by the USDA solely for the
intended recipients. Any unauthorized interception of this message or the use or
disclosure of the information it contains may violate the law and subject the violator to
civil or criminal penalties. If you believe you have received this message in error,
please notify the sender and delete the email immediately.
sssd-users mailing list
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.