locked
Replication Error "The target principal name is incorrect." RRS feed

  • Question

  • Hi,

    I manually decommissioned a DC from our domain using the valuable info over at petri and I promoted another server, using the same name as the decommissioned one (DC2).

    However, I am getting an error on DC1:

    The attempt to establish a replication link for the following writable directory partition failed.
     
    Directory partition:
    CN=Schema,CN=Configuration,DC=crsm,DC=ad
    Source directory service:
    CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=crsm,DC=ad
    Source directory service address:
    b8356a3f-c611-40ee-b818-863d043a7dcf._msdcs.crsm.ad
    Intersite transport (if any):
     
     
    This directory service will be unable to replicate with the source directory service until this problem is corrected.
     
    User Action
    Verify if the source directory service is accessible or network connectivity is available.
     
    Additional Data
    Error value:
    2148074274 The target principal name is incorrect.

    When I try to access DC2 from DC1 I get a "Logon Failure: target account name is incorrect". Connecting from any other client to DC1 and DC2 works with no problem and also accessing DC1 from DC2 works.

    L.E: It seems that changes are replicating correctly from DC1 to DC2 but they aren't from DC2 to DC1.

    Any suggestions?

    Victor Constantinescu - MVP Security, MCTS
    Thursday, March 19, 2009 12:44 PM

Answers

  • Hi Victor

    A couple of things to check.

    1.  Run repadmin /showreps on DC1 and look for errors in the output (post the output here).
    2.  Check to see whether the DNS alias for the NTDS Settings object (b8356a3f-c611-40ee-b818-863d043a7dcf._msdcs.crsm.ad) exists.  I suspect it might refer to the old DC2.  To check the current value for DC2, go to Sites and Services and look for the NTDS Settings object underneath DC2 in the appropriate site.  Open up the properties and the DNS Alias will appear on the General tab.
    3.  If the DNS alias refers to the old DC2 object, check DNS to see what CNAME values exist within _msdcs.crsm.ad.  Manually remove the old entry if it exists.
    4.  Stop and start netlogon on the new DC2.  This should force publication of the correct DNS records.
    5.  Look for any manually created connection objects underneath the NTDS settings object for DC1 in Sites and Services.  Remove them and then cycle the KCC using repadmin /kcc
    6.  Run repadmin /replsum to confirm that replication is now working as expected.

    Tony
    • Marked as answer by YounGun Tuesday, March 24, 2009 8:31 AM
    • Unmarked as answer by YounGun Tuesday, March 24, 2009 8:31 AM
    • Marked as answer by YounGun Tuesday, March 24, 2009 8:32 AM
    Friday, March 20, 2009 12:24 AM
  • Hi,

    Additional to Tony’s suggestions.

    This issue may also be caused by corrupt Secure channel. Please try the following steps to reset Secure channel.

    1.    Stopped KDC service and set that to manual.
    2.    Ran resetpwd /server:SERVER’s IP /userd:USER  /passwordd:*
    3.    Start KDC service to test.

    If the issue persists, it’s suggested to collect MPS Report for research.

    A.    Download MPS Reporting Tool (MPSRPT_PFE.EXE) from the following link:
    (http://www.microsoft.com/downloads/details.aspx?FamilyID=00ad0eac-720f-4441-9ef6-ea9f657b5c2f&DisplayLang=en)

    Please note: The link may be truncated when you read the E-mail. Be sure to include all text between '(' and ')' when navigating to the download location.

    B . Right click MPSRPT_PFE.EXE and select Run as Administrator to run this tool, and you will see a Command Window start up.

    C . Please type Y with the message of <Include the MSINFO32 report? (defaults to Y in 15 seconds)[Y,N]?

    D . When the tool is done you will see an Explorer Window opening up the %systemroot%\MPSReports\Setup\Reports\cab folder and containing a <Computername>MPSReports.cab file. After collecting, please use Windows Live SkyDrive (http://www.skydrive.live.com/) to upload the file and then give me the download address.

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by YounGun Tuesday, March 24, 2009 8:32 AM
    Friday, March 20, 2009 9:43 AM
  • Hi,

     

    It looks like a Kerberos issue. Before you ran the command netdom resetpwd, had you restarted the domain controller? If not, please perform the steps in the following KB article and check the result:

     

    288167          Error Message "Target Principal Name is Incorrect" When Manually Replicating Data Between Domain Controllers

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;288167

     

    Thanks. I look forward to your response.

    • Marked as answer by YounGun Tuesday, March 24, 2009 8:32 AM
    Monday, March 23, 2009 7:13 AM

All replies

  • Hi Victor

    A couple of things to check.

    1.  Run repadmin /showreps on DC1 and look for errors in the output (post the output here).
    2.  Check to see whether the DNS alias for the NTDS Settings object (b8356a3f-c611-40ee-b818-863d043a7dcf._msdcs.crsm.ad) exists.  I suspect it might refer to the old DC2.  To check the current value for DC2, go to Sites and Services and look for the NTDS Settings object underneath DC2 in the appropriate site.  Open up the properties and the DNS Alias will appear on the General tab.
    3.  If the DNS alias refers to the old DC2 object, check DNS to see what CNAME values exist within _msdcs.crsm.ad.  Manually remove the old entry if it exists.
    4.  Stop and start netlogon on the new DC2.  This should force publication of the correct DNS records.
    5.  Look for any manually created connection objects underneath the NTDS settings object for DC1 in Sites and Services.  Remove them and then cycle the KCC using repadmin /kcc
    6.  Run repadmin /replsum to confirm that replication is now working as expected.

    Tony
    • Marked as answer by YounGun Tuesday, March 24, 2009 8:31 AM
    • Unmarked as answer by YounGun Tuesday, March 24, 2009 8:31 AM
    • Marked as answer by YounGun Tuesday, March 24, 2009 8:32 AM
    Friday, March 20, 2009 12:24 AM
  • Hi,

    Additional to Tony’s suggestions.

    This issue may also be caused by corrupt Secure channel. Please try the following steps to reset Secure channel.

    1.    Stopped KDC service and set that to manual.
    2.    Ran resetpwd /server:SERVER’s IP /userd:USER  /passwordd:*
    3.    Start KDC service to test.

    If the issue persists, it’s suggested to collect MPS Report for research.

    A.    Download MPS Reporting Tool (MPSRPT_PFE.EXE) from the following link:
    (http://www.microsoft.com/downloads/details.aspx?FamilyID=00ad0eac-720f-4441-9ef6-ea9f657b5c2f&DisplayLang=en)

    Please note: The link may be truncated when you read the E-mail. Be sure to include all text between '(' and ')' when navigating to the download location.

    B . Right click MPSRPT_PFE.EXE and select Run as Administrator to run this tool, and you will see a Command Window start up.

    C . Please type Y with the message of <Include the MSINFO32 report? (defaults to Y in 15 seconds)[Y,N]?

    D . When the tool is done you will see an Explorer Window opening up the %systemroot%\MPSReports\Setup\Reports\cab folder and containing a <Computername>MPSReports.cab file. After collecting, please use Windows Live SkyDrive (http://www.skydrive.live.com/) to upload the file and then give me the download address.

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by YounGun Tuesday, March 24, 2009 8:32 AM
    Friday, March 20, 2009 9:43 AM
  • Hi,

    Thank you for the replies Tony and Mervyn.

    I deleted all remnants (I hope) in DNS of the old DC2 prior to promoting the new machine. I checked high and low and everything seems to point to  b8356a3f-c611-40ee-b818-863d043a7dcf._msdcs.crsm.ad.

    I tried also resetting the secure channel for DC2 using the netdom resetpwd as indicated, but no luck.

    And just to clear any firewall problems or conflicts, I tried accessing DC2 using its IP and it works, so its accessible. After I reset the pass I got 2 new errors in the System event Log on DC1:

    The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was cifs/DC2.crsm.ad. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. 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. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (CRSM.AD) is different from the client domain (CRSM.AD), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

    The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server dc1$. The target name used was E3514235-4B06-11D1-AB04-00C04FC2DCD2/b8356a3f-c611-40ee-b818-863d043a7dcf/crsm.ad@crsm.ad. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. 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. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (CRSM.AD) is different from the client domain (CRSM.AD), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.



    Victor Constantinescu - MVP Security, MCTS
    Saturday, March 21, 2009 9:15 AM
  • Here is the /showreps output ran from DC1:

    Default-First-Site-Name\DC1

    DSA Options: IS_GC

    Site Options: (none)

    DSA object GUID: 79291cd3-0c8e-4234-a1dd-845083cf6be0

    DSA invocationID: 79291cd3-0c8e-4234-a1dd-845083cf6be0





    Source: Default-First-Site-Name\DC2

    ******* 179 CONSECUTIVE FAILURES since 2009-03-19 14:09:04

    Last error: -2146893022 (0x80090322):

                The target principal name is incorrect.



    Naming Context: CN=Configuration,DC=crsm,DC=ad

    Source: Default-First-Site-Name\DC2

    ******* WARNING: KCC could not add this REPLICA LINK due to error.



    Naming Context: CN=Schema,CN=Configuration,DC=crsm,DC=ad

    Source: Default-First-Site-Name\DC2

    ******* WARNING: KCC could not add this REPLICA LINK due to error.



    Naming Context: DC=crsm,DC=ad

    Source: Default-First-Site-Name\DC2

    ******* WARNING: KCC could not add this REPLICA LINK due to error.

    Victor Constantinescu - MVP Security, MCTS
    Saturday, March 21, 2009 9:19 AM
  •  Hi Victor

    Well, there's nothing obvious from the output of the repadmin /showreps other than the pointer to the password reset mentioned by Mervyn (and shown in KB288167).

    Some other thoughts:

    1.  Did the promotion of DC2 complete fully?  Check RootDSE for IsSynchronized=TRUE and whether SYSVOL appears as a share when you type "net share" at the command prompt.
    2.  Any further information when you run "dcdiag /q" on DC2?
    3.  Run dnslint using the command "dnslint /ad <IP_of_DC1> /s <IP_of_DC1>" and check for errors.
    4.  Check the DNS client settings on both DCs to make sure they point to a DNS server that contains the appropriate zone info.

    Generally, replacing a DC with the same name is relatively straightforward and presents no issues.  The only times I have seen issues are when lingering information about the old DC remains in AD or DNS.   Given the problems that you are having it might just be simpler and quicker to demote DC2 and start again.

    Tony
    Sunday, March 22, 2009 1:13 AM
  • Hi,

     

    It looks like a Kerberos issue. Before you ran the command netdom resetpwd, had you restarted the domain controller? If not, please perform the steps in the following KB article and check the result:

     

    288167          Error Message "Target Principal Name is Incorrect" When Manually Replicating Data Between Domain Controllers

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;288167

     

    Thanks. I look forward to your response.

    • Marked as answer by YounGun Tuesday, March 24, 2009 8:32 AM
    Monday, March 23, 2009 7:13 AM
  • Hi,
    Thanks for helping me thru this aggravating error guys. It's been a while since I posted for help on the forums but it sure is nice to know that you can always ask someone if you're in trouble! Joson, I replied to you after the DNSlint report.

    @Tony 1. Yes, Yes. Like I told you before, DC2 is getting replication data from DC1 (when I create a GPO or username on Dc1 it will replicate to DC2 at the replication interval)
    2. No, just the error about a printer driver which I have to uninstall.
    3. Here is the dnslint report ran from DC2: 

    DNSLint Report

    System Date: Mon Mar 23 09:08:27 2009

    Command run:

    dnslint /ad 192.168.1.3 /s 192.168.1.3

    Root of Active Directory Forest:

        crsm.ad

    Active Directory Forest Replication GUIDs Found:

    DC: DC1
    GUID: 79291cd3-0c8e-4234-a1dd-845083cf6be0

    DC: DC2
    GUID: b8356a3f-c611-40ee-b818-863d043a7dcf


    Total GUIDs found: 2

    The following 2 DNS servers were checked for records related to AD forest replication:

    DNS server: User Specified DNS Server
    IP Address: 192.168.1.3
    UDP port 53 responding to queries: YES
    TCP port 53 responding to queries: Not tested
    Answering authoritatively for domain: Unknown

    SOA record data from server:
    Authoritative name server: dc1.crsm.ad
    Hostmaster: hostmaster.crsm.ad
    Zone serial number: 94
    Zone expires in: 1.00 day(s)
    Refresh period: 900 seconds
    Retry delay: 600 seconds
    Default (minimum) TTL: 3600 seconds

    Additional authoritative (NS) records from server:
    dc1.crsm.ad Unknown

    Alias (CNAME) and glue (A) records for forest GUIDs from server:
    CNAME: 79291cd3-0c8e-4234-a1dd-845083cf6be0._msdcs.crsm.ad
    Alias: dc1.crsm.ad
    Glue: 192.168.1.3


    CNAME: b8356a3f-c611-40ee-b818-863d043a7dcf._msdcs.crsm.ad
    Alias: dc2.crsm.ad
    Glue: 192.168.1.4



    Total number of CNAME records found on this server: 2

    Total number of CNAME records missing on this server: 0

    Total number of glue (A) records this server could not find: 0


    DNS server: dc1.crsm.ad
    IP Address: 192.168.1.3
    UDP port 53 responding to queries: YES
    TCP port 53 responding to queries: Not tested
    Answering authoritatively for domain: YES

    SOA record data from server:
    Authoritative name server: dc1.crsm.ad
    Hostmaster: hostmaster.crsm.ad
    Zone serial number: 94
    Zone expires in: 1.00 day(s)
    Refresh period: 900 seconds
    Retry delay: 600 seconds
    Default (minimum) TTL: 3600 seconds

    Additional authoritative (NS) records from server:
    dc1.crsm.ad Unknown

    Alias (CNAME) and glue (A) records for forest GUIDs from server:
    CNAME: 79291cd3-0c8e-4234-a1dd-845083cf6be0._msdcs.crsm.ad
    Alias: dc1.crsm.ad
    Glue: 192.168.1.3


    CNAME: b8356a3f-c611-40ee-b818-863d043a7dcf._msdcs.crsm.ad
    Alias: dc2.crsm.ad
    Glue: 192.168.1.4



    Total number of CNAME records found on this server: 2

    Total number of CNAME records missing on this server: 0

    Total number of glue (A) records this server could not find: 0


    Victor Constantinescu - MVP Security, MCTS
    Monday, March 23, 2009 7:26 AM
  •  @Joson,
    It does sound indeed like a Kerberos problem.
    It seems I have misundersood the syntax of the resetpwd command, thanks for the link.
    On Dc2, I stopped the KDC service and set it to manual. Restarted DC2. At DC2 logon, DC1 has only succesfull audit and grants DC2 auth ticket and the service ticket.
    After the reboot, I ran the resetpwd command on DC2 as specified in the Kb and the command completed succesfully. Reboot DC2. Still no errors in the security log.
    Same error. Dc1 cannot connect to Dc2.

    I just discovered a warning on DC1 under DFS replication:

    The DFS Replication service has detected that no connections are configured for replication group Domain System Volume. No data is being replicated for this replication group.

    Additional Information:

    Replication Group ID: F34D79DE-6E64-4224-BD11-A8CE180F2451

    Member ID: 23DEB45F-2404-43E5-8D34-D3AD3B08E9F3


    Victor Constantinescu - MVP Security, MCTS
    Monday, March 23, 2009 8:00 AM
  • Hi guys,

    I decided to remove the DC2 and start over again (since today I had to activate it).
    What else do I need to do apart from the info in petri's article here? Any other places I need to search in or remove before promoting a new machine with the same name?
    Victor Constantinescu - MVP Security, MCTS
    Tuesday, March 24, 2009 8:09 AM
  •  

    Hi,

     

    Please refer to the following steps:

     

    1.    Demote the old domain controller.

    2.    Follow the steps in the KB article 216498.

    How to remove data in Active Directory after an unsuccessful domain controller demotion
    http://support.microsoft.com/?id=216498

    3.    Force replicate throughout the domain so all DC's in the parent recognize this change.

    4.    Promote new domain controller.

     

    Hope it helps.

    Wednesday, March 25, 2009 3:16 AM
  • Hi Victor

    I usually follow the steps below when replacing an existing DC with a new DC of the same name.

    1.  Demote the DC.  If it fails, clean up the metadata as per the KB article mentione by Joson.
    2.  Restart the server and remove it from the domain.
    3.  Remove the server object from AD sites and services.
    4.  Remove any lingering records in DNS.  Most are removed automatically, but typically the name server records remain for the AD integrated zone or zones.
    5.  Remove the computer object (if present) using dsa.msc.
    6.  Ensure the deletion is fully replicated throughout the forest before joining the new server.
    7.  Join the new server to the domain.
    8.  Run DCPROMO to promote it to a DC.
    9.  Make it a GC and DNS Server (if required).

    Tony
    Thursday, March 26, 2009 2:20 AM
  • Hi Tony and Team

     

    I'm also having similar problem with one of my clients in Central Africa

    I really needed my work around: what i have done i have demoted the server (DC1) from being an AD

    bad news is that i cannot totally remove it from domain as the box also work as file server, which the guys cannot move the data there

    what i have done:

    1. demoted the dc

    2. does not apprear on domain controllers ou

    3. did ntdsutil metadata cleanup,

    removed it on sites and services

    Unfortunately i still receive same error "target principal name incorrect" when doing replication summary

    below is the summary for assistance guys, i ca also post dcdiag when needed

    C:\Documents and Settings\ait>repadmin /replsum
    Replication Summary Start Time: 2010-08-11 06:57:46

    Destination DC    largest delta    fails/total  %%  error
     TDA-PDI-DC1               08m:01s    0 /   5    0
    Assertion  TDAN-CUC-DC1      26d.09h:04m:32s   10 /  15   66  (2148074274) The target principal name is incorrect.
     TDAN-CUC-MAIL1    26d.08h:59m:05s   10 /  10  100  (2148074274) The target principal name is incorrect.
     TDAN-LOB-DC1      05d.13h:35m:53s    5 /  25   20  (2148074274) The target principal name is incorrect.
     TDAN-LOB-MAIL1    05d.13h:36m:14s    3 /  10   30  (2148074274) The target principal name is incorrect.
     TDAN-MUT-DC1      26d.09h:01m:03s   23 /  23  100  (2148074274) The target principal name is incorrect.
     TDAN-MUT-MAIL1   >60 days            9 /  12   75  (8524) The DSA operation is unable to proceed because of a DNS l...
     TDAN-SSS-FP               04m:42s    0 /  20    0

    Regards,,shakoanem

     

     

    Wednesday, August 11, 2010 6:07 AM
  • I just have restarted KDC, my problem is solved. 

    Thanks,


    das
    Saturday, August 27, 2011 8:20 AM
  • ^ haha I read this whole article. Came to this very last item, figured it was the easiest please to start. And it worked! Thank you!
    Wednesday, September 17, 2014 4:10 PM
  • THANK YOU!!!!!!  All the troubleshooting and all it needed was a password reset.  I had seen that same DC a few weeks back giving the error message about the workstation account not being in the database but I fixed some network and sites and services issues and it seemed to be replicating fine.  Then the error changed to the on mentioned here and all I needed to do was reset the computer account password.  Again, thanks!

    Thank you, MR

    Thursday, November 20, 2014 12:58 AM