Day 3365 PsExec和UAC

直接说方法：要使用PsExec在启用了UAC的远程系统上运行程序，需要这样做：

RunAs /user:domain\user “psexec \\remote-computer-name -h executable-file”

而不能这样做：

psexec \\remote-computer-name -u domain\user -h executable-file

详细原因见此：http://www.riosec.com/articles/Windows-UAC-PsExec

顺便把内容复制过来留给自己看：

Recently I ran across a scenario where the Microsoft Sysinternals tool PsExec would not work against a Windows 7 domain-joined computer. The command was failing with an “Access Denied” error. On Vista and newer, User Access Control (UAC) issues a restricted token to processes, but PsExec requires an elevated token. On the local system’s Microsoft-Windows-UAC\Operational log the following event appeared: The process failed to handle ERROR_ELEVATION_REQUIRED during the creation of a child process.

Further research found that newer versions of PsExec have a command argument (-h) to specify elevated rights.

However, even with specifying -h PsExec was still failing with “Access Denied”. After some digging, I discovered that it’s all about how the authentication credentials are presented to the remote system. UAC has an exception for remote connections using domain credentials, so that machines can still be administrated remotely (otherwise, there would be no way to respond to UAC prompts). When connecting remotely and authenticating with NTLM using a domain account, Windows 7 issues an elevated token.

With PsExec when you specify the username on the command line it causes an explicit (local) authentication to occur on the remote system, and Windows issues a limited rights token, causing PsExec to fail. However, if you authenticate as the target user on the local computer (using RunAs or logging in directly), and then use PsExec with implicit (NTLM) authentication to the remote computer, the process gets the elevated token on the remote system and it works.

This behavior becomes more obvious when using telnet. The built-in Windows telnet client automatically authenticates using NTLM (top window in the screen shot below), and the user is given an elevated token. However, logging in with the same user from a third-party telnet client results in a restricted token (bottom window).