Verstehen der FSMO-Rollen in Active Directory

Wenn Ihre Organisation auf Microsoft Active Directory basiert, verlassen Sie sich auf einen oder mehrere Domänencontroller, um den AD-Betrieb aufrechtzuerhalten. Oberflächlich betrachtet scheint Active Directory auf einem Peer-to-Peer-Modell zu laufen, bei dem jeder Domänencontroller (DC) die Autorität hat, AD-Objekte zu erstellen, zu ändern und zu löschen. Das liegt daran, dass jeder Domänencontroller eine beschreibbare Kopie der Partition seiner Domäne besitzt, die einzige Ausnahme bilden schreibgeschützte DCs. Sobald Änderungen oder Ergänzungen vorgenommen werden, werden sie durch Multi-Master-Replikation mit anderen DCs synchronisiert. Allerdings sind einige zentrale Operationen auf bestimmte DCs beschränkt, denen spezielle Rollen zugewiesen werden, die als Flexible Single Master Operations (FSMO) Rollen oder Operationsmaster-Rollen bekannt sind.

Im Folgenden erläutern wir die Bedeutung der FSMO-Rollen in Active Directory und teilen einige bewährte Methoden, um eine effektive Verwaltung und Schutz zu gewährleisten.

Einführung in FSMO-Rollen

FSMO steht für Flexible Single Master Operations, ein Begriff, der von Microsofts Arbeit stammt, um die Einschränkungen des Multi-Master-Replikationsmodells in AD zu adressieren. FSMO-Rollen gewährleisten die Funktionsfähigkeit und Konsistenz des Active Directory in einer Windows-Domäne, indem sie eine spezifische kritische Aufgabe bestimmten Controllern zuweisen und einen einzelnen Autoritätsprozess für Änderungen bereitstellen. Indem diese Operationen innerhalb bestimmter Domänencontroller zentralisiert werden, helfen FSMO-Rollen, die Integrität und Stabilität von Active Directory-Umgebungen zu erhalten.

Es gibt fünf einzigartige FSMO-Rollen. Standardmäßig, wenn Sie eine Active Directory domain erstellen, werden alle FSMO-Rollen dem ersten Domänencontroller im Wald zugewiesen. Domänenadministratoren können FSMO-Rollen bei Bedarf anderen Domänencontrollern zuweisen.

Die Notwendigkeit von FSMO-Rollen

Bevor wir uns mit den eigentlichen FSMO-Rollen befassen, ist es wichtig, die Multi-Master-Architektur zu verstehen, die die Notwendigkeit dafür schafft.

Multi-Master-Modell vs. Single-Master-Modell

Die frühe Netzwerkarchitektur von Microsoft basierte auf einem Single-Master-Modell, bei dem ein einzelner Server die beschreibbare Datenbankkopie enthielt, die alle Benutzer- und Computerkonten umfasste. Dieser Server war allein verantwortlich für das Hinzufügen oder Modifizieren der Kontendatenbank. Andere Server im Netzwerk hielten schreibgeschützte Kopien der Datenbank vor. Während diese Server Benutzer authentifizieren konnten, waren sie nicht in der Lage, die Datenbank zu ändern. Wenn der Master offline ging oder nicht funktionierte, konnten keine neuen Konten erstellt und bestehende Konten nicht modifiziert werden. Dies schuf einen einzelnen Ausfallpunkt.

Um die Einschränkungen des Single-Master-Modells zu überwinden, wechselte Microsoft bei Active Directory (AD) zu einem Multi-Master-Modell, bei dem jeder Domänencontroller (DC) eine beschreibbare Kopie der Kontendatenbank verwaltet. Dieses Design gewährleistet Redundanz und Ausfallsicherheit, da die Operationen auch dann fortgesetzt werden können, wenn ein DC ausfällt. Allerdings führte dieser Multi-Master-Ansatz das Potenzial für Konflikte ein, bei denen verschiedene DCs möglicherweise gleichzeitig widersprüchliche Änderungen vornehmen könnten. Um solche Inkonsistenzen zu verhindern und die Integrität und Leistung von AD aufrechtzuerhalten, führte Microsoft Flexible Single Master Operations (FSMO) Rollen ein.

Bedeutung der FSMO-Rollen in AD

Durch die Zuweisung von FSMO-Rollen stellt Active Directory sicher, dass wesentliche Vorgänge – wie Aktualisierungen des Schemas, Domain-Naming und Zeitsynchronisation – auf geordnete und konsistente Weise gehandhabt werden. Wenn der DC, der eine bestimmte FSMO-Rolle innehat, ausfällt, kann die Rolle auf einen anderen DC übertragen werden, um die Kontinuität zu gewährleisten. Die Verteilung von FSMO-Rollen ist entscheidend für die Aufrechterhaltung eines ausgewogenen und effizienten Netzwerks, und Organisationen können diese Verteilung basierend auf ihren spezifischen Bedürfnissen und den besten Praktiken für Leistung und Redundanz anpassen.

Die 5 FSMO-Rollen im Active Directory erklärt

Active Directory hat fünf einzigartige FSMO-Rollen:

• Schema-Master (Forest-Ebene)
• Domain Naming Master (Forest-Ebene)
• Relative ID (RID) Master (Domänenebene)
• Primärer Domänencontroller (PDC)-Emulator (Domänenebene)
• Infrastructure Master (Domänenebene)

Lassen Sie uns mehr über jede FSMO-Rolle und ihre spezifische Funktion innerhalb der Active Directory-Infrastruktur erfahren:

Schema-Master

Was ist die Schema-Master-FSMO-Rolle?

Der Schema-Master ist eine unternehmensweite FSMO-Rolle, daher gibt es in einem Active Directory Forest nur einen Schema-Master. Das Schema definiert die Objektklassen (Arten von Objekten, wie Benutzer, Gruppen und Computer) und deren Attribute, die in der AD database existieren können.

Wann und wie der Schema-Master verwendet wird

Manchmal muss das Schema geändert werden, zum Beispiel um einen erforderlichen neuen Objekttyp oder ein Attribut hinzuzufügen. Um überlappende oder widersprüchliche Aktualisierungen zu verhindern, kann nur der DC mit der Schema Master-Rolle Änderungen am AD-Schema verarbeiten. Wann immer eine Schemaaktualisierung vorgenommen wird, stellt der Schema Master sicher, dass die Änderungen auf alle anderen DCs im Wald repliziert werden.

Wenn ein Schema-Update erforderlich ist, muss der Schema-Master verfügbar sein. Allerdings sind Schemaänderungen in den meisten Umgebungen relativ selten. Umstände, die eine Schemaänderung erfordern können, umfassen das Upgrade von Active Directory, die Integration bestimmter Arten von Unternehmenssoftware, das Anheben der funktionalen Ebene des Forests und das Upgrade des Betriebssystems eines DC auf eine höhere Version als derzeit im Forest vorhanden.

Domain Naming Master

Rollen und Verantwortlichkeiten des Domain Naming Master

Der Domain Naming Master ist eine unternehmensweite Rolle; es gibt nur einen Domain Naming Master in einem Active Directory Forest. Es ist der einzige DC, der in der Lage ist, neue Domänen und Anwendungspartitionen zum Forest hinzuzufügen oder bestehende daraus zu entfernen.

Häufige Szenarien mit dem Domain Naming Master

Es kann sein, dass Sie Ihren AD-Wald anpassen müssen, wenn sich Ihr Unternehmen weiterentwickelt, oder es können aufgrund einer Fusion oder Übernahme zusätzliche Domänen zu Ihrem Wald hinzugefügt werden. Da das Hinzufügen und Entfernen von Domänen und Partitionen selten und selten zeitkritische Operationen sind, verursacht die Rolle des Domain Naming Master wenig Aufwand, und ihr Verlust dürfte wenig bis keinen betrieblichen Einfluss haben.

RID Master

Was ist die RID-Master-Rolle?

Der Relative Identifier Master (RID Master) ist eine Domänenrolle; in jeder Domäne eines AD-Waldes gibt es einen RID Master. Er ist dafür verantwortlich, RID-Pools an die DCs in seiner Domäne zu verteilen, um sicherzustellen, dass jeder Sicherheitsprinzipal (wie ein Benutzer oder eine Gruppe) einen eindeutigen Sicherheitsbezeichner hat.

Eine (SID) ist eine alphanumerische Zeichenkette variabler Länge, die so aussieht:

      `S-1-5-21-1234567890-1234567890-1234567890-1001`
      

Der erste Teil der Zeichenkette ist die Domain-SID, die für alle SIDs in einer Domain gleich ist. Der letzte Teil ist die RID, die für jede SID in der Domain einzigartig ist. Im obigen Beispiel ist 1001 die einer bestimmten Sicherheitsprinzipal in der Domain zugewiesene RID.

Funktionalität und Nutzung des RID Master

Der RID Master weist den DCs RID-Pools zu. Jeder Pool besteht aus einer einzigartigen, zusammenhängenden Reihe von RIDs, die der DC verwenden kann, um eine einzigartige SID zu generieren, wenn er ein Sicherheitsprinzipal erstellt. Durch die zentrale Verwaltung der Verteilung von RIDs stellt der RID Master sicher, dass keine zwei Domänencontroller denselben RID verschiedenen Sicherheitsprinzipalen zuweisen, wodurch die Einzigartigkeit jeder SID innerhalb der Domäne garantiert wird.

Sobald einem DC ein RID-Pool vom RID Master zugewiesen wurde, muss er nicht jedes Mal mit dem RID Master kommunizieren, wenn er ein AD-Objekt erstellt. Allerdings führt der Verlust des RID Masters einer Domäne letztendlich dazu, dass keine neuen Objekte in der Domäne erstellt werden können, da die Pools auf den DCs erschöpft sein werden. In ausgereiften AD-Umgebungen würde dies eine erhebliche Zeit in Anspruch nehmen, da relativ wenige Objekte erstellt werden.

Generell wird die RID Master-Rolle dem primären Domänencontroller (PDC) in einer Domäne zugewiesen, da der PDC in der Regel die meiste Aufmerksamkeit von den Administratoren erhält und daher eine hohe Verfügbarkeit hat. In ausgereiften Domänen ist die durch die RID Master-Rolle erzeugte Last vernachlässigbar. Obwohl diese Rolle nicht so kritisch ist wie einige der anderen Rollen, ist es dennoch wichtig, die Konnektivität zum RID Master sicherzustellen.

PDC-Emulator (PDCE)

Verständnis der PDC Emulator-Rolle: Erklärung und Geschichte

Primary Domain Controller (PDC) ist ein Begriff aus der Zeit von Windows NT, als ein einzelner DC eine beschreibbare Kopie des Verzeichnisses hatte. Heute sind die meisten DCs in einer Domäne beschreibbar, aber es gibt immer noch einen bestimmten DC, der die Rolle eines PDC emuliert. Jede Domäne in einem Active Directory Forest enthält einen DC mit der PDCE-Rolle.

PDC-Emulator-Funktionen in AD

Der Primary Domain Controller Emulator ist verantwortlich für Folgendes:

• Zeitsynchronisation — Der PDCE ist die autoritative Zeitquelle für die Domäne; alle Arbeitsstationen und Mitgliedsserver synchronisieren ihre Zeit mit dem PDC-Emulator. In einem Wald mit mehreren Domänen ist der PDCE in der Stammdomäne der Zeitwächter für alle anderen PDC-Emulatoren im Wald. Um eine genaue Zeitmessung im gesamten Wald zu gewährleisten, sollte der PDC-Emulator in der Stammdomäne so konfiguriert werden, dass er mit einer externen zuverlässigen Zeitquelle synchronisiert wird. Zeit ist eine sehr große Angelegenheit. Beispielsweise wird die Kerberos-Authentifizierung fehlschlagen, wenn die Differenz zwischen der Uhr des anfordernden Hosts und der Uhr des authentifizierenden DC die festgelegte Höchstgrenze (standardmäßig 5 Minuten) überschreitet; dies hilft, bestimmte bösartige Aktivitäten wie Replay-Angriffe zu bekämpfen.
• Passwortänderungen und Authentifizierung —Wenn das Passwort eines Benutzers geändert wird, erfolgt die Änderung zunächst auf dem DC, der den Benutzer authentifiziert hat. Dieses bestätigte Passwort-Update wird sofort zum PDCE der Domäne repliziert. Versucht ein Konto, sich an einem DC zu authentifizieren, der eine kürzliche Passwortänderung noch nicht über die geplante Replikation erhalten hat, wird die Anfrage an den PDCE der Domäne weitergeleitet, der die Authentifizierungsanfrage verarbeitet und den anfragenden DC anweist, diese entweder zu akzeptieren oder abzulehnen. Dieses Verhalten stellt sicher, dass Passwörter zuverlässig verarbeitet werden können, auch wenn kürzliche Änderungen noch nicht vollständig über die geplante Replikation verbreitet wurden.
• Kontosperrstatus — Ebenso, wenn ein Konto gesperrt wird aufgrund mehrerer fehlgeschlagener Anmeldeversuche, wird die Sperrung sofort beim PDC-Emulator verarbeitet und der Sperrstatus wird zu allen DCs im Domain repliziert, um sicherzustellen, dass ein gesperrtes Konto sich nicht an einem anderen DC anmelden kann. Wenn ein Administrator ein Konto entsperrt, wird diese Änderung sofort durch die Domain repliziert.
• Aktualisierungen der Gruppenrichtlinie — Wenn Aktualisierungen an einem Group Policy object (GPO) vorgenommen werden, werden sie zunächst auf dem DC mit der PDC-Emulatorrolle übernommen. Dies verhindert Versionskonflikte, die auftreten könnten, wenn ein GPO zur ungefähr gleichen Zeit auf zwei DCs geändert würde.
• Rückwärtskompatibilität — In Organisationen, die noch immer über Altgeräte oder Software verfügen, die von Windows NT abhängig sind, kann der PDCE-Emulator als PDC dienen. Dies umfasst die Funktion als Master Browser, der Informationen über Anwendungen und Geräte in einem Netzwerk sammelt und verteilt.
• Verteiltes Dateisystem (DSF) — Standardmäßig fordern DFS-Stammserver periodisch aktualisierte DFS-Namespace-Informationen vom PDCE an. Dieses Verhalten kann zu Ressourcenengpässen führen, aber durch Aktivierung des Dfsutil.exe RootScalability-Parameters können DFS-Stammserver Updates vom nächstgelegenen DC anfordern.

Die PDC-Emulator-Rolle sollte auf einem hochverfügbaren, gut angebundenen, leistungsstarken DC platziert werden, da der Verlust des DC mit dieser Rolle sofortige und erhebliche Auswirkungen auf den Betrieb haben kann.

Infrastructure Master

Rolle des Infrastructure Master FSMO

Infrastructure Master ist eine Domänen-Rolle, deren Hauptfunktion darin besteht, die Referenzen von Objekten über Domänen hinweg in einem Wald mit mehreren Domänen zu verwalten. Der Infrastructure Master vergleicht Objekte in seiner Domäne mit Objekten in anderen Domänen im selben Wald und synchronisiert sie mit den global catalog Servern.

Wann und warum der Infrastructure Master benötigt wird

Diese Aktionen sind in bestimmten Fällen nicht erforderlich. Offensichtlich gibt es in Umgebungen mit nur einer AD domain, keine domänenübergreifenden Verweise zu verwalten. Und wenn alle DCs in einer Domäne global catalog-Hosts sind (was heutzutage aufgrund besserer Netzwerkbandbreite üblich ist), werden sie alle aktuelle Informationen haben, ohne auf den Infrastructure Master angewiesen zu sein.

Dem Infrastructure Master werden folgende Verantwortlichkeiten zugewiesen:

• Übergreifende Objektreferenzen — In einem Wald mit mehreren Domänen können Objekte aus einer Domäne in einer anderen Domäne referenziert werden. Ein typisches Beispiel ist, wenn ein Benutzer aus einer Domäne zu einer Sicherheitsgruppe in einer anderen Domäne hinzugefügt wird. In diesem Szenario wird ein Platzhalter (ein sogenanntes „Phantomobjekt“) in der Domäne der Gruppe erstellt, um den Benutzer aus der anderen Domäne darzustellen. Phantomobjekte verfolgen und verwalten beständige Referenzen zu gelöschten Objekten und linkwertigen Attributen, die sich auf Objekte in einer anderen Domäne im Wald beziehen.
• Aktualisierung von Gruppen-zu-Benutzer-Referenzen —Der Infrastructure Master ist verantwortlich für die Aktualisierung einer Objekt-SID und des Distinguished Name (DN) bei einer domänenübergreifenden Objektreferenz und für die Übersetzung von GUIDs, SIDs und DNs zwischen Domänen in einem Wald.
• Bereinigung veralteter Objekte — Der Infrastructure Master überprüft regelmäßig sein Domain auf Objekte, die nicht mehr gültig sind (wie Objekte aus gelöschten Vertrauensstellungen) und entfernt diese.

Wenn ein DC mit der Rolle des Infrastructure Master ausfällt, sind die Auswirkungen hauptsächlich administrativ. Obwohl Quer-Domänen-Objektverknüpfungsnamen während seiner Abwesenheit möglicherweise nicht korrekt aufgelöst werden, funktionieren Quer-Domänen-Gruppenmitgliedschaften weiterhin.

FSMO-Rollen im Kontext von Forest und Domain

FSMO-Rollen auf Gesamtstrukturebene

Wie Sie der obigen Liste entnehmen können, operieren die letzten beiden FSMO-Rollen waldweit, was bedeutet, dass nur ein DC im Wald der Rolleninhaber sein kann. Mit anderen Worten, jeder Active Directory Forest hat einen einzigen Schema-Master und einen einzigen Domain Naming Master.

FSMO-Rollen auf Domänenebene

Die anderen drei FSMO-Rollen funktionieren innerhalb der Zuständigkeit einer einzelnen Domäne. In jeder Domäne gibt es einen Infrastrukturmaster, einen RID-Master und einen PDC-Emulator. Jede Domäne wird diese drei FSMO-Rollen in Umgebungen mit mehreren Domänen auf einem oder mehreren DCs hosten.

Verwaltung von FSMO-Rollen

Identifizierung der FSMO-Rolleninhaber

Es ist wichtig zu wissen, welche DCs in Ihrer AD-Umgebung die 5 FSMO-Rollen hosten. Es gibt mehrere Möglichkeiten, die DCs zu identifizieren, die FSMO-Rollen besitzen. Eine schnelle Methode ist die Verwendung der Eingabeaufforderung mit folgendem Befehl:

      netdom query fsmo /domain:<DomainName>
      

Hier ist ein Beispiel:

Sie können auch PowerShell mit dem folgenden Skript verwenden:

      (Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles
      

Hier ist ein Beispiel unten mit PowerShell:

Sie können auch herausfinden, welche DCs FSMO-Rollen zugewiesen sind, indem Sie Windows Active Directory Tools verwenden. Öffnen Sie Active Directory Users and Computers, klicken Sie mit der rechten Maustaste auf Ihre Domain und wählen Sie Operations Masters wie unten gezeigt:

Klicken Sie dann auf jeden Tab, um die drei Domain-FSMOs zu finden.

Sie können Active Directory Domains and Trusts verwenden, um herauszufinden, welcher DC die Rolle des Domain Naming Master innehat, indem Sie mit der rechten Maustaste auf Active Directory Domains and Trust klicken und dann Operations Master, wie unten gezeigt, auswählen.

Dadurch wird das folgende Pop-up geöffnet, um den aktuellen Rolleninhaber zu identifizieren.

Der Prozess zur Identifizierung des Schema Master FSMO ist etwas komplizierter. Sie können dessen Identität mit dem Active Directory Schema-Snap-In herausfinden, jedoch erscheint das Snap-In nicht standardmäßig in Windows Server. Um darauf zuzugreifen, müssen Sie es mit der Datei Schmmgmt.dll registrieren. Klicken Sie dazu auf Start > Ausführen und geben Sie regsvr32 schmmgmt.dll in das Feld Öffnen ein. Klicken Sie dann unten gezeigt auf OK.

Sobald Sie sich erfolgreich registriert haben, müssen Sie Folgendes tun:

1. Im Konsolenmenü klicken Sie auf Add/Remove Snap-in, klicken Sie auf Hinzufügen, doppelklicken Sie auf Active Directory Schema, klicken Sie auf Schließen und dann auf OK.
2. Klicken Sie mit der rechten Maustaste auf Active Directory Schema im oberen linken Bereich und dann auf Operations Masters, um den Server anzuzeigen, der die Rolle des Schema-Masters innehat.

Ein Beispiel ist im folgenden Screenshot dargestellt:

Dies wird Ihnen Zugriff auf das Snap-In geben, von dem aus Sie mit der rechten Maustaste auf Active Directory Schema klicken und Operations Master auswählen können.

Übertragen und Übernehmen von FSMO-Rollen

Wann und wie FSMO-Rollen übertragen werden

Während Active Directory die FSMO-Rollen automatisch Ihren DCs zuweist, gibt es Situationen, in denen Sie eine Rolle auf einen anderen DC übertragen möchten. Beispielsweise müssen Sie möglicherweise einen DC, der derzeit eine zugewiesene Rolle innehat, für Wartungsarbeiten herunterfahren. Sowohl Domain- als auch Enterprise-Admins haben das Ermessen, diese Rollen bei Bedarf zwischen den Domain-Controllern zu verschieben.

Übernahme der FSMO-Rollen

Für FSMO-Rollenübertragungen müssen sowohl der aktuelle Inhaber als auch die Ziel-Domänencontrollerrollen aktiv und netzwerkverbunden sein. Wenn der aktuelle FSMO-Rolleninhaber nicht verfügbar ist und nicht wiederhergestellt werden kann, muss ein Domänen- oder Unternehmensadministrator die Rolle übernehmen. Da dies ein abrupterer Vorgang ist, sollte das Übernehmen einer FSMO-Rolle nur durchgeführt werden, wenn es notwendig ist.

Best Practices und Fehlerbehebung

Optimierung der FSMO-Rollenplatzierung für eine höhere Effizienz

Obwohl es keine strikten Regeln für die Platzierung von FSMO-Rollen innerhalb von Active Directory gibt, werden Ihnen die folgenden Empfehlungen die besten Ergebnisse liefern:

• Platzieren Sie den PDC-Emulator und den RID-Master auf einem zuverlässigen Domain-Controller mit guter Konnektivität, der für andere Domain-Controller leicht verfügbar ist, da ihre Rollen für die täglichen Active Directory-Aktivitäten entscheidend sind.
• Wenn möglich, sollte der Infrastructure Master nicht auf einem globalen Katalogserver platziert werden. Dies ist natürlich nicht möglich, wenn alle DCs globale Katalogserver sind.
• Platzieren Sie die beiden Rollen auf der Waldseite (Schema Master und Domain Naming Master) auf demselben DC, da sie nicht sehr häufig genutzt werden.

Häufige Probleme und Lösungen

Es gibt einige Schlüsselereignisse, die darauf hindeuten könnten, dass ein FSMO nicht verfügbar ist. Beispielsweise wird jeder Versuch, das AD-Schema zu aktualisieren, zu einem Fehler führen, wenn der Schema-Master ausgefallen ist. Sie werden auch keine Domänen im Wald hinzufügen oder entfernen können, wenn der Domain Naming Master nicht zugänglich ist. In diesen Fällen müssen Sie bestätigen, welcher DC diese Rolle hat und überprüfen, ob er zugänglich ist.

Die Unfähigkeit, auf einen DC mit einer zugewiesenen FSMO-Rolle zuzugreifen, kann auf mehrere Faktoren zurückzuführen sein, einschließlich:

• Der Server ist offline oder heruntergefahren
• Probleme mit der Netzwerkverbindung
• Fehler oder Ausfälle in der DNS-Konfiguration

Die Behebung dieser Probleme kann erfordern, dass Sie Netzwerkdiagnosetools verwenden, um die Konnektivität im gesamten Netzwerk zu überprüfen, DNS-Einstellungen einschließlich SRV-Einträge zu verifizieren und die physische und logische Gesundheit des Servers zu gewährleisten, der die FSMO-Rolle innehat. Wenn das Problem weiterhin besteht, erwägen Sie, die Rolle auf einen anderen gesunden DC zu übertragen oder, als letzten Ausweg, die Rolle zu übernehmen, falls der aktuelle Inhaber dauerhaft nicht verfügbar ist.

Überwachung und Auditing von FSMO-Rollen

Da diese FSMO-Rollen so kritisch sind, sollten Sie regelmäßig die Server überwachen, auf denen diese Rollen liegen. Auf einer sehr grundlegenden Ebene können Sie die Ereignisprotokolle auf Ihren Domänencontrollern überprüfen. Bestimmte Ereignisse können darauf hinweisen, wann die FSMO-Rollen übertragen oder ergriffen wurden. Ihre Organisation kann auch Überwachungs- oder Verwaltungssoftware verwenden, die möglicherweise historische Daten oder Warnungen im Zusammenhang mit FSMO-Rollenänderungen hat. Es gibt auch Drittanbieter-Tools, die weit mehr Funktionalität bieten. Ein Beispiel ist Netwrix Auditor for Active Directory, das die Überwachung von FSMO-Rollen automatisiert und Sie über verdächtige oder unvorhergesehene Änderungen alarmieren kann. Es gilt auch als bewährte Praxis, zu dokumentieren, wann diese FMSO-Rollenänderungen stattfinden, damit auf diese Art von Historie zugegriffen werden kann, falls notwendig.

Wie Netwrix helfen kann

Wie wir gesehen haben, sind FSMO-Rollen sowohl für die Geschäftskontinuität als auch für die Sicherheit wichtig. Daher ist es entscheidend, alle Änderungen an Ihren FSMO-Rollen zu überwachen. Netwrix Auditor for Active Directory automatisiert diese Überwachung und kann Sie bei jeder verdächtigen Änderung alarmieren, damit Sie handeln können, bevor es zu Ausfallzeiten oder einem data breach führt.

Natürlich ist der Schutz von FSMO-Rollen nur ein Teil einer Sicherheitsstrategie. Netwrix Auditor for Active Directory bietet umfassende Sichtbarkeit und Kontrolle über die Kernsysteme, die Sie benötigen. Es überwacht und analysiert kontinuierlich Änderungen und andere Aktivitäten in Active Directory, um aufkommende Bedrohungen zu erkennen und ermächtigt Sie, umgehend und effektiv zu reagieren, um die Auswirkungen auf Geschäftsprozesse, Benutzerproduktivität und Sicherheit zu minimieren.

Fazit

Die FSMO-Rollen in AD sind ein Beispiel dafür, wie viel unter der Oberfläche passiert. Obwohl die FSMO-Rollen auf Wald-Ebene nicht jeden Tag kritisch sind, hängt Ihr Geschäft doch von Ihren Domänen-FSMO-Rollen und -Diensten ab. Zusätzlich zur Bedrohung durch erwartete Ausfälle, die periodisch auftreten, stellen diese Rollen ideale Ziele für bösartige Bedrohungsakteure dar, die darauf abzielen, Geschäftsabläufe zu stören. Das bedeutet, dass Sie Einblick in die Komplexität Ihrer AD-Umgebung benötigen.

AD-Supportteams setzen zunehmend auf automatisierte Überwachungstools, um diesen Herausforderungen zu begegnen. Diese Lösungen können bieten:

• Verbesserte Sichtbarkeit in den Status und die Leistung von FSMO-Rolleninhabern
• Echtzeitwarnungen bezüglich jeglicher Änderungen oder Anomalien bei FSMO-Rollenverteilungen
• Proaktive Identifizierung potenzieller Probleme, bevor sie eskalieren können
• Umfassende Überwachungsfunktionen, die historische Änderungen nachverfolgen können.

Dieser proaktive Ansatz kann AD-Administratoren dabei helfen, die Gesundheit und Stabilität einer AD-Infrastruktur zu erhalten und die allgemeine Sicherheitslage der Organisation zu stärken.

FAQ

Was ist FSMO?

FSMO steht für Flexible Single Master Operations. Diese Operationen sind spezielle Verantwortlichkeiten, die bestimmten Domänencontrollern zugewiesen werden, um Konflikte zu verhindern und den reibungslosen Betrieb des Netzwerks zu gewährleisten.

Was sind FSMO und seine Rollen?

Active Directory basiert auf einem Multi-Master-Modell, bei dem FSMO bestimmten Domänencontrollern die festgelegte Autorität zuweist.

Was sind die 5 FSMO-Rollen und wie würden Sie die Rolleninhaber überprüfen?

Die 5 FSMO-Rollen sind wie folgt:

• Schema Master: Verantwortlich für Aktualisierungen des AD-Schemas.
• Domain Naming Master: Steuert das Hinzufügen oder Entfernen von Domänen im Wald.
• RID (Relative ID) Master: Weist DCs RID-Pools zu, um eindeutige Sicherheitskennungen (SIDs) zu erstellen.
• PDC (Primary Domain Controller) Emulator: Dieser verarbeitet Passwortänderungen und Zeitabgleich und dient als Ausweichlösung für bestimmte Authentifizierungstypen.
• Infrastructure Master: Verwaltet Verweise auf Objekte in anderen Domänen

Mit Standard-Active Directory tools und PowerShell können Sie herausfinden, welche Domänencontroller die Rolleninhaber dieser FSMOs sind.

Wo befinden sich die FSMO-Rollen?

Standardmäßig hostet der erste Domänencontroller einer Active Directory-Gesamtsstruktur-Stammdomäne den Schema-Master und den Domain Naming Master. Der erste Domänencontroller jeder Domäne hostet den PDC-Emulator, RID-Master und Infrastructure Master. Active Directory-Administratoren können diese Rollen auf andere DCs verschieben, wenn sie möchten.

Warum übernehmen wir FSMO-Rollen?

Fällt ein Domänencontroller plötzlich aus, wird seine FSMO-Rolle nicht verfügbar. Eine Rollenübertragung ist nicht möglich, wenn keine Verbindung zum ursprünglichen Rolleninhaber besteht. In diesem Fall muss die Rolle beschlagnahmt und einem anderen DC zugewiesen werden.

Was ist die wichtigste FSMO-Rolle?

Während alle FSMO-Rollen wichtig sind, ist der PDC-Emulator am wichtigsten, da er die Zeit für die Domäne, Passwortänderungen und Gruppenrichtlinien Konfiguration verwaltet. In einigen Fällen können ältere Systeme davon abhängig sein, als einzige Methode zur Bearbeitung von Authentifizierungsanfragen.

Wie finde ich FSMO-Rollen?

Es gibt mehrere Möglichkeiten herauszufinden, welche Domänencontroller die Active Directory FSMO-Rollen haben. Eine davon ist die Verwendung des Befehls „netdom query fsmo“ in der Eingabeaufforderung. Sie können auch Active Directory-Tools und PowerShell verwenden, um herauszufinden, welcher Server jede Rolle hostet.

Wo sollten FSMO-Rollen platziert werden?

Wenn Sie nur einen oder zwei Domain-Controller in Ihrer AD-Umgebung haben, haben Sie nicht viel Auswahl. Alle FSMO-Rollen sollten einem DC zugewiesen werden, der eine gute Verbindung zu allen anderen DCs im Wald hat. Wenn möglich, sollte der Infrastructure Master nicht auf einem globalen Katalogserver platziert werden.

Welche FSMO-Rollen sollten zusammen sein?

Die beiden FSMO-Rollen auf Gesamtstrukturebene des Schema-Masters und des Domain-Naming-Masters sollten auf demselben DC platziert werden, aber es ist nur eine Empfehlung.

Was sind FSMO-Rollen in Active Directory?

Microsoft hat das Konfliktrisiko reduziert, indem bestimmte Domänencontroller als alleinige Autorität für fünf sensible Operationen bestimmt wurden. Dies sind die Flexible Single Master Operations (FSMO)-Rollen, und ihr Verständnis ist grundlegend für die Verwaltung einer stabilen, gut geführten Active Directory-Umgebung.

Active Directory arbeitet nach einem Multi-Master-Modell, bei dem jeder Domänencontroller eine beschreibbare Kopie seiner Domänenpartition führt. Dieses Design sorgt für Ausfallsicherheit (Operationen laufen weiter, auch wenn einzelne DCs offline sind), birgt aber auch die Möglichkeit von widersprüchlichen Änderungen.

Diese Anleitung erklärt jeden der fünf FSMO-Rollen, zeigt, wie man die Domänencontroller identifiziert, die sie innehaben, und liefert die Befehle zum Übertragen oder Übernehmen der Rollen, wenn die Umstände es erfordern.

Jede der fünf FSMO-Rollen gehört zu einem von zwei Bereichen:

Standardmäßig landen beim Hochstufen des ersten Domänencontrollers in einer Gesamtstruktur alle fünf FSMO-Rollen auf diesem DC. Administratoren können sie neu verteilen, wenn die Umgebung wächst und sich die betrieblichen Anforderungen ändern.

FSMO steht für Flexible Single Master Operations und bezieht sich auf fünf Active Directory-Operationen, die jeweils nur von einem bestimmten Domänencontroller verarbeitet werden können. Durch die Beschränkung dieser Operationen auf einen einzigen autoritativen DC pro Bereich verhindert Active Directory Datenkollisionen, die auftreten würden, wenn mehrere Controller versuchen würden, sie gleichzeitig auszuführen.

Netwrix Auditor überwacht FSMO-Rollen-Zuweisungen in Active Directory und benachrichtigt Ihr Team, wenn eine Rollenübertragung oder -übernahme außerhalb eines geplanten Wartungsfensters erfolgt. Demo anfordern

Warum Multi-Master-Replikation Single-Master-Operationen erfordert

Forest-weit angelegte Rollen haben genau einen Inhaber im gesamten AD-Forest, unabhängig davon, wie viele Domains der Forest enthält. Domain-weit angelegte Rollen haben genau einen Inhaber pro Active Directory-Domäne, sodass ein Forest mit drei Domains drei RID Masters, drei PDC Emulators und drei Infrastructure Masters enthält.

Bedeutung der FSMO-Rollen

Konfliktvermeidung

Frühe Netzwerkverzeichnisdienste basierten auf einem Single-Master-Modell: Ein Server hielt die beschreibbare Kopie der Kontodatenbank, während alle anderen schreibgeschützte Replikate führten. Dieses Modell verhinderte Konflikte, schuf aber eine starke Abhängigkeit von einem einzelnen Server: Wenn dieser offline war, konnten keine neuen Konten erstellt und keine bestehenden Konten geändert werden.

FSMO-Rollen halten Active Directory konsistent, sicher und wiederherstellbar. Ihre Bedeutung wird erst klar, wenn etwas schiefgeht: Ein Domänencontroller fällt aus, eine Rollenübertragung ist unter Druck erforderlich oder ein Angreifer zielt auf einen Rolleninhaber.

Active Directory ersetzte dieses Modell durch Multi-Master-Replikation. Jeder Domänencontroller kann in seine lokale Kopie des Verzeichnisses schreiben, und Änderungen werden über geplante Replikationen an alle anderen Controller weitergegeben. Das Design sorgt für Ausfallsicherheit, bringt aber bestimmte Operationen mit sich, bei denen zwei Controller gleichzeitig das Verzeichnis beschädigen würden. FSMO-Rollen lösen dies, indem sie genau dort eine Single-Master-Authority durchsetzen, wo das Multi-Master-Modell nicht sicher arbeiten kann.

Zuverlässigkeit der Authentifizierung

Sicherheitslage

Ohne festgelegte Single-Master-Behörden könnten zwei Domänencontroller gleichzeitig widersprüchliche Vorgänge verarbeiten: Einer weist RID 1050 einem neuen Benutzerkonto zu, während ein anderer dieselbe RID einem anderen Konto zuweist, oder zwei Administratoren erweitern das Schema mit inkompatiblen Attributdefinitionen. Beide Ergebnisse führen zu Verzeichnisbeschädigungen ohne klare Lösung. FSMO-Rollen stellen sicher, dass jede sensible Operation jederzeit genau eine autoritative Quelle hat.

Notfallwiederherstellung

Was sind die 5 FSMO-Rollen

Die FSMO-Zuweisung des PDC Emulator ist der Grund, warum Ihr Helpdesk ein Konto entsperren kann und die Änderung innerhalb von Sekunden im gesamten Domänenbereich wirksam wird. Ohne diese Kerberos authentication Entscheidungen auf der jeweils aktuell vorliegenden Passwortversion eines DC basieren würden, was zu Wettlaufsituationen zwischen kürzlich erfolgten Passwortänderungen und Anmeldeversuchen führen würde. Das Single-Master-Modell für die Passwortverarbeitung gibt jedem DC einen bekannten Eskalationspfad für Authentifizierungsfehler, und dieser Pfad funktioniert nur, weil ein DC die Rolle des PDC Emulator innehat.

Drei der fünf FSMO-Rollen liegen direkt auf dem Pfad von Angriffsszenarien mit hohem Wert. Der Schema Master steuert, ob ein Angreifer das Verzeichnisschema erweitern kann, um Persistenzmechanismen einzuführen. Der RID Master steuert die SID-Zuweisung, und die Manipulation von RID ist ein bekannter Vektor für privilege escalation und SID-Historienangriffe. Der PDC Emulator verarbeitet Authentifizierungen und Kontosperrungen und ist damit ein Hauptziel für jeden, der den Domänenzugang aufrechterhalten oder Sperrwarnungen unterdrücken möchte.

Active Directory definiert fünf FSMO-Rollen. Der Schema Master und der Domain Naming Master arbeiten auf der Forest-Ebene. Der RID Master, PDC Emulator und Infrastructure Master arbeiten auf der Domänenebene.

1. Schema-Master

Wenn ein Domänencontroller mit einer FSMO-Rolle ausfällt, hängt der Wiederherstellungspfad davon ab, ob Ihr Team weiß, welche Rollen er innehatte und ob der Ausfall vorübergehend oder dauerhaft ist. Organisationen, die Rollenverteilungen nicht verfolgen, entdecken die Lücke unter Druck: Neue Benutzerkonten können nicht erstellt werden, die Zeitsynchronisation driftet oder Gruppenrichtlinien-Updates hören auf sich zu verbreiten. Die Dokumentation der Rolleninhaber und das Testen der Übertragungsverfahren sind die operative Grundlage für die AD-Resilienz.

Jede Forest hat einen Schema Master. Das Schema der Active Directory database definiert jede Objektklasse (Benutzer, Gruppen, Computer, Drucker und mehr) und jedes Attribut, das diese Objekte enthalten können. Nur der Schema Master kann Schemaänderungen schreiben.

2. Domänennamensmaster

Jeder Forest hat einen Domain Naming Master. Er ist der einzige Domänencontroller, der berechtigt ist, Domänen und Anwendungspartitionen aus dem Forest hinzuzufügen oder zu entfernen.

Schema-Aktualisierungen sind selten. Sie erfolgen, wenn Sie das Forest-Funktionsniveau anheben, Active Directory auf eine neuere Version aktualisieren, Unternehmenssoftware integrieren, die das Schema erweitert (Exchange Server ist ein häufiges Beispiel), oder eine neue Windows Server-Betriebssystemversion in den Forest einführen. Der Schema Master muss online und erreichbar sein, damit eine dieser Operationen erfolgreich ist.

Nach der Bestätigung wird eine Schemaänderung auf jeden Domänencontroller im Forest repliziert. Ist der Schema Master offline, wenn Sie ein Schema-Update versuchen, schlägt die Operation fehl, bis der DC wieder erreichbar ist.

3. RID Master

Eine SID folgt dieser Struktur:

Sie interagieren mit dem Domain Naming Master, wenn sich die Verzeichnisstruktur Ihrer Organisation ändert: Hinzufügen einer untergeordneten Domäne, Entfernen einer veralteten Domäne oder Übernahme von Domänen eines übernommenen Unternehmens. Da diese Vorgänge selten und selten zeitkritisch sind, hat der Domain Naming Master geringere Verfügbarkeitsanforderungen als die rollen auf Domänenebene. Ein kurzer Ausfall des Domain Naming Master hat keine Auswirkungen auf den täglichen Betrieb.

Der RID Master stellt diese Einzigartigkeit sicher, indem er RID-Pools an Domänencontroller vergibt. Wenn ein DC einen neuen Sicherheitsprinzipal erstellen muss, entnimmt er eine RID aus seinem zugewiesenen Pool, anstatt für jedes Objekt den RID Master zu kontaktieren. Läuft ein Pool zur Neige, fordert der DC einen neuen beim RID Master an.

Wenn der RID Master offline geht, erstellen Domänencontroller weiterhin Objekte mit ihren vorhandenen RID-Pools. In ausgereiften Umgebungen mit großen Pools kann dies über einen längeren Zeitraum geschehen. Sobald alle DC-Pools erschöpft sind, schlägt die Objekterstellung fehl.

4. PDC-Emulator

Jede Domäne hat einen RID Master. Jeder Sicherheitsprinzipal in Active Directory (Benutzer, Computer und Gruppen) benötigt eine eindeutige Sicherheitskennung (SID). Eine SID besteht aus einem domänenweiten Präfix, gefolgt von einem relativen Bezeichner (RID). Der RID-Teil macht jede SID innerhalb der Domäne einzigartig.

Jede Domäne hat einen PDC-Emulator. Er trägt mehr Verantwortung als jede andere FSMO-Rolle und hat den direktesten Einfluss auf die täglichen Domänenoperationen. Der PDC-Emulator übernimmt Folgendes:

Die Domain-SID ist für alle Objekte in der Domäne gleich. Das letzte Segment (1001 in diesem Beispiel) ist die RID, die einem bestimmten Sicherheitsprinzipal zugewiesen ist.

• Zeitsynchronisierung: Der PDC-Emulator ist die autoritative Zeitquelle für seine Domäne. Alle Arbeitsstationen und Mitgliedsserver synchronisieren ihre Uhren mit ihm. In einem Multi-Domain-Wald fungiert der PDC-Emulator der Waldstammdomäne als Zeitgeber für alle anderen PDC-Emulatoren im Wald. Der PDC-Emulator in der Stammdomäne sollte sich mit einer zuverlässigen externen Zeitquelle synchronisieren. Die Kerberos-Authentifizierung schlägt fehl, wenn die Zeitabweichung zwischen einem Client und seinem authentifizierenden DC fünf Minuten überschreitet; genaue Zeit ist keine Option.
• Verarbeitung von Account-Sperren: Wenn eine account lockout auftritt, verarbeitet der PDC-Emulator sie sofort und repliziert den Sperrstatus an alle DCs in der Domäne. Wenn ein Administrator ein Konto entsperrt, repliziert der PDC-Emulator die Änderung sofort.
• Passwortänderungen und Authentifizierung: Wenn ein Benutzer ein Passwort ändert, wird die Änderung sofort an den PDC Emulator repliziert. Wenn ein Benutzer versucht, sich an einem DC zu authentifizieren, der das aktualisierte Passwort noch nicht über die normale Replikation erhalten hat, leitet dieser DC die Authentifizierungsanfrage an den PDC Emulator weiter. Dies stellt sicher, dass die Domäne gültige Anmeldeinformationen akzeptiert, auch wenn kürzliche Passwortänderungen noch nicht über die geplante Replikation verbreitet wurden.

Platzieren Sie den PDC-Emulator auf einem leistungsstarken DC mit guter Netzwerkverbindung zu allen anderen Controllern der Domäne. Sein Ausfall hat sofortige, sichtbare Auswirkungen auf den Betrieb.

• DFS-Namespace-Synchronisierung: Standardmäßig fordern DFS-Stammserver aktualisierte Namespace-Informationen vom PDC Emulator an. In großen Umgebungen kann dies zu Ressourcenengpässen führen. Das Aktivieren des Parameters RootScalability in Dfsutil.exe ermöglicht es DFS-Stammservern, stattdessen Updates vom nächstgelegenen DC anzufordern.

5. Infrastruktur-Master

• Group Policy-Aktualisierungen: Änderungen an einem Group Policy Object werden zunächst auf dem DC mit der PDC-Emulator-Rolle übernommen. Dies verhindert Versionskonflikte, die auftreten würden, wenn zwei Administratoren gleichzeitig dasselbe GPO auf verschiedenen DCs bearbeiten.

Jede Domäne hat einen Infrastructure Master. Seine Hauptaufgabe ist die genaue Pflege von domänenübergreifenden Objektverweisen in einem Multi-Domain-Wald.

Wenn der Infrastructure Master offline geht, können Objektnamen über Domänengrenzen hinweg möglicherweise nicht korrekt aufgelöst werden. Die gruppenübergreifenden Mitgliedschaften funktionieren weiterhin, sodass die Auswirkungen hauptsächlich administrativ sind.

So finden Sie FSMO-Rolleninhaber

Zwei Bedingungen machen den Infrastructure Master überflüssig: Einzeldomänen-Wälder (keine domänenübergreifenden Verweise) und Umgebungen, in denen jeder DC auch ein globaler Katalogserver ist (häufig in modernen Umgebungen mit ausreichender Netzwerkbandbreite). In beiden Fällen halten alle DCs bereits aktualisierte domänenübergreifende Informationen ohne Abhängigkeit vom Infrastructure Master.

Wenn ein Benutzer aus einer Domäne zu einer Sicherheitsgruppe in einer anderen Domäne hinzugefügt wird, erstellt Active Directory ein Platzhalterobjekt (genannt Phantomobjekt) in der Domäne der Gruppe, um den domänenübergreifenden Benutzer darzustellen. Der Infrastructure Master hält diese Phantomobjekte aktuell, indem er sie mit dem globalen Katalog synchronisiert. Er bereinigt auch veraltete Objekte, indem er Verweise auf Objekte aus gelöschten trusts oder Domänen.

Verwendung von netdom query fsmo

Verwendung von PowerShell

Ersetzen Sie <DomainName>Expand durch den vollqualifizierten Domänennamen der Ziel-Domäne. Die Ausgabe listet den Hostnamen des DC auf, der jede Rolle innehat.

Der Befehl netdomExpand wird auf jedem Windows-Gerät ausgeführt, das der Domäne beigetreten ist und RSAT installiert hat, oder direkt auf einem Domänencontroller. Er gibt alle fünf Rolleninhaber in einer einzigen Abfrage zurück:

Verwendung von Active Directory-Verwaltungstools

PowerShell bietet eine feinere Steuerung und funktioniert gut in Umgebungen mit mehreren Domänen. Das folgende Skript fragt alle Domänen im Forest ab und gibt jeden DC mit einer FSMO-Rollen-Zuweisung zurück:

Zu wissen, welche Domänencontroller die fünf FSMO-Rollen innehaben, ist eine Voraussetzung sowohl für geplante Wartungen als auch für die Vorfallreaktion. Es stehen drei Methoden mit integrierten Active Directory management tools.

So finden Sie den RID Master, PDC Emulator und Infrastructure Master:

1. Öffnen Sie Active Directory-Benutzer und -Computer.

Für eine einfachere Abfrage pro Domäne verwenden Sie Get-ADDomainExpand und Get-ADForestExpand direkt:

Die GUI-Tools in Active Directory Users and Computers zeigen die drei FSMO-Rollen auf Domänenebene an.

1. Klicken Sie im linken Bereich mit der rechten Maustaste auf den Domänennamen und wählen Sie Operations Masters.
2. Öffnen Sie Active Directory Domains and Trusts.

So finden Sie den Domain Naming Master:

1. Der Dialog zeigt den aktuellen Domain Naming Master an.
2. Überprüfen Sie die Registerkarten RID, PDC und Infrastructure, die jeweils den aktuellen Rolleninhaber anzeigen.
3. Klicken Sie im linken Bereich mit der rechten Maustaste auf Active Directory Domains and Trusts und wählen Sie Operations Master.

So finden Sie den Schema Master: Das Active Directory Schema-Snap-In wird standardmäßig nicht geladen. Registrieren Sie es zuerst:

So übertragen Sie FSMO-Rollen

1. Öffnen Sie den Ausführen-Dialog (Win + R) und geben Sie ein regsvr32 schmmgmt.dll. ExpandKlicken Sie auf OK.

3. Klicken Sie im linken Bereich mit der rechten Maustaste auf Active Directory Schema und wählen Sie Operations Master, um den aktuellen Schema Master anzuzeigen.

2. Öffnen Sie MMC (mmc.exeExpand), gehen Sie zu Datei > Snap-In hinzufügen/entfernen, und fügen Sie Active Directory Schema.

Eine Übertragung verschiebt eine FSMO-Rolle von ihrem aktuellen Inhaber zu einem anderen DC, während beide Controller online sind und kommunizieren. Verwenden Sie eine Übertragung für geplante Vorgänge: Außerbetriebnahme eines DC, Neuverteilung von Rollen zur Lastverteilung oder Redundanz oder Austausch veralteter Hardware.

Übertragung via PowerShell

Eine einzelne Rolle übertragen:

Übertragen Sie alle fünf Rollen auf einmal:

Beide DC müssen online, erreichbar und erfolgreich replizierend sein, bevor Sie eine Übertragung starten. Überprüfen Sie den Replikationsstatus mit repadmin /replsummaryExpand bevor Sie fortfahren.

PowerShell ist die effizienteste Methode zum Übertragen von Rollen, insbesondere beim gleichzeitigen Verschieben mehrerer Rollen. Das Move-ADDirectoryServerOperationMasterRoleExpand Cmdlet übernimmt alle fünf Rollen.

Übertragung über die GUI:

Die fünf Rollennamenwerte sind SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster und InfrastructureMasterExpand.

So übernehmen Sie FSMO-Rollen

Ersetzen Sie TargetDCName Expanddurch den NetBIOS-Namen oder FQDN des Ziel-DC. PowerShell fordert vor der Übertragung jeder Rolle eine Bestätigung an. Fügen Sie -Confirm:$falseExpand hinzu, um Eingabeaufforderungen in Skriptszenarien zu unterdrücken.

Führen Sie nach jeder Übertragung netdom query fsmoExpand aus, um die neuen Rollenzuweisungen zu bestätigen.

Rollen mit ntdsutil übernehmen:

Versuchen Sie vor der Übernahme, den ursprünglichen DC wiederherzustellen oder zu retten. Wenn die Wiederherstellung nicht möglich ist, fahren Sie mit der Übernahme fort und stellen Sie sicher, dass Sie den ursprünglichen DC nicht wieder in die Domäne aufnehmen, ohne ihn zuvor herabzustufen.

Für den RID Master, PDC Emulator und Infrastructure Master: Öffnen Sie ADUC, navigieren Sie zu Operations Masters, wählen Sie den entsprechenden Tab aus und klicken Sie auf Change. Für den Domain Naming Master: verwenden Sie Active Directory Domains and Trusts > Operations Master > Change. Für den Schema Master: verwenden Sie das Active Directory Schema-Snap-In > Operations Master > Change.

Nach der Verbindung übernehmen Sie jede Rolle einzeln:

Eine seizure weist eine FSMO-Rolle zwangsweise einem neuen DC zu, ohne mit dem ursprünglichen Inhaber abzustimmen. Verwenden Sie eine seizure nur, wenn der aktuelle Rolleninhaber dauerhaft offline und nicht wiederherstellbar ist. Nehmen Sie keine seizure vor, wenn der ursprüngliche Inhaber ins Netzwerk zurückkehren könnte; das Wiederanschalten eines ehemaligen Rolleninhabers nach einer seizure verursacht einen Split-Brain-Zustand, der manuell behoben werden muss.

Öffnen Sie eine erhöhte Eingabeaufforderung auf dem DC, der die Rollen erhalten soll, und führen Sie ntdsutilExpand. Führen Sie dann diese Schritte aus:

Geben Sie quit Expandzweimal ein, um ntdsutil nach Abschluss aller Übernahmen zu beenden.

Best Practices für die Platzierung von FSMO-Rollen

Bestätigen Sie die neuen Zuweisungen mit netdom query fsmoExpand bevor Sie Dienste, die von diesen Rollen abhängen, wieder online stellen.

Die Rollenverteilung beeinflusst direkt die Stabilität und Wiederherstellungszeit von AD. Überprüfen Sie den Leitfaden zu den besten Sicherheitspraktiken für Active Directory für weitergehende Empfehlungen zur Härtung neben diesen rollenbezogenen Richtlinien:

• Verteilen Sie Rollen nach Möglichkeit auf verschiedene physische Standorte: In Multi-Site-Umgebungen reduziert die Platzierung von Rollen auf DCs an Ihrem Hauptstandort die WAN-Abhängigkeit für rollenabhängige Vorgänge. Kombinieren Sie dies mit einem dokumentierten Übertragungsplan, damit Rollen schnell verschoben werden können, falls der Hauptstandort offline geht.
• Schema Master und Domain Naming Master zusammen auf einem weniger genutzten DC: Diese Rollen auf Forest-Ebene werden selten aufgerufen. Sie auf demselben DC zu gruppieren, vereinfacht die Verwaltung, ohne eine Leistungsengstelle zu verursachen.

Für Anleitungen zur Einrichtung und Konfiguration von Domänencontrollern zur Unterstützung dieser Platzierungsentscheidungen lesen Sie den Domänencontroller-Bereitstellungsleitfaden von Netwrix.

Wie Netwrix Auditor Ihnen hilft, FSMO-Rollenänderungen zu überwachen und zu prüfen

• PDC-Emulator und RID Master auf dem zuverlässigsten DC der Domäne: Beide Rollen erfordern hohe Verfügbarkeit. Der Ausfall des PDC-Emulators wirkt sich sofort auf die Benutzer aus; der Ausfall des RID Masters summiert sich im Laufe der Zeit, wenn Pools erschöpft sind. Platzieren Sie sie auf dem zuverlässigsten und bestvernetzten DC der Domäne.
• Infrastructure Master außerhalb eines globalen Katalogservers: In Umgebungen, in denen nicht alle DCs auch globale Katalogserver sind, sollte der Infrastructure Master auf einem DC laufen, der keine Kopie des globalen Katalogs besitzt. Ein Infrastructure Master, der ebenfalls einen globalen Katalog besitzt, findet niemals Phantomobjekte zum Aktualisieren, daher kann er keine domänenübergreifenden Verweise aktuell halten. Wenn alle DCs in Ihrer Domäne globale Katalogserver sind (üblich in modernen Umgebungen), gilt diese Einschränkung nicht.

Echtzeitwarnungen bei Änderungen der FSMO-Rollen

Netwrix Auditor für Active Directory schließt die Lücke zwischen dem, was native Protokolle erfassen, und dem, was Ihr Sicherheitsteam zur Reaktion benötigt.

Active Directory protokolliert FSMO-Übertragungen im Verzeichnisdienst-Ereignisprotokoll unter der Ereignis-ID 1458, aufgezeichnet auf dem Domänencontroller, der die Rolle erhalten hat, und nennt den vorherigen Inhaber. Das Ereignis bestätigt, dass eine Übertragung stattgefunden hat, liefert jedoch nicht den vollständigen Kontokontext oder die Sitzungsdetails, die für eine Untersuchung erforderlich sind.

Für einen vollständigen Überblick darüber, was in Ihrem Verzeichnis überwacht werden soll, decken die Active Directory auditing guidelines den gesamten Umfang der zu verfolgenden Ereignisse ab.

Eine unautorisierte Übertragung oder Übernahme der FSMO-Rolle ist ein bestätigter AD-Angriffsvektor mit Folgen, die über routinemäßige Betriebsstörungen hinausgehen. Ein Angreifer, der ausreichende Privilegien auf einem Domänencontroller erlangt, kann die PDC Emulator-Rolle übernehmen, um Authentifizierungsanfragen abzufangen, die Zeitsynchronisation zu manipulieren oder die Verteilung von Group Policy im gesamten Domänenbereich zu steuern. Diese Änderungen können in den nativen Windows-Ereignisprotokollen möglicherweise nicht mit ausreichend Kontext erscheinen, um den Akteur und die Absicht zu identifizieren.

Vollständige Audit-Trail vor und nach

Netwrix Auditor warnt in dem Moment, in dem eine FSMO-Rolle übertragen oder übernommen wird. Die Warnungen werden ausgelöst, unabhängig davon, ob die Änderung über PowerShell, die GUI oder ntdsutil vorgenommen wurde, und enthalten das Konto, das die Änderung initiiert hat, den Quellarbeitsplatz und den Zeitstempel. Ihr Team kann geplante Übertragungen sofort überprüfen und nicht erkannte Änderungen eskalieren, bevor weiterer Schaden entsteht.

Compliance-fähige Berichterstattung

Geplante Übertragungen von unbefugten Beschlagnahmungen unterscheiden

Jede Änderung der FSMO-Rolle wird mit dem vorherigen Rolleninhaber, dem neuen Rolleninhaber, dem Konto, das die Aktion ausgeführt hat, und der genauen Zeit der Änderung protokolliert. Native Windows-Ereignisprotokolle lassen diesen Kontext weg. Wenn ein Vorfall eine Rekonstruktion erfordert (für eine interne Untersuchung oder eine externe Prüfung), steht der vollständige Datensatz zur Verfügung, ohne sich auf die Protokollaggregation mehrerer Domänencontroller verlassen zu müssen.

Da Netwrix Auditor den vollständigen Konto- und Sitzungskontext erfasst, kann Ihr Team Rollenänderungen mit Ihren Änderungsmanagement-Aufzeichnungen abgleichen. Eine Übertragung, die von einem benannten Admin-Konto während eines geplanten Wartungsfensters ausgeführt wird, sieht anders aus als eine Übernahme durch ein Konto ohne vorherige administrative Aktivitäten. Die Prüfspur macht diesen Unterschied klar und nachvollziehbar.

Fordern Sie eine Demo an und sehen Sie, wie Netwrix Ihnen hilft, FSMO-Rollenänderungen zu prüfen, jede Active Directory-Änderung zu verfolgen und die ermittlungsbereiten Beweise zu erstellen, die Ihr Sicherheitsteam benötigt.

FSMO-Rollen-Zuweisungen sind Teil des privilegierten Zugriffs, den SOX, HIPAA und ISO 27001-Audits prüfen. Netwrix Auditor erstellt vorgefertigte Berichte über Änderungen von Active Directory-Privilegien, die Auditoranforderungen ohne manuelle Protokollauswertung erfüllen. Die Historie der Rollenänderungen wird gespeichert und ist durchsuchbar, sodass Compliance-Nachweise auf Abruf verfügbar sind und nicht unter Druck zusammengestellt werden müssen.