John Hodrien <J.H.Hodrien(a)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.