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.
You missed the point. You claim remote root is a nono yet you suggest to login remotely with local root pw.
I really appreciate sssd denying root completely. Most people concerned
about
security surely agree.
But it don't. sssd does not deny remote local root pw logins.
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.
But I don't. I just ask for the possibility choose. Let the default be as is.
PS. Please keep me on CC
Jocke
Ciao, Michael.
Joakim Tjernlund wrote:
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.
You missed the point. You claim remote root is a nono yet you suggest to login remotely with local root pw.
You're missing the point. Especially I did *not* suggest to login remotely with local root pw.
I'd recommend to establish proper operational procedures. It's your job to develop those for your system environment.
I really appreciate sssd denying root completely. Most people concerned
about
security surely agree.
But it don't. sssd does not deny remote local root pw logins.
To be more precise what I meant: It does prevent remote root users. And that's good!
Ciao, Michael.
Michael Ströder michael@stroeder.com wrote on 2014/09/25 15:25:03:
Joakim Tjernlund wrote:
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.
You missed the point. You claim remote root is a nono yet you suggest
to
login remotely with local root pw.
You're missing the point. Especially I did *not* suggest to login
remotely
with local root pw.
I'd recommend to establish proper operational procedures. It's your job to develop those for your system environment.
Yes, it is "my" job, not sssd's. Currently sssd dictate that no system ever should be allowed to login as root, no matter what.
Jocke
On Thu, 25 Sep 2014, Joakim Tjernlund wrote:
Yes, it is "my" job, not sssd's. Currently sssd dictate that no 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.
jh
-----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 no 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, sorry):
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.
Stephen Gallagher sgallagh@redhat.com wrote on 2014/09/25 17:36:08:
-----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 no 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, sorry):
There are two reasons why SSSD refuses to handle root:
- 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.)
- 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.
Don't quite follow here. I do have a local root user in passwd/shadow with a local pw as required by any UNIX I know. I also have a AD root account.
When logging in as root PAM first tries the local root account and if that fails SSSD is asked to authenticate. So if I use the local root pw PAM logs me in without SSSD involment, but if I use the domain root user pw, SSSD should log me in.
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.
I cannot see how my case above can cause a catastrophe such as 1)
Jocke
On 25/09/14 17:26, Joakim Tjernlund wrote:
Stephen Gallagher sgallagh@redhat.com wrote on 2014/09/25 17:36:08:
-----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 no 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, sorry):
There are two reasons why SSSD refuses to handle root:
- 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.)
- 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.
Don't quite follow here. I do have a local root user in passwd/shadow with a local pw as required by any UNIX I know. I also have a AD root account.
Lets get this straight, you have a user called 'root' in /etc/passwd and another user called 'root' in AD, is this correct ???
Rowland
When logging in as root PAM first tries the local root account and if that fails SSSD is asked to authenticate. So if I use the local root pw PAM logs me in without SSSD involment, but if I use the domain root user pw, SSSD should log me in.
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.
I cannot see how my case above can cause a catastrophe such as 1)
Jocke _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 09/25/2014 02:27 PM, Rowland Penny wrote:
On 25/09/14 17:26, Joakim Tjernlund wrote:
Stephen Gallagher sgallagh@redhat.com wrote on 2014/09/25 17:36:08:
-----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 no 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, sorry):
There are two reasons why SSSD refuses to handle root:
- 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.)
- 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.
Don't quite follow here. I do have a local root user in passwd/shadow with a local pw as required by any UNIX I know. I also have a AD root account.
Lets get this straight, you have a user called 'root' in /etc/passwd and another user called 'root' in AD, is this correct ???
You should name your central user something else. SSSD will deliberately not authenticate root because root should be authenticated by pam_unix.
Rowland
When logging in as root PAM first tries the local root account and if that fails SSSD is asked to authenticate. So if I use the local root pw PAM logs me in without SSSD involment, but if I use the domain root user pw, SSSD should log me in.
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.
I cannot see how my case above can cause a catastrophe such as 1)
Jocke _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 25/09/14 20:36, Dmitri Pal wrote:
On 09/25/2014 02:27 PM, Rowland Penny wrote:
On 25/09/14 17:26, Joakim Tjernlund wrote:
Stephen Gallagher sgallagh@redhat.com wrote on 2014/09/25 17:36:08:
-----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 no 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, sorry):
There are two reasons why SSSD refuses to handle root:
- 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.)
- 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.
Don't quite follow here. I do have a local root user in passwd/shadow with a local pw as required by any UNIX I know. I also have a AD root account.
Lets get this straight, you have a user called 'root' in /etc/passwd and another user called 'root' in AD, is this correct ???
You should name your central user something else. SSSD will deliberately not authenticate root because root should be authenticated by pam_unix.
Hi How about deleting the user called root in AD, choosing another domain user called adroot. Then use: username map = /some/file to make adroot map to root in /some/file?
adroot is now a domain user with uid 0 HTH, Steve
Hi How about deleting the user called root in AD, choosing another domain user called adroot. Then use: username map = /some/file to make adroot map to root in /some/file?
adroot is now a domain user with uid 0 HTH, Steve
Has anyone mentioned dropping a .k5login file in root's home directory? http://web.mit.edu/kerberos/krb5-devel/doc/user/user_config/k5login.html
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.
On 25/09/14 23:43, Nordgren, Bryce L -FS wrote:
Has anyone mentioned dropping a .k5login file in root's home directory? http://web.mit.edu/kerberos/krb5-devel/doc/user/user_config/k5login.html
Doesn't work here. Maybe it needs pam_krb5?
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.
Bryce
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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 no 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, sorry):
There are two reasons why SSSD refuses to handle root:
- 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.)
- 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
iEYEARECAAYFAlQkNmgACgkQeiVVYja6o6O/MQCffI/GNic0XVAKazJkMeDv4a DU TIYAn0tZLUHAYFUiW1xoNKBITVCJRUdg =amSE -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
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.
https://fedorahosted.org/freeipa/ticket/3644
Bryce
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users- bounces@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 no 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, sorry):
There are two reasons why SSSD refuses to handle root:
- 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.)
- 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
iEYEARECAAYFAlQkNmgACgkQeiVVYja6o6O/MQCffI/GNic0XVAKazJkMeDv4a DU TIYAn0tZLUHAYFUiW1xoNKBITVCJRUdg =amSE -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Joakim Tjernlund -
John Hodrien -
Michael Ströder -
Nordgren, Bryce L -FS -
Rowland Penny -
Stephen Gallagher -
steve