Way to run PsExec specifying a user name and password (-u -p) when running as Local System

local-systempstoolswindows-server-2003

I have a Windows Service running as Local System on Windows Server 2003 and I'm trying to use PsExec to run a command as another user (using the -u -p parameters) but I keep getting Access is denied. PsExec could not start errors.

The following can be performed to replicate the issue:

C:\Documents and Settings\me>PsExec.exe -s cmd

PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com


Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINNT\system32>whoami
nt authority\system

C:\WINNT\system32>PsExec.exe -u DOMAIN\my-user -p mypass cmd

PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

Access is denied.
PsExec could not start cmd:

In the example above, the first PsExec command (PsExec.exe -s cmd) will give you a command line as Local System. Then the second PsExec command (PsExec.exe -u DOMAIN\my-user -p mypass cmd) throws the error that I'm trying to resolve.

Any help would be greatly appreciated! Thank you in advance!

Best Answer

After starting your first instance of PSEXEC.EXE as the LocalSystem account, include the local computer's IP address in the command to start your second PSEXEC instance, like this:

PSEXEC.EXE \\LocalComputerIPAddress -u DOMAIN\my-user -p mypass CMD

Explanation

The behavior you're experiencing is due to a new security feature added by Windows Server 2003's Service Pack 1 called Loopback Check Functionality. According to the linked MSKB article:

After you [install Service Pack 1], you experience authentication issues when you try to access a server locally by using its fully qualified domain name (FQDN) or its CNAME alias in the following Universal Naming Convention (UNC) path:

    \\servername\sharename

In this scenario, you experience one of the following symptoms:

  • You receive repeated logon windows.
  • You receive an "Access denied" error message.
  • You receive a "No network provider accepted the given network path" error message.
  • Event ID 537 is logged in the Security event log.

The article suggests two solutions (in addition to the workaround I provided above), both which involve editing the Registry to either: 1) Add host names that can be referenced in an NTLM authentication request, or 2) Disable the authentication loopback check, effectively returning the server to the pre-SP1 behavior.

According to this WindowsITPro.com article on how PSEXEC works:

PsExec starts an executable on a remote system and controls the input and output streams of the executable's process so that you can interact with the executable from the local system. PsExec does so by extracting from its executable image an embedded Windows service named Psexesvc and copying it to the Admin$ share of the remote system.

So even though you're running PSEXEC against your local machine, it's using the ADMIN$ share nonetheless, hence the reason you're running into the Loopback Check Functionality behavior change described above.

Related Topic