Beginnen wir mit einer Rückblende in das Jahr 1986: Damals kämpfte sich der Schauspieler Christopher Lambert als Highlander durch das gleichnamige Hollywood-Spektakel. Damit hat der Darsteller offenbar einen derart bleibenden Eindruck hinterlassen, dass sich der Untertitel des Films bis heute im allgemeinen Sprachgebrauch wiederfindet. Es kann nur einen geben – das Highlander-Prinzip.

Mit dem im Vergleich zu heutigen Infrastrukturen überschaubaren Domänenmodell unter Windows NT 3.51 und 4.0 hatte Microsoft das Highlander-Prinzip in Reinkultur implementiert. Genau ein Domaincontroller (DC) fungierte als Primary Domaincontroller (PDC). Nur dieser eine PDC ermöglichte Änderungen am Verzeichnis sowie den darin gespeicherten Benutzer- und Computerkonten mit ihren Attributen und Passwörtern. Um Redundanz und Verfügbarkeit kümmerten sich ein oder mehrere Backup-Domaincontroller (BDC). Die BDCs synchronisierten jedoch nur schreibgeschützte Kopien der Datenbank des PDCs. Fiel der PDC aus, konnten sich Benutzer und Computer zwar noch an der Domäne anmelden, User- und Servermanager funktionierten aber nicht mehr. Um wieder Änderungen im Verzeichnis zu ermöglichen, mussten Admins erst manuell einen der BDCs zum PDC hochstufen und so die volle Funktionalität der Domäne wiederherstellen.

Multimaster-fähige Datenbank als Basis

Mit den Active Directory Domain Services (AD DS), im Folgenden verwenden wir der Einfachheit halber nur noch den kürzeren Oberbegriff Active Directory (AD), hatte Microsoft bereits unter Windows 2000 mit vielen Unzulänglichkeiten aus der Ära von Windows NT aufgeräumt. An die Stelle des rudimentären Domänenmodells ohne hierarchische Strukturen trat mit dem AD ein moderner Verzeichnisdienst, der die Spezifikation des Lightweight Directory Access Protocols (LDAP) vielleicht nicht buchstabengetreu umsetzte, sich aber doch deutlich daran orientierte.

Mit dem AD hat Microsoft eine hierarchische und Multi-Master-fähige Datenbank geschaffen, die den Bedarf von Organisationen nahezu jeder Größenordnung vom kleinen Unternehmen bis zum weltumspannenden Konzern abdeckt. Die Datenbank ist in der Lage, Millionen von Objekten zu verwalten, die die Benutzer, Computer, Gruppen, OUs und andere Ressourcen in einem Netzwerk repräsentieren. Die Hierarchie bilden dabei eine Gesamtstruktur auf oberster Ebene mit einer oder mehreren Domänen darunter sowie Organisationseinheiten (Organizational Units, OU) innerhalb der Domänen.

Gesamtstruktur und Domänen repräsentieren den logischen Aufbau einer Infrastruktur. Das AD verwaltet diese Struktur völlig getrennt von der physischen Struktur und geografischen Gegebenheiten. Für Letztere verwendet das AD losgelöst vom logischen Aufbau das Konzept von Standorten, mit denen sich unser Beitrag zur AD-Replikation detaillierter beschäftigt.

Unter der Haube setzt das AD auf die Microsoft Joint Engine Technology (Jet), genauer auf die Variante Jet Blue, die auch unter der Bezeichnung Extensible Storage Engine (ESE) bekannt ist und das Fundament für den klassischen Microsoft Exchange Server bildet. Diese relationale Datenbank kann – anders als die Variante Jet Red, die etwa als Basis für MS Access dient – auch mit einer sehr großen Anzahl gleichzeitiger Zugriffe umgehen.

Multi-Master-fähig bedeutet dabei, dass die Abhängigkeit von einem einzigen PDC entfällt. Grundsätzlich halten alle DCs eine beschreibbare Kopie der AD-Datenbank. Eine Ausnahme hiervon bildet lediglich der Sonderfall eines Read-only-Domaincontrollers (RODC). Dieser speichert weiterhin nur eine lesende Kopie der Datenbank für den Einsatz in Bereichen mit niedrigerem Sicherheitsniveau, etwa zur Anmeldung an Webservern in der Demilitarisierten Zone (DMZ). Im Folgenden widmen wir uns jedoch den regulären DCs, die lesend und schreibend auf das Verzeichnis zugreifen.

Das Highlander-Prinzip im AD

Abseits der RODCs können alle Domaincontroller Änderungen verarbeiten und dies unabhängig davon, ob sie online oder offline sind, also gerade unmittelbaren Kontakt zu anderen DCs haben oder nicht. Dieses Konzept eignet sich sehr gut für die meisten Aufgaben des Alltags, es bietet Flexibilität und Fehlertoleranz, jedoch auch die Möglichkeit von Konflikten, falls mehrere DCs gleichzeitig versuchen sollten, dieselben Objekte oder Attribute zu ändern. Das Highlander-Prinzip begleitet uns daher auch in einer modernen AD-Infrastruktur weiterhin. Um Konflikte bei besonders betriebskritischen Aufgaben zu vermeiden oder zu minimieren, verwendet das AD ein Single-Master-Modell für bestimmte Arten von Änderungen, die nur jeweils ein einziger DC in einer Gesamtstruktur oder einer ihrer Domänen verarbeiten darf.

Die entsprechenden Rollen bezeichnet Microsoft als Betriebsmaster oder Flexible Single Master Operations (FSMO). Dabei unterscheidet das Unternehmen insgesamt fünf FSMO-Rollen in zwei Kategorien, den gesamtstrukturweiten sowie den domänenweiten Rollen. Erstere existieren innerhalb einer Gesamtstruktur nur einmal, letztere pro Domäne. Im einfachsten Fall einer Gesamtstruktur mit nur einer Domäne darin hält typischerweise der zuerst installierte DC alle fünf Rollen und nimmt damit eine ähnliche Position ein wie der PDC zu seligen Zeiten von Windows NT. Anders als früher können Sie die Rollen jedoch flexibel auch auf mehrere DCs verteilen und zwischen ihnen verschieben.

Zwei FSMO-Rollen pro Gesamtstruktur

Schema- und Domänennamen-Master existieren nur einmal pro Gesamtstruktur. Das Schema ist die Blaupause für die Struktur der AD-Datenbank und definiert sämtliche Klassen von Objekten mit ihren Attributen sowie deren Syntax. Ein DC, der die Rolle des Schema-Masters hält, ist für die Verarbeitung sämtlicher Schemaänderungen verantwortlich. Er stellt sicher, dass das Schema konsistent und in der gesamten Struktur repliziert ist.

Sie können das Schema erweitern, um neue Objekt- oder Attributtypen hinzuzufügen, die neue Anwendungen oder Dienste benötigen. Das ist typischerweise bei Upgrades des ADs sowie bei Installation und Updates lokaler Instanzen des Exchange-Servers der Fall. Um solche Änderungen vorzunehmen, benötigen Sie ein Benutzerkonto, das Mitglied der Gruppe der Schema-Administratoren ist, und der Schemamaster muss zu diesem Zeitpunkt online sein.

Der Domänennamen-Master (Domain Naming Master) ist der DC, der das Hinzufügen oder Entfernen von Domänen in einer Gesamtstruktur koordiniert. Er stellt sicher, dass die Domänennamen eindeutig sowie synchronisiert sind, und ist weiterhin für die Verwaltung der Vertrauensstellungen zwischen Domänen verantwortlich. Auch hier greift das Highlander-Prinzip, denn es kann nur einen Domänennamen-Master innerhalb einer Gesamtstruktur geben und dieser muss zum Zeitpunkt einer Änderung online sein. Sie können nur dann neue Domänen anlegen oder bestehende entfernen, wenn Sie den Domänennamen-Master erreichen und er die jeweilige Änderung bestätigt.

Drei weitere Rollen pro Domäne

Hinzu gesellen sich drei domänenweite Rollen, die jeweils ein DC in einer bestimmten Domäne übernimmt. Auch hier kann es also bezogen auf die Grenzen der Domäne jeweils nur einen geben. Dies betrifft den Infrastruktur-Master, den RID-Master sowie den PDC-Emulator. Der Infrastruktur-Master ist vor allem in größeren Umgebungen mit mehreren Domänen relevant, er kümmert sich um das Aktualisieren von Verweisen auf Objekte in anderen Domänen. Dies ist wichtig, wenn Sie Objekte in einer Domäne umbenennen oder verschieben, da es die Mitgliedschaft oder die Berechtigungen von Objekten in anderen Domänen beeinflussen kann. Betreiben Sie noch lokale Exchange-Server, nutzen auch diese den Infrastruktur-Master, um Verteilergruppen aufzulösen.

Beachten Sie beim Infrastruktur-Master auch dessen Abhängigkeit vom globalen Katalog (Global Catalog, GC), auf den wir gleich zurückkommen. Der Infrastruktur-Master vergleicht seine Daten mit denen des globalen Katalogs, der eine teilweise Kopie aller Objekte in der Gesamtstruktur enthält, und aktualisiert sie entsprechend. Ein DC, der den GC bereitstellt, kann nur dann die Rolle des Infrastruktur-Masters übernehmen, wenn alle DCs innerhalb der Domäne den GC halten. Andernfalls dürfen sich Infrastruktur-Master und GC nicht auf demselben DC befinden. Eine weitere Besonderheit betrifft den optionalen AD-Papierkorb. Sobald Sie den Papierkorb aktivieren, kümmert sich jeder DC selbsttätig darum, domänenübergreifende Objektverweise bei Änderungen zu aktualisieren. In diesem Fall kommt dem Infrastruktur-Master keine Bedeutung mehr zu.

Der RID-Master kümmert sich um die Vergabe von Pools von relativen IDs (Relative Identifier, RID) an die DCs einer Domäne, die diese beim Erstellen neuer Objekte benötigen. Die Funktion wird deutlich anhand des Aufbaus des Security Identifiers (SID) von Objekten im AD. Jede SID besteht aus einem Präfix, das für alle Objekte in der Domäne identisch ist, sowie einem eindeutigen Teil, der pro Objekt eindeutig ist und nicht doppelt vorkommen darf, der RID. Eine RID ist also eine Nummer, die ein DC einem Objekt beim Erstellen zuweist, um es eindeutig zu identifizieren. Dazu verfügt jeder DC über einen Pool von RIDs, einen Block von jeweils 500 IDs, die er an neue Objekte fortlaufend vergibt. Ist ein solcher Pool zur Hälfte erschöpft, fordert der DC beim RID-Master einen weiteren Pool an. Der RID-Master stellt dabei sicher, dass die RIDs eindeutig sind. Beim Ausfall des RID-Masters können Sie keine neuen Objekte mehr anlegen, sobald alle übrigen DCs ihre Pools aufgebraucht haben.

Zu guter Letzt trägt der PDC-Emulator den deutlichsten Hinweis auf das Erbe von Windows NT im Namen. Der PDC-Emulator kümmert sich je nach Einsatzszenario um Passwortänderungen, die Synchronisation von Zeit und Gruppenrichtlinien sowie Kompatibilität mit älteren Versionen von Windows. Dieser Prä-Windows-2000-kompatible Zugriff hat heutzutage nur noch historische Bedeutung.

Weiterhin fungiert der PDC-Emulator pro Domäne als Taktgeber für den Windows-Zeitdienst. Der PDC-Emulator in der Stammdomäne der Gesamtstruktur ist für die gesamte Organisation autoritativ. Sie sollten diesen entsprechend so konfigurieren, dass er seine Zeit mit einer externen Quelle synchronisiert. Alle PDC-Emulatoren nachgeordneter Domänen orientieren sich bei der Auswahl ihres Partners für die eingehende Zeitsynchronisation an der Hierarchie der Domänen innerhalb der Gesamtstruktur.

Der PDC-Emulator spielt zudem bei Änderungen von Benutzerkennwörtern eine besondere Rolle. Grundsätzlich kann jeder DC eine solche Änderung verarbeiten. Kennwortänderungen werden jedoch bevorzugt an den PDC-Emulator repliziert, damit sie möglichst schnell in der Domäne verfügbar sind. Schlägt eine Authentifizierung aufgrund eines vermeintlich falschen Kennworts fehl, fragt ein DC zudem beim PDC-Emulator nach, bevor er die Anmeldung endgültig zurückweist.

Rolleninhaber ermitteln

Die Inhaber der Rollen identifizieren Sie über die klassische Kommandozeile mithilfe des Befehls netdom query fsmo. Alternativ nutzen Sie die PowerShell:

Get-ADForest | select SchemaMaster, DomainNamingMaster | fl

Get-ADDomain | select InfrastructureMaster, RIDMaster, PDCEmulator | fl

Die Vorteile der PowerShell bestehen darin, dass Sie das Ergebnis nach Ihren Wünschen formatiert ausgeben können, hier exemplarisch als formatierte Liste über "format-list, fl" oder auch als Tabelle über "format-table, ft". Aufgrund der objektorientierten Arbeitsweise der PowerShell lässt sich die Ausgabe auch zur weiteren Verarbeitung an andere Cmdlets weiterreichen.

Im Vergleich mit einem früheren PDC sei positiv erwähnt, dass der Ausfall einer oder mehrerer der FSMO-Rollen nicht sofort sämtliche administrativen Vorgänge im AD beeinträchtigt. Im Umkehrschluss bedeutet dies jedoch auch, dass Sie den Ausfall vielleicht nicht unmittelbar bemerken und Störungen erst zeitverzögert auftreten. Mögliche Auswirkungen hängen von der ausgefallenen Rolle, der Dauer des Ausfalls und der Art der Änderungen ab, die Sie im AD vornehmen möchten. Als Faustformel gilt, je länger eine FSMO-Rolle ausfällt, desto größer ist die Wahrscheinlichkeit, dass Probleme auftreten.

Rollen übertragen

Der bevorzugte Weg, FSMO-Rollen sauber und sicher von einem DC auf einen anderen zu verschieben, ist das Übertragen. Dies setzt allerdings voraus, dass der ursprüngliche Halter der jeweiligen Rolle noch funktionsfähig und online ist. Sollte eine FSMO-Rolle vorübergehend ausfallen, etwa aufgrund von Netzwerk- oder Hardwareproblemen, können Sie abwarten, bis der entsprechende DC wieder online ist, oder versuchen, das Problem zu beheben.

Fällt jedoch der Halter einer FSMO-Rolle irreparabel aus, bleibt Ihnen nur, die betroffene Rolle auf einen anderen DC zu übernehmen. Hierbei ist Vorsicht geboten, denn dabei handelt es sich um eine erzwungene Methode, die Sie nur verwenden sollten, wenn der ursprüngliche Halter der Rolle nicht mehr verfügbar ist und keinesfalls mehr zurückkehrt.

Der Weg zum Übertragen der FSMO-Rollen mittels grafischer Tools ist auch unter Windows Server 2025 eher unkomfortabel. Um den Schema-Master zu übertragen, müssen Sie zunächst eine Bibliothek registrieren, damit das zugehörige Werkzeug überhaupt sichtbar wird. Führen Sie dazu in einer administrativen Kommandozeile den folgenden Befehl aus:

regsvr32.exe schmmgmt.dll

Nun öffnen Sie mittels mmc.exe eine leere Instanz der Microsoft Management Console (MMC) und wählen aus dem Menü die Option "Snap-in hinzufügen/entfernen...". Aus der Liste der verfügbaren Snap-ins fügen Sie dann das "Active Directory-Schema" den auswählten Snap-ins unterhalb des Konsolenstamms hinzu und bestätigen mit "OK" (Bild 1). Im Hauptfenster finden Sie anschließend im Kontextmenü des Eintrags "Konsolenstamm / Active Directory-Schema…" den Punkt "Betriebsmaster…", mit dem Sie die Rolle des Schema-Masters auf einen anderen DC übertragen. Analog dazu öffnen Sie die MMC "Active Directory-Domänen und Vertrauensstellungen", erreichen auch dort über das Kontextmenü des obersten Knotens den Punkt "Betriebsmaster…" und übertragen damit den Domänennamen-Master.

Zu guter Letzt verwenden Sie für die drei domänenspezifischen Rollen die MMC "Active Directory-Benutzer und -Computer" und navigieren per Rechtsklick auf den obersten Knoten zur Aktion "Alle Aufgaben / Betriebsmaster...". Hier finden Sie nun einen Assistenten, der auf drei Registerkarten verteilt den Infrastruktur-Master, den RID-Master sowie den PDC-Emulator überträgt.

Deutlich schneller als über drei verschiedene grafische Konsolen gelangen Sie per PowerShell-Cmdlet ans Ziel. Der folgende Befehl erwartet eine oder mehrere Rollen als Parameter und überträgt sie auf den angegebenen Ziel-DC:

Move-ADDirectoryServerOperationMasterRole -Identity <Ziel-DC> -OperationMasterRole, SchemaMaster, DomainNamingMaster, InfrastructureMaster, RIDMaster, PDCEmulator

Per klassischer Kommandozeile erledigt alternativ das Werkzeug ntdsutil.exe die Aufgabe, das auch beim Troubleshooting, zwangsweisen Übernehmen von Rollen und allgemeinen Reparaturen am AD zum Einsatz kommt.

Funktionen des globalen Katalogs

Um Objekte in einer größeren Gesamtstruktur mit mehreren Domänen effizient zu finden und zu verwalten, kommt der GC zum Einsatz. Anders als bei den FSMO-Rollen begegnet uns hierbei nicht das Highlander-Prinzip. Es handelt sich beim GC um eine erweiterte Kopie der AD-Datenbank mit einer übergeordneten Teilmenge der Objekte und ihrer Attribute. Entsprechend konfigurierte DCs halten eine vollständige Kopie aller Objekte und Attribute ihrer eigenen Domäne sowie eine definierte Teilmenge aller Objekte und Attribute aller anderen Domänen in der Gesamtstruktur.

Diese Teilmenge umfasst nur die häufig verwendeten Attribute, die Sie domänenübergreifend für die Suche und Authentifizierung von Benutzern benötigen. Dazu zählen etwa deren Namen, E-Mail-Adresse sowie ihre Mitgliedschaft in universellen Gruppen. Über die von Microsoft vorkonfigurierte Auswahl von Attributen hinaus können Sie mit einer Änderung des AD-Schemas weitere Attribute in den Katalog aufnehmen.

Der GC hilft bei der schnellen und einfachen Suche nach Objekten in der Gesamtstruktur, ohne dass dazu zwingend eine Verbindung zu den DCs jeder Domäne erforderlich ist. Dadurch reduziert er den Netzwerkverkehr und die Latenz bei domänenübergreifenden Suchvorgängen. Weiterhin ermöglicht der GC die Authentifizierung von Benutzern, die sich per User Principal Name (UPN), also einem Benutzernamen der Form "user@example.com", anmelden.

Der erste DC in der Stammdomäne einer neu installierten Gesamtstruktur hält automatisch auch den GC. Weitere DCs richten Sie manuell über die MMC "Active Directory-Standorte und -Dienste" ein. Navigieren Sie dort zur Konfiguration des gewünschten DC unter "Sites / <Standort> / Servers / <Ziel-DC> / NTDS Settings". Öffnen Sie die Eigenschaften dieses Knotens und aktiveren Sie im folgenden Dialog auf der Registerkarte "Allgemein" die Option "globaler Katalog" (Bild 2).

Im einfachsten Fall einer Gesamtstruktur mit lediglich einer einzelnen Domäne darin aktivieren Sie einfach auf allen DCs auch den GC. Konfigurieren Sie in Gesamtstrukturen mit mehreren Domänen mindestens einen GC pro geografischen Standort, um die Anmeldezeit zu verkürzen und die Abhängigkeit von WAN-Verbindungen zu verringern. Mehrere GCs pro Standort sorgen für Ausfallsicherheit und Lastverteilung. Doch einfach alle vorhandenen DCs auch für den GC zu verwenden, kann sich je nach Größe und Komplexität einer Gesamtstruktur aufgrund erhöhten Datenverkehrs für die Replikation auch als kontraproduktiv erweisen. Ausführlich widmen wir uns den AD-Standorten sowie der Platzierung und Replikation von Servern mit und ohne GC im separaten Beitrag zur AD-Replikation.

Fazit

Die FSMO-Rollen nehmen besondere Aufgaben beim Betrieb einer AD-Infrastruktur wahr. Der Ausfall einer oder mehrerer Rollen führt nicht zwangsläufig sofort zu Störungen, kann je nach betroffener Rolle und Dauer jedoch wichtige administrative Funktionen beeinträchtigen. Die Rollen wie auch der GC sind daher für die ordnungsgemäße Funktion des Active Directory essenziell. Behalten Sie im Blick, welche DCs Ihrer Umgebung diese Aufgaben übernehmen, und nehmen Sie die Systeme ins Monitoring auf, soweit noch nicht geschehen. Die Befehle und Werkzeuge aus diesem Workshop helfen Ihnen dabei, die Rollen bei Bedarf auf andere DCs zu verschieben. Machen Sie sich, vorzugsweise zunächst in einer Testumgebung, mit ihrer Funktion und Handhabung vertraut, um für den Notfall und bei geplanten Migrationen gerüstet zu sein. (jp/ln)

Über den Autor: Dr. Christian Knermann veröffentlichte bisher zahlreiche Artikel im Bereich der Informationstechnologie für verschiedene Fachmagazine – darunter seit 20 Jahren für den IT-Administrator. Außerdem wirkt er an Buchprojekten mit und trägt auf nationalen und internationalen Konferenzen vor.

FAQs

Dieser Artikel erschien im IT-Administrator Sonderheft II/2024

"Active Directory – Administration,
Security und Troubleshooting"

Das Sonderheft II/2024 zeigt auf 211 Seiten Best Practices sowohl für den lokalen als auch den hybriden Betrieb des Active Directory und deckt dabei praxisnah Aspekte wie Betriebsmasterrollen, Globalen Katalog, AD-Migration und -Upgrades, Replikation, Standortkonzepte sowie Zertifikatsdienste einschließlich PKI ab.

Bestellen Sie das Sonderheft hier als E-Paper
(Die gedruckte Ausgabe ist leider vergriffen)