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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel