John Hodrien <[email protected]> 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.
_______________________________________________
sssd-users mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Reply via email to