Das Domänencontroller-Failover schlägt unidirektional fehl

Das Domänencontroller-Failover schlägt unidirektional fehl

Mein Problem besteht darin, dass, wenn ich einen meiner beiden beschreibbaren Domänencontroller offline nehme, scheinbar bei niemandem ein „Failover“ auf den anderen Domänencontroller durchführt, wie es vorgesehen ist. In unserem Netzwerk ausgeführte Anwendungen, die AD zur Authentifizierung verwenden, fragen ständig nach einem Benutzernamen und einem Kennwort, authentifizieren Sie jedoch nie wirklich. Und externe Benutzer, die auf einen schreibgeschützten Domänencontroller in einem anderen Netzwerksegment angewiesen sind, können sich auch nicht gegenüber unserer RAS-Website authentifizieren.

Ich habe derzeit drei Domänencontroller in meiner Domäne: DC1, DC2 und RO1. DC1 und RO1 sind Server 2019, DC2 ist Server 2012R2. Beide beschreibbaren DCs sind AD-integrierte DNS-Server, deren Netzwerkadapter so konfiguriert sind, dass sie aufeinander verweisen.

DC1 und DC2 befinden sich im selben Subnetz. RO1 ist ein Nur-Lese-Controller in einem anderen Netzwerksegment, um eine Remote-Zugriffslösung zu unterstützen, die von der Organisation über mir verwaltet wird (die das allgemeine Netzwerk verwaltet, mit dem ich verbunden bin).

Wenn ich in der Vergangenheit einen oder mehrere lokale DCs offline nahm, erfolgte für lokale Benutzer (wie erwartet) ein Failover auf den DC, der tatsächlich noch ausgeführt wurde. Das Gleiche galt für Remotebenutzer, da der RODC den aktiven DC zur Authentifizierung abruft.

Der aktuelle DC1 ist eine relativ neue Ergänzung und ersetzt einen DC. DC1 wurde online gebracht und mit DC und DC2 verbunden, und alles schien in Ordnung zu sein. Ich habe alle FSMO-Rollen, die DC hatte, auf seinen Ersatz DC1 übertragen – die Netdom-Abfrage FSMO zeigt alle Rollen als auf dem neuen DC1 befindlich an. Wir haben DC herabgestuft und offline genommen, um es außer Betrieb zu nehmen, da es sich um eine Server 2012-Maschine handelte und wir von dieser weg migrieren. Wir haben ein paar fehlerhafte DNS-Einträge bereinigt, die behaupteten, der alte DC sei noch da, aber ansonsten lief alles wie bisher. Im letzten Patchzyklus hatten wir DC2 jedoch offline, während DC1 und RO1 aktiv blieben, entdeckten aber die oben genannten authentifizierungsbezogenen Probleme. Externe Benutzer konnten sich überhaupt nicht authentifizieren, und Benutzer, die bereits angemeldet waren, wurden plötzlich von unseren AD-Authentifizierungsanwendungen aufgefordert, sich erneut anzumelden (ohne Erfolg).

Leider bin ich mir nicht sicher, warum das so ist. DC1, der neue Controller, wird definitiv von der Domäne erkannt. Die Replikation läuft einwandfrei – Repadmin /showrepl ist erfolgreich und /replsum meldet keine Fehler. Alle beteiligten internen Maschinen können ihre Hostnamen auflösen und sich gegenseitig anpingen. Wenn ich die Domäne anpinge, kann ich einen beschreibbaren DC erhalten, genauso, als ob ich zur Domäne tracert. Ich kann Änderungen an DC1 vornehmen und sie auf DC2 sehen und umgekehrt (und Änderungen wie Gruppenrichtlinien, die speziell an DC1 vorgenommen wurden, existieren definitiv im größeren Netzwerk). Ich kann den RODC nehmen und ihm sagen, dass er Datensätze von DC1 und DC2 ohne Probleme laden soll.

Wenn ich DC2 jedoch offline nehme, dann läuft alles schief. Ping oder Tracert zu unserer Domäne schlägt fehl, externen Benutzern wird der Zugriff verweigert und interne Benutzer sehen, dass unsere AD-authentifizierten Anwendungen fehlschlagen und ständig nach einem Benutzernamen und Passwort fragen. Das Gegenteil ist der Fall.nichtEs kann jedoch vorkommen, dass lokale Benutzer, wenn ich den neuen DC1 offline nehme, manchmal eine leichte Verzögerung feststellen, als ob ihre Maschine versucht hätte, Kontakt mit DC1 aufzunehmen, bevor ein Failover zu DC2 durchgeführt und die Authentifizierung erfolgreich abgeschlossen wurde. Externe Benutzer kommen problemlos rein.

In den Ereignisprotokollen ist nichts besonders Offensichtliches zu finden und alles, was mir einfällt, scheint richtig konfiguriert zu sein. Ich bin mir nicht sicher, wie es von hier aus weitergehen soll – hatte jemand ähnliche Symptome, die er beheben konnte?

Antwort1

Das Problem hing letztlich mit Firewall-Einstellungen zusammen, die ausschließlich von der Organisation verwaltet wurden, die das Netzwerk verwaltet, mit dem wir verbunden sind. Einige Regeln für eingehenden/ausgehenden Datenverkehr wurden nicht korrekt angewendet, was dazu führte, dass Hosts nicht korrekt auf den neuen Domänencontroller umschalten konnten, falls der alte offline ging.

verwandte Informationen