4
Replikation einer defekten AD auf 2. DC
Hallo,
wir haben von OS/2 auf Windows 2003 Serverumfeld umgestellt. Da wir noch Erfahrungen und Wissen hierzu sammeln, kommen immer wieder Fragen auf - vor allem von unserem Revisor für Datenschutz - auf die wir erstmal anhand der Dokumentation und Sekundärliteratur keine Antwort finden.
Hier ist nun das Thema Ausfallsicherheit der Domäne.
Wir setzen in unserem Netz ca. 40 Server ein, in einer Domäne. In der Domäne haben wir den DC und mehrere DCs als Backup.
Jetzt wurde darüber diskutiert, was passiert, wenn der Primary DC seine AD zerschiesst. Da er ja die AD mit den Backup-DCs repliziert, stellt sich hier die Frage, wie intelligent ist das Replikationsverfahren.
Erkennt es eine schadhafte AD? Wird immer die komplette AD repliziert, oder nur das Delta?
Wir wollen natürlich ausschliessen, dass eine defekte AD am Primary-DC uns die komplette Domäne abschiesst Ist nur die Frage, ist das mit den Boardmitteln von Win 2003 Standard gegeben?
Vielen Dank im voraus,
Markus Haupt
wir haben von OS/2 auf Windows 2003 Serverumfeld umgestellt. Da wir noch Erfahrungen und Wissen hierzu sammeln, kommen immer wieder Fragen auf - vor allem von unserem Revisor für Datenschutz - auf die wir erstmal anhand der Dokumentation und Sekundärliteratur keine Antwort finden.
Hier ist nun das Thema Ausfallsicherheit der Domäne.
Wir setzen in unserem Netz ca. 40 Server ein, in einer Domäne. In der Domäne haben wir den DC und mehrere DCs als Backup.
Jetzt wurde darüber diskutiert, was passiert, wenn der Primary DC seine AD zerschiesst. Da er ja die AD mit den Backup-DCs repliziert, stellt sich hier die Frage, wie intelligent ist das Replikationsverfahren.
Erkennt es eine schadhafte AD? Wird immer die komplette AD repliziert, oder nur das Delta?
Wir wollen natürlich ausschliessen, dass eine defekte AD am Primary-DC uns die komplette Domäne abschiesst Ist nur die Frage, ist das mit den Boardmitteln von Win 2003 Standard gegeben?
Vielen Dank im voraus,
Markus Haupt
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 57886
Url: https://administrator.de/forum/replikation-einer-defekten-ad-auf-2-dc-57886.html
Ausgedruckt am: 22.12.2024 um 13:12 Uhr
4 Kommentare
Neuester Kommentar
Hallo Markus,
nun zum Thema Ausfallsicherheit Active Directory würde ich grundsätzlich mein primäres Augenmerk auf die Sicherung und Wiederherstellung des Active Directory richten da ein "zerschießen der Datenbank" im Normalbetrieb mehr als unwahrscheinlich ist.
Grundsätzliches zum Einstieg:
Das AD arbeitet nicht wie NT mit einer Single-Master sondern mit einer Multi-Master Replikation d.h. jeder Server der zum AD hochgestuft wurde hält eine Schreibbare kopie der Datenbank und repliziert änderungen an alle seine kollegen.
Ab Domänenfunktionsebene 2000 replizieren die Server nur änderungen - ab 2003 kamen nochmals verbesserungen in bezug auf Replikation des Globalen Katalogs.
Die Replikationsverbindungen werden automatisch generiert und müssen normalerweise nicht angepasst werden.
Die wahrscheinlichkeit dass eine Domänenauthentifizierung aufgrund einer "zerschossen" (es gibt eigentlich im normalen betrieb nur eine möglichkeit das das passiert: Sabotage mit Schema-Admin Rechten! (das AD von Server 2003 enthält x features die in kombination mit dem File Replication Service genau das verhindern sollen und können...)
Auch gibt es mechanismen die bei der replikation die itegrität der AD-Datenbank sicherstellen.
D.h. man sollte sich in erster Linie gedanken um den Restore von irrtümlicherweise gelöschten Objekten machen.
Fällt ein normaler DC (keine FSMO Rollen) aus irgendeinem Grund aus so ist es das allereinfachste einen neuen Server 2003 zum DC heraufzustufen und den alten nie wieder in Betrieb zu nehmen. Der neue Repliziert dann mit den noch vorhandenen Servern und alles ist wieder ok.
Fällt ein "primärer DC" (so bezeichne ich jetzt mal den / die Server der in deiner Domäne die FSMO Rollen hält) aus so muss zusätzlich auch noch die entsprechende Rolle (RID-master, infrastruktur master, pdc-emulator - in jeder einzelnen domäne der gesamtstruktur bzw schemamaster, domänennamensmaster nur einmal pro Domain tree) auf einen anderen DC übertragen werden. Das geht in den meisten fällen über die AD Gui tools.
In harten fällen ist das kommandozeilentool fsutil in der lage das verschieben einer rolle zu erzwingen und unabhängig von der funktionsfähigkeit des alten "Role-holders" die rolle einem noch funktionstüchtigen DC zuzuweisen. (Achtung - den alten nach so einer aktion nie wieder starten sonst krachts).
Dies bezeichnet man als non Authoritative Restore.
Werden mehrere Objekte aus dem AD mit entsprechender berechtigung fälschlicherweise gelöscht so ist (von einigen tools die über tombstone lifetime arbeiten und meist käuflich erworben werden müssen einmal abgesehen) meist ein sogenannter authoritative restore nötig der ebenfalls über das Tool fsutil möglich ist.
Dazu wird ein DC im "AD Repair mode" gebootet und eine Sicherung der Datenbank wieder eingespielt. Da nach dem neustart aber der zeitstempel der rücksicherung sofort dazu führen würde das die objekte wieder gelöscht werden werden die RID der objekte um 100000 nach oben gesetzt was dazu führt das die objekte nach einem normalen Start des DC wieder mit den Anderen repliziert werden.
ACHTUNG: Für die Sicherung würde ich das Win-Backupprogramm empfehlen. Es muss eine Systemstate sicherung gemacht werden. Es reicht nicht die datenbankdatei zu sichern!!!
Noch ein wichtiger hinweis: niemals ein image von dc's machen! Das wird in keinem fall ein brauchbares ergebnis bei einer rücksicherung liefern - führt nur zu vielen fehlermeldungen auf allen dcs....
Ich hoffe dir ein wenig geholfen zu haben....
Viele Grüße aus Nürnberg
Friedrich G.
nun zum Thema Ausfallsicherheit Active Directory würde ich grundsätzlich mein primäres Augenmerk auf die Sicherung und Wiederherstellung des Active Directory richten da ein "zerschießen der Datenbank" im Normalbetrieb mehr als unwahrscheinlich ist.
Grundsätzliches zum Einstieg:
Das AD arbeitet nicht wie NT mit einer Single-Master sondern mit einer Multi-Master Replikation d.h. jeder Server der zum AD hochgestuft wurde hält eine Schreibbare kopie der Datenbank und repliziert änderungen an alle seine kollegen.
Ab Domänenfunktionsebene 2000 replizieren die Server nur änderungen - ab 2003 kamen nochmals verbesserungen in bezug auf Replikation des Globalen Katalogs.
Die Replikationsverbindungen werden automatisch generiert und müssen normalerweise nicht angepasst werden.
Die wahrscheinlichkeit dass eine Domänenauthentifizierung aufgrund einer "zerschossen" (es gibt eigentlich im normalen betrieb nur eine möglichkeit das das passiert: Sabotage mit Schema-Admin Rechten! (das AD von Server 2003 enthält x features die in kombination mit dem File Replication Service genau das verhindern sollen und können...)
Auch gibt es mechanismen die bei der replikation die itegrität der AD-Datenbank sicherstellen.
D.h. man sollte sich in erster Linie gedanken um den Restore von irrtümlicherweise gelöschten Objekten machen.
Fällt ein normaler DC (keine FSMO Rollen) aus irgendeinem Grund aus so ist es das allereinfachste einen neuen Server 2003 zum DC heraufzustufen und den alten nie wieder in Betrieb zu nehmen. Der neue Repliziert dann mit den noch vorhandenen Servern und alles ist wieder ok.
Fällt ein "primärer DC" (so bezeichne ich jetzt mal den / die Server der in deiner Domäne die FSMO Rollen hält) aus so muss zusätzlich auch noch die entsprechende Rolle (RID-master, infrastruktur master, pdc-emulator - in jeder einzelnen domäne der gesamtstruktur bzw schemamaster, domänennamensmaster nur einmal pro Domain tree) auf einen anderen DC übertragen werden. Das geht in den meisten fällen über die AD Gui tools.
In harten fällen ist das kommandozeilentool fsutil in der lage das verschieben einer rolle zu erzwingen und unabhängig von der funktionsfähigkeit des alten "Role-holders" die rolle einem noch funktionstüchtigen DC zuzuweisen. (Achtung - den alten nach so einer aktion nie wieder starten sonst krachts).
Dies bezeichnet man als non Authoritative Restore.
Werden mehrere Objekte aus dem AD mit entsprechender berechtigung fälschlicherweise gelöscht so ist (von einigen tools die über tombstone lifetime arbeiten und meist käuflich erworben werden müssen einmal abgesehen) meist ein sogenannter authoritative restore nötig der ebenfalls über das Tool fsutil möglich ist.
Dazu wird ein DC im "AD Repair mode" gebootet und eine Sicherung der Datenbank wieder eingespielt. Da nach dem neustart aber der zeitstempel der rücksicherung sofort dazu führen würde das die objekte wieder gelöscht werden werden die RID der objekte um 100000 nach oben gesetzt was dazu führt das die objekte nach einem normalen Start des DC wieder mit den Anderen repliziert werden.
ACHTUNG: Für die Sicherung würde ich das Win-Backupprogramm empfehlen. Es muss eine Systemstate sicherung gemacht werden. Es reicht nicht die datenbankdatei zu sichern!!!
Noch ein wichtiger hinweis: niemals ein image von dc's machen! Das wird in keinem fall ein brauchbares ergebnis bei einer rücksicherung liefern - führt nur zu vielen fehlermeldungen auf allen dcs....
Ich hoffe dir ein wenig geholfen zu haben....
Viele Grüße aus Nürnberg
Friedrich G.
Wirklich sehr gut beschrieben. Allerdings sollte man ntdsutil nutzen 
Was man vieleicht auch noch dazu schreiben könnte, die AD Datenbank ohne Schema-Rechte Strukturweit zu beschädigen ist normalerweise nicht möglich. Es kann aber zu ausfällen der Struktur kommen wenn zb. die DNS-Server ausfallen. Man sollte sehr großen Wert auf ein zuverlässiges DNS legen. Ein Ansatz ist die _msdcs.domain.... - Domain in einer extra AD-Partitionabzulegen. Diese kann mit den wichtigsten DC´s in der Domäne replizieren. Auf diesen Servern kannst du den DNS-Dienst zu Installieren und eine Auflösung der kritischen DNS-Records im fehlerfall sicherstellen. Dabei sollte man aber berücksichtigen das das wiederum Replikationstraffic verursacht wenn die Server ihre SVR Records aktualisieren.
Was man auch beachten sollte, das man mehr als nur einen Globalen Katalog im Netzwerk hat. Wenn kein GC mehr zur verfügung steht hast du ein Problem. Aber Achtung, die GC´s verursachen ziemlich viel Replikationstraffic. 2 GC´s bei sollten reichen. Ich verwende immer einen pro Standort und falls es nur einen Standort gibt, 2 Katalogserver an diesem.
Es gibt von MS auch ziemlich gute Papers wie man das AD ausfallsicher einrichten kann.
Was man vieleicht auch noch dazu schreiben könnte, die AD Datenbank ohne Schema-Rechte Strukturweit zu beschädigen ist normalerweise nicht möglich. Es kann aber zu ausfällen der Struktur kommen wenn zb. die DNS-Server ausfallen. Man sollte sehr großen Wert auf ein zuverlässiges DNS legen. Ein Ansatz ist die _msdcs.domain.... - Domain in einer extra AD-Partitionabzulegen. Diese kann mit den wichtigsten DC´s in der Domäne replizieren. Auf diesen Servern kannst du den DNS-Dienst zu Installieren und eine Auflösung der kritischen DNS-Records im fehlerfall sicherstellen. Dabei sollte man aber berücksichtigen das das wiederum Replikationstraffic verursacht wenn die Server ihre SVR Records aktualisieren.
Was man auch beachten sollte, das man mehr als nur einen Globalen Katalog im Netzwerk hat. Wenn kein GC mehr zur verfügung steht hast du ein Problem. Aber Achtung, die GC´s verursachen ziemlich viel Replikationstraffic. 2 GC´s bei sollten reichen. Ich verwende immer einen pro Standort und falls es nur einen Standort gibt, 2 Katalogserver an diesem.
Es gibt von MS auch ziemlich gute Papers wie man das AD ausfallsicher einrichten kann.
Danke an alle für die Info.
MfG,
Markus Haupt
MfG,
Markus Haupt
