Replikationsfehler zwischen den DCs

[RalphT 15]

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?

 

[RalphT 15]

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.

 

[v-rtc 88]

Vielleicht hilfreich? -> 

 

Waren die eine Zeitlang getrennt/Offline?

bearbeitet 15. Januar 2019 von RolfW

[RalphT 15]

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 15. Januar 2019 von RalphT

[RalphT 15]

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.

 

 

[NilsK 2.930]

Moin,

 

Lass die Replikation in Ruhe. Die berechnet das AD selbst. Wenn es die nötigen Informationen dazu hat, klappt zuverlässig. Dass ab vier DCs nicht jeder mit jedem repliziert, ist normal.

 

Gruß, Nils

[RalphT 15]

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.

 

[NilsK 2.930]

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 15. Januar 2019 von NilsK

[RalphT 15]

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?

 

 

[NilsK 2.930]

Moin,

 

nein, das sind unterschiedliche Dinge. Das krbtgt-Kennwort ändert man nur manuell, die Computerkennwörter handeln die Rechner regelmäßig mit dem AD aus.

 

Gruß, Nils

 

[daabm 1.348]

Lies mal das hier: How the Kerberos Version 5 Authenticati…

Beste Einführung in Kerberos, die ich kenne... Wenn das krbtgt-Kennwort auf den Domain Controllern out of sync ist, hast das o.a. Problem.

[v-rtc 88]

Zudem sollte man es regelmäßig  (genaue Zeit muss ich nachschaue) ändern. Meine erst nach dem 3-4 mal ist es aus der Historie raus und kann so nicht missbraucht werden.

 

Als Passwort kannst Du irgendwas nehmen, da der DC das sowieso nicht übernimmt.

bearbeitet 18. Januar 2019 von RolfW

[NilsK 2.930]

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

 

[v-rtc 88]

Danke Nils.

Wie meinst Du obsolet? 

[NilsK 2.930]

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 18. Januar 2019 von NilsK