On Mon, Aug 11, 2014 at 09:54:30AM -0700, Michichael Folfsunè wrote:
> In our case, when a user calls "sudo ls", I think it
is a three-step
> 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
This is all fine for the AD use-case, but sudo (or any other PAM-aware
application for that matter) has no idea what is on the server side,
whether it's AD or some home-grown LDAP server. And with LDAP, you
typically don't detect the account lockout until the pam_account phase
as the authentication only binds as the user DN..
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