Sysinternals Homepage
Forum Home Forum Home > Sysinternals Utilities > PsTools
  New Posts New Posts RSS Feed - PsExec to localhost: Logon failure
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

PsExec to localhost: Logon failure

 Post Reply Post Reply
Author
Message
davidmc24 View Drop Down
Newbie
Newbie
Avatar

Joined: 19 April 2006
Location: United States
Status: Offline
Points: 2
Post Options Post Options   Thanks (0) Thanks(0)   Quote davidmc24 Quote  Post ReplyReply Direct Link To This Post Topic: PsExec to localhost: Logon failure
    Posted: 19 April 2006 at 5:51am
I have two machines, Machine A and Machine B.  Both are running Windows XP Pro SP2, and are members of the same Windows domain.  I'm using PsExec v1.71.  Machine A is the local machine for all commands below.  The user used for all commands below is a domain user with a non-empty password and local admin rights on both Machine A and Machine B.

On Machine A, I've verified that:

    * the Workstation service is running
    * the Server service is running
    * the Admin$ share is available
    * the Windows Network is running and Printer and File Sharing is enabled
    * Simple File Sharing is disabled
    * the "Sharing and security model for local accounts" is set to "Classic - local users authenticate as themselves"
    * the Windows Firewall is disabled (no other firewalls installed)

Running command on Machine A without PsExec (no error):
D:\>D:\glancepd\pdw.exe
pdw       Version 04-Aug-1998
Usage:    pdw  [Options] file-name
Options:  -w  break down text blocks to blank separated words

Running command on Machine A with PsExec w/o specifying machine:
D:\>psexec D:\glancepd\pdw.exe

PsExec v1.71 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

PsExec could not start D:\glancepd\pdw.exe:
Logon failure: unknown user name or bad password.

Running command on Machine A with PsExec specifying machine name:
D:\>psexec \\bulldog D:\glancepd\pdw.exe

PsExec v1.71 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

PsExec could not start D:\glancepd\pdw.exe:
Logon failure: unknown user name or bad password.

Running command on Machine A with PsExec specifying IP address:
D:\>psexec \\10.10.10.200 D:\glancepd\pdw.exe

PsExec v1.71 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

Could not start PsExec service on 10.10.10.200:
The system cannot find the path specified.

Running command on Machine A with PsExec specifying username (command executes, but output not captured):
D:\>psexec -u NEXUS\dcarr D:\glancepd\pdw.exe

PsExec v1.71 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

Password:
D:\glancepd\pdw.exe exited with error code 0.

Running command on Machine B with PsExec specifying machine name (works):
D:\>psexec \\baboon D:\glancepd\pdw.exe

PsExec v1.71 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals - www.sysinternals.com


pdw       Version 04-Aug-1998
Usage:    pdw  [Options] file-name
Options:  -w  break down text blocks to blank separated words
D:\glancepd\pdw.exe exited on baboon with error code 0.
Back to Top
Karlchen View Drop Down
Senior Member
Senior Member
Avatar

Joined: 18 June 2005
Location: Germany
Status: Offline
Points: 5131
Post Options Post Options   Thanks (0) Thanks(0)   Quote Karlchen Quote  Post ReplyReply Direct Link To This Post Posted: 19 April 2006 at 1:53pm
Good evening, David.

Quote I have two machines, Machine A and Machine B. Both are running Windows XP Pro SP2, and are members of the same Windows domain. [...]
On Machine A, I've verified that:[...]

Wow, you have definitely done your homework and gone through the PRBP and the FAQs.
No chance for the "Documentation Police" to arrest you.

=====

OK, a general note before addressing each of the issues you are experiencing:
Quote Both are running Windows XP Pro SP2, and are members of the same Windows domain. [...] The user used for all commands below is a domain user with a non-empty password and local admin rights on both Machine A and Machine B.

Very precise. Yet one unaswered question, though:
Does this mean the admin user has got the same password on both machines?
Inside an ADS domain, a domain admin user exists just once (on the ADS Domain Controller), but can logon to any ADS client machine, same loginname/same password.
But your admin user might as well be a local admin user on MachineA and on MachineB, having the same username and the same privileges, but having different passwords on each machine.
I am asking because you get
Quote unknown user name or bad password.
error messages which suggest that as the user exists on both machines the password might be different.

=====

Anyway, let us tackle the issues one by one, top down:

===== psexec as a prefix =====

Quote Running command on Machine A with PsExec w/o specifying machine:
D:\>psexec D:\glancepd\pdw.exe
[...]
PsExec could not start D:\glancepd\pdw.exe:
Logon failure: unknown user name or bad password.

In order to understand why this psexec command line does not work, please read PsExec could not start (local machine w2k.
In this thread I try to list what psexec can do and what it cannot.

Essence for your particular command:

Sorry, no offense meant, but it does not make too much sense, because even if it worked it would have the same effect as simply launching
D:\glancepd\pdw.exe

So simply prefixing "psexec " to this command is meaningless. Does not work for me either.


===== psexec \\bulldog =====

Quote Running command on Machine A with PsExec specifying machine name:
D:\>psexec \\bulldog D:\glancepd\pdw.exe
[...]
PsExec could not start D:\glancepd\pdw.exe:
Logon failure: unknown user name or bad password.

This definitely indicates an authentication issue on the target machine \\bulldog (Having read your complete post, it is clear that there is more than just 1 MachineB, I counted 3).

As you use psexec without the -u username -p password arguments, psexec will try an implicit login to \\bulldog using your local username and password on MachineA. Obviously this fails.

In order to get more information about the differences between implicit and explicit network authentication, please read psexec - remote share problem.


===== psexec \\10.10.10.200 =====

Quote Running command on Machine A with PsExec specifying IP address:
D:\>psexec \\10.10.10.200 D:\glancepd\pdw.exe
[...]
Could not start PsExec service on 10.10.10.200:
The system cannot find the path specified.

As you get a different error message, this seems to suggest that \\bulldog and \\10.10.10.200 are not the same machine. So there seems to be more than just 1 MachineB?!
The error message seems to indicate that psexec could not locate/access Admin$ on 10.10.10.200, because psexec stated it could not launch the service.
Again the reason might be omitting the -u username -p password arguments.


===== psexec as runas replacement =====

Quote Running command on Machine A with PsExec specifying username (command executes, but output not captured):
D:\>psexec -u NEXUS\dcarr D:\glancepd\pdw.exe
[...]
Password:
D:\glancepd\pdw.exe exited with error code 0.

I am not sure why you cannot see any output, because your next example (see below) seems to indicate that there is no general problem which prevents psexec.exe and pdw.exe from co-operating.

You might try to add the -i switch to your psexec command line, try again and let us know if it helped in this scenario.
psexec -i -u NEXUS\dcarr D:\glancepd\pdw.exe
.
I will not bet it will though.


===== psexec \\baboon =====

Quote Running command on Machine B with PsExec specifying machine name (works):
D:\>psexec \\baboon D:\glancepd\pdw.exe

So \\baboon is the only machine of all the machines which you tested where implicit network authentication works, i.e. username/password on MachineA == username/password on \\baboon.

The fact that you could see the output of pdw.exe on MachineA seems to indicate that there is no general problem when using psexec to launch pdw.exe, but only different tricky issues on different machines.

=====

Although I certainly did not give a satisfying answer to each of your differnet issues, hopefully you got at least some useful information which helps solve your problems.

Kind regards,
Karl



Edited by Karlchen - 19 April 2006 at 1:54pm
Back to Top
davidmc24 View Drop Down
Newbie
Newbie
Avatar

Joined: 19 April 2006
Location: United States
Status: Offline
Points: 2
Post Options Post Options   Thanks (0) Thanks(0)   Quote davidmc24 Quote  Post ReplyReply Direct Link To This Post Posted: 19 April 2006 at 8:25pm
Thank you for your prompt reply.

No local users were used; the only user involved is NEXUS\dcarr, an ADS domain user.  This user was logged in on Machine A, and was also used in the example commands where credentials were specified.  No local users with the same name exist on either machine.  This user has local admin rights by adding the domain user to the machine's Administrators group.

psexec D:\glancepd\pdw.exe
Agreed, this isn't a particularly useful command.  However, I'm pretty sure it worked on my system before upgrading from Windows 2000 Pro to Windows XP Pro SP2, and it's the simplest command that demostrates the failure.

There are only two machines involved; I was referring to the same machines by different methods to see if the behavior was different (and in some cases, it was).

Machine A, aka bulldog, aka 10.10.10.200
Machine B, aka baboon, aka 10.10.10.117
All commands were run from bulldog, while logged in as NEXUS\dcarr.  Some of the commands also used bulldog as the target machine.

While specifying psexec as a prefix by itself isn't useful, specifying psexec with a target machine (even if the target machine is the local machine), is useful.  It allows making commands target independent.  By always using the same syntax for the command, it removes the need to know a priori whether the desired destination is a local machine or a remote machine.  If this is not a currently supported usage, I would like to request it as an enhancement.

psexec -i -u NEXUS\dcarr D:\glancepd\pdw.exe
The output with the -i argument is the same as without it.


Edited by davidmc24 - 19 April 2006 at 8:25pm
Back to Top
Karlchen View Drop Down
Senior Member
Senior Member
Avatar

Joined: 18 June 2005
Location: Germany
Status: Offline
Points: 5131
Post Options Post Options   Thanks (0) Thanks(0)   Quote Karlchen Quote  Post ReplyReply Direct Link To This Post Posted: 20 April 2006 at 8:21am
Hi, David.

Ok, I see, you were referring to 2 machines by using three different names for each machines.

This means I will have to revise the different commandlines keeping this in mind.

My final statement about simply prefixing psexec to a local commandline:
Quote psexec D:\glancepd\pdw.exe
Agreed, this isn't a particularly useful command. However, I'm pretty sure it worked on my system before upgrading from Windows 2000 Pro to Windows XP Pro SP2, and it's the simplest command that demostrates the failure.

Disagree:
This usage has never ever worked for me: neither on WinXP SP1, nor on WinXP Sp2, nor on Win2k, nor or Win2003.
In this commandline "psexec" can be simply dropped. psexec will not work in this situation.
This gives you no clue whatsoever on how psexec will behave in different situations.
So this commandline does not prove more than that psexec will not work if used in this particular way.

Please read PsExec could not start (local machine w2k.
The list on what psexec can do and what it cannot is not based on my personal beliefs, but on my experience, and on other users' reports which you might find in the PSTools forums.

Kind regards,
Karl
Back to Top
slylabs13 View Drop Down
Newbie
Newbie
Avatar

Joined: 12 January 2011
Location: California
Status: Offline
Points: 11
Post Options Post Options   Thanks (0) Thanks(0)   Quote slylabs13 Quote  Post ReplyReply Direct Link To This Post Posted: 19 January 2011 at 5:54pm
In my case, I am logged into a domain admin account, I explicitly use the same domain admin account, the executable shows up on the remote machine, the service is installed, and yet I get the dreaded error that it cannot find the path specified. I am using psexec \\<fqdn of remote machine> -u <domain\user> cmd.exe

It cannot even run the command line, never mind the script I use to force a windows update. I know that was correct because almost all of my domain computers (using \\*) ran the script. Only 3 or 4 didn't because of this error. I can log into the admin share fine. It's making me crazy. They all have the same server based antivirus, and there are no alerts about a blocked process in the AV.

So it would help if I knew ALL circumstances where a path not found error could be generated. Remember that the executable IS getting there, and the service IS being installed! The service simply will not run! It's something the service is looking to find, and cannot so it fails.

Also if I try to start the (now) installed service on the remote machine it fails.  
"Thinking gets you not one step down the road of knowledge"
Back to Top
vabdulrahim View Drop Down
Newbie
Newbie


Joined: 06 December 2012
Location: KUWAIT
Status: Offline
Points: 1
Post Options Post Options   Thanks (0) Thanks(0)   Quote vabdulrahim Quote  Post ReplyReply Direct Link To This Post Posted: 06 December 2012 at 7:19am
Hi
psexec is failing with the error "Logon failure: unknown user name or bad password" if the date is different between source and target
 
C:\PsTools>psservice \\server -u user  -p ** query dhcp
 
PsService v2.24 - Service information and configuration utility
Copyright (C) 2001-2010 Mark Russinovich
Sysinternals - www.sysinternals.com
Unable to connect to \\server:
Logon failure: unknown user name or bad password.
 
Any alternative other than changing the date ?
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down