Jan 31 2008

How to deal with “Login Failure: the target account name is incorrect” on a Windows file share

If you're new here, you may want to start with my most popular posts. Then, subscribe to my RSS feed to stay updated. Thanks for visiting!



Google Query: Login Failure: the target account name is incorrect

This problem had me going for a bit today. As it turns out the answer was simple. Let me set up the scenario for you.

At work we are in the middle of an Active Directory child domain migration (we are migrating our users and computers into a child domain). As part of this domain migration, we are also moving from separate departmental file servers onto a single file server for the building. I had a logon script in place that would disconnect old mapped printers from a client and reconnect new mapped printers so that we could decommission one of the old file servers (a dying behemoth HP that looks like a mini-fridge).

The script worked beautifully except for on two legacy Windows 2000 Professional workstations (the rest are Windows XP). The old printers were not removed and the new printers were not mapped on these machines. So, I proceed to try and run the script manually by going to:
\\script-server\script-share

I get the following message:
Login Failure: the target account name is incorrect

Huh!?! OK, so this sounds like a DNS or WINS problem. I proceed to check both using nslookup and nbtstat. Everything looks normal. I can query the server and get the appropriate IP address. I even flushed both the DNS and NetBIOS cache. Still the same message. Google time.

After searching for “Login Failure: the target account name is incorrect” I came upon a forum entry at experts-exchange that got me thinking in the right direction.

One of the accepted answers said to remove the problem server from the domain and rejoin it. What that does is essentially reset the computer account for that server. So, I got to thinking (dangerous, I know). The server that I was using for the logon script had recently been migrated to the child domain…

What if the old computer account still existed in the parent domain? A quick query in Active Directory confirmed this to be true. AHA! I deleted the account from the parent domain and all was well after that. The two Windows 2000 Professional workstations were able to access the Script server share.

The only thing that I am still fuzzy on is why the Windows 2000 Professional workstations had a problem and the Windows XP Professional workstations didn’t. Any ideas? Leave them in the comments.

This was a very specific case in which the error was experienced. However, the cause may enlighten those administrators in a similar situation. Perhaps the server computer account is screwed up. In this case, maybe resetting it in Active Directory or removing and re-joining the server to the domain will help. I hope you find this helpful. I was glad that it was a relatively simple solution.

Happy File Serving!

Technorati Tags: , , ,

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

17 Comments on this post

Trackbacks

  1. Coop said:

    I too have experienced these symptoms, with different results observed just as you, between x\2k3 and windows 2000 servers.

    February 14th, 2008 at 5:31 pm
  2. anonymous coward said:

    The error has to do with conflicting kerberos information. You will typically see event id 4 with a source of kerberos in the System EventLog.

    September 9th, 2008 at 2:21 pm
  3. matt said:

    I get this same error when trying to access my Windows XP workstation form other (but not all) workstations in my subnet:

    C:\>net use m: \\myworkstation\c$
    System error 1396 has occurred.

    Logon Failure: The target account name is incorrect.

    Thanks to the Anonymous Hero above I learned that “The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/myworkstation.domain.ext The target name used was cifs/myworkstation. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (DOMAINB), and the client realm.” (from event log).

    December 10th, 2008 at 7:44 pm
  4. David said:

    Thanks… this twigged me into figuring out my problem. It wasn’t the same thing, but close enough for me to put the pieces together. I’m putting this in here in case it helps the next schmuck Googling around, pulling his hair out.

    We have two AD domains with a trust between them. My issues was that a batch of computers were “temporarily” put on the other domain. The problem was, those old domain accounts were not deleted after the computers were moved back to my domain. Local domain accounts would work fine, but the other domain accounts couldn’t do some very specific things. The process was trying to use the old, now with invalid password, computer accounts on the other domain. Obvious, once you see it, but I wasted a lot of time going around in circles. So yeah, two separate computer accounts with the same computer name can cause very strange things… funny how that works.

    January 30th, 2009 at 12:50 am
  5. Steve T said:

    Hmm. Well, I’ve got the problem on 2 XP workstations in a Win2k3 domain…

    I’ve removed them from the domain, rebooted, removed their records from ADUC, rebooted, checked DNS, ADUC, added back on to the domain, (for some reason I can only add them to the domain if I use the FQDN – hmmm…), ran ipconfig /flushdns & nbtstat -R.

    I eventually log back on to them as the domain admin and run “dir \\domaincontroller\c$” (to test DNS & security in 1 hit) and from the workstation to the DC works fine… the other way around doesn’t work (”target account name….” error still) weird!

    There must be something else that’s jammed up…

    March 3rd, 2009 at 2:11 pm
  6. Dirk M said:

    Well thanks,

    After more than a year this is still valid. We had the same problem on XP stations after a domain migration (still in progress). Deleting the servers account in the source domain solved the error for us.

    November 6th, 2009 at 3:08 pm
  7. Grant said:

    Had a similar problem on one of our clients, but no duplicate workstations or child domains. The solution was to Uninstall the ‘Client for Microsoft Networks’ from the network adapter, reboot, reinstall and reboot. Problem fixed.

    November 19th, 2009 at 7:14 pm
  8. David said:

    Thanks, I found the same thing. Some PCs on my network continued to work whilst others did not. All worked with FQDN. Removed from second domain. What was obviously happening was it was trying to connect to the box with the creds from the other domain. Thanks!

    January 7th, 2010 at 9:23 pm
  9. Narayan said:

    Hi,

    I faced same issue, but on a VM.
    I have created a snapshot on Win 2k3 vm and tried to use the snapshot after 2 months.
    My snapshot has a setup of web application so when ever I try to use it, I got “No authority could be contacted xxx ” message on browser and Login Failue if i try to access the HDD of the VM.

    Fix:

    My network admin said that, if snapshot is of 1 month old and we revert back to it then the VM is automatically kicked out of domain and we need to add it back again.

    Regards,
    Narayan

    February 11th, 2010 at 1:18 am
  10. Chalise said:

    I also had this problem, but it was occurring when a Powershell script was running WMI queries on a workstation that had recently been renamed. Turns out someone was adding a new machine to AD every time he was deploying a machine that was previously named something different on the domain instead of renaming it. A network connection repair and log on/off was all that was needed to fix it on the workstation and fix the problem.

    May 27th, 2010 at 10:27 am
  11. Jenn said:

    Still a useful article, as well as useful comments. I followed Grant’s suggestion from Nov 2009. I had just one workstation with this issue. I removed it from network/AD, deinstalled ‘Client for Microsoft Networks’ from the network adapter, rebooted, reinstalled it and rebooted. Re-added to the domain, and now I can access the workstation’s shared drive. I was two seconds away from re-imaging the thing, so thanks!

    June 1st, 2010 at 4:43 pm
  12. Rob said:

    reinstalling the client for MS networks on the network adapter worked for me

    January 17th, 2011 at 4:38 pm
  13. Joey said:

    nothing worked. still getting the same error that target name is incorrect. joined it to dev domain-success, removed from dev domain add to qa domain-error. there is no trust between dev and qa domains…object has been re created, deleted and added back to qa domain…not about to reimage teh server…

    March 3rd, 2011 at 12:55 pm
  14. Joe said:

    I had a similar issue, trying to map a drive on a Windows 7 laptop in one domain to a Windows 2000 server in another domain. The answer was to enter the FQDN as the server name, e.g. \\server.domain.com\sharename and it worked fine after that.

    April 13th, 2011 at 4:22 pm
  15. Jen said:

    Genius! Thanks for this post, I was baffled by this error!

    June 10th, 2011 at 4:26 am
  16. Johnny said:

    Worked for me, I had a duplicate computer name from when it was joined to another trusted domain, deleted it and it worked.

    August 30th, 2011 at 1:56 pm
  17. Matthew said:

    Thank you Grant on November 6th, 2009.

    I have only one domain with no children or trust relationships and had this error all over my domain when dealing with a particular server. Removing the Client for Microsoft Networks, Rebooting, adding it again, and rebooting fixed the issue.

    October 26th, 2011 at 8:29 am

LEAVE A COMMENT

Subscribe Form

Subscribe to Blog

Sponsors

Recent Readers

JOIN MY COMMUNITY!
                  Computers Blogs - Blog Top Sites