John Hodrien J.H.Hodrien@leeds.ac.uk wrote on 2014/09/25 11:22:52:
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
Because as an admin I need to login on users boxes to fix stuff they
broke.
Sometimes su/sudo are not setup/broken too.
If your goal is to have the same root password across an enterprise,
I
recommend something like Puppet or Ansible.
How does that help me to ssh in and what if Puppet/Ansible is not setup/broken? Not every box is installed the same.
If every machine is different, and you can't be sure su/sudo are
working, and
you don't know the local root password, I'd not have a lot of faith that
sssd
How is local root pw any different than domain pw? In your view remote root access is a big nono so sssd should also enforce no remote root login in that case. I have no problem using local root pw when I known what it is but I don't care to memorize them all, besides users can change local root pw.
would be working. Add to that, you're talking about breaking best
practice as
I'd prefer to see root password based logins disallowed.
You just said it: "best practice", not a law. In this context, sssd dictates policy and that is not sssd's call to make IMHO. You should encourage best practice though. One day we will get there but not today :)
Finally, why are you not up front with this policy? Nowhere I can find is this documented and since this is a unusual enforcement you should document this limitation with "big letters" so everyone is aware beforehand, it sure would have saved me a lot of time.
Jocke
PS. An unrelated request, it would be highly appreciated if sssd could have two build targets, sever and client(default both of course). This would help multilib installs immensely.