10

Inspired by my previous question here, I've been experimenting with PSExec.

The goal is to trip off some fairly simple scripts / programs on one WindowsXP machine from another, and as PowerShell 2 doesn't yet do remoting on XP, PSexec seems like it'll solve my problems nicely.

However, I can't get anything but the "Access is Denied" error.

Here's what I've tried so far:

I've got a pair of WindowsXP MCE machines, networked together in a workgroup without a server or domain controller.

I've turned off "simple file sharing" on both machines.

Under the security policy, Network Access: Sharing and Security model for local accounts is set to Classic, not Guest for both machines.

There is an Administrative user for each computer that I know the passwords to. :)

With all that, a command like "> psexec \\otherComputer -u adminUser cmd" prompts for the password (like it should) and then exits with:

Couldn't access otherComputer:
Access is denied.

So, at this point I turn to the community. What step am I missing here?

Community
  • 1
Electrons_Ahoy
  • 1,801
  • 3
  • 14
  • 16
  • Problem solved - turns out it was an empty password issue. See my response down below for more details. Thanks for all the help, though, everybody! – Electrons_Ahoy May 21 '09 at 22:57

10 Answers10

12

Add the following registry DWORD to the remote computer and it should fix the issue.

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Community
  • 1
7

Problem Solved.

It turns out that, by default, Windows won't let you remote in with a user account with an empty password. For the purpose of experimenting with PSExec I had changed the password of the admin account on the target machine to nothing, thinking that would reduce the amount of typing needed. Turns out, that was my problem, and once I put a password back, it all worked perfectly.

However, this set off another investigation - If anyone wants to use PSExec with an empty password, here's what you need to do (under Windows XP MCE, anyway):

  • In the Control Panel, open Administrative Tools.
  • Open Local Security Policy.
  • Navigate to Local Policies -> Security Options
  • Change "Accounts: Limit local account use of blank passwords to console logon only" to Disabled
Electrons_Ahoy
  • 1,801
  • 3
  • 14
  • 16
6

I think PSEXEC relies on being able to open the ADMIN$ share, so check that with the same credentials, 

net use \\otherComputer\ADMIN$ /user:otherComputer\adminUser *
nray
  • 1,540
  • 17
  • 23
1

I encountered this error when running PSExec from a non-elevated command prompt (on Windows 7). Running the command from an elevated command prompt fixed it.

Tweek
  • 292
  • 3
  • 9
1

I found another reason PSEXEC (and other PS tools) fail - If something (...say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an "Access is Denied" error, PSLIST will give the error "Processor performance object not found on " and you'll be left in the dark as to the reason.

You can RDP in; You can access the admin$ share; You can view the drive contents remotely, etc. etc., but there's no indication that file(s) or folder(s) being hidden is the reason.

I'll be posting this information on several pages that i was perusing yesterday while trying to determine the cause of this odd problem, so you might see this elsewhere verbatim - just thought I'd put the word out before anyone else pulled their hair out by the roots trying to understand why the performance counter has anything to do with PSEXEC running.

Jeff
  • 11
  • 1
1

If you type

\\computername

into my computer and authenticated as adminUser does it work?

I assume you did use a double slash and the system stripped it.

You do need the standard windows file sharing turned on and allowed through the firewall for this to work.

Jona
  • 746
  • 1
  • 9
  • 17
  • \\computername in My Computer works fine. And yeah, SF stripped the \\. Editing now... – Electrons_Ahoy May 15 '09 at 23:16
  • Couple of other suggestions - Have you tried computername\username as the username, have you tried passing the password from the command line and have you tried the -s (system account) switch? – Jona May 15 '09 at 23:37
0

Here's an idea that worked for me. Rather than passing the username and password to psexec with the -u and -p parameters, instead first open a command prompt running in the context of that user:

C:\> runas /user:domain\name cmd.exe

When prompted, enter the password. Then from that new command prompt, run psexec as normal:

C:\> psexec \\remotepc cmd.exe
nwsmith
  • 121
  • 1
  • 1
  • 6
0

Another thing to check is whether your antivirus is blocking psexecsvc.exe. I just ran into that with Sophos. I was getting an Access Denied and saw that Sophos was blocking PSEXEC from the Application log.

Andrew S
  • 498
  • 3
  • 7
  • 12
0

Is Windows Defender or other malware protection running? Is it blocking? I know Windows Defender is capable of doing so.

K. Brian Kelley
  • 9,004
  • 31
  • 33
0

Capturing traffic using Wireshark can often help track down the issue in these situations. You can look at the SMB traffic and see how Windows is trying to authenticate or if it even gets that far in the first place in the case of firewalls blocking traffic etc.

Leon Sodhi
  • 101
  • 1
  • 3