Replication error -2146893022 The target principal name is incorrect

  • Article

Updated: March 1, 2012

Applies To: Windows Server 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2

This topic explains symptoms, causes and how to resolve Active Directory replication error -2146893022: The target principal name is incorrect.

  • Symptoms

  • Causes

  • Resolutions

  • More Information

Symptoms

This article describes the symptoms, cause, and resolution steps when Active Directory replication fails with error -2146893022: “The target principal name is incorrect."

  1. DCDIAG reports that the Active Directory Replications test has failed with error -2146893022: “The target principal name is incorrect."

    [Replications Check,<DC Name>] A recent replication attempt failed:
From <source DC> to <destination DC>
Naming Context: <DN path of directory partition>
The replication generated an error (-2146893022):
The target principal name is incorrect.
The failure occurred at <date> <time>.
The last success occurred at <date> <time>.
<X> failures have occurred since the last success.

  2. REPADMIN.EXE reports that replication attempt has failed with status -2146893022 (0x80090322).

    REPADMIN commands that commonly cite the -2146893022 (0x80090322 status) include but are not limited to:

    • REPADMIN /REPLSUM

    • REPADMIN /SHOWREPL
    • REPADMIN /SHOWREPS

    • REPADMIN /SYNCALL

    Sample output from "REPADMIN /SHOWREPS" and REPADMIN /SYNCALL depicting the "target principal name is incorrect" error are shown below:

    c:\>repadmin /showreps
<site name>\<destination DC>
DC Options: IS_GC 
Site Options: (none)
DC object GUID: <NTDS settings object object GUID>
DChttps://bemis/13/Pages/2090913_en-US.aspx invocationID: <invocation ID string>
==== INBOUND NEIGHBORS ======================================
DC=<DN path for directory partition>
<site name>\<source DC via RPC
DC object GUID: <source DCs ntds settings object object guid>
Last attempt @ <date> <time> failed, result -2146893022 (0x80090322):
The target principal name is incorrect.
<X #> consecutive failure(s).
Last success @ <date> <time>.


c:\>repadmin /syncall /Ade
Syncing all NC's held on localhost.
Syncing partition: DC=<Directory DN path>
CALLBACK MESSAGE: Error contacting server CN=NTDS Settings,CN=<server name>,CN=Servers,CN=<site name>,CN=Sites,CN=Configuration,DC=<forest root domain> (network error): -2146893022 (0x80090322):

  3. The Replicate now command in Active Directory Sites and Services returns "The target principal name is incorrect."

    Right-clicking on the connection object from a source DC and choosing Replicate now fails with ""The target principal name is incorrect.” The on-screen error message text and screenshot is shown below:

    Dialog title text: Replicate Now

    Dialog message text:

    The following error occurred during the attempt to contact the domain controller <source DC name>:

    The target principal name is incorrect

  4. NTDS KCC, NTDS General or Microsoft-Windows-ActiveDirectory_DomainService events with the -2146893022 status are logged in the Directory Services log in Event Viewer.

    Active Directory events that commonly cite the -2146893022 status include but are not limited to:

    Event ID Event Source Event String

    1586

    NTDS Replication

    The Windows NT 4.0 or earlier replication checkpoint with the PDC emulator master was unsuccessful.

    A full synchronization of the security accounts manager (SAM) database to domain controllers running Windows NT 4.0 and earlier might take place if the PDC emulator master role is transferred to the local domain controller before the next successful checkpoint.

    1925

    NTDS KCC

    The attempt to establish a replication link for the following writable directory partition failed.

    1308

    NTDS KCC

    The Knowledge Consistency Checker (KCC) has detected that successive attempts to replicate with the following domain controller has consistently failed.

    1926

    Microsoft-Windows-ActiveDirectory_DomainService

    The attempt to establish a replication link to a read-only directory partition with the following parameters failed.

    1373

    NTDS Inter-site Messaging

    The Intersite Messaging service could not receive any messages for the following service through the following transport. The query for messages failed.

Causes

The -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL error code is not an error returned by Active Directory but may be returned by lower layer components, including RPC, Kerberos, SSL, LSA and NTLM, for different root causes.

Kerberos errors that are mapped by Windows code to -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL include:

  • KRB_AP_ERR_MODIFIED (0x29 / 41 decimal / KRB_APP_ERR_MODIFIED)

  • KRB_AP_ERR_BADMATCH (0x24h / 36 decimal / Ticket and authenticator do not match)

  • KRB_AP_ERR_NOT_US (0x23h / 35 decimal / The ticket is not for us)

Some specific root causes for Active Directory logging -2146893022 \ 0x80090322 \ SEC_E_WRONG_PRINCIPAL include:

  • A bad name-to-IP mapping in DNS, WINS, HOST or LMHOST file caused the destination DC to connect to the wrong source DC in the same Kerberos realm.

  • A bad name-to-IP mapping in DNS, WINS, HOST or LMHOST file caused the destination DC to connect to the wrong source DC in a different Kerberos realm.

  • The Kerberos target computer (source DC) was unable to decrypt Kerberos authentication data sent by the Kerberos client (destination DC) because the KDC and source DC have different versions of the source DCs computer account password.

  • The KDC could not find a domain to look for the SPN of the source DC.

  • Authentication data in Kerberos encrypted frames were modified by hardware (including network devices), software, or an attacker.

Resolutions

  1. Run dcdiag /test:checksecurityerror on the source DC

    SPNs may be missing, invalid or duplicated due to simple replication latency, especially following promotion, or replication failures.

    Duplicate SPNs may cause bad SPN to name mappings.

    DCDIAG /TEST:CheckSecurityErrorr can check for missing or duplicate SPNs and other errors.

    Run this command on the console of all source DCs that fail "outbound" replication with the SEC_E_WRONG_PRINCIPAL error.

    You can check SPN registration against a specific location using the syntax:

    dcdiag /test:checksecurityerror replsource:<remote dc>

  2. Verify that Kerberos encrypted network traffic reached the intended Kerberos target (name-to-IP mapping).

    When inbound replicating Active Directory, destination DCs search their local copy of Active Directory for the objectGUID of the source DCs NTDS Settings objects, then query the active DNS Server for a matching DC GUIDed CNAME record which is then mapped to a host "A" / "AAAA" record containing the source DCs IP address. Active Directory performs name resolution fallback that includes queries for fully qualified computer names in DNS or single-label hostnames in WINS (note: DNS servers can also perform WINS lookups in fallback scenarios).

    Stale NTDS Settings objects, bad name-to-IP mappings in DNS and WINS host records, stale entries in HOST files can all cause a destination DC to submit Kerberos-encrypted traffic to the wrong Kerberos target.

    There are two methods to check for this condition:

    • Take a network trace.

    Or

    1. Manually verify that name DNS / NetBIOS name queries resolve to the intended target computer.

    Network trace method (as parsed by Network Monitor 3.3.1641 with full default parsers enabled)

    The table below shows a synopsis of network traffic exhibited when destination DC1 inbound replicates Active Directory from source DC2.

    F# SRC DEST Protocol Frame Comment

    1

    DC1

    DC2

    MSRPC

    MSRPC:c/o Request: unknown Call=0x5 Opnum=0x3 Context=0x1 Hint=0x90

    Dest DC RPC call to EPM on source DC over 135

    2

    DC2

    DC1

    MSRPC

    MSRPC:c/o Response: unknown Call=0x5 Context=0x1 Hint=0xF4 Cancels=0x0

    EPM response to RPC caller

    3

    DC1

    DC2

    MSRPC

    MSRPC:c/o Bind: UUID{E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR(DRSR) Call=0x2 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0

    RPC bind request to E351… service UUID

    4

    DC2

    DC1

    MSRPC

    MSRPC:c/o Bind Ack: Call=0x2 Assoc Grp=0x9E62 Xmit=0x16D0 Recv=0x16D0

    RPC Bind response

    5

    DC1

    KDC

    Kerberos v5

    KerberosV5:TGS Request Realm: CONTOSO.COM Sname: E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso.com

    TGS request for replication SPN of source DC. This operation will not appear on the wire of destination DC uses self as KDC.

    6

    KDC

    DC1

    Kerberos v5

    KerberosV5:TGS Response Cname: CONTOSO-DC1$

    TGS response to destination DC contoso-dc1. This operation will not appear on the wire of destination DC uses self as KDC.

    7

    DC1

    DC2

    MSRPC

    MSRPC:c/o Alter Cont: UUID{E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR(DRSR) Call=0x2

    AP request

    8

    DC2

    DC1

    MSRPC

    MSRPC:c/o Alter Cont Resp: Call=0x2 Assoc Grp=0x9E62 Xmit=0x16D0 Recv=0x16D0

    AP response
    Drilldown on Frame 7 Drilldown on Frame 8 Comments

    MSRPC MSRPC:c/o Alter Cont: UUID{E3514235-4B06-11D1-AB04-00C04FC2DCD2} DRSR(DRSR) Call=0x2

    MSRPC:c/o Alter Cont Resp: Call=0x2 Assoc Grp=0xC3EA43 Xmit=0x16D0 Recv=0x16D0

    DC1 connects to AD Replication Service on DC2 over the port returned by the EPM on DC2.

    Ipv4: Src = x.x.x.245, Dest = x.x.x.35, Next Protocol = TCP, Packet ID =, Total IP Length = 0

    Ipv4: Src = x.x.x.35, Dest = x.x.x.245, Next Protocol = TCP, Packet ID = 31546, Total IP Length = 278

    Verify that AD replication source DC (referred to here as the “Dest” computer in 1st column and “Src” computer in column 2 “owns’ the IP address cited in the trace (x.x.x.35 in this example).

    Ticket: Realm: CONTOSO.COM, Sname: E3514235-4B06-11D1-AB04-00C04FC2DCD2/6f3f96d3-dfbf-4daf-9236-4d6da6909dd2/contoso.com

    ErrorCode: KRB_AP_ERR_MODIFIED (41)

    Realm: <verify that realm returned by the source DC matches the Kerberos realm intended by the destination DC>.

    Sname: <verify that the sName in the AP response matches contains the hostname of the intended source DC and NOT another DC that the destination incorrectly resolved to due to a bad name-to-ip mapping problem.

    In column 1, note the realm of the target Kerberos realm as “contoso.com” followed by the source DCs Replication SPN (“Sname”) which consists of the Active Directory replication service UUID (E351…) concatenated with object GUID of the source DCs NTDS Settings object.

    The GUIDED value "6f3f96d3-dfbf-4daf-9236-4d6da6909dd2" to the right of the E351... replication service UUID is the Object GUID for the source DCs NTDS settings object currently defined in the destination DCs copy of Active Directory. Verify that this object GUID matches the value in the “DSA Object GUID” field when “repadmin /showreps” is run from the console of the source DC).

    A ping or nslookup of the source DCs fully qualified CNAME concatenated with "_msdcs.<forest root DNS name>" from the console of the destination DC must return the source DCs current IP address:

    ping 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2._msdcs.contoso.com
    nslookup –type=cname 6f3f96d3-dfbf-4daf-9236-4d6da6909dd2._msdcs.<forest root domain> <DNS Server IP>

    In the reply shown in column 2, focus on the “Sname” field and verify that it contains the hostname of the AD replication source DC.

    Bad name-to-IP mappings could cause the destination DC to connect to a DC in a completely invalid target realm causing the Realm value to be invalid as shown in this case. Bad host-to-IP mappings could cause DC1 to connect to DC3 in the same domain which would still generate KRB_AP_ERR_MODIFIED but the realm name in frame 8 would match the realm in frame 7.

    Name to IP mapping verification (without using a network trace)

    From the console of the source DC:

    Command Comment

    IPCONFIG /ALL |MORE

    Note IP address of NIC used by destination DCs.

    REPADMIN /SHOWREPS |MORE

    Note value of “DSA Object GUID” which denotes the object GUID for the source DC’s NTDS Settings Object in the source DC’s copy of Active Directory.

    From the console of the destination DC:

    Command Comment

    IPCONFIG /ALL |MORE

    Note the primary, secondary and any tertiary DNS Servers configured that the destination DC could query during DNS lookups.

    REPADMIN /SHOWREPS |MORE

    In the “Inbound Neighbors” section of the repadmin output, locate the replication status where the destination DC replicates a common partition from the source DC in question.

    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.

    IPCONFIG /FLUSHDNS

    Clear the DNS Client cache.

    Start ->Run -> Notepad %systemroot%\system32\drivers\etc\hosts

    Check for host to IP mappings referencing the source DCs single label or fully qualified DNS name. Remove if present. Save changes to HOST file.

    Run “Nbtstat –R” (upper case “R”) to refresh the NetBIOS name cache.

    NSLOOKUP –type=CNAME <object guid of source DCs NTDS Settings object>._msdcs.<forest root DNS name> <primary DNS Server IP

    Repeat for each additional DNS Server IP configured on the destination DC.

    example:

    c:\>nslookup -type=cname 8a7baee5-cd81-4c8c-9c0f-b10030574016._msdcs.contoso.com 152.45.42.103

    Verify that IP returned matches the IP address of target DC listed above recorded from the console of the source DC.

    Repeat for all DNS Servers IPs configured on destination DC.

    nslookup -type=A+AAAA <FQDN of source DC> <DNS Server IP>

    Check for duplicate host "A" records on all DNS Server IPs configured on the destination DC.

    nbtstat -A <IP address of DNS Server IP returned by nslookup>

    Should return name of the source DC.

    Note: A replication request directed to a non-DC (due to a bad name-to-IP mapping) or a DC that does not currently have the E351... service UUID registered with the endpoint mapper will return error 1753: there are no more endpoints available with the endpoint mapper.

  3. The Kerberos target cannot decrypt Kerberos authenticated data due to a password mismatch

    This condition can occur if the password for the source DC differs between the KDC and source DC’s copy of Active Directory. The destination DC’s copy of the source DC computer account password may be stale if it is not using itself as the KDC.

    Replication failures can prevent DCs from having a current password values for DCs in a given domain.

    Every domain controller runs the KDC service for their domain realm. For same realm transactions, a destination DC favors getting Kerberos tickets from itself but may obtain a ticket from a remote DC. Referrals are used to obtain Kerberos tickets from other realms.

    To quickly identify which KDC a Kerberos client is targeting, open an elevated command prompt and run the following command near to when the SEC_E_WRONG_PRINCIPAL error appears.

    NLTEST /DSGETDC:<DNS domain of target domain> /kdc

    The definitive way to determine which DC a Kerberos client obtained a ticket from is to take a network trace. The lack of Kerberos traffic in a network trace may indicate that the Kerberos client has already acquired tickets, is getting tickets off-the-wire from itself or your network trace application is not properly parsing Kerberos traffic.

    Kerberos tickets for the logged on user account can be purged from an admin privileged CMD prompt using "KLIST purge".

    Kerberos tickets for the system account used by Active Directory replication can be purged without a reboot using "KLIST -li 0x3e7 purge".

    DCs can be made to use other DCs by stopping the KDC service on a local or remote DC.

    Use REPADIN /SHOWOBJMETA to check for obvious version number differences in password-related attributes (dBCSPwd, UnicodePWD, NtPwdHistory, PwdLastSet, lmPwdHistory) for the source DC and destination DC’s copy of Active Directory

    C:\>repadmin /showobjmeta <source DC> <DN path of source DC computer account>

C:\>repadmin /showobjmeta <KDC selected by destination DC> <DN path of source DC computer account>

    To reset DC machine account passwords, run the following command at an elevated command prompt:

    netdom resetpwd /server:<DC to direct password change to> /userd:<user name> /passwordd:<password>

More Information

Repro steps for bad host to IP mapping causing destination DC to pull from wrong source

  1. Promote \\dc1 + \\DC2 + \\DC3 in contoso.com domain. End-to-end replication occurs without error.

  2. Stop the KDC on \\DC1 and \\DC2 to force off-box Kerberos traffic that can be observed in network trace. End-to-end replication occurs without error.

  3. Create Host file entry for \\DC2 pointing to IP address of a DC in a remote forest simulating a bad host to IP mapping in a host "A" / "AAAA" record or perhaps a stale NTDS Settings object in the destination DC’s copy of Active Directory.

  4. Start Active Directory Sites and Services on the console of \\DC1. Right-click \\DC1's inbound connection object from \\DC2 and note replication error "the target account name is incorrect.”

Repro steps for source DC password mismatch between KDC and source DC

  1. Promote \\dc1 + \\DC2 + \\DC3 in contoso.com domain. End-to-end replication occurs without error.

  2. Stop the KDC on \\DC1 and \\DC2 to force off-box Kerberos traffic that can be observed in network trace. End-to-end replication occurs without error.

  3. Disabling inbound replication on KDC \\DC3 simulating a replication failure on the KDC.

  4. Reset the computer account password on \\DC2 three or more times such that \\DC1 and \\DC2 have DC2 current password.

  5. Start Active Directory Sites and Services on the console of \\DC1. Right click \\DC1's inbound connection object from \\DC2 and note replication error "the target account name is incorrect."

DS RPC client logging

Set NTDS\Diagnostics Loggings\DS RPC Client = 3. Trigger replication. Look for Task Category Event 1962 + 1963. Note the fully qualified cname cited in the "directory service" field. Destination DC should be able to ping this record and have the returned address map to the current IP address of the source DC.

Kerberos Workflow

Workflow

  1. Client Computer calls IntializeSecurityContext and specifies the Negotiate security support provider (SSP).

  2. The client contacts the KDC with its TGT and requests a TGS Ticket for the target DC.

  3. The KDC searches the Global Catalog for a source (either e351 or hostname) in destination DCs realm.

  4. If the target DC is in the destination DCs realm, the KDC hands the client a service ticket.

  5. If the target DC is in a different realm, the KDC hands the client a referral ticket.

  6. The client contacts a KDC in the target DCs domain requesting a service ticket.

  7. If the source DC’s SPN does not exist in the realm, you get an error.

  8. The destination DC contacts the target and presents its ticket.

  9. If the target DC owns the name in the ticket and can decrypt it, the authentication works.

  10. If the target DC hosts the RPC server service UUID, then the on-wire Kerberos error "KRB_AP_ERR_NOT_US or KRB_AP_ERR_MODIFIED gets remapped to -2146893022 decimal / 0x80090322 / SEC_E_WRONG_PRINCIPAL / "The target principal name is incorrect."

See the Troubleshooting Kerberos Errors white paper for additional information

See Also

Other Resources

Troubleshooting Active Directory operations that fail with error -2146893022: The target principal name is incorrect.
How the Active Directory Replication Model Works
repsFrom, RepsFrom