<div dir="ltr"><div>&gt; In our case, when a user calls &quot;sudo ls&quot;, I think it is a three-step<br>
&gt; procedure:<br>
&gt; 1) sudo calls pam_authenticate to authenticate the user<br>
&gt; 2) sudo calls pam_acct_mgmt to make sure that the account is not<br>
&gt; locked, that the ldap/gpo policies permit the user to run sudo, etc<br>
&gt; 3) sudo refers to /etc/sudoers to determine if it can perform the sudo<br>
&gt; action (i.e. &quot;ls&quot;).<br>
&gt;<br>
&gt; The GPO Logon Rights relate to step (2) of this procedure.<br><br></div>Forgive me if I&#39;m misunderstanding, but wouldn&#39;t the pam_authenticate attempt an authentication against AD if AD was available, and at that phase determine whether it&#39;s locked out or not? In testing, a locked account cannot use sudoers, even if it has a session. If AD isn&#39;t available, it&#39;d use the cached password (if enabled), but it wouldn&#39;t detect a lockout regardless. Step 2 seems moot outside of that permission check. <br>
<br>&gt;You assert that Windows would allow a user to perform remote login <br>&gt;(and 
then access other services, batch jobs, privileged operations) <br>&gt;using 
only the RemoteInteractiveLogonRight. Is your assertion based <br>&gt;on actual 
testing on a Windows client?  I ask because this is not <br>&gt;my 
understanding. I would expect that the RemoteInteractiveLogonRight <br>&gt;would
 be consulted when the user used RemoteDesktop on a <br>&gt;Windows client to 
login to the remote Windows server, and that the <br>&gt;InteractiveLogonRight 
(Allow/Deny Local Logon) would be consulted <br>&gt;when the user attempted to 
perform a privileged operation (using <br>&gt;RunAs or UAC). However, I haven&#39;t 
actually tested this yet, so it would <br>&gt;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&#39;m going to refer to it as this just to keep the references clear, I think we all understand that it&#39;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&#39;t drop into the &quot;console&quot; session or start a Local Interactive session. UAC runs perfectly fine for the user to elevate their rights (if authorized) using these rights; that&#39;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>&gt; Are you suggesting that sudo skip all of the pam_acct_mgmt checks<br>
&gt; (checking for locked accounts, ldap filter policies), or that it skip<br>
&gt; 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">&lt;<a href="mailto:simo@redhat.com" target="_blank">simo@redhat.com</a>&gt;</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>
&gt;<br>
&gt; In our case, when a user calls &quot;sudo ls&quot;, I think it is a three-step<br>
&gt; procedure:<br>
&gt; 1) sudo calls pam_authenticate to authenticate the user<br>
&gt; 2) sudo calls pam_acct_mgmt to make sure that the account is not<br>
&gt; locked, that the ldap/gpo policies permit the user to run sudo, etc<br>
&gt; 3) sudo refers to /etc/sudoers to determine if it can perform the sudo<br>
&gt; action (i.e. &quot;ls&quot;).<br>
&gt;<br>
&gt; 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&#39;s the point of 2 ?<br>
<br>
[..]<br>
<div class=""><br>
&gt; Are you suggesting that sudo skip all of the pam_acct_mgmt checks<br>
&gt; (checking for locked accounts, ldap filter policies), or that it skip<br>
&gt; 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>