> 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.

Forgive me if I'm misunderstanding, but wouldn't the pam_authenticate attempt an authentication against AD if AD was available, and at that phase determine whether it's locked out or not? In testing, a locked account cannot use sudoers, even if it has a session. If AD isn't available, it'd use the cached password (if enabled), but it wouldn't detect a lockout regardless. Step 2 seems moot outside of that permission check.

>You assert that Windows would allow a user to perform remote login
>(and then access other services, batch jobs, privileged operations)
>using only the RemoteInteractiveLogonRight. Is your assertion based
>on actual testing on a Windows client?  I ask because this is not
>my understanding. I would expect that the RemoteInteractiveLogonRight
>would be consulted when the user used RemoteDesktop on a
>Windows client to login to the remote Windows server, and that the
>InteractiveLogonRight (Allow/Deny Local Logon) would be consulted
>when the user attempted to perform a privileged operation (using
>RunAs or UAC). However, I haven't actually tested this yet, so it would
>be useful to know if you have already tested this.

Correct, though Windows makes this is a bit muddy. If a user has rights granted for RemoteInteractive, but rights explicitly denied for Local Interactive (I'm going to refer to it as this just to keep the references clear, I think we all understand that it's InteractiveLogonRight), they can remote desktop into a server and perform all manner of activities and privileged operations. However, with deny Local Interactive in place, if their account is used as the target of a RunAs, the SecondaryLogon service ONLY checks Local Interactive, and they would be denied. They can still make changes to registry, run programs or installers under their privileges, etc; but they can't drop into the "console" session or start a Local Interactive session. UAC runs perfectly fine for the user to elevate their rights (if authorized) using these rights; that's what my personal testing has found. I had to use the explicit denies because of how Windows nests its privileges, the explicit deny supersedes an approval, but only for its respective permission (Local Interactive/Deny Local Interactive).

> 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?

Our discussion concluded with the recommendation that it skips the gpo policy check, the authentication handles the lockout check if AD is available.

On Mon, Aug 11, 2014 at 9:10 AM, Simo Sorce <simo@redhat.com> wrote:
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 ?

[..]

> 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.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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