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.
That should be my decision, not enforced by SSSD.
Jocke
On 09/26/2014 06:52 AM, Joakim Tjernlund wrote:
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.
That should be my decision, not enforced by SSSD.
Jocke
Sorry. Non necessarily true. root should not fail so SSSD does not process root. This has been an architectural decision. However you are welcome to summarize your requirements and file a ticket. There is a chance that we still fully do not understand what you are trying to accomplish and why you are trying to do it that way.
Keep in mind that if you are relying on SSSD then you can rely on SUDO too so you can use non root central name. This is a recommended approach. If you do not trust SSSD for root (which is also how it should be as Stephen explained) then you should rely on pam_unix to process root.
Having root defined centrally because you trust SSSD but do not trust SUDO does not make much sense, sorry.
Dmitri Pal dpal@redhat.com wrote on 2014/09/26 13:11:38:
On 09/26/2014 06:52 AM, Joakim Tjernlund wrote:
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.
That should be my decision, not enforced by SSSD.
Jocke
Sorry. Non necessarily true. root should not fail so SSSD does not process root. This has been an architectural decision. However you are welcome to summarize your requirements and file a
ticket.
There is a chance that we still fully do not understand what you are trying to accomplish and why you are trying to do it that way.
I think you do understand by now, it is a simple request.
Keep in mind that if you are relying on SSSD then you can rely on SUDO too so you can use non root central name. This is a recommended approach. If you do not trust SSSD for root (which is also how it should be as Stephen explained) then you should rely on pam_unix to process root.
Having root defined centrally because you trust SSSD but do not trust SUDO does not make much sense, sorry.
I see this the other way, SSSD has little to no technical reason to deny an AD root user. It is just an "architectural decision" and best practice enforced with no way out.
Jocke
On Fri, 26 Sep 2014 13:44:56 +0200 Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
I see this the other way, SSSD has little to no technical reason to deny an AD root user.
SSSD denies access to any 'root' or uid = 0 users from any domain regardless of type. The technical decision was made when we started the project to avoid causing issues recovering a machine should sssd misbheave. By not handling the root user we cannot break the root user login.
It is just an "architectural decision" and best practice enforced with no way out.
Indeed, there is no way out, and SSSD internals make it impossible to easily fix as uid=0 is considered an invalid uid throughout all the caching layer.
Sorry it does not meet your expectations, but this is how it works.
Simo.
Simo Sorce simo@redhat.com wrote on 2014/09/26 18:34:56:
On Fri, 26 Sep 2014 13:44:56 +0200 Joakim Tjernlund joakim.tjernlund@transmode.se wrote:
I see this the other way, SSSD has little to no technical reason to deny an AD root user.
SSSD denies access to any 'root' or uid = 0 users from any domain regardless of type. The technical decision was made when we started the project to avoid causing issues recovering a machine should sssd misbheave. By not handling the root user we cannot break the root user login.
It is just an "architectural decision" and best practice enforced with no way out.
Indeed, there is no way out, and SSSD internals make it impossible to easily fix as uid=0 is considered an invalid uid throughout all the caching layer.
Sorry it does not meet your expectations, but this is how it works.
I understand better now. Thank you for bearing with me and the history lesson. We will adapt and make sure sudo and k5login are setup on every install.
Jocke
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Joakim Tjernlund -
Simo Sorce