Fehlerbehebung zu Replikationsfehler mit “The target principal name is incorrect” unter Windows Server 2008

Fehlerbehebung zu Replikationsfehler mit “The target principal name is incorrect” unter Windows Server 2008

  • Comments 5
  • Likes

Hallo, hier wieder einmal Rol mit einem Erfahrungsbericht. Zurück aus dem Urlaub habe ich nach der Wiederinbetriebnahme meine virtuellen Windows Server 2008 Domäne feststellen müssen, daß die AD Replikation nicht mehr funktioniert. DC RW08DC1 repliziert zwar problemlos von RW08DC2, umgekehrt aber nicht mehr.

REPADMIN /SHOWREPL zeigt dazu folgenden Fehler auf RW08DC2:

C:\Users\Administrator>repadmin /showrepl rw08dc2
Hub2\RW08DC2
DSA Options: (none)
Site Options: (none)
DSA object GUID: 500ac16c-8970-4b5f-8d15-f0f7c0ce219e
DSA invocationID: d2dcab05-f0e4-48fe-af8d-9c3913976b40

==== INBOUND NEIGHBORS ======================================

DC=RW08,DC=NET
    Hub1\RW08DC1 via RPC
        DSA object GUID: d0dab649-fe5b-4c50-9665-0a955b337c79
        Last attempt @ 2009-04-01 13:04:33 failed, result -2146893022 (0x80090322):
            The target principal name is incorrect.
        7 consecutive failure(s).
        Last success @ 2009-04-01 12:16:11.

Der Hintergrund für diesen Fehler wird klar, wenn man die Metadaten für das DC Konto RW08DC1 auf beiden DCs vergleicht.

Metadaten auf DC RW08DC1:

C:\Users\Administrator>repadmin /showmeta "cn=rw08dc1,ou=domain controllers,dc=rw08,dc=net" rw08dc1

Loc.USN                           Originating DSA  Org.USN  Org.Time/Date        Ver Attribute
=======                           =============== ========= =============        === =========
  12290                              Hub1\RW08DC1     12290 2008-09-04 16:50:28    1 objectClass
  12290                              Hub1\RW08DC1     12290 2008-09-04 16:50:28    1 cn
...
  61516                              Hub1\RW08DC1     61516 2009-04-01 11:30:08    8 dBCSPwd
  61516                              Hub1\RW08DC1     61516 2009-04-01 11:30:08    8 unicodePwd
  61516                              Hub1\RW08DC1     61516 2009-04-01 11:30:08    8 ntPwdHistory
  61516                              Hub1\RW08DC1     61516 2009-04-01 11:30:08    8 pwdLastSet

Metadaten auf DC RW08DC2:

C:\Users\Administrator>repadmin /showmeta "cn=rw08dc1,ou=domain controllers,dc=rw08,dc=net" rw08dc2

Loc.USN                           Originating DSA  Org.USN  Org.Time/Date        Ver Attribute
=======                           =============== ========= =============        === =========
   7629                              Hub1\RW08DC1     12290 2008-09-04 16:50:28    1 objectClass
   7629                              Hub2\RW08DC2      7629 2008-09-05 14:10:24    1 cn
...
  49154                              Hub1\RW08DC1     61452 2009-04-01 12:13:51    6 dBCSPwd
  49154                              Hub1\RW08DC1     61452 2009-04-01 12:13:51    6 unicodePwd
  49154                              Hub1\RW08DC1     61452 2009-04-01 12:13:51    6 ntPwdHistory
  49154                              Hub1\RW08DC1     61452 2009-04-01 12:13:51    6 pwdLastSet

Die Version das Passwortes für RW08DC1 ist in der Datenbank von DC RW08DC2 zwei Versionen älter als auf RW08DC1. Der DC RW08DC2 hat sich als KDC selbst ein Ticket für den Replikations-Zugriff auf RW08DC1 ausgestellt, allerdings mit einem bereits ungültigen Password (auch für die (n-1) Version). RW08DC1 lehnt den Zugriff ab, das erzeugt den Fehler “The target principal name is incorrect.”.

Die Lösung ist unter Windows 2008 ist nun wesentlich eleganter als noch unter Windows Server 2003 oder 2000. Wie zuvor muß man den DC RW08DC2 nur dazu bringen nicht sich selbst, sondern RW08DC1 als KDC zu verwenden. Hierbei kann man jetzt aber ein essentielles Windows Server 2008 Feature nutzen.

1) Dazu stoppt man auf RW08DC2 über den Server Manager oder Services.msc den KDC Dienst “Kerberos Key Distribution Center” und setzt den Startup Type auf Disabled.

2) Auf RW08DC2 startet man nun auch noch den NTDS Dienst “Active Directory Domain Services” neu.
Dies ist erst mit Windows Server 2008 möglich, dadurch werden die im Dienst Kontext gecachten Tickets beim Stoppen verworfen. Beim Start wird nun der KDC nicht mit gestartet (steht auf Disabled) und RW08DC1 als KDC verwendet. Jetzt stimmen auch wieder die entsprechenden Kerberos Tickets für die Replikation von RW08DC1.

3) Nach der erfolgreichen Replikation von RW08DC1 stellt man den Startup Type des KDC Dienst “Kerberos Key Distribution Center” auf Automatc und startet den Dienst. Damit hat man wieder den Normalzustand erreicht.

Unter Windows Server 2003 und 2000 war der Ticket Cache mit dem System Prozess LSASS.EXE verknüpft und daher ein kompletter Reboot notwendig, um das gleiche zu erreichen. Das neue Windows Server 2008 Feature des NTDS Dienstes verringert hier die Downtime für den DC also erheblich.

Damit frohes Schaffen und viele Grüße aus München, Rol

Comments
  • Hallo Rol,

    ich hätte da ein sehr kniffliges Problem mit zwei DCs, die Spinnen nur noch rum und wollen nimmer mit einander replizieren. Da ich jetzt nicht der absolute Active Directory Guru bin, steh ich gerade etwas auf dem Schlauch. Da Du aber anscheinend ein echter Fuchs auf dem Gebiet bist, würde ich mich sehr freuen wenn Du mir helfen könntest. E-Mail: XXX@XXX

    Gruß Mario

  • Hi Mario,

    vielen Dank für Dein Interesse an unserem Support. ;-)

    Wir können hier über den Blog als auch über E-Mails o.ä. keinen direkten Support leisten. Ich würde vorschlagen, je nach Dringlichkeit eine Anfrage bei uns zu öffnen - wenn es "nicht eilt", können alternativ auch die Microsoft Communities weiterhelfen, so etwa unsere Technet Foren: http://www.technet-foren.de .

    "Füchse" wie Rol kannst Du an den Apparat bekommen, wenn Du einen Premier Vertrag mit uns abschließt. Dann steht Dir dieser Service plus eine ganze Menge zusätzlicher Optionen zur Verfügung.

    Viele Grüße

    Fabian

  • Hallo Rol,

    bei uns sieht die Sache etwas anderes aus. Wir habe gleiches Problem mit Replikation und dem Fehler "The target principal name is incorrect. " Allerdings sind die Versionen von Passwörter gleich. Was aber nicht gleich ist, die Version von nTSecurityDescriptor. Bei einem DC ist die Version 2, bei anderem 3. Das ist das einzige was nicht identisch ist.

    Die vorgeschlagene Vorgehensweise hilft in dem Fall nicht.

    Was könnte man noch machen?

    Danke!

  • Hallo Kas Tigar, richtig falsche Permission können so nicht behoben werden. Man kann versuchen diese nach funktionierendem Vorbild zurückzusetzen, oder mittels DSACL /S zum Schema default. Vorher Backup nicht vergessen. Ansonsten ist das sicher ein Thema für eine gesonderte Untersuchen, sprich Support Case.

    Grüße, Roland

  • Exzellenter Blog Post. Das Problem trat heute bei einem Kunden auf und konnte exakt wie beschrieben gelöst werden.

    Vielen Dank!

    Sven

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment