Jump to content

Replikationsfehler zwischen den DCs


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Moin,

ich habe auf zwei DCs die folgende Fehlermeldung:

Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "server-DC-2$" empfangen. Der verwendete Zielname war SERVER-DC-2$. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte.

In der Hauptstelle stehen 2DCs, in der Nebenstelle stehen auch zwei DCs.
Zwischen den beiden zusammenstehenden DCs scheint die Replikation wohl zu stimmen. Zwischen der Haupstelle und Nebenstelle besteht das Problem.

Wenn ich jetzt eine Verbindung von der Nebenstelle zu einem der beiden DCs in Hauptstelle einrichte dann bekomme ich diese Fehlermeldung. Diese sind dann nur den beiden DCs der Nebenstelle.
Auch ein REPADMIN /SHOWREPL zeigt auf den beiden besagten DCs Fehler.

Hier scheint mit den SPS etwas nicht zu stimmen. Nur hier komme ich derzeit nicht weiter.
Wer hat eine Idee, wo ich nachsehen sollte?

 

Link zu diesem Kommentar

Hier noch ein paar Ausgaben, die ich gerade erstellt habe.

Server-DC-1 und Serer-DC-2 stehen in der Haupstelle und die anderen beiden Server-DC-3 und 4 in der Nebenstelle.

Ausgabe repadmin /replmon auf Nebenstelle DC-3:

 


==== EINGEHENDE NACHBARN=====================================


DC=ForestDnsZones,DC=SUB,DC=FIRMA,DC=DE

    Sande\SERVER-DC-4 über RPC

        DSA-Objekt-GUID: c24f5916-0819-463c-9a67-3cdb9bbefa72

        Letzter Versuch am 2019-01-15 13:56:58 war erfolgreich.

 

Quelle: SUB\SERVER-DC-2

******* 5 AUFEINANDERFOLGENDE FEHLER seit 2019-01-15 13:11:03

Letzter Fehler: -2146893022 (0x80090322):

            Der Zielprinzipalname ist falsch.

 

Namenskontext: DC=ForestDnsZones,DC=SUB,DC=FIRMA,DC=DE

Quelle: Sub\SERVER-DC-2

******* WARNUNG: KCC konnte diese REPLIKATVERKNPÜFUNG aufgrund eines Fehlers nicht hinzufügen.

 


Ausgabe repadmin /replmon auf Nebenstelle DC-4:

DC=SUB,DC=FIRMA,DC=DE

    Sande\SERVER-DC-3 über RPC

        DSA-Objekt-GUID: 2b58a3ff-cae0-49b6-99ec-234893fb7905

        Letzter Versuch am 2019-01-15 14:21:51 war erfolgreich

 

 

Ausgabe repadmin /replmon auf Hauptstelle DC-2:

 

DC=ForestDnsZones,DC=SUB,DC=FIRMA,DC=DE

    SUB\SERVER-DC-1 über RPC

        DSA-Objekt-GUID: c450d19c-1343-4e32-a8d5-e5ce37d4d636

        Letzter Versuch am 2019-01-15 13:58:33 war erfolgreich.

    Sande\SERVER-DC-3 über RPC

        DSA-Objekt-GUID: 2b58a3ff-cae0-49b6-99ec-234893fb7905

        Letzter Versuch am 2019-01-15 14:13:34 war erfolgreich.

 

Link zu diesem Kommentar

Was bedeutet Zeitlang? DC-1 und DC-2 waren ca. 5 Std. offline. Die anderen beiden DCs in der Nebenstellen waren jedoch immer an.

 

Nachtrag:

 

In der Zeit, wo die beiden DCs aus waren, habe ich in beiden Geräten eine neue Netzwerkkarte eingebaut. Nach dem Hochfahren des DC-1 fiel mir sofort auf, dass bei beiden die Windowsaktivierung futsch war. Das muss jetzt nicht unbedingt mit diesem Fehler zusammenhängen, nur ich vermute es schon fast.

Siehe auch hier:

 

bearbeitet von RalphT
Link zu diesem Kommentar

So, jetzt bin ich weiter.

 

Wie es aussieht funktioniert das wieder. Die große Hilfe kam von hier:

https://blogs.technet.microsoft.com/deds/2009/04/02/fehlerbehebung-zu-replikationsfehler-mit-the-target-principal-name-is-incorrect-unter-windows-server-2008/

 

In dem o.g. Beispiel ging es um 2 DCs. Ich habe dann von allen Vieren mir die Metadaten anzeigen lassen. Dort habe ich dann gesehen, dass die Kerberos-Passwörter von der Außenstelle deutlich älter, als die beiden in der Haupstelle waren.

Anschließend habe ich dann auf den beiden DCs von der Außenstelle, das o.g. Verfahren durchgeführt.

Nach einer Minute lief wieder alles.

 

Eine Kontrolle mit repadmin /showrepl zeigt bei allen DCs keine Fehler.

 

Meistens ist es ja so, wenn man vorher irgandwo etwas herumgeschraubt hatte, dass auf diese Sache sofort der Verdacht fällt. Ist ja meistens auch richtig, nur nicht in diesem Fall.

Hier war wohl die Offlinezeit der beiden DCs einfach zu hoch.

 

Noch eine abschließende Frage:

 

Bei der Kontrolle der NTDS-Settings ist mir bei dem DC-Paar in der Haupstelle aufgefallen, dass bei einem Server (DC-1) keine automatisch generierte Verbindung besteht. Auf dem anderen Server (DC-2) ist eine automatische Verbindung zum DC-1 vorhanden.

Wird das irgendwann noch wieder automatisch erstellt? Ich wollte das jetzt nicht manuell hinzufügen.

 

 

Link zu diesem Kommentar
vor 6 Minuten schrieb NilsK:

Lass die Replikation in Ruhe

Hab ich auch. Ich habe gerade mal nachgesehen. Jetzt ist dort auch ein Eintrag. Sieht gut aus.

 

Eine Frage noch:

 

Wie lange könnte man eine Seite komplett down lassen? Ich habe in den Metadaten gesehen, dass eine Aktualisierung des Kerebos-Passworts wohl alle 5 Min. durchgeführt wird.

 

Link zu diesem Kommentar

Moin,

 

ein DC darf maximal  so lange offline sein, bis die Tombstone Lifetime erreicht wird. Das sind entweder 60 oder 180 Tage.

 

Ich weiß nicht, von was für einem Kerberos-Passwort du sprichst. Vielleicht ein Missverständnis? Kerberos akzeptiert keine Zeitabweichung zwischen DC und Client von mehr als 5 Minuten. Das hat mit deinem Problem aber nichts zu tun.

 

Bei dem Phänomen, das anscheinend bei dir vorlag, geht es um das Computerkennwort des DCs. Wie es zu der Versionsabweichung kommt, kann ich grad nicht aus dem Kopf sagen, aber es ist ein eher unübliches Phänomen. Kann es sein, dass die Verbindung zwischen den Standorten nicht ausreichend zuverlässig ist?

 

Gruß, Nils

 

bearbeitet von NilsK
Link zu diesem Kommentar
vor 12 Stunden schrieb NilsK:

ch weiß nicht, von was für einem Kerberos-Passwort du sprichst. Vielleicht ein Missverständnis?

Hm, da bin ich mir selber nicht so sicher.

Ich habe gerade etwas tiefer den "Bauchschußthread" gesehen. Hier war wohl das gleiche Problem.

 

Hier noch mal das Zitat daraus:

Bauchschuß: krbtgt-Kennwort nicht mehr synchron... Lösung: kdc auf allen DCs außer dem PDC deaktivieren, dann alle außer dem PDC neu booten.

 

Ist das krbtgt-Kennwort das Gleiche, wie das Computertkennwort? Oder besser gesagt, redet man hier von der gleichen Sache?

 

 

Link zu diesem Kommentar

Moin,

 

einen festen Turnus gibt es dafür nicht. Der ist auch obsolet. Sollte jemand das ausgespäht haben, dann muss man es sofort ändern. Das grundsätzliche Dilemma.

 

Die Änderung muss zweimal erfolgen, weil das Vorgängerkennwort ebenfalls noch gültig ist. Das ist Absicht, damit auch in komplex replizierten Umgebungen die Kommunikation sichergestellt ist. Erster Wechsel - Warten (maximale Replikationszeit der Umgebung plus Puffer) - zweite Änderung.

 

Gruß, Nils

 

Link zu diesem Kommentar

Moin,

 

ein Turnus zum Kennwortwechsel ist ein komplett falscher Ansatz. Die Erkenntnis hat sich nur noch nicht überall durchgesetzt.

 

Entweder ist ein Kennwort "sicher" bzw. stark, dann muss man es nie wechseln. Oder es ist schwach, dann bringt aber auch ein turnusmäßiger Wechsel nichts. Ein Kennwort muss man dann wechseln, wenn es kompromittiert wurde (bzw. der Verdacht besteht) - und nicht ein paar Wochen danach zum festgelegten Termin. Regelmäßige Kennwortwechsel verringern in der Praxis die Kennwortsicherheit, weil 100 Prozent der Anwender dann simple Mechanismen verwenden (hochzählen, Zahl des Monats usw.), die das Kennwort leicht vorhersagbar machen.

 

Das krbtgt-Kennwort wird nicht vom Admin gesetzt (auch wenn das so aussieht), sondern vom System (= egal, was der Admin einträgt, das System generiert ein Kennwort, das es nirgends anzeigt). Das ist von einer Qualität, die als "sicher" gelten kann. Hier gilt das Gesagte: Es hat keinen Sinn, das regelmäßig zu wechseln. Die Kunst bestünde darin, eine mögliche Kompromittierung aufzudecken - da das faktisch unmöglich ist, muss man die verhindern. Ein Angreifer, der das Kennwort einmal kompromittiert hat, ist aber kaum aus dem System zu werfen, weil er dann eine ganze Reihe von Möglichkeiten hat, sich festzusetzen und einen erfolgreichen Angriff auf das neue Kennwort auszuführen. Wer sich näher dafür interessiert, nimmt sich ein paar Tage Zeit und sucht nach "Golden Ticket" und "Silver Ticket".

 

Gruß, Nils

 

bearbeitet von NilsK
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...