Help Center

Follow

Authentication

Description

The target computer did not properly authenticate the user.

Possible Causes

The target computer is in a different domain than the user or an invalid user name or password were supplied.

Recommended Fix

Change the user name and password and try again.

Other possible logon/password issues are covered in the following:

Was this article helpful?
0 out of 2 found this helpful
Have more questions? Submit a request

21 Comments

  • 0

    This is not working for me. The pc is not joined to the domain yet. I am using a local admin account I created on it. Firewall is turned off & no security software is installed that could be blocking it. I've even added the local admin account to the "log on as a service" local gpo.

    I keep getting "logon failure: unknown user name or bad password". I've retyped it lots of type now just to make sure. This is a win xp os. When I try the "remote admin repair" tool it fails everything. I know it says net 3.5 is needed, which this pc doesn't have installed. Any net for that matter. Is net required for installations?

  • 0

    .NET isn't needed for deployment, only to run the repair utility locally on the computer.

    Are you able to connect to the computer's network shares (ADMIN$ or C$) using Windows explorer?  The computer may have simple file sharing still enabled which will prevent access to the ADMIN$ shares.

    http://support.microsoft.com/kb/307874

  • 0

    Right on the money Adam. SFS was indeed turned on. This is a brand new install & SFS is not turned off until the pc is joined to the domain & gpo disables it. Once I turned it off pdq could do its thing.

    Although by this time I had already installed 99% of the apps manually on this pc. But at least I'll know for next time! Thanks.

  • 0

    We receive this issue, when deploying batch files from the network, for example ones contained within our netlogon folder.

    Copying the files to the machine we deploy from is fine.

    Can access the files via windows explorer and execute them, can also run them on other local machines as this administator account

    any ideas

    thanks

  • 0

    Kmcfaul,

    Which version of PDQ Deploy are you using?  If you're using version 1.2 then you need to ensure that you use the "Other Authentication" option to allow the deployment to access network resources.

  • 0

    Hi apologies,

    the service was running with the wrong password. changed password over the weekend for the user account. Changed the credentials but not the service account

     

    thanks

  • 0

    Kmcfaul,

    Thanks for the update.  We've fixed that issue for the next version, when you change the password in the credentials it will update the service as well.

  • 0

    I've purchased Pro 2.0.2.0 for my company and ran it over 400 PCs, most of them with WinXP Pro SP3. I'm having the same issue but with a variant:

    Only 25% of the PCs ran without problems. But most of the PCs failed with the authentication error. I've checked a couple of dozens by RDP and the checklist is complete:

    • Firewall is off
    • SFS is off
    • Server service is on
    • RPC service is on

    Now, when i run the Remote Repair tool from the console, the first time it fails all tests. Then I go to specify the credentials -it seems it doesn't get the password from the credentials DB- and try the test and it goes perfectly. Then I run it again and it fails to create the service. Then again and it goes ok, then again and it fails again to create the service. I can be doing that for hours with no change.

    But even when the tests come all ok and I try to re-deploy, I get the same error again.

    Any hints? I've been dealing with this issue for an entire day and I have to deploy important stuff next sunday for more than 300 computers that failed :(

  • 0

    a) do a gpupdate /force on the target computer

    b) set login as domain\login + password

  • 0

    One more question - do the compouters have some security suite installed? I mean not only antivirus, but alse firewall.

  • 0

    Selfman ~ Thanks for the reply :) but:

    • I've missed saying that I don't use a domain. All machines have local login.
    • All machines use kaspersky, but it doesn't matter if it is enabled or not -well, for my case-

    I also tried restarting services, restarting the machine, turning the xp firewall off/on (with the proper exceptions) but nothing :(

    The only thing I've missed to say is that the machines are remote, behind a VPN, but I triple checked the firewalls and routes and there's nothing in the middle affecting the traffic. Either way, I can browse the admin$ resource remotely without problems, but well, as I said before, the weird thing with the Remote Repair Tool still doesn't let me think clearly on what may the issue be.

  • 0

    How are you entering the credentials? If the accounts are all local just enter the user name. Do not place anything for the domain (unless it is a single dot)

    The following credentials would work when authenticating the local administrator account (assuming the password was correct)

    Administrator

    .\Administrator

    Are you using the same deployment credentials for all the computers? In other words, does the account name that you are using for your deployment credentials also exist on all the other targets?  

  • 0

    Hi there Shane! You see... different credentials are being used by different groups of computers, that's not a problem. And no, there's no domain here. I've tested using a single computer and got no success. In fact, I have the computers grouped by location, and I have lists of lists of groups of machines, and I run the deployment per credentials for the machines that have the same admin password.

    The issue here is: why does this happend?

    Please see the image sequence I'm attaching so you can clearly see what I'm experiencing. This is for one machine, but it happened with some others, and I'm sure is the same problem for all.

  • 0

    It would help to have a trace log from Sysinternas's Process Monitor from the time of deployment failure.

    You can see there everything what is going on there.

  • 0

    Hola,

    I see you speak Spanish according to the ping output. Never seen it in Spanish before. That was cool.

    I noticed you put "administrador". Is it called that in a Spanish system & not "administrator"? Also have you tried the ".\administrator". That's what I use, I don't use it without the ".". 

    Also have you made sure the local admin acccount is enabled on those computers? If it's disabled it won't work. 

    I also noticed you're running this from a win7 / server 2008 pc since I see "administrator" in the CMD window. You need to make sure that "allow network discovery" & "file & printer sharing" are turned on. 

    Well hope some of those things help. I won't be able to reply until tomorrow. I'm going out the door & won't be back until my bed time. Buena suerte.

  • 0

    Selfman: I'll try that. By the way, the connection is stablished, so the machine is being accessed without issue. For some reason, the service can't be created. I'll try to log the processes later on.

    Jonathan: Yes, I'm aware of the "administrador" vs "administrator" difference :) ...and yes, it is enabled, I'm in connected to both machines (server & client) by RDP using their respecitve administrator or administrador accounts.

    The server is 2003 SP2. I've tried from my personal machine at the office (Win7 x86) and get the same thing. Network discovery is useless because the clients are on a VLAN behind an OpenVPN link, and there are places in where I can deploy to some machines and can't deploy to others. And yes, the Server and RPC service are up and running.

    Now I wonder: all machines have XP Pro SP3, but they may not be fully updated. I'll try updating them, just to discard any missing update (or maybe some update in the machines I can deploy that is missing or even is present but messing up in the machines I can't deploy).

  • 0

    I finally discovered where the problem lies!!! PDQ's password manager is not sending the proper credentials to the computers!

    You see... In my company, I have two external support providers, and the branch offices they attend have a different "administrador" password. Plus, here at the Headquarters, we have a disctinct "administrador" password. So, in PDQ Deploy Credentials, I have four "administrador" accounts, every one with different password.

    A few minutes ago I tested SysInternals PSEXEC to one machine and worked with no problems, but then I've deployed again my test package and failed. Then I removed all except one "administrador" accounts from PDQ Credentials and voila! it worked!

    So, guys, we have a bug here :) ...You need to change the way PDQ looks up the credentials from all those entered by the users at the console.

  • 0

    Alejandro,

    Please accept our apologies for not thinking of this earlier.  This is indeed a bug in the current version, multiple local users with the same name aren't always handled correctly. Any user with a domain that starts with a . is treated as a local user,  so to have multiple local users with different passwords use different domains.  The following users are all the local Administrator:

    .\administrator

    .region1\administrator

    .region2\administrator

    With the distinct domains they won't trigger the bug.  Version 2.1 fixes this and will be going into beta in the next few days.

  • 0

    I'll be waiting for the update :) ...in the mean time I'll figure out the way to push my updates in 4 parts (one for each "administrador" account) without pulling my hairs too much (~_~)

  • 0

    Hopefully we'll have that fixed soon as well.  Quite a few people have requested that we allow multiple credentials be used within a single deployment.  It's pretty high on our priority list.

  • 0

    I already did, I just... well, I didn't get the .whatever\account thing until I tried :) ...now I'm deploying as I originally did but specifying the accounts as you mentioned:

    .hq\administrador

    .provider1\administrador

    .provider2\administrador

    .rest\administrador

    Now I know that when you prefix the dot, the domain part is just ignored :)

    That's what I call a clever way to turn around the bug :D

Article is closed for comments.
Powered by Zendesk