>Anyway, this discussion started as a thread about mapping sudo to either
>InteractiveLogonRight or RemoteLogonRight. It sounds to me that
>Michichael and Simo are for moving sudo to the Remote bucked. Is that
>right?

Negative - we're for removing it from GPO checks entirely.

> Isn't the use of RunAs/UAC on Windows similar to sudo (in that they are used for privilege escalation)?

Yes and no - When you RunAs it checks the target account for Local InteractiveLogon - if you try to RunAs an account that is denied Local InteractiveLogon it'll fail (even if you can remotely log into that account and execute the task as that account). Sudoers is closer to creating process tokens and act as operating system since it does impersonation. RunAs isn't impersonation, it's a secondary logon. UAC does impersonation for admin tokens, but not with the ruleset that sudo has. That's why it's so muddy.

>It's not clear to me which option you are suggesting?

My position is option B. An account with only RemoteInteractiveLogon and/or Denied Local InteractiveLogon should still be able to authenticate against sudo and use its functionality.


On Mon, Aug 11, 2014 at 12:17 PM, Yassir Elley <yelley@redhat.com> wrote:


----- Original Message -----
> On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:
> >
> > In our case, when a user calls "sudo ls", I think it is a three-step
> > procedure:
> > 1) sudo calls pam_authenticate to authenticate the user
> > 2) sudo calls pam_acct_mgmt to make sure that the account is not
> > locked, that the ldap/gpo policies permit the user to run sudo, etc
> > 3) sudo refers to /etc/sudoers to determine if it can perform the sudo
> > action (i.e. "ls").
> >
> > The GPO Logon Rights relate to step (2) of this procedure.
>
> Except we do not have a logon right in windows that really matches what
> sudo is/does ... besiodes given sudo does its own authorization checks,
> what's the point of 2 ?

Isn't the use of RunAs/UAC on Windows similar to sudo (in that they are used for privilege escalation)?

>
> [..]
>
> > Are you suggesting that sudo skip all of the pam_acct_mgmt checks
> > (checking for locked accounts, ldap filter policies), or that it skip
> > only the gpo policy check?
>
> Yes I think that is what Michichael and I ended up agreeing is the most
> sensible solution, given any other would prevent the rightful use of
> sudo in some situations where it should be allowed.
>

It's not clear to me which option you are suggesting?
Option A: sssd should skip *all* pam_acct_mgmt checks (including locked accounts, ldap filter policies, gpo logon rights)
Option B: sssd should skip only the gpo logon rights check, but continue to check for locked accounts and ldap filter policies

Thanks,
Yassir.
_______________________________________________
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel