8Active Directory-Domänendienste

Auf der Schulter den Bogen und ringsverschlossenen Köcher.
Laut erschallen die Pfeile zugleich an des Zürnenden Schulter,
Als er einher sich bewegt’; er wandelte, düster wie Nachtgraun;
Setzte sich drauf von den Schiffen entfernt, und schnellte den Pfeil ab;
Und ein schrecklicher Klang entscholl dem silbernen Bogen.

Wenn Sie in Windows Server 2012 die Liste der hinzuzufügenden Rollen betrachten, sehen Sie nicht nur eine Active Directory-Rolle, sondern fünf (Abbildung 8.1):

• Active Directory-Domänendienste: Hierbei handelt es sich um das eigentliche Active Directory.

  

  Abbildung 8.1 Nicht weniger als fünf Rollen haben einen Namen, der mit »Active Directory« beginnt.

• Active Directory-Verbunddienste (AD Federation Services): Dieser seit Windows Server 2003 R2 vorhandene Dienst wird verwendet, um Benutzer zu authentifizieren, die sich außerhalb Ihres Active Directorys befinden, und zwar ohne eine zusätzliche Anmeldung.
• Active Directory Lightweight Directory Services: Hinter dieser Bezeichnung verbirgt sich ein auf Active Directory-Technologie basierender LDAP-Server – früher bekannt als ADAM, Active Directory Application Mode.
• Active Directory-Zertifikatdienste: Die Zertifikatdienste sind grundsätzlich bereits von den vorherigen Versionen von Windows Server bekannt. Dort trugen sie allerdings noch kein »Active Directory« im Namen.
• Active Directory-Rechteverwaltungsdienste: Hier geht es um den Schutz von Informationen (z. B. Dokumenten, Nachrichten) mit kryptografischen Methoden.

In diesem Kapitel werden wir uns schwerpunktmäßig mit den Domänendiensten befassen, also der Keimzelle des Active Directory.

8.1 Aufbau und Struktur

Die Installation eines Domänencontrollers und damit die grundsätzliche Einrichtung eines Active Directory ist nicht schwierig – auch ein Anfänger ohne tiefergehende Kenntnisse kann das innerhalb weniger Minuten erledigen. Die Kehrseite der Medaille ist, dass viele Active Directorys zwar funktionieren, aber gegenüber der flachen NT4-Domänenstruktur kaum Vorteile bieten. In einem kleinen Unternehmen mit 10 PC-Arbeitsplätzen ist das im Normalfall kein Problem. Bei einem größeren Mittelständler verschenkt man aber sehr viel Optimierungspotenzial, wenn man die Möglichkeiten des ADs nur zu einem ganz geringen Teil ausnutzt.

Dieser erste Abschnitt des Kapitels über Active Directory-Domänendienste zeigt die wesentlichen Grundlagen.

8.1.1 Logische Struktur

Betrachten wir zunächst die logische Struktur des Active Directory. Die wesentlichen Elemente sind:

• Domäne
• Tree
• Forest/Gesamtstruktur
• Namensraum
• OU = Organizational Unit = Organisationseinheit

Domäne

Die Domäne ist die »Keimzelle« einer Active Directory-Umgebung. Sie muss aus mindestens einem Domänencontroller (Domain Controller, DC) bestehen. Da die Domäne ohne einen Domänencontroller nicht arbeitsfähig ist, wird man in einem produktiven Umfeld aus Redundanzgründen mindestens zwei DCs planen. Weitere Objekte einer Domäne sind:

• Member Server: Das sind Server, die Dienste wie Exchange, SQL, Fileservices etc. bereitstellen und eben keine Domänencontroller sind.
• PCs
• Benutzer
• Benutzergruppen
• Organizational Units: Über diese erfahren Sie im weiteren Verlauf des Kapitels Genaueres.

Abbildung 8.2 Eine Domäne enthält mindestens einen Domänencontroller (Domain Controller). Im Allgemeinen werden auch Member Server, PCs, Benutzer und Benutzergruppen in einer Domäne vorhanden sein.

Einige weitere Objekte können ebenfalls in einer Domäne angelegt werden, haben aber für einen ersten Überblick keine Bedeutung.

Neue Objekte werden in Active Directory-Benutzer und -Computer angelegt. Abbildung 8.3 zeigt das entsprechende Kontextmenü.

Abbildung 8.3 Verschiedene Objekte können in »Active Directory-Benutzer und -Computer« hinzugefügt werden.

Wenn Ihr Unternehmen nicht allzu groß und nicht allzu komplex strukturiert ist, werden Sie vermutlich nur eine einzige Domäne betreiben. Auch wenn Sie mehrere NT4-Domänen benötigt haben, bedeutet das nicht, dass dies im Active Directory-Umfeld beibehalten werden muss, da die OUs (Organizational Units) den Aufbau einer leistungsfähigen Struktur ermöglichen.

Im NT4-Umfeld gab es Primary Domänencontroller (PDC) und Backup Domänencontroller (BDC). Alle Änderungen (z. B. das Anlegen von Benutzerkonten) wurden auf dem PDC durchgeführt, der diese Änderungen unidirektional an die untergeordneten BDCs weitergegeben (synchronisiert) hat. Im AD-Umfeld sind prinzipiell alle Domänencontroller gleich, d. h., Änderungen können auf allen DCs durchgeführt werden. Diese replizieren mit den anderen in einer Multimaster-Replikation. Über die Replikationstopologie brauchen Sie sich keine Gedanken zu machen: Das System ermittelt selbstständig eine recht optimierte Topologie; ein manuelles Eingreifen und Optimieren ist im Allgemeinen nur in sehr großen und gleichzeitig sehr komplexen Umgebungen notwendig.

Tree

Wenn in Ihrer Organisation mehrere Domänen benötigt werden, bildet man einen Tree (Abbildung 8.4). Das Wichtigste zu Trees in Stichworten:

• Die Domänen bleiben jeweils eigenständige »Verwaltungszonen«, d. h., der Administrator der höchsten Domain hat nicht automatisch Administrationsberechtigungen in den darunter angeordneten Domains.
• Es werden automatisch transitive Vertrauensstellungen zwischen den Domänen eingerichtet (Kerberos Two Way Transitive Trusts). Das bedeutet: Auch wenn sie nicht explizit eingerichtet werden müssen, existieren zwischen allen Domänen Vertrauensstellungen.
• Der Tree ist ein einheitlicher Namensraum (mehr dazu später).
• Es gibt keine Vererbungen von Gruppenrichtlinien (mehr dazu später) über Domänengrenzen hinweg. Die Gruppenrichtlinien der obersten Domäne vererben sich also nicht auf die darunterstehenden.

Abbildung 8.4 Mehrere Domänen bilden einen Tree.

Fazit: Jede Domäne muss separat administriert werden. Das kann so gewollt sein, beispielsweise wenn zwei fusionierte Firmen zwar ein gemeinsames Active Directory einrichten, ansonsten aber weitgehend autark arbeiten wollen. Im Endeffekt gilt allerdings: »Viele Domänen machen viel Arbeit.«

Da es oft Unklarheiten gibt, hier noch einige Anmerkungen zum Thema »Vertrauensstellungen« (Abbildung 8.5):

• Die Vertrauensstellung zwischen zwei Domänen eines Trees bedeutet, dass der Benutzer aus Domäne 1, der auf eine Ressource in Domäne 2 zugreifen will, von Letzterer nicht nochmals authentifiziert wird.
• Wenn in Domäne 1 festgestellt wurde, dass der Benutzer ein gewisser »Ulrich B. Boddenberg« ist, wird die Ressource zwar prüfen, ob dieser Benutzer Zugriff hat – sie wird aber nicht nochmals die Prüfung der »Echtheit« vornehmen.

Abbildung 8.5 Zugriff auf eine Ressource einer anderen Domäne

Ein Vergleich aus dem wahren Leben: Wenn Sie eine große Firma besuchen, wird man Ihnen am Empfang einen Besucherausweis aushändigen, eventuell erst, nachdem Sie sich ausgewiesen haben. Mit dem Aushändigen des Besucherausweises ist festgestellt worden, wer Sie sind. Darüber, ob Sie jeden Büroraum des Gebäudes betreten dürfen, macht der Besucherausweis keine Angaben. Dies wird der jeweilige Benutzer des Büroraums individuell entscheiden.

Gesamtstruktur/Forest

Die nächstgrößere Organisationseinheit ist die Gesamtstruktur bzw. der Forest. Er besteht (ganz wie im richtigen Leben) aus mehreren Trees (Abbildung 8.6).

Merkmal eines Forests ist insbesondere, dass jeder Tree einen eigenen Namensraum (siehe den nächsten Abschnitt) darstellt. Diese Konstruktion würde Sinn machen, wenn ein multinationaler Großkonzern seine jeweils aus mehreren Firmen bestehenden Geschäftsbereiche weitgehend autark lassen will, aber trotzdem eine gemeinsame übergreifende AD-Struktur einführen möchte.

Für den gesamten Forest gibt es übrigens ein einheitliches Schema (das Schema wird weiter hinten besprochen). Wenn jemand dem Schema ein Attribut hinzufügen möchte, wird dieses in der gesamten Organisation vorhanden sein.

Abbildung 8.6 Ein Forest besteht aus mehreren Trees.

Namensraum

Active Directory arbeitet mit einer auf DNS basierenden Namensstruktur. Sie haben beim Tree gesehen, dass die Anordnung der Domäne keine Auswirkungen auf die Sicherheitseinstellungen hat, also ist der Administrator der »höheren« Domäne nicht automatisch Administrator der darunter angeordneten.

Die Anordnung der Domäne hat allerdings Auswirkungen auf die DNS-Namen der Domäne. Am besten schauen Sie sich den Tree in Abbildung 8.7 an:

• Die oberste Domäne heißt alpha.intra. Die darunter angeordnete Domäne heißt deutschland.alpha.intra etc.
• Für die in der Domäne angesiedelten Objekte leiten sich entsprechende DNS-Namen ab: So heißt beispielsweise die Maschine server01 in der obersten Domäne server01.alpha.intra.

In einem Forest gibt es keinen einheitlichen Namensraum. In einem solchen Konstrukt bleiben die einzelnen Trees bezüglich des Namensraums autark.

OU = Organizational Unit = Organisationseinheit

Im Gegensatz zu NT4-Domänen können Active Directory-Domänen weiter unterteilt werden, und zwar in Organizational Units (OUs), die in den deutschen Windows-Versionen Organisationseinheiten genannt werden. In einer OU können sich Benutzer, Computer, Server oder auch andere OUs befinden.

Abbildung 8.7 Der hierarchische Namensraum eines Trees

In Abbildung 8.8 ist eine Domäne mit sechs Organizational Units gezeigt:

• Die Domänencontroller sind in der OU DC angelegt.
• Alle anderen Server befinden sich in der OU Server.
• In der OU entwicklung befinden sich die Benutzer, PCs und Gruppen der Entwicklungsabteilung. Die Abteilungsleiter nebst PCs sind in der Unter-OU leitung angesiedelt.
• Genauso wie die OU entwicklung ist die OU vertrieb aufgebaut.

Abbildung 8.8 Eine Domäne mit Organisationseinheiten

Der Sinn und Zweck der OUs ist es, die Struktur Ihrer Firma abzubilden. Wenn Sie das Active Directory nur dazu verwenden würden, Benutzerkonten und die zugehörigen Passwörter einzutragen, wären OUs letztendlich überflüssig, aber es ergeben sich viele andere Möglichkeiten. Zum Beispiel:

• Mithilfe von Gruppenrichtlinien (GPO = Group Policy Objects) können Sie gezielt Konfigurationsanpassungen für Benutzer und Computer in einer OU vornehmen.
• Sie können mit Werkzeugen zur Softwareverteilung den neuen CRM-Client gezielt an die Mitglieder der OU vertrieb verteilen.
• Sie können Login-Skripts in Abhängigkeit von der OU-Zugehörigkeit definieren.
• Benutzer können die AD-Struktur durchsuchen und so herausfinden, wer zur Leitung des Vertriebs gehört (nämlich die Benutzer, die in dieser Unter-OU angesiedelt sind).
• Vielleicht setzen Sie demnächst Software ein, die anhand der OU-Zugehörigkeit bestimmte Funktionen bietet und Benutzerrechte ableitet.

Organizational Units sind übrigens bezüglich des Namensraums transparent. Der DNS-Name eines Servers ist server.domain.intra, egal in welcher OU er sich befindet.

OUs vs. Gruppen

Man kann nicht direkt den Mitgliedern einer OU Ressourcenrechte gewähren. Wenn Sie eine Freigabe für die Benutzer der Vertriebsleitung angelegt haben, können Sie also nicht direkt diese OU als berechtigt eintragen – leider!

Sie müssen in der OU eine Gruppe anlegen. Diese enthält als Mitglieder die in dieser OU angelegten Benutzer – das müssen Sie leider manuell zuweisen. Dieser Gruppe können Sie dann Berechtigungen für das Filesystem zuweisen (Abbildung 8.9).

Generell sollten Sie sich bei der Planung Gedanken über die Gruppenstrukturen machen. Mit einer einfachen und durchgängigen Struktur können Sie viel Administrationsarbeit sparen.

Das klassische Beispiel: Wer darf auf eine Dateifreigabe zugreifen?

• Sie richten eine Lokale Gruppe ein, der Sie die Berechtigung zum Zugriff auf die Fileshare erteilen.
• Wenn z. B. die Mitglieder der Vertriebsleitung Zugriff haben sollen, wird die Gruppe Vertriebsleitung Mitglied dieser Gruppe. Vertriebsleitung wird übrigens als globale Gruppe angelegt.

Abbildung 8.9 Da man OUs keine Ressourcenberechtigungen zuweisen kann, empfiehlt sich das Anlegen einer Gruppe.

Daraus ergibt sich folgende Faustregel:

• Benutzer fasst man in globalen Gruppen zusammen.
• Ressourcenberechtigungen weist man lokalen Gruppen zu.
• Globale Gruppen werden Mitglied in lokalen Gruppen.

Und weil es auch nach dreimaligem Lesen verwirrend ist, folgt diese Struktur hier noch als Skizze (Abbildung 8.10).

Abbildung 8.10 Benutzer werden Mitglied in globalen Gruppen. Die globalen Gruppen werden wiederum Mitglied in lokalen Gruppen, denen Ressourcenberechtigungen zugewiesen sind.

Stichwortartig noch einige weitere Anmerkungen zu Gruppen:

• Gruppen können verschachtelt werden, d. h., die Gruppe Vertrieb kann die Gruppen V_Innendienst und V_Aussendienst enthalten.
• Globale Gruppen werden nicht über Domänengrenzen hinweg repliziert.
• Domänenübergreifend funktionieren Universelle Gruppen.
• Best Practice, wenn Sie eine domänenübergreifende Grupppe benötigen: Wenn Sie beispielsweise in jeder Domäne eine globale Gruppe Vertrieb angelegt haben, würde man eine universelle Gruppe U_Vertrieb einrichten, deren Mitglieder die Vertrieb-Gruppen der einzelnen Domänen sind. Der Vorteil ist, dass sich die Mitgliedschaft der universellen Gruppe nicht ändert (dort sind ja nur die globalen Gruppen Mitglied) und somit der Replikationsverkehr zwischen den Domänen begrenzt bleibt. Die Gruppe U_Vertrieb würde dann Mitglied einer lokalen Gruppe, um die Berechtigung für den Ressourcenzugriff zu erteilen.
• Replikation: In sehr großen Umgebungen mit Außenstandorten, die über schmalbandige WAN-Strecken angebunden sind, ist der durch Gruppenmitgliedschaften erzeugte Replikationsverkehr durchaus planungsrelevant.

Sie sehen, dass das Thema »Gruppen« nicht ganz trivial ist. Es ist in den meisten Umgebungen durchaus sinnvoll, hin und wieder das Gruppenkonzept einer kritischen Prüfung zu unterziehen. Es macht Sinn, das Thema »Gruppen« deutlich genauer zu betrachten – das passiert in Abschnitt 8.5.

8.1.2 Schema

In den vorangegangenen Erläuterungen ist der Begriff Schema bereits erwähnt worden. Das Schema ist sozusagen die Datenbankstruktur des Active Directory. In ihm ist beispielsweise definiert, dass es beim Benutzerobjekt eine Eigenschaft »E-Mail-Adresse« gibt. Mehr über den Aufbau des Schemas lesen Sie ein wenig weiter hinten.

Das Schema ist übrigens für eine Active Directory-Gesamtstruktur einzigartig (d. h. überall gleich). Um dies sicherzustellen, werden Änderungen am Schema nur auf einem DC vorgenommen, und zwar auf demjenigen mit der Betriebsmasterrolle Schemamaster.

Wenn Sie genauer ins Active Directory schauen, werden Sie Klassen und Attribute finden:

• Klassen sind Objekte wie Accounting, Computer und dergleichen mehr.
• Mit Attributen wird eine Klasse genauer beschrieben, d. h., es werden Eigenschaften wie ein Name definiert.

Abbildung 8.11 zeigt das Snap-In ADSI-Editor (um es aufzurufen, starten Sie die MMC und fügen das Snap-In hinzu). Mit ihm können Sie das Schema untersuchen. Sie erkennen Attribute (»attributeSchema«) und Klassen (»classSchema«).

Abbildung 8.11 Mit ADSI-Editor kann das Schema des Active Directory genauer betrachtet werden.

Wenn Sie eine Klasse genauer betrachten (was in Abbildung 8.12 am Beispiel der Klasse »account« gezeigt wird), sehen Sie, dass einer Klasse beliebig viele Attribute zugeordnet werden können. Dabei kann ein Attribut mehreren Klassen zugeordnet sein. So verfügen beispielsweise viele Klassen über das Attribut »displayName«.

Abbildung 8.12 Eine Klasse enthält beliebig viele Attribute.

Um es an dieser Stelle ganz deutlich zu erwähnen: Es ist mittels ADSI-Edit und anderen Werkzeugen recht einfach, am Schema »herumzubasteln«. Ebenso einfach ist es aber auch, das Schema und damit häufig auch die komplette Netzwerkumgebung nachhaltig zu beschädigen; im Extremfall kann sich niemand mehr im Netz anmelden.

Zu beachten ist auch, dass eine Schemaerweiterung (jede Veränderung gilt als Erweiterung) in der kompletten Organisation repliziert wird. Wenn Sie also ein Attribut ergänzen, freuen sich auch Ihre Kollegen, die den Domänencontroller der chinesischen Niederlassung betreuen.

Weiterhin sind Änderungen am Schema nicht vollständig rückgängig zu machen. Es gibt viele gute Gründe dafür, eine Schemaerweiterung durchzuführen. Dies sollte aber immer erst nach reiflicher Überlegung erfolgen.

Administrieren mit ADSI-Editor

ADSI-Editor kann übrigens nicht »nur« verwendet werden, um das Schema anzupassen, man kann mit diesem Werkzeug auch die Inhalte des ADs unter Umgeheung der eigentlichen AD-Management-Applikationen verändern. Hierzu klicken Sie mit der rechten Maustate auf den Eintrag ADSI-Editor (ganz oben) und entscheiden sich für Konfiguration. Wie in Abbildung 8.13 zu sehen ist, können die Inhalte des Active Directory, beispielsweise die Namenskontexte (Partitionen), eingesehen und modifiziert werden.

Abbildung 8.13 ADSI-Editor gestattet einen tiefen Blick in die Interna des Active Directory.

Abbildung 8.14 Man könnte zwar die Administration der Benutzerkonten prinzipiell mit ADSI- Editor durchführen – das ist aber keinesfalls zu empfehlen!

Wählt man in ADSI-Editor die Bearbeitung des Standardmässigen Namenskontext, sind die Informationen zu sehen, die normalerweise im Snap-In Active Directory-Benutzer und -Computer bearbeitet werden. Wie in Abbildung 8.14 zu sehen ist, kann man auch direkt die Werte der Attribute, beispielsweise des Benutzers, modifizieren.

Im Normalfall sollten Sie nicht mit ADSI-Editor direkt das Active Directory bearbeiten. In der Microsoft Knowledge Base sind hin und wieder Fälle beschrieben, in denen derartige Eingriffe notwendig sind. Außer in diesen »kontrollierten Situationen« sollten Sie die hier beschriebenen Möglichkeiten ausschließlich nutzen, um das Innenleben des ADs zu erkunden, was übrigens sehr interessant sein kann.

Arbeiten mit dem Schema-Manager

Wer noch intensiver mit dem Schema arbeiten möchte, benötigt das Schema Manager-Snap-In. Dieses taucht nicht standardmäßig in der Liste der Administrations-Snap-Ins auf, ist aber auf Windows Server 2008 ff. bereits vorhanden und muss lediglich registriert werden. Dazu öffnen Sie die Eingabeaufforderung, navigieren in das Verzeichnis c:\windows\system32 und geben folgenden Befehl ein:

regsvr32 schmmgt.dll
      
   

Abbildung 8.15 Wer sich intensiv mit dem Schema befassen möchte, benötigt das »Schema Manager«-Snap-In; es muss registriert werden.

Kurz danach wird eine Dialogbox darauf hinweisen, dass das Objekt registriert worden ist. Wenn Sie nun die MMC erneut (!) öffnen, findet sich bei den hinzufügbaren Snap-Ins das soeben registrierte mit dem Namen Active Directory Schema. In Abbildung 8.15 ist das Snap-In zu sehen. Man erkennt die bekannten Grundelemente, nämlich Klassen und Attribute.

An dieser Stelle möchte ich Sie nochmals eindringlich darauf hinweisen, dass man mit dem Schema Manager in einer produktiven Umgebung schweren und unter Umständen irreparablen Schaden anrichten kann!

8.1.3 Der globale Katalog (Global Catalog, GC)

Den globalen Katalog wird man als Mensch zwar nie direkt zu Gesicht bekommen, trotzdem übernimmt er eine wichtige Rolle in einer Active Directory-Umgebung.

Abbildung 8.16 zeigt ein technisch stark vereinfachtes Beispiel:

• Benutzer A möchte die Telefonnummer des Benutzers B aus dem Active Directory ermitteln.
• Benutzer B arbeitet zwar in derselben Organisation, ist aber in einer anderen Domäne angelegt. Der Domänencontroller der Domäne von Benutzer A kennt also weder Benutzer B und schon gar nicht dessen Telefonnummer.
• Ohne den globalen Katalog müsste der Client von Benutzer B zunächst sämtliche Domänen der Organisation (es können ja mehr als die gezeichneten zwei Domänen vorhanden sein) abklappern und prüfen, ob irgendwo der gesuchte Benutzer B angelegt ist – im Zweifelsfall weltweit über WAN-Strecken!
• Faktisch sieht es so aus, dass der Client von Benutzer A lediglich im Global Catalog nachschaut, da auf diesem grundlegende Informationen über die Benutzer gespeichert sind, beispielsweise auch die Telefonnummer.

Der globale Katalog wird übrigens nicht nur für Suchanfragen von Benutzern vorgehalten, sondern wird beispielsweise auch für eine schnelle Prüfung von Gruppenmitgliedschaften und für andere »AD-interne« Dinge verwendet. Im Detail sind dies:

• Eine Suche im gesamten Forest: Eine Anwendung, die im Global Catalog suchen möchte, sendet die Suchanfragen zu dem entsprechenden Server auf Port 3268. (»Normale« LDAP-Anfragen laufen über Port 389.)
• Domänencontroller fordern beim Anmeldevorgang eines Benutzers die Liste der Mitgliedschaften in universellen Gruppen an.
• Meldet sich der Benutzer mit seinem User Principal Name (UPN) in einem Forest mit mehr als einer Domäne an, wird der Name mittels des Global Catalog aufgelöst. Der UPN sieht beispielsweise so aus: uboddenberg@ubinf.intra.
• In Exchange-Umgebungen spielt der GC ebenfalls eine herausragende Rolle, weil die Adressdaten der Benutzer vom Global Catalog angefordert werden.

Abbildung 8.16 Funktionsweise des globalen Katalogs

Im Gegensatz zu der Darstellung in Abbildung 8.16 benötigt der Global Catalog keinen separaten Server. Prinzipiell kann man jedem Domänencontroller per Mausklick die Funktion eines Global Catalog hinzufügen. Einen Domänencontroller zu einem globalen Katalogserver zu machen, ist mit einem Mausklick erledigt. Rufen Sie dazu im Konfigurationswerkzeug Active Directory-Benutzer und -Computer den Eigenschaftendialog des entsprechenden Domänencontrollers auf. Auf der Karteikarte Allgemein findet sich ein Schalter NTDS-Einstellungen. Dieser wiederum führt zu einem Dialog mit der Checkbox Globaler Katalog (Abbildung 8.17).

Abbildung 8.17 Ein Domänencontroller wird mit einem Mausklick zum globalen Katalogserver.

Die Aufgabe bei der Planung ist nun, die beste Anzahl und Positionierung für globale Kataloge zu ermitteln:

• Wenn ein Außenstandort keinen eigenen GC hat, werden die entsprechenden Anfragen über WAN-Strecken abgewickelt.
• Da der GC natürlich über die notwendigen Daten verfügen muss, findet ein permanenter Replikationsverkehr zu diesem statt.
• Globale Kataloge sollen/müssen redundant vorhanden sein. Der Ausfall des einzigen GCs führt zu schweren Einschränkungen der Funktion! Ein Exchange-System ist beispielsweise ohne Global Catalog nicht funktionsfähig!

Wenn ein Attribut im globalen Katalog vorhanden sein soll, muss dies entsprechend konfiguriert werden. Abbildung 8.18 zeigt den Eigenschaftendialog des Attributs telephoneNumber im Schema Manager-Snap-In. Wie man an der Checkbox erkennt, wird es standardmäßig in den GC repliziert.

Abbildung 8.18 Das Attribut »telephoneNumber« wird in den globalen Katalog repliziert (Screenshot aus dem »Schema Manager«-Snap-In).

Abhängigkeiten zwischen dem globalen Katalog und der Betriebsmasterrolle Infrastrukturmaster sind zu berücksichtigen; mehr dazu finden Sie im übernächsten Abschnitt.

8.1.4 Betriebsmasterrollen/FSMO-Rollen

Im Active Directory geht es letztendlich so zu wie in George Orwells »Animal Farm«: Die Domänencontroller sind letztendlich doch nicht alle gleich, weil es einige gibt, die gleicher als die anderen sind.

Es gibt pro Domäne jeweils einen Domänencontroller für folgende Betriebsmasterrollen (FSMO = Flexible Single Master Operations):

• PDC Emulator
• RID Master
• Infrastrukturmaster

Pro Forest, also einmal je Active Directory-Gesamtstruktur, gibt es noch folgende Betriebsmasterrollen:

• Domain Naming Master
• Schemamaster

Diese fünf Betriebsmasterrollen können auf einem einzigen DC laufen oder auf mehrere Maschinen verteilt werden.

Warum gibt es diese speziellen Funktionen? Bei verteilten replizierten Datenbanken sind natürlich stets Konflikte denkbar. In größeren verteilten Umgebungen wird es jeweils dauern, bis Änderungen auf alle DCs repliziert sind. So könnte es beispielsweise sein, dass die Telefonnummer des Benutzers innerhalb eines kürzeren Zeitraums auf zwei unterschiedlichen Domänencontrollern geändert wird. Letztendlich wird die später durchgeführte Änderung die »endgültige Fassung« werden, d. h., die ältere Änderung wird bei einem Replikationskonflikt verworfen. Das ist eventuell ein wenig lästig, mehr aber auch nicht. Nun sind auch Änderungen denkbar, die für die Gesamtumgebung »stabilitätsgefährdend« wären, wenn die ältere Änderung einfach verworfen würde: Stellen Sie sich vor, dass an zwei Stellen im Unternehmen eine neue Domäne »Vertrieb« angelegt würde – es gäbe dann zwei völlig unterschiedliche Domänen mit demselben Namen. Das würde zu absolutem Chaos führen. Damit der beschriebene Fall nicht auftritt, gibt es pro Gesamtstruktur einen Domain Naming Master: Der Domänencontroller, der diese FSMO-Rolle innehat, prüft, ob ein neu anzulegender Domänenname zulässig ist.

Die Aufgaben der Betriebsmasterrollen

Nachfolgend sind die Aufgaben der einzelnen FSMO-Rollen kurz beschrieben:

PDC-Emulator

Wie der Name bereits vermuten lässt, wurde der PDC-Emulator in Umgebungen, in denen sich noch NT4-BDCs (BDC = Backup Domänencontroller) befanden, verwendet, um diese mit Änderungsdaten zu versorgen. Er übernahm also die Aufgabe des früheren NT4-PDCs (PDC = Primary Domain Controller). In einem Active Directory, das auf Windows Server 2008-Technologie basiert, gibt es keine NT4-Domänencontroller; das ist übrigens schon daran zu erkennen, dass es keine entsprechende Domänenfunktionsebene gibt.

Der Domänencontroller mit der PDC-Emulator-Rolle hat allerdings noch andere Funktionen. So ist er beispielsweise für die Synchronisierung der Uhrzeit innerhalb der Umgebung verantwortlich. Die Uhrzeit ist in Active Directory-Umgebungen übrigens außerordentlich wichtig, weil die von Kerberos erstellten Tickets nur eine relativ kurze Gültigkeitsdauer haben. Wenn ein Server eine Stunde vor- und ein anderer eine halbe Stunde nachgeht und die Clients irgendwo dazwischenliegen, wird die Anmeldung an einer Ressource zu einem Glücksspiel.

Weitere Funktionen sind:

• Kennwortänderungen, die von anderen Domänencontrollern in der Domäne ausgeführt werden, werden bevorzugt auf den PDC-Emulator repliziert.
• Fehler bei der Authentifizierung, die auf einem bestimmten Domänencontroller in einer Domäne aufgrund eines fehlerhaften Kennwortes auftreten, werden an den PDC-Emulator weitergeleitet, bevor dem Benutzer eine Meldung zu einem Kennwortfehler angezeigt wird.
• Die Kennwortsperrung wird auf dem PDC-Emulator verarbeitet.

Der PDC-Emulator ist einmal pro Domäne vorhanden.

RID-Master

Wenn ein Domänencontroller ein Objekt (genauer gesagt: ein Sicherheitsprinzipalobjekt) erstellt, wie z. B. einen Benutzer oder eine Gruppe, dann weist er diesem eine eindeutige Sicherheitskennung (SID) zu. Diese SID besteht aus einer Domain-SID (die für alle Objekte, die in einer Domäne erstellt werden, identisch ist) und aus einer RID (Relative ID), die für jede SID, die in einer Domäne erstellt wird, eindeutig ist.

Jedem Domänencontroller in einer Domäne wird ein RID-Pool zugeordnet, aus dem die RIDs stammen, die er neu angelegten Objekten zuweist.

Wenn der einem Domänencontroller zugewiesene RID-Pool einen Grenzwert unterschreitet, dann sendet er dem RID-Master der Domäne eine Anforderung, zusätzliche RIDs zur Verfügung zu stellen. Der RID-Master der Domäne antwortet auf die Anforderung, indem er RIDs aus dem Pool der nicht zugeordneten RIDs der Domäne abruft und diese dem Pool des DCs zuweist, vom dem die Anforderung kam.

Zusammenfassend gesagt ist der Domänencontroller mit der Rolle RID-Master derjenige DC, der für das Verarbeiten von Anforderungen an den RID-Pool von allen DCs in einer bestimmten Domäne zuständig ist. Darüber hinaus ist übrigens er dafür zuständig, ein Objekt aus seiner Domäne zu entfernen und es bei einer Objektverschiebung in eine andere Domäne zu versetzen.

Der RID-Master ist einmal pro Domäne vorhanden.

Infrastrukturmaster (auch Infrastruktur Daemon)

Der Domänencontroller, der die Rolle Infrastrukturmaster ausführt, ist dafür verantwortlich, die SIDs eines Objekts und dessen Distinguished Name in einer domänenübergreifenden Referenz zu aktualisieren. Da der Satz etwas hölzern klingt, hier zwei Details zum Verständnis:

• Der Distinguished Name eines Objekts ist der für einen menschlichen Benutzer verwertbare Name des Objekts. Er lässt sich übrigens mit ADSI-Editor auslesen (Abbildung 8.19); er ist aber leicht zu bilden, wenn man weiß, in welcher Domäne und in welcher OU sich das Objekt befindet.
• Eine domänenübergreifende Referenz ist beispielsweise die Mitgliedschaft eines Benutzers in einer Gruppe, die zu einer anderen Domäne der Gesamtstruktur gehört.

Der Infrastrukturmaster ist einmal pro Domäne vorhanden.

Abbildung 8.19 Der Distinguished Name eines Objekts kann beispielsweise mit ADSI-Editor ausgelesen werden. Er ist aber auch leicht zu bilden.

Die Rolle Infrastructure Master (IM) sollte von einem Domänencontroller ausgeführt werden, der kein globaler Katalogserver (Global Catalog, GC) ist. Wenn der Infrastructure Master auf einem GC-Server ausgeführt wird, werden die Objektinformationen nicht mehr aktualisiert, da der Infrastructure Master keine Verweise auf Objekte speichert, die er nicht enthält. Das liegt daran, dass der GC-Server eine partielle Kopie von jedem Objekt der Gesamtstruktur gespeichert hat. Wenn diese Rolle von einem GC-Server übernommen wird, werden die domänenübergreifenden Objektreferenzen in dieser Domäne nicht aktualisiert, und in das Ereignisprotokoll des Domänencontrollers wird eine entsprechende Warnung geschrieben.

Domain Naming Master (Domänennamen-Master)

Der DC mit der FSMO-Rolle Domänennamen-Master ist für das Ausführen von Änderungen im gesamtstrukturübergreifenden Domänennamespace des Verzeichnisses zuständig. Nur dieser Domänencontroller kann eine Domäne zum Verzeichnis hinzufügen oder aus diesem entfernen. Er stellt beispielsweise die Eindeutigkeit der Namen der Domänen sicher. Er kann auch Querverweise zu Domänen in externen Verzeichnissen hinzufügen oder aus diesen entfernen.

Der Domain Naming Master ist einmal pro Forest/Gesamtstruktur vorhanden.

Schemamaster

Der Domänencontroller, der die FSMO-Rolle Schemamaster ausführt, ist für Änderungen des Schemas zuständig. Er ist der einzige DC, der Aktualisierungen für das Verzeichnisschema verarbeiten kann. Wenn die Schemaaktualisierung abgeschlossen ist, wird sie vom Schemamaster aus auf alle anderen Domänencontroller im Verzeichnis repliziert.

Der Schemamaster ist einmal pro Forest/Gesamtstruktur vorhanden.

Verfügbarkeit

In einer etwas größeren Umgebung sollten mehrere Domänencontroller und mehrere Global Catalogs vorhanden sein. Bekanntlich ist es nie auszuschließen, dass ein Server – aus welchen Gründen auch immer – ausfällt. Das Active Directory nebst Diensten wie der Namensauflösung muss für den störungsfreien Betrieb permanent verfügbar sein, was sich durch den Einsatz mehrerer Server recht einfach realisieren lässt. Da die FSMO-Rollen aber jeweils nur einmal vorhanden sind, ist zu prüfen, was ein Ausfall einer Rolle für den Betrieb des Gesamtsystems bedeutet. Die gute Nachricht ist, dass die direkten Auswirkungen auf den Produktivbetrieb gering sind. Vielmehr stehen einige Administrationsmöglichkeiten nicht mehr zur Verfügung, zum Beispiel:

• Schemaänderungen können nicht durchgeführt werden (bei Ausfall des Schemamasters).
• Neue Domänen können nicht angelegt werden, und vorhandene Domänen können nicht entfernt werden (bei Ausfall des Domain Naming Masters).
• Betriebssysteme, die keinen Active Directory-Client besitzen (z. B. NT4), können keine Passwörter ändern (bei Ausfall des PDC-Emulators).
• In den Mitgliederlisten von universellen Gruppen werden veraltete Benutzernamen angezeigt (bei Ausfall des Infrastrukturmasters).

Die beiden oben genannten Beispiele sind sicherlich die plakativsten Fälle. Bei einem wirklich langen, vielleicht unbemerkten Ausfall einer Rolle könnte es zu »subtileren« Störungen kommen:

• Fehlt die Zeitsynchronisation durch den PDC-Emulator, werden eventuell die Uhrzeiten der Server so weit auseinanderlaufen, dass es Probleme mit der Gültigkeit der Kerberos-Tickets gibt. Das führt dazu, dass ein Anmelden an Ressourcen nicht mehr möglich ist.
• Ist der RID-Master über lange Zeit ausgefallen, könnten die anderen Domänencontroller die ihnen zugewiesenen RIDs aufgebraucht haben. Die Folge ist, dass keine neuen Sicherheitsprinzipale (z. B. Benutzer) angelegt werden können.

Es ist also durchaus eine gute Idee, die Betriebszustände der Domänencontroller mit einem Werkzeug wie dem Microsoft Operations Manager zu überwachen, um sicherzustellen, dass es keinen längeren unbemerkten Ausfall gibt.

Verschieben der Betriebsmasterrollen

Die Verwaltung der FSMO-Rollen ist nicht weiter kompliziert – es gibt einfach nicht viel, was zu verwalten wäre.

Im Grunde genommen besteht die Verwaltungsarbeit lediglich darin, die Rollen zwischen Servern zu verschieben. Dies könnte beispielsweise notwendig sein, wenn ein Server, der FSMO-Rollen trägt, außer Betrieb genommen wird oder für einen längeren Zeitraum ausfällt.

Das Verschieben der Betriebsmasterrollen wird mit folgenden Werkzeugen durchgeführt:

• Active Directory-Benutzer und -Computer verschiebt die domänenweiten Rollen (RID-Master, PDC-Emulator, Infrastrukturmaster).
• Mit Active Domänen und Vertrauensstellungen wird die forest-weite Rolle Domain Naming Master verschoben.
• Mit dem Schema Manager wird – wie sollte es auch anders sein – die Rolle Schemamaster einem anderen Domänencontroller zugeordnet.

Die zuvor genannten Management-Werkzeuge verfügen im Kontextmenü über einen Eintrag Betriebsmaster. Dieser Eintrag findet sich bei Active Directory-Benutzer und -Computer im Kontextmenü der Domäne: Schließlich ist dieses Werkzeug auch für die Domänen-Betriebsmaster zuständig (Abbildung 8.20).

Abbildung 8.20 Einige Snap-Ins ermöglichen das Verschieben von Betriebsmasterrollen.

Der Dialog zum Verschieben der Betriebsmasterrollen ist recht unspektakulär (Abbildung 8.21). In der Tat ist jeweils nur der Schalter Ändern vorhanden; weitere Administrationsmöglichkeiten finden sich nicht.

Abbildung 8.21 Der Dialog zum Ändern der domänenweiten Betriebsmasterrollen

Wenn Sie mit dem Domänencontroller verbunden sind, der die Betriebsmasterrolle zurzeit innehat, werden Sie die Fehlermeldung aus Abbildung 8.22 erhalten. Was will uns diese Fehlermeldung sagen? Die Administrationswerkzeuge verbinden sich mit einem der Domänencontroller und greifen auf dessen Active Directory-Datenbank und die von ihm bereitgestellten Funktionen zu. Im Kontextmenü der Domäne findet sich eine Funktion, mit der der DC gewechselt werden kann, auf dem administriert wird.

Abbildung 8.22 Die gezeigte Fehlermeldung erscheint, wenn der zurzeit administrierte DC bereits die Betriebsmasterrolle innehat.

Um also eine Betriebsmasterrolle zu transferieren, wechseln Sie im Administrationswerkzeug den zu verwendenden Domänencontroller (siehe Abbildung 8.20, Menüpunkt Domänencontroller ändern). Ein Anruf der Funktion öffnet das in Abbildung 8.23 gezeigte Dialogfenster. Hier haben Sie die Möglichkeit, einen beliebigen beschreibbaren Domänencontroller aussuchen zu lassen oder aber selbst einen DC zu bestimmen. Da ein bestimmter anderer Server und eben nicht eine beliebige Maschine die Betriebsmasterrolle erhalten soll, machen Sie natürlich von der zweiten Möglichkeit Gebrauch.

Die Formulierung »schreibbarer Domänencontroller« kommt übrigens dadurch zustande, dass es in einer Windows Server 2008-Umgebung (und in späteren Versionen) auch Read Only Domain Controller (RODC) gibt – dazu später mehr.

Abbildung 8.23 Mit diesem Dialog können Sie den DC bestimmen, der von dem Administrationswerkzeug verwendet werden soll.

Das eigentliche Übertragen der Betriebsmasterrolle wird nach einer Sicherheitsabfrage innerhalb weniger Augenblicke durchgeführt. Die Änderung ist sofort aktiv.

Wie bereits zuvor erwähnt, wird das Verschieben der Domain Naming Master-Rolle mit dem Werkzeug Active Directory-Domänen und -Vertrauensstellungen durchgeführt. Bevor Sie lange suchen: Die Funktion befindet sich in diesem Fall nicht im Kontextmenü des Domäneneintrags, sondern in der Wurzel des Snap-Ins. Das ist im Grunde genommen auch einleuchtend, der Domain Naming Master ist ja schließlich eine forest-übergreifende Betriebsmasterrolle und nicht einer bestimmten Domäne zugeordnet (Abbildung 8.24).

Abbildung 8.24 In diesem Kontextmenü finden Sie den Dialog, mit dem Sie die Position der »Domain Naming Master«-Rolle ändern können.

Die Betriebsmasterrolle Schemamaster wird mit dem Schema Manager verschoben. Wie bereits zuvor erwähnt wurde, muss dieser mit dem Aufruf regsvr32 schmmgt.dll zunächst registriert werden. Anschließend kann MMC geöffnet werden und das Snap-In Active Directory-Schema der Konsole hinzugefügt werden (Abbildung 8.25). Wenn in dem Snap-In-Auswahldialog das Schema-Snap-In nicht auftaucht, ist es vermutlich noch nicht registriert.

Abbildung 8.25 Wenn der Schema Manager registriert ist, kann er einer Konsole hinzugefügt werden.

Abbildung 8.26 zeigt das Kontextmenü zum Aufruf der Änderung der Betriebsmasterrolle nebst zugehörigem Dialog. Wenn Sie das Kontextmenü einmal genau anschauen, werden Sie feststellen, dass es zwei Einträge gibt: nämlich einen zum Wechseln des Domänencontrollers, was Sie zu Beginn dieses Abschnitts bereits kennengelernt haben, und einen weiteren Eintrag zum Verbinden mit dem Schemamaster. Letztgenannter Eintrag ist übrigens sehr praktisch, denn man kann einem Server schließlich nicht an der Nasenspitze (bzw. an der Gehäusefront) ansehen, ob er ein Betriebsmaster ist (jedenfalls, wenn die Dokumentation fehlt).

Wenn man einmal weiterüberlegt, fragt man sich vielleicht, was eigentlich passiert, wenn man eine Schemaänderung durchführen möchte und nicht mit dem Schemamaster verbunden ist. Sie wissen ja, dass die einzige Maschine im Forest, die Schemaänderungen durchführt, derjenige DC ist, der die Schemamaster-Rolle innehat.

Abbildung 8.26 Hier finden Sie den Dialog zum Verschieben der Betriebsmasterrolle »Schemamaster«.

Abbildung 8.27 zeigt die Meldung, die erscheint, wenn das Schema Manager-Snap-In gezielt mit einem DC verbunden wird, der in Ermangelung der entsprechenden Betriebsmasterrolle keine Schemaänderung durchführen kann: Das Konfigurationswerkzeug wird Änderungen direkt auf den Schemamaster schreiben. Dieser wird per Replikation die Änderungen verteilen. Sie werden im Konfigurationswerkzeug erst zeitverzögert – eben nach Abschluss der Replikation – zur Verfügung stehen.

Abbildung 8.27 Verbindet man das »Schema Manager«-Snap-In mit einem DC, der nicht Schemamaster ist, erscheint diese Warnmeldung.

Die folgende Tabelle zeigt, welche Rechte ein Administrator braucht, der Betriebsmasterrollen verschieben möchte:

8.1.5 Verteilung von Betriebsmasterrollen und Global Catalog

Sie haben gehört, dass nach der Installation die Betriebsmasterrollen wie folgt verteilt sind:

• Der erste DC im Forest verfügt über sämtliche Betriebsmasterrollen.
• Der erste DC jeder Domäne verfügt über die drei Domänen-Betriebsmasterrollen.

Der erste DC im Forest ist darüber hinaus Global Catalog Server.

Globaler Katalog und Infrastrukturmaster

Die Aufgabe des Infrastrukturmasters ist die Aktualisierung domänenübergreifender Objektreferenzen (z. B. der Mitgliedschaft eines Benutzers in einer Gruppe einer anderen Domäne). Dazu vergleicht er diese Referenzen mit den Einträgen auf einem Global Catalog Server. Da es auf einem Global Catalog Server keine verwaisten Objektreferenzen geben kann, wird ein auf ihm laufender Infrastrukturmaster auch keine solchen entdecken können. Demzufolge kann er seine Aufgabe nicht erfüllen. Ein Global Catalog Server kann übrigens deshalb keine verwaisten Objektreferenzen haben, weil er ständig aktuelle Daten aus anderen Domänen erhält.

Wenn Ihr Forest nur aus einer Domäne besteht, ist die Thematik für Sie übrigens unerheblich: In einer solchen Umgebung kann es keine domänenübergreifenden Objektreferenzen geben, daher sind in diesem Fall keine weiteren Überlegungen notwendig.

Besteht Ihr Forest aus mehreren Domänen, haben Sie zwei Möglichkeiten:

• Wenn in einer Domäne sämtliche Domänencontroller auch Global Catalog Server sind, kann einer von ihnen Infrastrukturmaster werden. Das Problem mit verwaisten Einträgen existiert dann ohnehin nicht, da es diese auf einem Global Catalog Server nicht gibt.
• Sind in einer Domäne nicht sämtliche DCs auch Global Catalog Server, muss der Infrastrukturmaster auf einem Non-GC-DC laufen.

Wenn Sie sich die beiden zuvor genannten Punkte merken, können Sie einen häufig vorkommenden Fehler vermeiden. Wenn Sie nachträglich versuchen, die Betriebsmasterrolle Infrastrukturmaster auf einen Global Catalog Server zu verschieben, erscheint die Warnmeldung aus Abbildung 8.28. Die Falle schnappt eher dann zu, wenn eine neue Domäne installiert wird. Der erste DC erhält automatisch alle drei domänenweiten Rollen. Wenn man bei seiner Installation den globalen Katalog mitinstallieren ließ und einen weiteren DC ohne GC-Funktion installiert, ist es auch schon passiert.

Abbildung 8.28 Wenn die Rolle »Infrastrukturmaster« auf einen Global Catalog Server verschoben werden soll, erscheint eine Warnung.

Empfehlung für die Verteilung der Betriebsmasterrollen

Die Verteilung der Betriebsmasterrollen ist natürlich eine sehr individuelle Angelegenheit. Dennoch gibt es einige allgemeingültige Hinweise. Kommen wir zunächst zur Positionierung der forest-weiten Betriebsmasterrollen:

• Die beiden forest-weiten Betriebsmasterrollen sollten in der Forest Root Domain (also der ersten installierten Domäne) verbleiben.
• Die beiden forest-weiten Betriebsmasterrollen sollten weiterhin auf einem Global Catalog Server liegen.

Für die domänenweiten Rollen gibt es diese Empfehlungen:

• Alle drei domänenweiten Rollen sollten auf demselben Domänencontroller eingerichtet werden.
• Wenn in einem Forest mehrere Domänen vorhanden sind, dürfen die domänenweiten Rollen nicht auf einem Global Catalog Server liegen, es sei denn, alle Domänencontroller dieser Domäne sind Global Catalog Server (siehe auch den vorherigen Abschnitt).
• Der Domänencontroller mit den Betriebsmasterrollen sollte durchaus leistungsstärker als ein »normaler« DC sein. Quantitative Angaben müssen individuell durch Messen und Analyse gewonnen werden. Es ist an dieser Stelle unmöglich, wirklich verlässliche Aussagen zu Speicherausbau und Prozessorleistung zu treffen.

Weiterhin ist es notwendig, dass die Betriebsmaster netzwerkmäßig erreichbar sind. Nicht jeder Client muss den Domänennamen-Betriebsmaster erreichen können; ein Administrator, der an einem entfernten Standort eine Subdomäne anlegen soll, muss aber mit ihm kommunizieren können – sonst geht nichts!

Empfehlung für die Verteilung von globalen Katalogservern

Die Empfehlung für die Verteilung von globalen Katalogservern hat zwei Ziele. Einerseits soll Ausfallsicherheit erreicht werden, andererseits soll der Zugriff auf die globalen Katalogserver möglichst performant sein. Glücklicherweise stehen sich diese Ziele nicht gegenseitig im Weg, sodass diese Empfehlungen resultieren:

• Redundanz lässt sich einfach dadurch erreichen, dass mehrere globale Katalogserver vorhanden sind.
• Es sollte nach Möglichkeit an jedem Standort ein globaler Katalogserver vorhanden sein.
• Ist dies nicht möglich, kann zur Schonung der WAN-Verbindungen das Zwischenspeichern der universellen Gruppenmitgliedschaft (Universal Group Membership Caching) aktiviert werden. Dies wird, wie in Abbildung 8.29 gezeigt, im Konfigurationswerkzeug Active Directory-Standorte und -Dienste vorgenommen. Wählen Sie den entsprechenden Standort aus, und rufen Sie dessen NTDS Site Settings auf.
• Falls nach bestimmten Attributen häufig gesucht wird, können diese in den globalen Katalog aufgenommen werden. Das ist weiter vorn in Abbildung 8.18 gezeigt.

Abbildung 8.29 Wenn an einem Standort kein globaler Katalogserver vorhanden ist, kann dort das Zwischenspeichern der universellen Gruppenmitgliedschaft aktiviert werden.

8.1.6 Schreibgeschützte Domänencontroller – Read Only Domain Controller (RODC)

Wird in einem Außenstandort ein Domänencontroller installiert, gibt es, wie fast immer im Leben, einige Vor-, aber leider auch einige Nachteile. Zu den Vorteilen zählt, dass die Benutzer einen schnellen Zugriff auf die Domäne haben und die WAN-Strecken geschont werden. Zu den Nachteilen gehört insbesondere, dass die physikalische Sicherheit eines solchen Servers in vielen Fällen nicht gewährleistet werden kann. Die Daten sind in den Datenbanken des Active Directorys natürlich verschlüsselt gespeichert, trotzdem wird es im Allgemeinen nicht gern gesehen, wenn sensible Passwörter auf nicht optimal gesicherten Maschinen liegen. Letzteres umfasst sowohl die physikalische Sicherheit des Geräts als auch die »Abschottung« gegen lokale (Hilfs-)Administratoren. Viele mir bekannte Unternehmen haben in entfernten Standorten einen IT-Beauftragten, der notgedrungen über einen Administratorzugang zu dem Server bzw. den Servern verfügt.

Mit Windows Server 2008 ist der Read Only Domain Controller (RODC) eingeführt worden. Ein solcher Domänencontroller verfügt nicht über eine beschreibbare Datenbankkopie, und – was noch wichtiger ist – er verfügt auch nicht über die Passwörter der Benutzer.

Abbildung 8.30 Ein schreibgeschützter Domänencontroller (RODC) wird installiert, indem bei der Installation das entsprechende Häkchen gesetzt wird.

Die Installation eines RODCs ist genauso einfach wie die Installation eines »normalen« Domänencontrollers. Wenn Sie den Assistenten zur Einrichtung eines DCs nutzen, sehen Sie den bereits bekannten Dialog, der wie in Abbildung 8.30 gezeigt ausgefüllt werden kann:

• Ein RODC kann gleichzeitig DNS-Server sein. In vielen Fällen wird das auch zu empfehlen sein, da hierdurch die Namensauflösung an dem entsprechenden Standort lokal erfolgen kann und nicht die WAN-Strecken belastet.
• Ein RODC kann auch ein globaler Katalogserver sein, was ebenfalls Sinn macht, denn viele Verzeichnisinformationen fragen Clients von sich aus beim globalen Katalog an. In den Beta-Versionen von Windows Server 2008 war die Kombination RODC und globaler Katalog übrigens noch nicht möglich. In der Release-Version geht das, wie auch in der Abbildung zu sehen ist.

Wenn der schreibgeschützte Domänencontroller »irgendwo draußen« steht, könnte der Wunsch aufkommen, dass er von einem lokalen Mitarbeiter verwaltet werden soll. Bei der Installation eines RODCs erscheint daher der Dialog aus Abbildung 8.31, der einen Benutzer oder eine Gruppe zum Administrator des RODC macht.

Abbildung 8.31 Ein Benutzer- oder Gruppenkonto kann zur Verwaltung des RODC berechtigt werden.

Dass ein Domänencontroller ein RODC ist, lässt sich im Konfigurationswerkzeug Active Directory-Benutzer und -Computer auf einen Blick erkennen, da der DC-Typ entsprechend vermerkt ist (Abbildung 8.32).

Abbildung 8.32 Ob ein Domänencontroller ein RODC ist, ist in dieser Übersicht leicht zu erkennen.

Ein RODC funktioniert wie folgt:

• Wenn eine Anwendung nur lesenden Zugriff auf das Verzeichnis benötigt, kann der RODC-Domänencontroller alle gewünschten Informationen liefern.
• Möchte eine Anwendung schreibend auf den RODC-Domänencontroller zugreifen, erhält sie eine LDAP-Weiterleitungsantwort und wird zu einem DC mit einer beschreibbaren Active Directory-Datenbank geleitet.
• Wenn ein Benutzer sich authentifizieren möchte, sendet der RODC die Anfrage an einen beschreibbaren Domänencontroller, in dessen Datenbank auch die Passwortinformationen enthalten sind. Je nach Richtlinie zur Kennwortreplikation (Password Replication Policy) erhält der RODC eine Kopie der Anmeldeinformationen – oder eben auch nicht.

Die Password Replication Policy auf einem RODC beschreibt, welche Anmeldeinformationen auf diesem Domänencontroller gespeichert werden dürfen. Die Informationen werden nicht durch Replikation übertragen, sondern werden gespeichert, wenn der Anwender sich zum ersten Mal über diesen DC authentifiziert hat. Ein guter Kompromiss aus Sicherheit und Performance ist folgende Vorgehensweise:

• Die Speicherung der Kennwörter von den Benutzergruppen, die sich an dem Standort mit RODC-Domänencontroller befinden, wird zugelassen.
• Die Speicherung der Kennwörter sämtlicher anderen Konten, inklusive der lebenswichtigen Konten von Administratoren und dergleichen, wird unterbunden.

Sollte die Datenbank des RODC tatsächlich gestohlen und korrumpiert werden, halten sich die Verluste in Grenzen; zumindest müssen nicht die Kennwörter der kompletten Organisation ausgetauscht werden.

Die Kennwortreplikationsrichtlinie wird mit dem Dialog aus Abbildung 8.33 konfiguriert; er ist in den Eigenschaften des entsprechenden Servers im Konfigurationswerkzeug Active Directory-Benutzer und -Computer zu finden.

Neben den Sicherheitsaspekten ist der verminderte Replikationsaufwand ein Argument für den Einsatz von RODC-Domänencontrollern. Da nur in eine Richtung repliziert werden muss, sinkt die Komplexität des Replikationsvorgangs. Dies macht sich auf stark belasteten Bridgehead-Servern bemerkbar.

Welche Kennwörter auf dem RODC aktuell gespeichert sind, können Sie recht einfach herausfinden. Ein Klick auf den Schalter Erweitert zeigt einen Dialog mit genau dieser Liste (Abbildung 8.34). Falls Benutzer, deren Kennwörter laut Richtlinie eigentlich auf dem RODC gespeichert werden dürfen, hier nicht auftauchen, liegt das daran, dass diese sich bislang noch nicht über diesen Domänencontroller angemeldet haben.

Diesen Dialog gibt es übrigens auch »andersherum«: Im Eigenschaftendialog eines Benutzers findet sich eine Karteikarte Kennwortreplikation, auf der angezeigt wird, auf welchen RODCs das Kenntwort des gewählten Anwenders gespeichert ist.

Abbildung 8.33 Die Konfiguration der Kennwortreplikationsrichtlinie für einen Read Only Domain Controller (RODC)

Abbildung 8.34 Zu Kontrollzwecken sehr praktisch ist diese Liste, die anzeigt, welche Kennwörter auf dem RODC gespeichert sind.

Der Dialog aus Abbildung 8.34 listet »nur« die Konten auf, für die bereits ein Kennwort auf dem RODC gespeichert ist. Die Frage, ob das Kennwort eines bestimmten Kontos prinzipiell gespeichert würde, beantwortet der Dialog auf der Karteikarte Richtlinienergebnis (Abbildung 8.35): Sie können der Liste beliebige Konten hinzufügen und erhalten die gewünschte Information.

Abbildung 8.35 Mit diesem Dialog kann geprüft werden, zu welchen Konten die Kennwörter laut Konfiguration (= Richtlinie) auf dem RODC gespeichert werden.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.