On Wed, Sep 24, 2014 at 06:57:54PM +0200, Joakim Tjernlund wrote:
Trying to figure how to setup sssd to allow me to ssh into another box
as
root using the domain root passwd.
It's not possible by design, SSSD explicitly drops all requests for either root or UID 0. root is really a machine-local administrator, nothing that should be present on the remote servers.
Thanks, I can stop trying then. This should be clearly stated somewhere though.
Nothing I tried lets me do that so could someone please give me an
example
config which lets root in with domain passwd?
Why do you need this?
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 the goal is to let users administer machines, then storing sudo rules in LDAP is the best way forward.
That we have but I am looking for easy admin access.
sssd should not dictate way of working. Admins should be able to change this behaviour, especially since this a new sssd specific rule and makes it harder for existing IT environments to migrate to sssd. Keep as default but let me override please.
PS. Please CC me as I am not on the list.
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 would be working. Add to that, you're talking about breaking best practice as I'd prefer to see root password based logins disallowed.
If you want the lightest touch setup that gets you what you want, I'd just stick a /root/.ssh/authorized_keys file on every machine's root account. That'd work just fine with sssd, and unless ssh is broken, and the local admin has deliberately deleted that file, you'll get in. You'll get into a much more broken system with that than you would relying on sssd.
jh
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.
On 25/09/14 12:15, Joakim Tjernlund wrote:
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. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
When you say 'logon as root using the domain root passwd' , do you mean as the 'root' user or as another user i.e. 'Administrator' on an AD domain ? and what sort of domain.
If you actually mean the 'root' user, then this is a local Unix user and as such should never be a domain user. Just think what would happen if something drastic occurred, like the domain software failing on a machine along with sssd corruption (yes I know this is unlikely, but unlikely things can and do happen) and your root user is only available via the domain. If the unlikely did happen, just how would you login to the machine and fix it???
Rowland Rowland
root using the domain root passwd
Joakim Tjernlund wrote:
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.
Yes, remote root password is a big no-no. Because it would be effective on all systems at once circumventing most security mechanisms.
I really appreciate sssd denying root completely. Most people concerned about security surely agree.
If you personally don't like this important aspect of sssd just use something else.
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 :)
It seems you don't have proper operational processes on your side to handle incidents and lock out your users from doing something bad. Then you ask for a significant security relevant change in a widely used component. That sucks.
Ciao, Michael.
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
John Hodrien J.H.Hodrien@leeds.ac.uk wrote on 2014/09/25 11:22:52:
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.
It isn't, but sssd isn't in a position to enforce it for local accounts. ssh is, which is why ssh provides the option:
AllowRoot without-password
If users change local root passwords they can equally well break sssd. They're unlikely to remove an authorized_keys file, and if they do, discipline them. I can't see what advantage you have using a network root credential over an ssh key, or a kerberos ticket.
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 :)
SSSD dictates what it does to be safe. I've no problem with that default.
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.
It might be worth forgiving sssd a little here.
auth requisite pam_succeed_if.so uid >= 500 quiet
You've almost certainly got something like this in pam. Don't accept network auth for local system accounts is a normal PAM policy.
jh
John Hodrien J.H.Hodrien@leeds.ac.uk wrote on 2014/09/25 15:06:16:
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
John Hodrien J.H.Hodrien@leeds.ac.uk wrote on 2014/09/25 11:22:52:
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.
It isn't, but sssd isn't in a position to enforce it for local accounts.
ssh
But you argue strongly for never allowing remote root login to the degree that you have forcefully disabled root login in sssd. Then it is reasonably you should also do your best to disallow local root pw login. You could scan sshd, PAM, securetty etc. and simply refuse to start if sssd finds that local root pw is allowed over the network.
is, which is why ssh provides the option:
AllowRoot without-password
Why would I want to enable that?
If users change local root passwords they can equally well break sssd. They're unlikely to remove an authorized_keys file, and if they do,
discipline
them. I can't see what advantage you have using a network root
credential
over an ssh key, or a kerberos ticket.
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 :)
SSSD dictates what it does to be safe. I've no problem with that
default.
It is not a default, there is no choice
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.
It might be worth forgiving sssd a little here.
auth requisite pam_succeed_if.so uid >= 500 quiet
You've almost certainly got something like this in pam. Don't accept
network
auth for local system accounts is a normal PAM policy.
That is a choice I got in PAM, sssd offers no choice.
Still, I don't see how the above somehow documents sssd's "no root login whatsoever" policy. The docs actually hints the opposite: filter_users, filter_groups (string) Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the particular domain. Default: root
This make me think I only have to add an empty filter_users to allow root
Jocke
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
is, which is why ssh provides the option:
AllowRoot without-password
Why would I want to enable that?
Because it's more secure than the default of allowing root logins with password remotely. But forget it, it's not entirely ontopic, as I'd partially misread what you'd said.
That is a choice I got in PAM, sssd offers no choice.
Still, I don't see how the above somehow documents sssd's "no root login whatsoever" policy. The docs actually hints the opposite: filter_users, filter_groups (string) Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the particular domain. Default: root
This make me think I only have to add an empty filter_users to allow root
Sure, the documentation encouragages you to think you could disable it, and if that's not the case, it's a flaw in the documentation.
Maybe you've got a point that sssd should allow this unusual setup.
jh
On Thu, Sep 25, 2014 at 03:46:14PM +0200, Joakim Tjernlund wrote:
Still, I don't see how the above somehow documents sssd's "no root login whatsoever" policy. The docs actually hints the opposite: filter_users, filter_groups (string) Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the particular domain. Default: root
This make me think I only have to add an empty filter_users to allow root
Jocke
You have a point about documenting us dropping root requests. Can you open a ticket upstream?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2014 10:01 AM, John Hodrien wrote:
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
is, which is why ssh provides the option:
AllowRoot without-password
Why would I want to enable that?
Because it's more secure than the default of allowing root logins with password remotely. But forget it, it's not entirely ontopic, as I'd partially misread what you'd said.
That is a choice I got in PAM, sssd offers no choice.
Still, I don't see how the above somehow documents sssd's "no root login whatsoever" policy. The docs actually hints the opposite: filter_users, filter_groups (string) Exclude certain users from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the particular domain. Default: root
This make me think I only have to add an empty filter_users to allow root
Sure, the documentation encouragages you to think you could disable it, and if that's not the case, it's a flaw in the documentation.
Maybe you've got a point that sssd should allow this unusual setup.
SSSD is designed to protect you from yourself. First of all, let's be clear: SSSD is a daemon and despite our best efforts, a daemon can fail. If you cannot log in as root using only the /etc/passwd and /etc/shadow files, it is *impossible* to restart SSSD or get your system back.
Without root in /etc/passwd and /etc/shadow, you also cannot start your system in single-user mode to deal with critical system failures, because SSSD would not have been started.
Because of those two *absolutely critical* situations, we expressly designed SSSD to ignore requests for UID 0. This fundamental decision is too ingrained to change at this point because it would require a major rewrite of nearly the entire code.
I have no regrets about this and no: we should not allow this unusual setup. The only thing that can possibly come out of this is tragedy.
If you want a remote "root" password, the much saner approach would be to create a central sudo rule allowing a user (or group of users) privilege to execute 'sudo su -' on all machines. Then you can simply log in as that user and trivially *become* root, without leaving all of your machines in a state that will inevitably lead to breakage.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Joakim Tjernlund -
John Hodrien -
Michael Ströder -
Rowland Penny -
Stephen Gallagher