<div dir="ltr"><div>> In our case, when a user calls "sudo ls", I think it is a three-step<br>
> procedure:<br>
> 1) sudo calls pam_authenticate to authenticate the user<br>
> 2) sudo calls pam_acct_mgmt to make sure that the account is not<br>
> locked, that the ldap/gpo policies permit the user to run sudo, etc<br>
> 3) sudo refers to /etc/sudoers to determine if it can perform the sudo<br>
> action (i.e. "ls").<br>
><br>
> The GPO Logon Rights relate to step (2) of this procedure.<br><br></div>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. <br>
<br>>You assert that Windows would allow a user to perform remote login <br>>(and
then access other services, batch jobs, privileged operations) <br>>using
only the RemoteInteractiveLogonRight. Is your assertion based <br>>on actual
testing on a Windows client? I ask because this is not <br>>my
understanding. I would expect that the RemoteInteractiveLogonRight <br>>would
be consulted when the user used RemoteDesktop on a <br>>Windows client to
login to the remote Windows server, and that the <br>>InteractiveLogonRight
(Allow/Deny Local Logon) would be consulted <br>>when the user attempted to
perform a privileged operation (using <br>>RunAs or UAC). However, I haven't
actually tested this yet, so it would <br>>be useful to know if you have
already tested this.<br><div><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">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). <br>
<br>> Are you suggesting that sudo skip all of the pam_acct_mgmt checks<br>
> (checking for locked accounts, ldap filter policies), or that it skip<br>
> only the gpo policy check?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Our discussion concluded with the recommendation that it skips the gpo policy check, the authentication handles the lockout check if AD is available. <br>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 9:10 AM, Simo Sorce <span dir="ltr"><<a href="mailto:simo@redhat.com" target="_blank">simo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">On Mon, 2014-08-11 at 11:59 -0400, Yassir Elley wrote:<br>
><br>
> In our case, when a user calls "sudo ls", I think it is a three-step<br>
> procedure:<br>
> 1) sudo calls pam_authenticate to authenticate the user<br>
> 2) sudo calls pam_acct_mgmt to make sure that the account is not<br>
> locked, that the ldap/gpo policies permit the user to run sudo, etc<br>
> 3) sudo refers to /etc/sudoers to determine if it can perform the sudo<br>
> action (i.e. "ls").<br>
><br>
> The GPO Logon Rights relate to step (2) of this procedure.<br>
<br>
</div>Except we do not have a logon right in windows that really matches what<br>
sudo is/does ... besiodes given sudo does its own authorization checks,<br>
what's the point of 2 ?<br>
<br>
[..]<br>
<div class=""><br>
> Are you suggesting that sudo skip all of the pam_acct_mgmt checks<br>
> (checking for locked accounts, ldap filter policies), or that it skip<br>
> only the gpo policy check?<br>
<br>
</div>Yes I think that is what Michichael and I ended up agreeing is the most<br>
sensible solution, given any other would prevent the rightful use of<br>
sudo in some situations where it should be allowed.<br>
<span class=""><font color="#888888"><br>
Simo.<br>
<br>
--<br>
Simo Sorce * Red Hat, Inc * New York<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
sssd-devel mailing list<br>
<a href="mailto:sssd-devel@lists.fedorahosted.org">sssd-devel@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/sssd-devel" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/sssd-devel</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>