On Mon, 2014-08-11 at 15:17 -0400, Yassir Elley 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)?
Not really, they are more like su/su-l than sudo/sudo-l
>
> [..]
>
> > 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
Option C:
for sudo/sudo-l assume a local overriding policy of "Allow"
Simo.
--
Simo Sorce * Red Hat, Inc * New York