Fix “Logon Failure: The Target Account Name is Incorrect” Error

“Logon Failure: The target account name is incorrect” blocks domain logons, UNC share access, and machine joins, usually because of a Kerberos ticket mismatch, a stale machine account password, a DNS problem, or a duplicate computer account in Active Directory.

Fix #1: Use the Fully Qualified Domain Name (FQDN)

If the error appears when accessing a UNC share or running a logon script, swap the short server name for the FQDN. This bypasses DNS suffix resolution issues without touching anything else.

1. Instead of \\servername\share, type \\servername.domain.com\share in File Explorer’s address bar and press Enter.
2. If that connects, the fix is permanent: open Network and Sharing Center > Change adapter settings, right-click your network adapter, and select Properties.
3. Select Internet Protocol Version 4 (TCP/IPv4) and click Properties.
4. Click Advanced, then open the DNS tab.
5. Under Append these DNS suffixes (in order), confirm your domain suffix (e.g., domain.com) is listed. Add it if it’s missing.
6. Click OK on each dialog to save.

Fix #2: Flush DNS and Check for Duplicate Records

Stale or duplicate DNS A records are the top cause of this error in 2026. A server with two A records pointing to different IPs will fail Kerberos validation even if the password is correct.

1. On the affected client, open an elevated Command Prompt (Windows + S, type cmd, right-click, Run as administrator).
2. Run ipconfig /flushdns and press Enter. You should see Successfully flushed the DNS Resolver Cache.
3. Test resolution: run nslookup servername and then nslookup servername.domain.com. Both should return the same single IP address.
4. If you see multiple IP addresses or conflicting results, log into your DNS server and open an elevated PowerShell window.
5. Run the following to list all A records for the problem server (replace servername and domain.com with your values):
   Get-DnsServerResourceRecord -ZoneName "domain.com" -Name "servername"
6. Delete any duplicate or stale records in DNS Manager (dnsmgmt.msc) by right-clicking the duplicate entry and selecting Delete.
7. Re-run the nslookup tests from step 3 to confirm only one record remains.

Fix #3: Reset the Machine Account Password

Every domain-joined computer has a machine account password that rotates every 30 days. If that password falls out of sync between the client and the domain controller, Kerberos authentication fails with this exact error. You’ll see Event ID 4 (KRB_AP_ERR_MODIFIED) in Event Viewer on the DC when this is the cause.

Note: The old netdom resetpwd command is deprecated in Windows Server 2022 and 2025. Use PowerShell instead.

1. On the domain controller, open an elevated PowerShell 7 window.
2. Stop the Kerberos Key Distribution Center service to flush the ticket cache:
   net stop kdc
3. Reset the machine account password for the problem server (replace DCName with your DC’s name):
   Reset-ComputerMachinePassword -Server DCName -Credential (Get-Credential)
   Enter domain administrator credentials when prompted.
4. Restart the KDC service:
   net start kdc
5. Reboot the affected server or client so it picks up the new ticket.
6. Try logging in again.

Alternatively, you can use Test-ComputerSecureChannel -Repair run locally on the affected machine as this is faster for a single workstation and doesn’t require stopping the KDC.

Fix #4: Check for SPN Conflicts and Rejoin the Domain

Duplicate Service Principal Names (SPNs) across accounts or a stale computer account left over from a domain migration will also trigger this error. This is the most invasive fix, so save it for when the above three haven’t resolved the problem.

Check for duplicate SPNs

1. On the domain controller, open an elevated Command Prompt or PowerShell window.
2. Query the SPN for the affected server:
   setspn -Q HOST/servername
3. The result should show the SPN registered to exactly one account. If it appears under multiple accounts, remove the duplicate:
   setspn -D HOST/servername duplicateaccountname
4. Repeat for the FQDN version: setspn -Q HOST/servername.domain.com

Delete the stale computer account and rejoin

If the machine was recently migrated between domains, the old computer account may still exist. Deleting it and rejoining forces a clean account creation.

1. On the domain controller, open Active Directory Users and Computers (dsa.msc).
2. Locate the old computer account in the source domain or OU, right-click it, and select Delete.
3. On the affected machine, open Settings > System > About > Domain or workgroup (or right-click Start > System > Advanced system settings > Computer Name tab > Change).
4. Select Workgroup, type a temporary name (e.g., WORKGROUP), and click OK. Reboot when prompted.
5. After rebooting, return to the same dialog, select Domain, enter your domain name, and click OK. Enter domain administrator credentials when prompted.
6. Reboot again. The machine will rejoin with a fresh computer account.

Fix #5: Fix Kerberos Encryption Mismatches via Group Policy

On mixed environments with Windows Server 2012 R2 or newer alongside older clients, AES vs. RC4 encryption mismatches can cause this error. A Group Policy change resolves it across the domain.

1. On the domain controller, open Group Policy Management Console (gpmc.msc).
2. Right-click the relevant GPO (or Default Domain Policy) and select Edit.
3. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options.
4. Double-click Network security: Configure encryption types allowed for Kerberos.
5. Check all available encryption types: AES128_HMAC_SHA1, AES256_HMAC_SHA1, RC4_HMAC_MD5, and Future encryption types.
6. Click OK.
7. On the affected client or server, run gpupdate /force in an elevated Command Prompt, then reboot.

When the Fixes Don’t Work

If none of the above resolves the error, check whether a specific domain controller is offline or has experienced a USN rollback as this causes authentication to fail only when that DC handles the request. In Event Viewer on the DC, filter System logs for Event ID 4 (Security-Kerberos) and Event ID 5722 (NETLOGON) to narrow it down. For hybrid environments using Microsoft Entra Connect, run the IdFix tool to detect SPN or UPN conflicts that are silently blocking on-premises authentication.

Conclusion

Fix #2 (flushing DNS and removing duplicate records) or Fix #3 (resetting the machine account password) solves this for most people, check Event Viewer for KRB_AP_ERR_MODIFIED first to know which one applies. If the error comes back after a few weeks, the machine account password is likely resyncing incorrectly, which points to a replication problem between your domain controllers worth investigating before it affects more accounts.