Fix ERROR_WRONG_TARGET_NAME (0x574) Logon Failure Fast

You try to hit a share, a SQL box, or a remote desktop, and Windows hands you this: Logon failure: The target account name is incorrect. Error code 0X00000574 (decimal 1396, hex 0x574). It's not a password problem, even though it looks like one. Windows is telling you the name it's authenticating against doesn't match the name the other side knows. Somewhere between your machine and the target, the account name got mangled, cached, or duplicated.

I've seen this bite people right after a server rename, after a domain migration, and — most often — after someone types a share path with the wrong hostname and Windows stashes the bad credential in Credential Manager for the rest of its life. The good news: it's almost always fixable without rebooting the DC. Work down this list and stop when it clears.

The 30-Second Fix: Clear the Wrong Cached Credential

Nine times out of ten, this is it. You (or a script, or a coworker) connected to the target with a bad username once, and Windows cached that. Now every connection attempt reuses the garbage.

Step 1 — Kill the existing session

Open an elevated Command Prompt and drop every connection to the target:

net use * /delete /y

If you want to be surgical and only wipe one:

net use \\FILESERVER\Share /delete

Step 2 — Wipe the credential

Run this from the same elevated prompt. It opens the classic credential dialog:

control keymgr.dll

Or on Windows 10/11, go straight to Credential Manager → Windows Credentials. Look for anything referencing the target hostname. Delete it. Don't be cute and edit it — Windows sometimes keeps the old entry alive even after an edit. Delete.

Step 3 — Reconnect with the exact FQDN

This matters. If the target's real name is fileserver.corp.local, don't connect to \\fileserver. Use the FQDN:

net use \\fileserver.corp.local\Share /user:CORP\yourname *

If it works now, you're done. If it still throws 0x574, move on. The problem is deeper than cache.

Had a client last month whose entire print queue died because of this exact error. Their print server had been renamed, but every desktop still had a cached credential pointing at the old name. Clearing Credential Manager on 40 machines fixed it in under an hour.

The 5-Minute Fix: Check the Name Resolution

If clearing creds didn't help, Windows is resolving the target to the wrong machine. That happens more than you'd think — stale DNS records, hosts file entries from a previous IT guy, or a WINS relic still floating around.

Ping the short name and the FQDN separately

ping fileserver
ping fileserver.corp.local
nslookup fileserver.corp.local

Do they resolve to the same IP? If not, you found it. Common culprits:

• A leftover entry in C:\Windows\System32\drivers\etc\hosts pointing the short name somewhere old
• A stale A record in DNS that hasn't scavenged yet
• An old WINS entry on a legacy network
• Two NICs on the target with different names registered to each

Open the hosts file as admin, remove the bad line, and flush DNS:

ipconfig /flushdns
ipconfig /registerdns

Now retry the connection. If the name resolves clean and it still fails, the issue is on the identity side, not networking.

The 15-Minute Fix: SPN Mismatch and Duplicate Names

Here's where it gets interesting. Once name resolution is correct, Kerberos looks up the target's Service Principal Name (SPN) in Active Directory. If that SPN is registered to the wrong computer account — or duplicated across two accounts — you get 0x574 every single time. This is the classic post-rename failure. Someone renamed a server but the old SPN stuck around, or two machines ended up sharing an SPN after a clone.

Step 1 — Query the SPNs

On a machine with RSAT, or directly on a DC:

setspn -L fileserver
setspn -Q HOST/fileserver.corp.local

setspn -Q is the money shot. It searches the whole forest. If you see the same SPN listed under two different computer accounts, that's your bug.

Step 2 — Remove the duplicate

Identify the stale account — usually the older one, or one whose lastLogonTimestamp is ancient. Then:

setspn -D HOST/fileserver.corp.local OLDSERVERNAME
setspn -D HOST/fileserver OLDSERVERNAME

You need Domain Admin or delegated rights on the computer object to do this. If the stale object is a ghost from a deleted machine, you may need to reanimate it, remove the SPN, then delete it again. Annoying, but that's AD.

Step 3 — Check for account name case mismatch (yes, really)

In some legacy systems — old SQL Server instances, some network appliances — the target's account name is stored with a specific case. If your client is sending FILESERVER and the target expects fileserver, you can get 0x574 on non-Kerberos auth. Rare, but real. Check what the app or appliance has configured and match the case exactly.

Step 4 — Reboot the target's Netlogon

After SPN changes, force the target to re-register its names:

net stop netlogon
net start netlogon
nltest /sc_reset:CORP

Then retry from the client. If it still fails, run klist purge on the client to dump any cached Kerberos tickets — a stale TGT can mask the fix.

Still Broken? What the Error Code Actually Tells You

Windows logs the specific cause in the Security event log on the target side. Look for Event ID 4625 with a status of 0xC0000064 (no such user) or 0xC000006E (account restriction). Those line up nicely with a duplicate SPN or a renamed object that hasn't replicated yet.

A few other things that trip people up:

• Trust relationship breaks — if the target is in another domain and the trust is broken, you'll see 0x574 alongside trust errors. Test with nltest /sc_verify:OTHERDOMAIN.
• Time skew over 5 minutes — Kerberos hates clock drift. Run w32tm /monitor and check that target and client agree.
• Third-party credential managers — some VPN clients and SSO tools inject their own credential providers that grab the connection before Windows does. Test with the tool disabled.
• Saved RDP entries — if this is RDP and not SMB, the wrong target name is often stored in the .rdp file itself. Open it in Notepad and check the full address line.

Quick Decision Tree

Start at the top. Don't skip the 30-second fix because it feels too simple — cached credentials cause this more than everything else combined. Only escalate to SPN surgery when the simple stuff has been ruled out clean.