Helpdesk: "BR-DC2 came back on Friday after the branch was offline for most of a month. Now replication from it fails with 'The target principal name is incorrect', a file server we reach through an old alias says 'target account name is incorrect', and the old DC we're retiring won't demote. A forum post says to stop the KDC on every DC, force-remove the old DC, and rejoin the file server. Can we start with that?"
Not yet. "The target principal name is incorrect" doesn't mean Active Directory is corrupt. It means a Kerberos ticket reached a computer that couldn't decrypt it: the wrong computer, the right computer holding a different password than the KDC used, or a name (SPN) registered on the wrong account. Microsoft's replication article says the error "occurs when the source domain controller doesn't decrypt the service ticket provided by the destination (target) domain controller", and that the -2146893022 (0x80090322, SEC_E_WRONG_PRINCIPAL) "error code isn't an Active Directory error." Its top cause: "the KDC has an old version of the password for the source domain controller." Stopping the KDC on every DC, forcing a demotion, or rejoining a server can each hide which of those three it was, and a forced demotion leaves metadata behind that you then have to clean up by hand. Work through it as a chain: which computers, which name, since when → where is the error reported (repadmin, dcdiag, Kerberos Event 4, KDC Event 11)? → did the traffic reach the computer you meant (DNS, hosts file, NTDS Settings GUID)? → which KDC issued the ticket, and does it have the current password for the target? → are the target's SPNs present, and on only one account? → what does the client's Event 4 name as the target and the server that answered? → is an alias (CNAME) involved? → are time and the secure channel in order? → is this a demotion? repadmin, dcdiag, nltest, setspn, Get-WinEvent, Resolve-DnsName, and Get-ADComputer are the sources for that chain. Stop the KDC everywhere and you'll be finding out later which DC was handing out the stale ticket.
If replication fails with 1722 (the RPC server is unavailable) instead, no connection was made yet, and AD Replication Error 1722 starts earlier in the chain. If the message ends in "Cannot generate SSPI context" from SQL Server, SQL Server Error 18456 covers SQL SPNs in depth. This post covers "Active Directory replication, a domain controller, a demotion, or a file server fails with 'The target principal name is incorrect' (-2146893022, 0x80090322), 'target account name is incorrect', or Kerberos Event 4 KRB_AP_ERR_MODIFIED, and you need a read-first path before you stop KDCs, reset DC passwords, delete SPNs, force a demotion, or rejoin servers."
TL;DR
- It's a decryption failure, not a network failure. Microsoft: "Kerberos errors that are mapped by Windows code to -2146893022" include KRB_AP_ERR_MODIFIED, KRB_AP_ERR_BADMATCH, and KRB_AP_ERR_NOT_US. The connection worked; the ticket didn't (Step 2).
- Check you reached the right computer first. Microsoft's first specific cause: "A bad name-to-IP mapping in DNS, WINS, HOST, or LMHOST file." (Step 3).
- Then the password the KDC used. Microsoft: "Replication failures can prevent domain controllers from having a current password value for domain controllers in a given domain." (Step 4).
- SPNs have to be on one account. Microsoft: "Unless a service uses the computer account and the HOST SPN, SPNs must be unique in the AD DS forest." (Step 5).
- Event 4 names both sides. Microsoft's Event 4 text: "Please ensure that the target SPN is registered on, and only registered on, the account used by the server." (Step 6).
- Forced demotion is a last resort. Microsoft: "Forced demotion leaves orphaned metadata in Active Directory on the remaining domain controllers in the forest." (Step 9).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which computers, which name was used, which direction, since when | "AD is broken" with no partner named |
| 2. Where it's reported | You know whether it's replication, a member's Event 4, or a KDC event | Fixing replication when only one file server fails |
| 3. Name-to-IP | The name resolves to the computer you meant, on every DNS server the caller uses | A stale A record, a hosts entry, or a GUID CNAME pointing at another DC |
| 4. KDC and password | The KDC that issued the ticket has the target's current password | DC back from a long outage or a restore; password versions differ |
| 5. SPNs | The target's SPNs exist and sit on one account | KDC Event 11, setspn -X finds duplicates |
| 6. Event 4 read | You know the SPN asked for and the server that answered | Event 4 read as "Kerberos is broken" |
| 7. Aliases | Clients use a name the server has SPNs for |
\\alias\share fails, \\server\share works |
| 8. Time and channel | Clocks within five minutes; DC secure channels healthy | KERB_AP_ERR_SKEW, Netlogon 3210 or 5722 |
| 9. Demotion | Graceful demotion with replication working | Demotion fails, forced removal tempting |
| 10. Change | Only after Steps 1-9 agree: one link, one change | KDC stopped on every DC, same error |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which two computers | For replication: the destination (the DC pulling changes) and the source. Microsoft: "The destination domain controller is the domain controller requesting changes." For a share: the client and the server |
| Which name was used | NetBIOS name, FQDN, IP address, or an alias. A name the server has no SPN for behaves differently from its real name (Step 7) |
| One pair or many | One source failing for every partner points at the source (its password, its DNS records); one destination failing for every source points at the destination's DNS or KDC (our reading) |
| Since when, and what changed | A DC back from a long outage, a DC restored from backup, a rename, a new alias, a new service account, a promotion or demotion, a DNS cleanup |
| Exact error text and code | -2146893022 (0x80090322), "Access is denied", 1722, and 1753 lead to different steps |
| Which domains | Microsoft's Event 4 text warns about "identically named server accounts in these two domains" |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| Replication from one source fails with -2146893022 for every partner | The source's password differs between the KDC and the source | Step 4 |
| One destination fails from several sources | That destination's DNS servers or hosts file, or its KDC | Steps 3 and 4 |
| Error began right after a DC came back from a long outage or a restore | Password versions out of step | Step 4 |
| KDC Event 11 on DCs | A duplicate SPN | Step 5 |
| Kerberos Event 4 on clients reaching one server | SPN on another account, or that server's password | Step 6 |
\\alias\share fails, \\server\share works |
No SPN for the alias | Step 7 |
| Works by IP address, fails by name | Microsoft notes for one scenario: "However, if you use the IP address, the command may succeed." Using an IP usually leaves Kerberos out | Steps 3 and 4 |
| Demotion fails with the error | Replication or the KDC on the DC being removed | Step 9 |
| 1722 or 1753 instead | A connection or endpoint problem, not a decryption problem | The 1722 post |
Step 2: Find where the error is reported (read-only)
For replication, Microsoft lists the commands that show it: REPADMIN /REPLSUM, /SHOWREPL, /SHOWREPS, and /SYNCALL, plus DCDIAG's replications test. Start forest-wide:
:: Read-only. From a DC or an admin box with RSAT: every DC's inbound replication, errors only (Microsoft's repadmin forms)
repadmin /showrepl * /errorsonly
repadmin /showrepl * /csv > showrepl.csv
Microsoft's own shortcut for reading the CSV is repadmin /showrepl * /csv | convertfrom-csv | out-gridview. To pull out only the rows with this error:
# Read-only. Which source and destination pairs report -2146893022 (the Select-String filter is ours)
repadmin /showrepl * /csv | Select-String -Pattern '2146893022'
List every pair. If one source DC appears in every row, that DC is where Step 4 starts. Microsoft's event table for this error includes NTDS KCC 1925 ("The attempt to establish a replication link for the following writable directory partition failed.") and 1308 in the Directory Service log on the destination.
For member servers and clients, the evidence is Kerberos Event 4. Microsoft: "The client then puts Kerberos event 4 (example below) in its System event log."
# Read-only. On the client that can't connect: Kerberos Event 4 in the System log, last 7 days
# (other providers also log an Id 4, so the provider filter is ours)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 4; StartTime = (Get-Date).AddDays(-7) } -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -match 'Kerberos' } |
Select-Object TimeCreated, ProviderName, Message | Format-List
On the DCs, look for duplicate names. Microsoft's archived KDC Event 11 message: "There are multiple accounts with name %1 of type %2." On Windows Server 2012 R2 and later DCs, a blocked attempt to add a duplicate is Event 2974 in the Directory Service log. Microsoft: "The event 2974 lists the value that was blocked and a list of one or more objects (up to 10) that already contain that value."
# Read-only. On each DC: KDC Event 11 (System log) and Event 2974 (Directory Service log), last 7 days
# (the provider match for the KDC is ours)
$since = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 11; StartTime = $since } -ErrorAction SilentlyContinue |
Where-Object { $_.ProviderName -match 'KDC|Key-Distribution' } |
Select-Object TimeCreated, Message | Format-List
Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service'; Id = 2974; StartTime = $since } -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Message | Format-List
Microsoft's Kerberos guidance says to check the Security and System logs on "The authenticating client", "The target server or service", and "The domain controller". Do all three before deciding which one is at fault.
Step 3: Did the traffic reach the computer you meant? (read-only)
Microsoft: "The following situations can all cause a destination domain controller to submit Kerberos-encrypted traffic to the wrong Kerberos target:" stale NTDS Settings objects, bad name-to-IP mappings in DNS and WINS host records, and stale entries in HOST files. If DC1 asks for a ticket for DC2 but the packets land on DC3, DC3 can't decrypt a ticket made for DC2. Microsoft notes the realm in the error can even match: "Bad host-to-IP mappings could cause DC1 to connect to DC3 in the same domain."
How a destination DC finds its source, per Microsoft: it looks up the source's NTDS Settings objectGUID, queries DNS for "a matching DC GUIDED CNAME record", and follows that to the source's host A or AAAA record. Microsoft's check without a network trace, on the source DC first:
:: Read-only. On the SOURCE DC: its IP addresses, and its own DSA object GUID (top of the output; Microsoft's article uses /showreps)
ipconfig /all
repadmin /showreps
Then on the destination DC (Microsoft's sequence; DC1, the GUID, and the DNS server IP are examples):
:: Read-only. On the DESTINATION DC: which DNS servers it asks, and the source's GUID as this DC sees it
ipconfig /all
repadmin /showreps
:: Read-only. What each of those DNS servers returns for the source's GUID CNAME and host record (repeat per DNS server IP)
nslookup -type=cname 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2._msdcs.contoso.com 10.0.0.10
nslookup -type=A+AAAA DC1.contoso.com 10.0.0.10
Microsoft: "The DSA object GUID listed for the source DC in the replication status section of the report should match the object GUID listed in the /showreps header when run on the console of the source DC." For the host records: "Check for duplicate host A records on all DNS Server IPs configured on the destination DC."
The same reads in PowerShell, one pass per DNS server (our form of Microsoft's nslookup steps):
# Read-only. On the destination DC. Fill in the DNS server IPs from ipconfig /all and the source's DSA object GUID
$dnsServers = '10.0.0.10', '10.0.0.11'
$guidName = '6f3f96d3-dfbf-4daf-9236-4d6da6909dd2._msdcs.contoso.com'
foreach ($d in $dnsServers) {
"--- DNS server $d"
Resolve-DnsName -Name $guidName -Type CNAME -Server $d -DnsOnly -ErrorAction SilentlyContinue | Format-Table -AutoSize
Resolve-DnsName -Name 'DC1.contoso.com' -Type A -Server $d -DnsOnly -ErrorAction SilentlyContinue | Format-Table -AutoSize
}
# The hosts file: any line naming the source DC?
Select-String -Path "$env:SystemRoot\System32\drivers\etc\hosts" -Pattern 'DC1'
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
| The GUIDs differ between the source and the destination's view | The destination holds a stale NTDS Settings object for that source (our reading of Microsoft's list) | Replication of the Configuration partition, or metadata cleanup if the old DC is gone (Step 9) |
| One DNS server returns a different IP, or two A records | Bad name-to-IP mapping; often a stale record that scavenging never removed (our reading) | Step 10, and DNS Scavenging Not Working |
| A hosts entry names the source | Microsoft: "Remove if present." | Step 10 |
| The IP answers but isn't a DC | Microsoft: a request sent to a non-DC "returns error 1753" rather than this error | The 1722 post |
| Everything resolves to the right IP | The traffic reached the right DC | Step 4 |
For a member server or client, the same question applies to the server name it used: does Resolve-DnsName for that name, against the client's DNS servers, return the server you meant? If the client can't find a DC at all, Netlogon Event ID 5719 covers DC location.
Step 4: Which KDC issued the ticket, and does it have the current password? (read-only)
This is Microsoft's top cause. Every DC runs a KDC, and Microsoft: "For same realm transactions, a destination domain controller favors getting Kerberos tickets from itself. However, it may get a ticket from a remote domain controller." If whichever KDC issued the ticket holds an older password for the source DC than the source itself does, the source can't decrypt it.
Why the passwords drift: Microsoft's netdom article says "Each Windows-based computer maintains a machine account password history that contains the current and previous passwords that are used for the account," and "If the sequence of password changes exceeds two changes, the computers involved may not be able to communicate, and you may receive error messages." A DC that was offline, or couldn't replicate, while its partners changed passwords is the usual way to get there (our reading). Microsoft's replication article: "Replication failures can prevent domain controllers from having a current password value for domain controllers in a given domain."
Find the KDC, close to the time of the failure:
:: Read-only. On the destination (or the client): which KDC does it find? /FORCE skips the cache
nltest /dsgetdc:contoso.com /kdc /force
Microsoft: the nltest /dsgetdc command "that's run at an elevated command prompt in close time proximity to a SEC_E_WRONG_PRINCIPAL error can be used to quickly identify which KDC a Kerberos client is targeting." The definitive answer is a network trace; Microsoft: "The definitive way to determine which domain controller a Kerberos client got a ticket from is to take a network trace."
Then compare the source DC's password attributes as the source sees them and as that KDC sees them:
:: Read-only. The source DC's computer account: on the source (DC1), then on the KDC the destination used (DC3). Names are examples
repadmin /showobjmeta DC1 "CN=DC1,OU=Domain Controllers,DC=contoso,DC=com"
repadmin /showobjmeta DC3 "CN=DC1,OU=Domain Controllers,DC=contoso,DC=com"
Microsoft: look "for obvious version number differences in password-related attributes (dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet, lmPwdHistory)". The same comparison as a quick read across every DC:
# Read-only. PasswordLastSet for the source DC's account (DC1) as each DC currently holds it (the loop is ours)
$source = 'DC1'
foreach ($dc in (Get-ADDomainController -Filter *)) {
Get-ADComputer -Identity $source -Server $dc.HostName -Properties PasswordLastSet |
Select-Object @{ n = 'AskedDC'; e = { $dc.HostName } }, Name, PasswordLastSet
}
| Finding | What it means (our reading unless noted) | Next |
|---|---|---|
| The KDC's copy has a lower version, or an older PasswordLastSet | The KDC has the old password: Microsoft's top cause | Step 10: Microsoft's KDC sequence |
| Several DCs hold the old value | Inbound replication of the domain partition is failing to those DCs | Fix replication to them first (the 1722 post if that's the code) |
| The source itself is the odd one out (newer locally than anywhere else) | The source changed its password and couldn't replicate it out | Step 10: netdom resetpwd on the source |
| All copies match | The password isn't the cause | Step 5 |
Step 5: Are the target's SPNs present, and on only one account? (read-only)
Microsoft: "SPNs may be missing, invalid, or duplicated due to simple replication latency, especially following promotion, or replication failures." And: "Duplicate SPNs may cause bad SPN to name mappings." Microsoft's first resolution step for the replication error is a DCDIAG test that isn't run by default:
:: Read-only. On the console of each source DC that fails outbound replication with this error
dcdiag /test:checksecurityerror
:: Read-only. Add the partner check (DC2 is an example)
dcdiag /test:checksecurityerror /ReplSource:DC2.contoso.com
Microsoft: "Run this command on the console of all source domain controllers that fail outbound replication with the SEC_E_WRONG_PRINCIPAL error." Per the dcdiag reference, the test checks that "at least one KDC is online for each domain and is reachable", that the DC's computer object has replicated to other DCs, and that the account "has the minimum required Service Principal Names (SPN) configured." With /ReplSource, it also checks time skew: "The time skew calculated between the servers to verify it's less than 300 seconds (5 minutes) for Kerberos."
Then read the SPNs directly:
:: Read-only. The SPNs registered on the DC's own computer account (DC1 is an example)
setspn -L DC1
:: Read-only. Which account holds a given SPN
setspn -Q HOST/DC1.contoso.com
:: Read-only. Search for duplicate SPNs, forest-wide (can take a while)
setspn -X -F
From Microsoft's setspn reference: -L "Lists the currently registered SPN for the computer.", -Q "Queries for any existing SPNs.", -X "Performs a search of duplicate SPNs.", and -F "Performs queries at the forest, rather than domain level." (combining -X with -F is our form). Microsoft warns: "Searching for duplicates, especially forest-wide, can take a long time and lots of memory." Run it from one admin box, not every DC at once (our habit).
The replication SPN in a DC's ticket request is the replication service UUID plus the source's NTDS Settings GUID, as in Microsoft's trace: E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso.com. Microsoft: "If the source domain controller's SPN doesn't exist in the realm, you receive a KDC_ERR_S_PRINCIPAL_UNKNOWN error."
| Finding | What it means (Microsoft unless noted) | Next |
|---|---|---|
checksecurityerror reports missing SPNs on a new DC |
Microsoft: replication latency "especially following promotion" | Let replication finish, then re-run (our reading) |
setspn -Q returns two accounts for one SPN |
"One SPN can be associated with only one account." | Step 10: remove it from the wrong one |
| A HOST/ or service SPN for a server sits on a user account | Microsoft's Event 4 cause: "When the SPN is on the wrong account in Active Directory the secret that is used is the one of the accounts the SPN is on instead of the one of the servers." | Step 10 |
| Duplicates only across two forests | "SPNs aren't required to be unique across forests, but duplicate SPNs can cause authentication issues during cross-forest authentication." | Decide which forest should own it (our reading) |
| No duplicates, SPNs present | SPNs aren't the cause | Step 6 or Step 8 |
Since Windows Server 2012 R2, Microsoft says DCs "block the creation of duplicate service principal names (SPN) and user principal names (UPN)", so new duplicates usually come from writes to older DCs or from before that (our reading). Microsoft's blocked-write error 8647 reads "The operation failed because SPN value provided for addition/modification isn't unique forest-wide."
Step 6: Read Kerberos Event 4 on the client (read-only)
On member servers and clients, the error behind "target principal name" and "target account name" messages is usually a Kerberos Event 4 with KRB_AP_ERR_MODIFIED (our reading of Microsoft's Event 4 articles). Microsoft's Kerberos guidance: "Because more than one issue can cause this error, check for related events. For example, this string might mean that the client and target server clocks are out of sync, or that the SPN isn't unique." The current event text, from Microsoft's file-share article, names three causes:
- The SPN on the wrong account: "This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using."
- A password mismatch: "This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account."
- Two accounts with the same name: "If the server name is not fully qualified, and the target domain (DNS_prefix.dns_suffix) is different from the client domain (DNS_prefix.dns_suffix), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server."
Read the two names in the message. Microsoft's example: "The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/machinename.childdomain.rootdomain.com. The target name used was cifs/machinename.domain.com." The first is the server that answered; the second is the SPN the client asked a ticket for (our reading).
:: Read-only on the directory. On the client: who holds the SPN from "The target name used was", then ask for that ticket
setspn -Q cifs/FS01.contoso.com
klist get cifs/FS01.contoso.com
klist
klist get "Allows you to request a ticket to the target that is specified by the SPN." It adds a ticket to your cache; nothing changes in AD.
| What the event shows | What it means (our reading unless noted) | Next |
|---|---|---|
| The server that answered isn't the one in the target name | The name resolved to another computer | Step 3 |
setspn -Q returns an account other than the server's |
SPN on the wrong account (Microsoft's Event 4 cause) | Step 10 |
| The server's own account holds the SPN, only once | The server's password differs from the KDC's copy, or the clocks differ | Steps 4 and 8, and for members the trust-relationship post |
| Short name used, two domains in the forest | Identically named accounts; Microsoft: "use the fully-qualified name" | Test with the FQDN |
| Windows Server 2012 R2 file server, Event 4 plus Event 1097 | Microsoft's 2012 R2 article: "the file server cannot decrypt the ticket that was encrypted in AES256" | Microsoft's encryption-types policy fix, after reading the current setting |
| None of these | Microsoft: "Less commonly this is caused by network problems between client and server where the ticket is truncated." | A simultaneous network trace (Microsoft's guidance) |
Step 7: Is an alias (CNAME) involved? (read-only)
The member-server version of this error often comes from a name the server doesn't own. Microsoft's SMB article: with a CNAME, \\CNAME\share_name can fail with "Logon Failure: The target account name is incorrect." while the NetBIOS name and FQDN work. Microsoft's causes: "Configuration issue or SMB server service hardening issue." and "The service principal name (SPN) for the DNS alias (CNAME) record for the file share server is missing."
:: Read-only. On the server (or with RSAT): which names does it own, and does each have a DNS record and an SPN? (FS01 is an example)
netdom computername FS01.contoso.com /enumerate:allnames
netdom computername FS01.contoso.com /verify
setspn -L FS01
# Read-only. On the client: what the alias resolves to (files.contoso.com is an example)
Resolve-DnsName -Name 'files.contoso.com' -DnsOnly | Format-Table -AutoSize
From Microsoft's netdom reference, /verify "Checks if there's a DNS record and a service principal name (SPN) for each computer name." If the alias resolves through a CNAME and isn't in the /enumerate list, and no SPN for it appears in setspn -L, that's this case. Microsoft's fix is in Step 10. If the alias points at a cluster name or a NAS, the SPN belongs on that object's account instead (our reading).
Step 8: Are time and the DC secure channel in order? (read-only)
Time. Microsoft's Kerberos guidance: "The difference in time between the domain controller and the client computer or the target server must be less than five minutes." A skew failure is logged as Event 4 with KERB_AP_ERR_SKEW (Microsoft's table), not MODIFIED, but check it while you're here:
:: Read-only. Three samples of the offset from this DC to its partner (DC1 is an example)
w32tm /stripchart /computer:DC1.contoso.com /samples:3 /dataonly
If the offset is minutes, read Windows Time Not Syncing With Domain Controller before you change any passwords.
The DC's secure channel. Microsoft's article on this error during manual replication lists Netlogon events alongside it: 3210 ("Failed to authenticate with \\DOMAINDC, a Windows NT domain controller for domain DOMAIN.") and 5722 ("The session setup from the computer 1 failed to authenticate."). On a DC, don't use Test-ComputerSecureChannel. Microsoft: "This cmdlet only works on Domain Member computers. When you run it on Domain Controllers, it returns false positive errors. To verify and reset the secure channels for Domain Controllers, use netdom.exe or nltest.exe."
:: Read-only. On the DC: state of its secure channel the last time it was used, and the PDC emulator
nltest /sc_query:contoso.com
netdom query fsmo
/sc_query "Reports on the state of the secure channel the last time that you used it." Leave nltest /sc_verify for later: Microsoft says if the channel doesn't work, "this parameter removes the existing channel, and then builds a new one." That's a change. For member servers and workstations, Trust Relationship Between This Workstation and the Primary Domain Failed covers the member-side secure channel and machine password.
The machine password itself. Microsoft's Directory Services blog: "Machine account passwords as such do not expire in Active Directory." And: "It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD." So a DC that was offline for a month doesn't come back with an expired password; it comes back possibly behind on its partners' passwords, or with its own change not yet replicated (our reading, Step 4).
SQL Server. If the message is "The target principal name is incorrect. Cannot generate SSPI context.", that's SQL Server's version. Microsoft: "In most cases, a misconfigured Service Principal Name (SPN) causes this error." The SQL side (service account, MSSQLSvc SPNs, Kerberos Configuration Manager) is in SQL Server Error 18456; Steps 3, 5, and 8 here still apply to the DCs behind it.
Step 9: Is this a demotion? (read-only)
A demotion has to replicate its last changes out and talk to a partner, so a DC that can't authenticate to its partners fails here too (our reading). Microsoft's DC deployment troubleshooting: "The built-in logs are the most important instrument for troubleshooting issues with domain controller promotion and demotion." Read them first:
# Read-only. On the DC that won't demote: the last 60 lines of each demotion log, then search them for the error (the Select-String filter is ours)
Get-Content -Path "$env:SystemRoot\debug\dcpromoui.log" -Tail 60
Get-Content -Path "$env:SystemRoot\debug\dcpromo.log" -Tail 60 -ErrorAction SilentlyContinue
Select-String -Path "$env:SystemRoot\debug\dcpromo*.log" -Pattern 'target principal|2146893022|0x80090322'
Microsoft: "Examine the Dcpromoui.log and dcpromo.log for the errors shown in the output, then work backwards from them to see indications of why the failure occurred." Then run Steps 2-5 for this DC as a replication source: its outbound replication, its DNS records, its password versions, and dcdiag /test:checksecurityerror on its console. If SYSVOL (DFS Replication) is what's failing during the demotion, DFS Replication Not Working covers the DFSR side.
Forced removal. Microsoft is direct about it: "Don't select this option unless the domain controller can't contact other domain controllers and there's no reasonable way to resolve that network issue." Also: "all unreplicated changes on that domain controller, such as passwords or new user accounts, are lost forever." And: "If you forcibly demote a domain controller, you must manually perform metadata cleanup immediately."
A community answer in an archived TechNet forum thread on this exact failure: "I was able to get my DC to demote after stopping the KDC service. Then I reran the demotion with force removal and it completed successfully." That's a forced removal, with the metadata cleanup it requires (community, labeled). If the DC still replicates with anyone, fix the password or DNS link first (Step 10) and demote gracefully.
Common false starts
| What people try | Why it misleads (our reading unless noted) |
|---|---|
| Stopping the KDC on every DC | Microsoft's sequence stops it on the destination, or on the DC whose password you reset. Its netdom article allows "on all domain controllers except one" only if needed; with every KDC stopped, nobody can get a ticket |
| Forcing the demotion first | Microsoft: forced removal is only for a DC that "can't contact other domain controllers"; it loses unreplicated changes and needs metadata cleanup |
| Rejoining the file server | Rejoining resets the computer's password, but doesn't move an SPN off another account or fix a CNAME. The Event 4 cause has to be read first (Step 6) |
setspn -A to add the missing SPN |
Microsoft: "you should use setspn -S instead because it verifies that there are no duplicate SPNs." Adding a duplicate makes Event 4 worse |
| Deleting SPNs from the DC's own account | The DC needs its own SPNs; dcdiag /test:checksecurityerror checks for "the minimum required Service Principal Names (SPN)" |
| A hosts-file entry to "pin" the partner | Microsoft lists stale hosts entries as a cause and says to remove them |
| Connecting by IP address and calling it fixed | Usually works because Kerberos isn't used, which hides the broken link |
nltest /sc_verify or /sc_reset as a check |
Both can rebuild the channel; /sc_query is the read |
klist purge everywhere |
Microsoft: "Purging tickets destroys all tickets that you have cached, so use this attribute with caution." Purge the one logon session you're testing (Step 10) |
Step 10: Change one link, then prove it
Only after Steps 1-9 agree on which link failed. Write down the current state first: the repadmin /showrepl * /csv output from Step 2, the setspn -L output for every account you're about to touch, and the repadmin /showobjmeta pair from Step 4 (our habit). An SPN you delete by mistake is easy to put back only if you saved the list.
Wrong name-to-IP (Step 3). Fix the record, not the client. Delete the stale or duplicate A record on the DNS server, or the hosts entry, then clear the caches on the destination. Microsoft's steps: IPCONFIG /FLUSHDNS to "Clear the DNS Client cache", and "Run Nbtstat -R (upper case R) to refresh the NetBIOS name cache." If scavenging should have removed the record, DNS Scavenging Not Working covers why it didn't.
:: Change (low risk). On the destination DC, after the record or hosts entry is fixed
ipconfig /flushdns
nbtstat -R
klist -li 0x3e7 purge
Microsoft: "Kerberos tickets for the system account that are used by Active Directory replication can be purged without a restart by using KLIST -li 0x3e7 purge."
KDC holding an old password for the source (Step 4). Microsoft's top resolution, on the destination DC: disable its KDC so it gets a ticket from another DC, restart, replicate from the source, then put the KDC back. Microsoft: "Domain controllers can be made to use other domain controllers by stopping the KDC service on a local or remote domain controller."
# Change, on the DESTINATION DC (BR-DC2). Microsoft's sequence; dry-run the startup change first
Set-Service -Name KDC -StartupType Disabled -WhatIf
# ...restart the destination DC, then replicate from the source. Microsoft's form, run against the destination:
# repadmin /replicate BR-DC2.contoso.com DC1.contoso.com "DC=contoso,DC=com"
Set-Service -Name KDC -StartupType Automatic -WhatIf # Microsoft's article writes Auto; Set-Service documents Automatic
Start-Service -Name KDC -WhatIf
Remove -WhatIf when the dry run shows the service you meant. Microsoft: "If it doesn't resolve the issue, see the Resolution section for an alternative solution in which you use the netdom resetpwd command to reset the computer account password of the source domain controller."
The source DC's own password (Step 4). Run this on the DC whose password is wrong; Microsoft: "This command must be run on the DC whose machine account password you wish to reset." Microsoft's manual-replication article resets it against the PDC emulator, so find that first. Microsoft: "If you want to reset the password for a Windows domain controller, you must stop the Kerberos Key Distribution Center service and set its startup type to Manual."
:: Change, on the DC whose password is wrong (DC1). PDC01 is the PDC emulator from netdom query fsmo; names are examples
netdom query fsmo
sc config KDC start= demand
net stop KDC
klist -li 0x3e7 purge
netdom resetpwd /server:PDC01 /userd:contoso\admin.user /passwordd:*
demand is the sc config value for a manual start, from Microsoft's sc config reference. Then Microsoft: "Restart the server whose password was changed." After the restart, start the KDC and set it back to Automatic (sc config KDC start= auto, then net start KDC). If you run netdom resetpwd on the PDC emulator itself, point /server: at another healthy DC (our reading of Microsoft's "the name of the domain controller to use for setting the machine account password").
SPN on the wrong account, or duplicated (Steps 5 and 6). Microsoft's three commands, in order:
:: Change. Find, remove from the wrong account, add to the right one (SPN and account names are examples)
setspn -Q cifs/FS01.contoso.com
setspn -D cifs/FS01.contoso.com OLD-FS01
setspn -S cifs/FS01.contoso.com FS01
Microsoft's Event 4 article runs these "using Enterprise Administrator credentials". Use -S, not -A; Microsoft says Setspn.exe has had "duplicate SPN detection built-in to it since the Windows Server 2008 release" with the -S option. If the right account is a service account rather than the computer, add it there instead; Microsoft: "If the SPN is assigned to any account other than the correct service account (custom account or computer account), remove the SPN from those accounts."
Alias without an SPN (Step 7). Microsoft: "avoid using the DNS CNAME to configure the file server's alternative name." Add the alias to the server's own account:
:: Change, on the file server (elevated). Then verify; remove the old CNAME only after clients work by the alias (our habit)
netdom computername FS01.contoso.com /add:files.contoso.com
netdom computername FS01.contoso.com /verify
setspn -L FS01
Per Microsoft's Core Infrastructure blog post on aliases, the command will "register the DNS A record, register additional SPNs, and add OptionalNames registry key." If the old CNAME stays in DNS, clients may keep using it, so plan its removal (our reading).
The demotion (Step 9). Fix the password or DNS link above, confirm the DC replicates outbound, then demote normally. A forced removal (Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole) is only for a DC that truly can't reach a partner. Microsoft: "Metadata cleanup is a required procedure after a forced removal of Active Directory Domain Services (AD DS)." Microsoft's console route deletes the old DC's computer object in Active Directory Users and Computers with This Domain Controller is permanently offline and can no longer be demoted using the Active Directory Domain Services Installation Wizard (DCPROMO) selected. Then delete its stale DNS records.
Then prove it. For replication, one destination, one source, one partition. Microsoft's article on diagnosing replication lists "Time accuracy within 5 minutes to support Kerberos authentication" among its dependencies, so run the Step 8 time read again if you changed anything near the clocks.
:: Read-mostly. Trigger one inbound replication, then re-read status (names and partition are examples)
repadmin /replicate BR-DC2.contoso.com DC1.contoso.com "DC=contoso,DC=com"
repadmin /showrepl BR-DC2.contoso.com
dcdiag /test:checksecurityerror /ReplSource:DC1.contoso.com
For a member server, purge only your own tickets, connect by the same name that failed, and look for the new service ticket:
:: Low-risk. On the client, in the user's own session
klist purge
dir \\files.contoso.com\share
klist
The pass is a successful replication with no new -2146893022 in /showrepl, or a share that opens by the alias with a cifs/ ticket listed by klist and no new Event 4 (Step 2's read). Then the next pair, or the next client, since a destination that pulled from one source can still hold a bad ticket for another (our reading).
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| The source's name resolves to another computer | Fix the DNS record or hosts entry, flush, purge the system tickets | A hosts entry pinning a new IP |
| KDC holds an old password for the source | Microsoft's KDC sequence on the destination | Stopping the KDC on every DC |
| The source's own password is wrong |
netdom resetpwd on that DC against the PDC emulator |
Rebuilding the DC |
| SPN on the wrong account or duplicated |
setspn -D from the wrong account, setspn -S on the right one |
setspn -A, or deleting a DC's own SPNs |
| Alias with no SPN | netdom computername /add |
DisableStrictNameChecking and manual SPN edits |
| Demotion fails while replication still works | Fix the link, then a graceful demotion | Forced removal without metadata cleanup |
| 2012 R2 file server can't decrypt AES tickets | Microsoft's encryption-types policy fix for that version | Disabling AES across the domain |
FAQ
What does "The target principal name is incorrect" mean?
A computer received a Kerberos ticket it couldn't decrypt. Microsoft's top cause in AD replication: "the KDC has an old version of the password for the source domain controller." The other causes Microsoft lists are a bad name-to-IP mapping (the ticket went to the wrong computer), an SPN the KDC couldn't find or found on the wrong account, and frames modified in transit.
What is error -2146893022 (0x80090322)?
It's SEC_E_WRONG_PRINCIPAL, the code behind "The target principal name is incorrect." Microsoft: it "isn't an Active Directory error" and can come from RPC, Kerberos, SSL, LSA, or NTLM. In replication, Microsoft's article shows it remapped from the Kerberos errors KRB_AP_ERR_MODIFIED or KRB_AP_ERR_NOT_US.
How do I find duplicate SPNs?
setspn -Q <SPN> shows which account holds one SPN; setspn -X searches for duplicates (add -F for the whole forest). On DCs, KDC Event 11 reports multiple accounts with the same name, and Event 2974 reports a blocked attempt to add a duplicate.
Should I stop the KDC on every domain controller?
No. Microsoft's top resolution disables the KDC on the destination DC only, restarts it, replicates, and turns it back on. Its netdom article allows stopping the KDC "on all domain controllers except one" only if needed. With none running, no one in the domain can get a ticket.
Is this the same as SQL Server's "Cannot generate SSPI context"?
Same family. SQL Server shows "The target principal name is incorrect. Cannot generate SSPI context." and Microsoft says a misconfigured SPN causes it in most cases. Start with the SQL Server post for the service account side; the DNS, SPN, and time steps here still apply.
Related posts
- AD Replication Error 1722 (the sibling when no connection was made: DNS, RPC ports, firewalls, NICs)
- SQL Server Error 18456 (SQL SPNs, service accounts, and "Cannot generate SSPI context")
- DNS Scavenging Not Working (the stale A records that send a ticket to the wrong computer)
- Netlogon Event ID 5719 (when a computer can't find a domain controller at all)
- Windows Time Not Syncing With Domain Controller (the five-minute Kerberos clock limit)
- Trust Relationship Between This Workstation and the Primary Domain Failed (the member-side secure channel and machine password)
- DFS Replication Not Working (SYSVOL replication, including during a demotion)
Free checklist
Stopping the KDC on every domain controller before anyone read which DC issued the bad ticket is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=target-principal-name-is-incorrect
Admin Pack Studio; not affiliated with Microsoft. Steps 1-9 favor read-only checks: repadmin /showrepl, /showreps, and /showobjmeta, dcdiag /test:checksecurityerror, Get-WinEvent, ipconfig /all, nslookup, Resolve-DnsName, Select-String, nltest /dsgetdc and /sc_query, Get-ADDomainController, Get-ADComputer, setspn -L, -Q, and -X, klist, netdom computername /enumerate and /verify, netdom query fsmo, w32tm /stripchart, and Get-Content on the demotion logs. klist get adds a ticket to your own cache. Fixing DNS records and hosts entries, flushing caches, purging tickets, disabling or stopping the KDC, netdom resetpwd, setspn -D and -S, netdom computername /add, nltest /sc_verify and /sc_reset, demotion, forced removal, and metadata cleanup are deliberate changes. Change one link at a time, test from the failing pair or client, and check current Microsoft Learn for version-specific behavior.
