User Account Control (UAC) and PsExec

Sat, 2010-12-11 23:57 — Christopher

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.

PsExec output

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).

I hope this information is helpful to someone else wondering why their PsExec might be failing on Windows 7 due to UAC.

Add new comment

Comments

Sun, 2011-03-13 07:37 — Anonymous

Nice find! However, it

Nice find!
However, it doesn't seem to work here, I'm wondering what's wrong.
I'm running W7U on both systems. The remote system is a fresh install, with UAC in the lowest level(but not off).
Everything works if UAC is off, but when it's on, it doesn't work, even with your method.
I'm getting this (translated, might be a bit different): error running as: can't - psexec \\192.168.178.39 cmd
5 run: access denied.

In dutch it's:
fout bij uitvoeren als: kan - cmd
5 niet uitvoeren: toegang geweigerd.

I'm guessing that 5 is the error code. I'm running this command from a system cmd:
runas /user:jazz-pc\jazz "psexec \\192.168.178.39 cmd"

Using "-h" doesn't make a difference, adding "-u user -p pass" doesn't help either, running it from a normal administrator cmd also doesn't work (I got this error: "error running as: can't - ....... 1326 run: login error: unknown username or wrong password")

I created a user on the local system with the same username and pass as the user on the remote system, and tried to run it that way. It opens a cmd that closes immediately, I managed to take a screen of it, and I also got access denied.

the remote pc is jazz-pc, and the username is jazz. pass is abc.

Any idea's?

btw, your post seems to be the only one on the internet with a fix that doesn't require tampering with the remote machine(disabling uac, changing stuff in the registry, adding the pc's to a domain,..), so that's why I'm asking you :)

thanks!

Sun, 2011-02-20 09:04 — Anonymous

Nice Work

Thanks for the Tip it realy help me, it also works on a WORGROUP configuration without any domain.

___
Rui Paz