8.2 Planung und Design des Active Directory

Sie haben im vorigen Abschnitt einiges über die technischen Grundlagen des Active Directory erfahren. Die Planung eines AD ist ein Thema, mit dem man leicht ein tausendseitiges Buch füllen könnte. Es gibt aber einige recht einfache Grundregeln beim Design, die letztendlich in jeder Umgebung Gültigkeit haben.

8.2.1 Abbildung des Unternehmens

Im Active Directory bildet man die Struktur des Unternehmens bzw. der Organisation ab. Ein Unternehmen könnte beispielsweise so strukturiert sein wie in dem Organigramm aus Abbildung 8.36. (Das Organigramm ist natürlich nicht vollständig, sondern zeigt nur einen Ast.)

Sie sind natürlich nicht gezwungen, sich beim Design des ADs an eine solche Unternehmensstruktur zu halten. Man könnte auch alle Benutzer in eine OU einordnen, alle PCs in eine weitere und in eine dritte sämtliche Server. Technisch würde das selbstverständlich funktionieren, und es hätte vielleicht bei der Verwaltung sogar einige Vorteile. Aber: Ein Verzeichnisdienst soll und muss mehr sein als nur die Datenbank, in der der Benutzername und das Passwort für die Anmeldung gespeichert werden.

Wenn ein Benutzer wissen möchte, wer in der Vertriebsassistenz arbeitet, kann er, wenn Sie die Firmenstruktur im Verzeichnis abbilden, diese Information aus dem Active Directory gewinnen. Wenn Sie hingegen alle Benutzerobjekte in einer flachen Struktur »aufbewahren«, entfällt diese Möglichkeit.

In der Praxis hat sich gezeigt, dass AD-Strukturen, die sich nach Geschäftsführungsbereichen und Kostenstellenplänen richten, für die Benutzer ebenfalls nicht oder nur schwer durchschaubar sind. Der »normale« Benutzer denkt eben: »Ich bin im Vertriebsinnendienst« und nicht »Ich bin im Geschäftsführungsbereich ?External Relations?, und mein Team hat die Kostenstelle 99 837.«

Abbildung 8.36 Beispiel für die Struktur eines Unternehmens

Rein technisch gesehen ist ein Abbilden von unterschiedlichen Standorten in der Struktur des Active Directory nicht notwendig – hierzu gibt es mit Sites/Standorten weitere Konfigurationsmöglichkeiten.

Für das Abbilden der Standorte in der logischen Struktur gibt es prinzipiell drei Gründe:

• Wenn der Benutzer das Verzeichnis durchsucht, wird er den geografischen Bezug als wichtige Orientierungshilfe ansehen.
• Für einzelne OUs können Administrationsaufgaben an bestimmte Benutzer delegiert werden, beispielsweise das Zurücksetzen von Passwörtern. Wenn es in München einen Mitarbeiter gibt, der dazu berechtigt werden soll, können Sie das natürlich nur konfigurieren, wenn der Standort in der Struktur auch auftaucht.
• Wenn in den Standorten unterschiedliche Gruppenrichtlinien verwendet werden sollen, bedingt das natürlich auch, dass die Standorte in der logischen Struktur erscheinen.

Für die Integration der Standorte in die logische Struktur gibt es natürlich mehrere Möglichkeiten. Die »Extremfälle« sind in Abbildung 8.37 und Abbildung 8.38 dargestellt.

Abbildung 8.37 Eine Unternehmensstruktur mit Standorten als erstem Gliederungsmerkmal

Abbildung 8.38 Alternative Struktur, die Fachbereiche als primäres Gliederungsmerkmal verwendet

Im ersten Fall ist der Standort die oberste »Organisationsinstanz«, im zweiten Fall wird erst zum Schluss der Standort angegeben. Beliebige Mischformen sind natürlich möglich – es hängt von Ihren individuellen Anforderungen ab.

8.2.2 Übersichtlichkeit und Verwaltbarkeit

Dieser Abschnitt befasst sich ausführlicher mit der Fragestellung, ob man die Unternehmensstruktur lieber mit Domänen oder OUs abbildet bzw. inwieweit man welches Organisationsmittel einsetzt.

Ich erläutere einige Varianten am Beispiel der in Abbildung 8.37 gezeigten Konfiguration – das bedeutet allerdings nicht, dass dies notwendigerweise die beste Variante ist.

Für die jetzt folgenden Erläuterungen weiche ich von der sonst in der Literatur üblichen Darstellung ab: Abteilungen/Bereiche, die als Domäne implementiert werden, sind mit einem Dreieck gekennzeichnet, Organisationseinheiten ohne Dreieck werden als OU eingerichtet. Abbildung 8.39 zeigt eine Struktur, in der relativ stark von Domänen Gebrauch gemacht wird.

Abbildung 8.39 Abbildung der Struktur mit vielen Domänen (So würde man das aber nie aufbauen!)

Vorteile

• Der Replikationsverkehr zwischen Domänen ist wesentlich geringer als innerhalb von Domänen. Da das Beispiel von vier Standorten ausgeht, könnte das bezüglich der Belastung der WAN-Strecken ein Vorteil sein. Anzumerken wäre allerdings, dass heute im Normalfall die Replikationslast auf den WAN-Strecken kaum mehr ins Gewicht fällt – wir leben nicht mehr im Zeitalter der 2.400-Baud-Modems.
• An dem Namen des Servers lässt sich relativ einfach erkennen, an welchem Standort und für welchen Bereich er eingesetzt wird, also beispielsweise server18.vertrieb.lindau.alpha.intra. Zur Erinnerung: OUs verhalten sich bezüglich des Namensraums neutral.

Nachteile

• Je mehr Domänen Sie haben, desto höher ist der administrative Aufwand, weil jede Domäne einzeln administriert werden muss. Es gibt beispielsweise keine Gruppenrichtlinien, die sich über Domänengrenzen hinweg vererben. Wenn Sie die einzelnen Bereiche getrennt voneinander administrieren wollen, macht die Trennung durch die Domänengrenzen andererseits wieder Sinn.
• Für jede Domäne wird mindestens ein Domänencontroller benötigt. Aus Redundanzgründen sind eigentlich zwei Domänencontroller pro Domäne erforderlich. Wenn Sie eine Struktur mit elf Domänen aufbauen, brauchen Sie demzufolge 22 Server!

Die in Abbildung 8.39 gezeigte Vorgehensweise mit elf Domänen macht eventuell (!) in einem Unternehmen mit 200.000 PC-Arbeitsplätzen Sinn. Wenn Sie lediglich 1.000 Arbeitsplätze haben, ist sie mit Sicherheit der falsche Weg.

Abbildung 8.40 zeigt ein realistischeres Szenario: Hier gibt es eine Root-Domäne (ganz oben), darunter ist für die Standorte jeweils eine Domäne vorhanden. Die weitere Strukturierung erfolgt mittels OUs.

Dieses Szenario macht unter folgenden Voraussetzungen Sinn:

• Die einzelnen Standorte werden weitgehend autark administriert.
• Der Replikationsverkehr zwischen den Standorten soll auf ein Minimum begrenzt bleiben. (Der Replikationsverkehr zwischen Domänen ist deutlich geringer als innerhalb von Domänen.) Es sei aber darauf hingewiesen, dass der Replikationsverkehr heute meistens (!) kein wirklich wesentliches Problem ist.

Die dritte Möglichkeit ist die Einrichtung einer einzigen Domäne für die gesamte Organisation (Abbildung 8.41).

Sie werden in diesem Fall übrigens gegenüber dem zuvor gezeigten Szenario nicht allzu viele Server einsparen können, weil Sie vermutlich an jedem Standort mindestens einen Domänencontroller einsetzen werden, denn schließlich muss auf das Active Directory zugegriffen werden. Der Administrationsaufwand dürfte in diesem Szenario am geringsten sein, weil Sie beispielsweise für die Gruppenrichtlinien Vererbungen nutzen können. »Unterbereichs-Administratoren« lassen sich übrigens auch in diesem Szenario anlegen.

Abbildung 8.40 Abbildung mit einer Domäne pro Standort; die restliche Strukturierung erfolgt mit OUs.

Abbildung 8.41 Abbildung der Struktur mit nur einer Domäne

8.2.3 Standorte

Die physikalische Struktur ist recht schnell erklärt. Es gibt den Begriff des Standorts – fertig. In der englischsprachigen Literatur sprich man übrigens von »sites«. Ein Standort wird durch ein oder mehrere IP-Subnetze definiert.

Standorte und Domänen

In diesem Abschnitt betrachten wir den Zusammenhang zwischen Standorten und Domänen.

Der erste Fall ist, dass Standort- und Domänengrenzen identisch sind, anders gesagt: Wo eine separate Domäne ist, ist ein separater Standort (Abbildung 8.42).

Der zweite Fall ist, dass sich mehrere Domänen an einem Standort befinden (Abbildung 8.43). Dieses Szenario macht übrigens durchaus Sinn: Wenn eine Organisation mehrere autarke Geschäftsbereiche hat, die in einem Gebäude sitzen, wird man genau diese Konstellation vorfinden.

Wenn zwischen mehreren Standorten sehr schnelle WAN-Verbindungen liegen, könnte man sich auch überlegen, nur einen Standort zu definieren, frei nach dem Motto: »Je weniger definiert wird, desto geringer ist der Administrationaufwand.«

Abbildung 8.42 Jede Domäne befindet sich an einem eigenen Standort.

Abbildung 8.43 Mehrere Domänen befinden sich an einem Standort.

Der dritte Fall ist, dass sich eine Domäne über mehrere Standorte erstreckt (Abbildung 8.44). Auch dieser Fall kommt in der Praxis häufig vor: Gerade in mittelgroßen Organisationen macht es häufig Sinn, nur eine Domäne einzurichten. Wenn die Firma sich über mehrere Standorte erstreckt, wird man genau den hier beschriebenen Fall vorfinden.

Abbildung 8.44 Eine Domäne erstreckt sich über mehrere Standorte.

Standorte konfigurieren

Active Directory muss in der Lage sein, den Standort eines Mitgliedsservers oder eines Clients problemlos und zuverlässig zu ermitteln. Die einfachste Möglichkeit ist die Auswertung der IP-Adresse des jeweiligen Geräts. Aus diesem Grund müssen bei der Abbildung der physikalischen Struktur zunächst die IP-Subnetze erfasst werden. Die Konfigurationsarbeiten werden im Werkzeug Active Directory-Standorte und -Dienste vorgenommen.

Die Erfassung der IP-Subnetze (IP-Subnets) ist in Abbildung 8.45 zu sehen. Angegeben wird die erste Adresse des Subnetzes nebst Subnetzmaske.

Hinter der eigentlichen IP-Adresse wird die Länge der Subnetzmaske in Bits angegeben. Zwei Beispiele:

• Die Subnetzmaske eines Class-C-Netzes, also 255.255.255.0, ist 24 Bit lang.
• Die Subnetzmaske eines Class-B-Netzes, also 255.255.0.0, ist 16 Bit lang.

Abbildung 8.45 Die Erfassung der IP-Subnetze ist der erste Schritt bei der Konfiguration der physikalischen Struktur.

Im nächsten Schritt werden die Standorte (Sites) angelegt. Für die Beziehung zwischen IP-Subnetz und Active Directory-Standort gilt:

• Ein Standort kann mehrere Subnetze umfassen.
• Ein Subnetz kann immer nur an einem Standort sein.

Standorte werden insbesondere für die Optimierung der Replikationsvorgänge eingerichtet. Eine weitere Möglichkeit ist die Zuweisung von standortbezogenen Gruppenrichtlinien. Weiterhin können Clients mithilfe von Sites den nächstgelegenen Domänencontroller identifizieren. Falls DFS (Distributed File System) verwendet wird, finden die Clients mithilfe der definierten Standorte die nächstgelegene Ressource.

Ein Standort zeichnet sich dadurch aus, dass alle dort vorhandenen Domänencontroller über schnelle Verbindungen miteinander kommunizieren können. Hierbei ist es wichtig anzumerken, dass jeder DC dieses Standorts mit jedem anderen kommunizieren können muss. Ob die Server über mehrere Subnetze verteilt sind, ist dabei unerheblich – solange das Routing funktioniert.

Ein Standort aus Active Directory muss übrigens nicht mit einem geografischen Standort übereinstimmen. Wenn beispielsweise fünf deutsche Standorte über sehr schnelle Verbindungen vernetzt sind (Weitverkehrs-Ethernet ist ja heute auch keine Vision mehr, sondern eine buchbare Dienstleistung), könnte man durchaus für diese fünf geografischen Standorte lediglich einen AD-Standort definieren. Die genauen Auswirkungen auf die Replikation werden im nächsten Abschnitt besprochen.

Das Anlegen eines neuen Standorts ist in Abbildung 8.46 gezeigt (man beginnt im Kontextmenü von Sites). Sofern keine weiteren Standortverknüpfungsobjekte (mehr dazu im nächsten Abschnitt) definiert sind, können Sie zunächst lediglich den Namen für diesen Standort eintragen. Sie erhalten aber direkt eine Warnung, die sinngemäß besagt, dass noch viel zu tun ist. (Abbildung 8.47).

Abbildung 8.46 Anlegen eines neuen Standorts

Abbildung 8.47 Die Meldung nach dem Anlegen des Standorts zeigt, dass Sie noch lange nicht fertig sind.

Bislang stehen Standorte und Subnetze noch reichlich unverbunden in der Landschaft. Wenn Sie den Eigenschaftendialog eines angelegten Subnetzes aufrufen, kann es einem Standort zugeordnet werden; gezeigt ist dies in Abbildung 8.48. Im umgekehrten Fall, wenn Sie alle Subnetze anzeigen lassen wollen, die zu einem Standort gehören, verwenden Sie den Eigenschaftendialog des Standorts (Abbildung 8.49). Dieser Dialog dient aber nur zur Anzeige und ermöglicht keine Konfiguration.

Abbildung 8.48 In den Eigenschaften des Subnetzes wird der zugehörige Standort gewählt.

Abbildung 8.49 In den Eigenschaften des Standorts können die zugehörigen Subnetze angeschaut werden; es besteht aber keine Konfigurationsmöglichkeit.

In einem gerade installierten Active Directory existiert immer ein Standort namens »Standardname-des-ersten-Standorts«. Dieser Standort kann problemlos (und übrigens auch risikolos) umbenannt werden.

Falls ein Domänencontroller im »falschen« Standort angezeigt wird, kann er sehr einfach verschoben werden. Im Kontextmenü des Servers in Active Directory-Standorte und -Dienste findet sich die Funktion Verschieben (Abbildung 8.50). Ein Klick auf diesen Eintrag öffnet eine Liste mit allen vorhandenen Standorten.

Abbildung 8.50 Das Verschieben des Domänencontrollers an einen anderen Standort ist mit wenigen Klicks erledigt.

8.2.4 Replikation

Active Directory basiert auf einer verteilten und replizierten Datenbankarchitektur. Wer mit Datenbanken zu tun hat, weiß, dass gerade die Replikation von Daten zu den anspruchsvollen Aufgabenstellungen unserer Zeit gehört. Erschwerend kommt hinzu, dass die Domänencontroller häufig nicht durch ein Hochgeschwindigkeits-LAN verbunden sind, sondern unter Umständen weltweit verteilt sind. Es muss also Rücksicht auf langsame WAN-Strecken genommen und die Tatsache berücksichtigt werden, dass Firewalls und Router zwischen den Systemen stehen.

Einige theoretische Aspekte

Die Replikation des Active Directory basiert auf folgenden Aspekten:

• Multimaster-Replikation: Auf allen Domänencontrollern können Veränderungen vorgenommen werden, die an alle anderen DCs weitergegeben werden. Es gibt keinen zentralen (einzigen) DC, der der Ausgangspunkt aller Änderungen ist. (Hinweis: Zu Zeiten von NT4 war der PDC dieser zentrale DC.)
• Pull-Replikation: Domänencontroller fordern Updates bei anderen DCs an. Auf diese Weise wird der Replikationsverkehr klein gehalten, da keine nicht benötigten Updates herumgeschickt werden, sondern nur diejenigen transportiert werden, die von dem jeweiligen DC wirklich gebraucht werden.
• Store-And-Forward-Replikation: Nicht jeder Domänencontroller muss mit jedem anderen der Gesamtorganisation kommunizieren. Vielmehr »verbreiten« die DCs die Informationen über Änderungen innerhalb der Replikationstopologie weiter.
• Statusbasierte Replikation: Jeder Domänencontroller überwacht den Status der Replikations-Updates, die er erhalten hat bzw. noch benötigt. Auf diese Weise werden Konflikte schnell erkannt und wird unnötiger Datenverkehr vermieden.

Wie Sie zuvor bereits gesehen haben, besteht das Active Directory aus einer Anzahl von Klassen, die jeweils durch eine Anzahl von Attributen beschrieben werden. Die Replikation im AD basiert auf Attributen. Wenn also nur ein Attribut eines Benutzerobjekts geändert wird, wird nicht das komplette Objekt übertragen, sondern nur das geänderte Attribut.

Active Directory verwendet mehrere Datenbankbereiche, auch Partitionen oder Namenskontexte genannt.

• Jeder Domänencontroller verfügt über einen Namenskontext mit den Daten »seiner« Domäne. Dieser Namenskontext ist in vielen Werkzeugen unter der Bezeichnung Default Naming Context zu finden. Jeder DC speichert nur einen Domänennamenskontext, also niemals den einer fremden Domäne. Dementsprechend wird er nur innerhalb der Domäne repliziert.
• Weiterhin gibt es zwei organisationsweite Namenskontexte, die über den gesamten Forest repliziert werden. Dies sind der Configuration-Namenskontext und der Schema-Namenskontext.

Man kann sich die Namenskontexte übrigens mittels ADSI-Editor im Active Directory anschauen. In dem Namenskontext Configuration sind im Container Partitions die entsprechenden Einträge zu sehen (Abbildung 8.51):

• CN=UBINF ist der Default Naming Context und enthält die Daten der Domäne. Die auf dieser Abbildung gezeigte Organisation umfasst nur eine Domäne; wären mehrere Domänen angelegt, könnte man zusätzliche Namenskontexte sehen.
• CN=Enterprise Configuration ist der organisationsweit replizierte Namenskontext mit den Konfigurationsdaten.
• CN=Enterprise Schema ist der organisationsweit replizierte Namenskontext mit dem Schema.

Weiter vorn in diesem Kapitel haben Sie erfahren, dass es für die Organisation (den Forest) nur ein einziges Schema gibt. Dies kann man auch daran erkennen, dass es nur einen Schema-Namenskontext gibt, der eben organisationsweit repliziert wird. Dass es für eine Organisation eine gemeinsame und allen Domänencontrollern bekannte (d. h. replikationsweit replizierte) Konfiguration geben muss, ist ebenfalls einleuchtend.

Abbildung 8.51 Mit ADSI-Editor können Sie die vorhandenen Namenskontexte anschauen.

Mit dem nun erworbenen Wissen können Sie einen ersten vorsichtigen Blick auf die Replikationswege im Active Directory riskieren (Abbildung 8.52):

Abbildung 8.52 Stark vereinfache Darstellung der Replikationswege im Active Directory

• Innerhalb einer Domäne werden die Änderungen aller drei Namenskontexte repliziert. Da die Namenskontexte Configuration und Schema im Allgemeinen nur sehr wenige Änderungen erfahren, wird der Hauptverkehr durch die Domänennamenskontexte verursacht werden. Dementsprechend sind in der Abbildung die Pfeile innerhalb der Domäne deutlich breiter gezeichnet.
• Zwischen den Domänen werden wie gesagt nur Schema- und AD-Konfigurationsänderungen transportiert. Im Normalfall ist das ein eher geringes Datenaufkommen; daher sehen Sie hierfür schmale Pfeile in der Abbildung.

Die Skizze ist nun zwar keinesfalls vollständig, liefert aber einen ersten Eindruck. Sie erkennen, dass die Entscheidung über die Anzahl der Domänen nicht nur administrative Konsequenzen, sondern auch Einfluss auf den Replikationsverkehr hat.

Ablauf der Replikation

Nun wird es Zeit, einmal den Ablauf der Replikation zu untersuchen. Abbildung 8.53 zeigt einen Replikationsvorgang.

Abbildung 8.53 Darstellung eines Replikationsvorgangs

• Auf einem Domänencontroller wird ein Attribut geändert. Der DC schreibt es in den Domänennamenskontext (oder Configuration- oder Schema-Namenskontext).
• Im zweiten Schritt ermittelt er die Replikationspartner.
• Im dritten Schritt löst er mittels DNS die Namen der Replikationspartner auf. Dieser Schritt ist in dieser Betrachtung extrem wichtig – nicht etwa, weil es technologisch so spannend wäre, sondern weil hier der häufigste »Störfall« in der AD-Replikation liegt. Wenn eine Replikation nicht funktioniert, liegt in vielen (meiner Erfahrung nach sogar in den meisten) Fällen ein Problem mit der Namensauflösung vor.
• Im vierten Schritt werden die Replikationspartner über Änderungen informiert.
• Der empfangende DC ermittelt im fünften Schritt, welche Änderungen er benötigt, woraufhin der sendende DC diese aus seiner Datenbank liest und übermittelt.
• Im siebten und letzten Schritt schreibt der empfangende DC die erhaltenen Änderungen in seine Datenbank.

Was hat sich geändert?

Die spannende Frage bei einer Replikation ist, welche Daten sich geändert haben und demzufolge repliziert werden müssen.

Die Erkennung der zu replizierenden Daten im Active Directory basiert auf USNs (Update Sequence Numbers). Wird eine Änderung durchgeführt, zählt der Domänencontroller seine USN hoch. Damit Sie es gesehen haben, führe ich Ihnen diesen Vorgang einmal vor.

RootDSE ist ein virtuelles Objekt, das als Einsprungspunkt in das Active Directory fungiert. Man kann mit ADSI-Editor eine Verbindung zum RootDSE-Objekt aufbauen und dessen Eigenschaften auslesen. Das RootDSE-Objekt ist für jeden Domänencontroller individuell vorhanden. In Abbildung 8.54 können Sie beispielsweise erkennen, dass das Attribut dnsHostName des aktuell geöffneten RootDSE-Objekts den Wert alphaDC1.alpha.intra hat.

Im RootDSE-Objekt ist eine weitere Eigenschaft vorhanden, nämlich die highestCommitedUSN, die im gezeigten Beispiel zunächst den Wert 21.059 hat. Etwas vereinfacht gesagt bedeutet dieser Wert, dass die letzte Änderung die USN, also die Änderungsseriennummer 21.059 bekommen hat. Sie werden später sehen, dass diese USN nur die Änderungsnummer auf diesem Domänencontroller ist.

Nun wird eine Änderung am Benutzerobjekt Kathrin Schmitt vorgenommen: Der Name der Abteilung wird geändert. In Abbildung 8.55 können Sie erkennen, dass der Wert der Eigenschaft highestCommitedUSN nach dieser Änderung um 1 hochgezählt worden ist und nun den Wert 21.060 hat.

Abbildung 8.54 Vor dem Durchführen der Änderung ist die höchste USN 21.059.

Abbildung 8.55 Nach dem Durchführen einer Änderung ist die höchste USN 21.060.

Der »Trick« ist nun, dass die Domänencontroller jeweils den Wert highestCommitedUSN aller Domänencontroller speichern, von denen eine Änderung gesendet worden ist. Das System funktioniert dann in etwa wie folgt:

• alphaDC3 hat bei der letzten Replikation gespeichert, dass der Wert für das Attribut highestCommitedUSN von alphaDC1 21.037 ist.
• alphaDC1 hat aber mittlerweile schon eine highestCommitedUSN von 21.062.
• Somit weiß alphaDC3, dass alphaDC1 neuere Daten hat, die er abrufen kann. Die Anzahl der Änderungen, die auf alphaDC1 nach der letzten Replikation mit alphaDC3 aufgelaufen sind, beträgt 21.062 – 21.037 = 25.

Mit dem Kommandozeilenwerkzeug repadmin.exe, das zum Standardumfang von Windows Server 2008/2012/R2 gehört, kann man die highestCommitedUSN-Werte abrufen, die jeder Domänencontroller für die anderen DCs gespeichert hat. Um die Daten für alphadc3.alpha.intra bezüglich des Domänennamenskontexts zu erhalten, lautet der Aufruf:

repadmin /showutdvec alphadc3.alpha.intra dc=alpha,dc=intra

Abbildung 8.56 Vor der Replikation ist die USN für »alphaDC1« auf den Domänencontrollern unterschiedlich.

Abbildung 8.56 zeigt das Ergebnis für den Abruf der drei in diesem Beispiel beteiligten Domänencontroller:

• Es ist zu erkennen, dass auf alphaDC1 als höchste verwendete USN 21.062 verwendet worden ist. Das ist in dem Eintrag für alphaDC1 zu erkennen.
• Die beiden anderen Domänencontroller haben das letzte Mal mit alphaDC1 repliziert, als dort ein Wert von 21.037 aktuell war.
• Folglich gibt es Änderungen auf alphaDC1, die den beiden anderen DCs nicht bekannt sind: unter anderem die zuvor durchgeführte Änderung im Benutzerobjekt Kathrin Schmitt mit der USN 21.060.

Nachdem die Replikation stattgefunden hat, sieht die Situation anders aus. Gezeigt ist dies in Abbildung 8.57: Allen Domänencontrollern ist als highestCommitedUSN für alphaDC1 der Wert von 21.062 bekannt. Die Synchronisation der auf alphaDC1 vorgenommenen Änderungen ist also abgeschlossen.

Interessant wird es nun, wenn man das Benutzerobjekt auf den drei Domänencontrollern anschaut. Zunächst wird man feststellen, dass sämtliche DCs die Änderung bekommen haben – das haben wir ja auch so erhofft.

Abbildung 8.57 Nach dem Replikationsvorgang ist die USN für »alphaDC1« auf allen Domänencontrollern identisch.

Zunächst sollten Sie sicherstellen, dass im Administrationswerkzeug Active Directory-Benutzer und -Computer die Erweiterten Funktionen eingeschaltet sind; im Menü Ansicht findet sich der entsprechende Eintrag. Wenn Sie das Benutzerobjekt aufrufen und auf die Karteikarte Objekt wechseln, wird die aktuelle USN des Objekts angezeigt. (Falls Sie die Karteikarte Objekt nicht sehen, haben Sie die Erweiterten Funktionen nicht eingeschaltet.) Das Ergebnis ist, dass die USN auf allen Domänencontrollern unterschiedlich ist. In Abbildung 8.58 sind die Eigenschaftendialoge der drei DCs gezeigt:

• Die Änderung wurde auf alphaDC1 am 06.01.2007 um 13:57:54 durchgeführt und bekam die USN 21.060 (linke Abbildung).
• Um 14:11:19 wurde die Änderung auf alphaDC2 repliziert, wo sie die Änderung 21.032 war (mittlere Abbildung).
• Einige Sekunden später, nämlich um 14:11:33, kam die Änderung bei alphaDC3 an, wo sie als Änderung 20.953 geführt wird (rechte Abbildung).

Sie sehen, dass die Datenbanken auf den unterschiedlichen DCs nicht ganz exakt identisch sind. Unterschiede gibt es bei den USNs, die auf jedem DC unterschiedlich sind, je nachdem, in welcher Reihenfolge die Änderungen auf dem DC eingehen.

Bei genauerer Betrachtung der Abbildung 8.58 ist übrigens eine weitere interessante Beobachtung zu machen:

• Auf alphaDC1 (links) ist die »ursprüngliche« USN 14.022.
• Auf den beiden anderen Domänencontrollern liegen die Werte deutlich niedriger und sehr nahe beieinander.

Abbildung 8.58 Auf jedem Domänencontroller hat ein Objekt eine andere Update Sequence Number (USN).

Der Hintergrund ist, dass zunächst alphaDC1 da war, auf dem unter anderem das Benutzerobjekt angelegt worden ist. Einige Zeit später wurden dann kurz hintereinander alphaDC2 und alphaDC3 als Domänencontroller installiert. Auf diese Systeme sind dann sämtliche Daten des Domänennamenskontexts übertragen worden, die dort aus Sicht der lokalen AD-Datenbank immer eine Neuanlage dargestellt haben. Dabei wird das Attribut uSNCreated mit der aktuellen USN befüllt.

In der Literatur ist im Zusammenhang mit der Active Directory-Replikation dauernd von einem Up-to-dateness Vector die Rede. Diesen haben Sie bereits kennengelernt – es handelt sich hierbei um die Information, welche die höchste USN eines Domänencontrollers bei der letzten Replikation gewesen ist. Der Up-to-dateness Vector sorgt dafür, dass Änderungen, die bereits bekannt sind, nicht übertragen werden. Der Befehl für das Werkzeug repadmin lautet übrigens /showutdvec: In Langform wird daraus »Show Up-to-dateness Vector«.

Der Up-to-dateness Vector besteht übrigens aus drei Teilen:

• aus der GUID des Replikationspartners
• aus der USN
• aus der Uhrzeit der letzten Replikation

Ein weiterer Mechanismus ist der High-watermark, auch Direct Up-to-dateness Vector genannt. Aus der zweiten Bezeichnung lässt sich schon erkennen, was der Unterschied zum zuvor vorgestellten Up-to-dateness Vector ist:

• Up-to-dateness Vectors werden für alle Domänencontroller gespeichert, die für den entsprechenden Namenskontext jemals Änderungen initiiert haben. Das hört sich auf den ersten Blick eventuell nach »sehr viel« an, ist es aber vermutlich nicht. Bei den organisationsweiten Namenskontexten (Configuration und Schema) wird es nicht allzu viele DCs geben, auf denen wirklich Änderungen vorgenommen werden; im Fall des Schemas kann es ohnehin nur einen geben, nämlich den Schemamaster. Falls es mehrere Domänen in Ihrer Organisation gibt, werden die dortigen Änderungen nur innerhalb der Domäne repliziert, demzufolge werden auch nur Up-to-dateness Vectors für Systeme derselben Domäne gespeichert.
• Der High-Watermark (bzw. Direct Up-to-dateness Vector) bezieht sich lediglich auf direkte Replikationspartner.

Up-to-Dateness Vector und High-Watermark übernehmen also zwei ineinandergreifende Filterfunktionen:

• Über den Up-to-dateness Vector kann erkannt werden, ob Änderungen von einem bestimmten Domänencontroller benötigt werden.
• Über den High-Watermark wird gesteuert, dass nicht von direkten Replikationspartnern Änderungsdaten angefordert werden, die bereits von diesem System empfangen wurden.

Wenn diese Beschreibung Sie nicht zu sehr verwirrt hat, werden Sie jetzt schließen, dass ein Domänencontroller dann also die ursprüngliche USN kennen muss – also die, die auf dem Domänencontroller vergeben wurde, auf dem die Änderung vorgenommen wurde. Man kann das mit repadmin /showvalue überprüfen. Abbildung 8.59 zeigt die Ausgabe einer Änderung, die ursprünglich auf alphaDC1 ausgeführt wurde, für alle drei Domänencontroller. Zu beachten sind insbesondere die Fehler Loc.USN und Org.USN, also die lokale USN und die originale USN, sowie der Eintrag für Originating DSA (DSA = Directory Service Agent, in diesem Fall der Domänencontroller):

• Auf alphaDC1 sind die Werte von Loc.USN und Org.USN erwartungsgemäß gleich.
• Auf alphaDC2 und alphaDC3 sind die Org.USN-Werte identisch, die Loc.USN-Werte unterscheiden sich. Weiterhin erkennen alphaDC2 und alphaDC3, dass die Änderung von alphaDC1 vorgenommen wurde, da dies im Feld Originating DSA gespeichert ist.

Es liegt in der Natur einer Replikation, dass es Konflikte geben kann. Wenn ein Attribut auf zwei Domänencontrollern gleichzeitig geändert wird, muss ein Mechanismus definieren, welcher Wert Gültigkeit haben soll.

• Active Directory geht zunächst nicht nach dem Zeitpunkt der Änderung vor, sondern wertet die Anzahl der Veränderungen aus. In Abbildung 8.59 ist zu erkennen, dass es ein Feld Ver (Version) gibt, dessen Wert bei jeder Änderung hochgezählt wird. Es »gewinnt« die Änderung mit der höheren Versionsnummer.
• Haben beide Änderungseinträge die gleiche Versionsnummer, wird der Zeitstempel ausgewertet.
• Ist auch der Zeitstempel identisch (was schon ein riesiger Zufall sein müsste), gewinnt der Eintrag, der von dem Server mit der höheren GUID kommt.

Abbildung 8.59 Die Änderung eines Attributs an einem Objekt, ausgegeben mit »repadmin«

Ein Beispiel:

• DC1 ändert einen Wert.
• DC2 ändert ebenfalls diesen Wert.
• DC1 ändert den Wert wieder.
• Ergebnis: Der gültige Wert ist derjenige von DC1, weil dieser zweimal geändert wurde. Die Uhrzeit der Änderungen ist dabei unerheblich. Selbst wenn die Uhr von DC2 deutlich vorgeht, wird der DC1-Eintrag gewinnen.

Ich könnte über das Replikationsverfahren noch viele weitere Seiten füllen, für ein erstes grundlegendes Verständnis sollte diese Darstellung aber genügen. Tiefergehende Informationen können Sie in Microsoft TechNet (http://www.microsoft.com/technet) erhalten.

Die Replikationstopologie

Die nächste zu klärende Frage ist, welcher Domänencontroller mit welchem anderen DC replizieren soll.

Um es gleich zu Anfang dieses Abschnitts festzuhalten: In einer kleinen und mittleren Umgebung sollten Sie im Normalfall nicht in die automatisch berechneten Replikationswege eingreifen. KCC (Knowledge Consistency Checker) und ISTG (Intersite Topology Generator) sind so leistungsfähig, dass Sie es per Hand auch nicht besser machen können! Die Frage ist natürlich, was eine »kleine und mittlere Umgebung« im Sinne der automatischen Generierung der Replikationstopologie ist. Wenn Sie in Ihrer Umgebung ein Dutzend Domänen verteilt auf hundert Standorte haben, besteht vermutlich nicht einmal leichter Optimierungsbedarf.

In einem Knowledge-Base-Artikel gibt Microsoft für eine Windows-2000(!)-Umgebung an, dass Sie bei der Bildung der Replikationstopologie beruhigt auf KCC und ISTG vertrauen können, wenn für Ihre Umgebung folgende Formel gilt, wobei D die Anzahl der Domänen und S die Anzahl der Standorte beschreibt:

(1 + D) * S^2 <= 100.000

Auch für eine größere mittelständische Umgebung mit 10 Domänen und 100 Standorten waren also schon zu Zeiten der ersten Version von Active Directory die Grenzen sehr weit gesteckt. Für eine Umgebung, die größer ist, beschreibt der Knowledge-Base Artikel (224368) übrigens keine Eingriffe in die Replikationstopologie an sich, sondern beschreibt einige Änderungen in der Registry, um die Berechnung der Topologie zu beschleunigen.

Mit den neueren Server-Versionen (Windows 2000 ist zum Zeitpunkt, an dem ich diese Zeilen schreibe, bereits fast vierzehn Jahre alt) sind die Verfahren deutlich optimiert worden, sodass Sie davon ausgehen können, dass mit Windows Server 2012 nur in sehr großen Umgebungen wirklich ernsthaft in die Replikationstopologie eingegriffen werden muss. Microsoft gab schon damals in einer Tabelle für Windows Server 2003 an, das die Errechnung der Replikationstopologie bei 40 Domänen und 2.000 Standorten in 38 Sekunden abgeschlossen ist – das dürfte für die Umgebung der meisten Leser genügen.

Dieser Abschnitt über die Replikationstopologie hat daher auch eher die Zielsetzung, zu beschreiben, wie »es funktioniert«, und soll keine Anleitung zum Selbermachen sein.

Bei den Replikationswegen sind grob zwei Fälle zu unterscheiden (Abbildung 8.60):

• die Replikation innerhalb eines Standorts, auch Intrasite-Replikation genannt
• die Replikation zwischen zwei Standorten, auch Intersite-Replikation genannt

Abbildung 8.60 Bei der Replikationstopologie ist zwischen Intrasite- und Intersite-Replikation zu unterscheiden.

Gemeinsam ist diesen beiden Szenarien das Ziel – nämlich alle Domänencontroller möglichst schnell mit aktuellen Daten zu versorgen. Es gibt aber einige fundamentale Unterschiede:

• Da sich alle Domänencontroller eines Standorts in einem LAN befinden oder zumindest über schnelle Verbindungen miteinander kommunizieren können, muss nicht besonders sparsam mit den Netzwerkressourcen umgegangen werden. Innerhalb eines Standorts geht es vielmehr um eine möglichst schnelle Verteilung der Daten.
• Zwischen den Standorten werden zumeist eher langsame und vergleichsweise teure WAN-Strecken liegen. Hier ist das primäre Ziel, möglichst wenig Bandbreite zu verbrauchen. Das wird über zwei Verfahren erreicht: Der Datenverkehr wird komprimiert, und es wird seltener repliziert. Der zweite genannte Punkt mindert zwangsläufig die Aktualität der Daten. Das lässt sich in den meisten Fällen aber verschmerzen, zumal die Replikationsintervalle einstellbar sind.
• Es könnte sein, dass aufgrund der durch Firewalls verbesserten Netzwerksicherheit nicht jeder Domänencontroller über das WAN kommunizieren darf, sondern dass nur ausgewählte DCs Daten über die Firewall austauschen dürfen. Das ist bei der Intersite-Replikation durch die Definition von Bridgeheadservern zu realisieren. Innerhalb eines Standorts muss jeder Domänencontroller mit jedem anderen kommunizieren können.

Der Replikationsverkehr wird über Verbindungen transportiert. Hierbei handelt es sich nicht um separate Softwarekomponenten, sondern um virtuelle Objekte, die durch Konfiguration entstehen. Diese Verbindungsobjekte arbeiten immer unidirektional. Da zwei Domänencontroller im Allgemeinen in beiden Richtungen Daten austauschen, müssen demzufolge zwei Verbindungsobjekte angelegt werden.

Intrasite-Replikation

Innerhalb eines Standorts wird ein Ring gebildet. Dies ist in Abbildung 8.61 gezeigt. Die Anordnung der Domänencontroller in dem Ring ist übrigens nicht zufällig, sondern orientiert sich an den GUIDs der Server. Bei Bedarf lässt sich die GUID mit ADSI-Editor auslesen. Das Attribut heißt objectGUID.

Abbildung 8.61 Innerhalb eines Standorts wird ein Ring gebildet.

Bei großen Standorten, also solchen mit vielen Domänencontrollern, werden zusätzlich Querverbindungen eingefügt. Das Szenario aus Abbildung 8.62 ist übrigens kein großer Standort im Sinne des Active Directory; bei dieser Größe würde keine Querverbindung eingefügt werden. Das Bild ist also als exemplarische Darstellung zu verstehen. Bei der Planung der Verbindungen wird das Ziel verfolgt, dass eine Information über maximal drei Hops (»zu DC2, zu DC3, am Ziel bei DC4«) zwischen zwei Domänencontrollern repliziert wird.

Abbildung 8.62 Bei großen Standorten (d. h. vielen DCs) werden zusätzlich Querverbindungen eingefügt.

Intersite-Replikation

Ein einfaches Beispiel für die standortübergreifende Replikation ist in Abbildung 8.63 gezeigt. Ebenso wie bei der Replikation innerhalb eines Standorts muss nicht jeder Standort mit jedem anderen kommunizieren. Es wird automatisch eine geeignete Topologie erzeugt, wie beispielsweise die in der Abbildung gezeigte.

Abbildung 8.63 Ein Beispiel für standortübergreifende Replikation

Wenn man das Erzeugen der standortübergreifenden Replikationstopologie der »Automatik« überlässt, wird stillschweigend angenommen, dass prinzipiell jeder Domänencontroller mit jedem anderen kommunizieren kann, egal, wo er sich im unter Umständen weltweiten Netz des Unternehmens findet. Anders gesagt müsste das Netz vollständig geroutet sein, und keine Firewalls dürften die Kommunikation zwischen zwei DCs verhindern.

Weiterhin wird angenommen, dass alle Weitverkehrsverbindungen gleich gut (oder schlecht) sind. In der Praxis kann es sehr wohl vorkommen, dass es bevorzugte Verbindungen gibt, die schneller, kostengünstiger und stabiler sind. Hier können Sie manuell eingreifen. Wie das geht, wird ein wenig später besprochen. Zunächst zeige ich Ihnen, wie man eine automatisch erzeugte Replikationstopologie anschauen kann – ohne Drittherstellerprodukte.

Replikationstopologie anschauen

Die kleine Testumgebung hat drei Standorte (RGS, BMS und SBR), in denen sich jeweils ein Domänencontroller befindet. Im Konfigurationswerkzeug Active Directory-Standorte und -Dienste können Sie sehen, dass automatisch Verbindungsobjekte erzeugt werden (Abbildung 8.64). Diese Verbindungsobjekte arbeiten unidirektional und zeigen eine eingehende Verbindung. In der Abbildung gibt es also eine Verbindung von alphaDC2 zu alphaDC1 und eine von alphaDC1 zu alphaDC2.

Abbildung 8.64 Für die Replikation zwischen Standorten werden Standortverknüpfungen erzeugt, die mit »Active Directory-Standorte und -Dienste« eingesehen werden können.

Da man sich anhand der tabellarisch aufgelisteten Verbindungsobjekte nur sehr schwer die resultierende Topologie vorstellen kann (das gilt zumindest für mich), ist sie in Abbildung 8.65 visualisiert. Die Topologie entspricht den Erwartungen. Alle Standorte sind in die Replikation einbezogen. Im Gegensatz zur Intrasite-Replikation wird kein Ring zwischen den Standorten gebildet.

Abbildung 8.65 Die Replikationstopologie mit den automatisch erzeugten Verbindungsobjekten

Falls übrigens Änderungen vorgenommen werden – weil ein Standort hinzugefügt oder entfernt wird oder es zu einem Ausfall kommt – wird eine Neuberechnung der Replikationstopologie vorgenommen, und zwar automatisch.

Verbindungen, Standortverknüpfungen und Standortverknüpfungsbrücken

Sie haben die Chance, in die Replikation zwischen den Standorten einzugreifen. Dies geschieht im Wesentlichen mit Verbindungsobjekten, Standortverknüpfungen und Standortbrücken.

Verbindungen

Ein Verbindungsobjekt repräsentiert eine Verbindung zwischen zwei Domänencontrollern. Wie Sie zuvor schon gesehen haben, können Sie die eingehenden Verbindungen eines Servers sehen, wenn Sie in Active Directory-Standorte und -Dienste auf den Knoten NTDS-Settings unterhalb des Servers klicken. Verwechseln Sie diesen Knoten nicht mit NTDS Site Settings, der sich unterhalb des Standorteintrags befindet.

Die Eigenschaften der Verbindung können Sie mit dem Dialog aus Abbildung 8.66 einstellen:

• Eine Beschreibung können Sie frei eintragen.
• Als Transport kommt im Normalfall IP zum Einsatz. SMTP macht in Sonderfällen Sinn, eignet sich aber nicht für die Replikation zwischen zwei DCs einer Domäne.
• Weiterhin kann eingestellt werden, welcher Server der Replikationspartner dieser Verbindung ist.
• Der Button Zeitplan ändern ruft den ebenfalls in der Abbildung gezeigten Dialog auf, mit dem die Zeitfenster und die Häufigkeit der Replikation konfiguriert werden können.

Abbildung 8.66 Konfiguration eines Verbindungsobjekts

Um die Verbindungen eines Servers zu sehen, rufen Sie die Eigenschaften des Knotens NTDS Settings auf, die sich unterhalb von Servers befinden. Auf der Karteikarte Verbindungen des Eigenschaftendialogs finden Sie eine Auflistung der eingehenden und ausgehenden Replikationsverbindungen (Abbildung 8.67). Obwohl in diesem Dialog nichts konfiguriert werden kann, ist er sehr praktisch, weil man sich die ausgehenden Verbindungen sonst mühsam zusammensuchen müsste.

Abbildung 8.67 In diesem Eigenschaftendialog finden Sie eine Übersicht über alle eingehenden und ausgehenden Replikationsverbindungen eines Domänencontrollers.

Mit den Verbindungsobjekten könnte man sich vollkommen manuell eine Replikationstopologie basteln. Davon ist aber unbedingt abzuraten, denn schließlich verfügt Active Directory ja über Technologie, um eine optimale Routing-Topologie zu erstellen und diese auch im Fehlerfall (beispielsweise nach dem Ausfall eines zentralen Domänencontrollers) sehr zeitnah zu korrigieren. Wenn Sie bestimmte Netzwerkwege vorgeben möchten, können Sie das implementieren, ohne gleich alle Automatismen über Bord werfen zu müssen. Hierzu bedient man sich der Standortverknüpfungen.

Standortverknüpfungen

Wenn das Active Directory neu installiert ist, findet sich eine Standortverknüpfung (Site Link) mit dem Namen DEFAULTIPSITELINK. In dieser Standortverknüpfung sind standardmäßig alle Standorte enthalten – das ist auch der Grund dafür, dass alles funktioniert, auch ohne dass man sich Gedanken über Standortverknüpfungen macht. Wenn diese Standortverknüpfung die einzige ist, signalisiert das dem Active Directory, dass die Replikationswege völlig frei gebildet werden können, ohne dass weitere Parameter zu beachten sind (Abbildung 8.68).

Abbildung 8.68 Die Standardstandortverknüpfung sorgt dafür, dass zunächst alles funktioniert – allerdings werden keine Besonderheiten Ihres Netzes berücksichtigt.

In Abbildung 8.65 haben Sie bereits das Ergebnis der automatischen Generierung der Intersite-Replikationstopologie gesehen. Der Replikationsverkehr lief dort zwischen den Standorten RGS/BMS und BMS/SBR. Nun wäre es durchaus denkbar, dass der Zentralstandort, der breitbandige Verbindungen zu allen Außenstandorten hat, RGS ist. Zwischen BMS und SBR hingegen liegt nur eine ISDN-Wählleitung, die im Notfall verwendet werden kann.

Wie bringt man das dem Active Directory bei? Und zwar richtig?

Das Ergebnis soll der Skizze aus Abbildung 8.69 entsprechen. Die Vorgehensweise ist diese:

• Zwischen RGS und BMS wird eine Standortverknüpfung erzeugt. Ihr werden als Kosten 10 zugeordnet.
• Weiterhin wird eine Standortverknüpfung zwischen RGS und SBR erzeugt, ebenfalls mit Kosten von 10.
• Fertig!

In der Tat sind Sie mit Ihren Konfigurationsarbeiten fertig, denn das Erzeugen der Verbindungen erledigt Active Directory bzw. der Knowlegde Consistency Checker selbst. Sie sehen, dass keine Notwendigkeit besteht, selbst an den Verbindungsobjekten herumzuwerkeln!

Abbildung 8.69 So soll die Replikationstopologie aussehen. Die Verbindungen werden vom Knowledge Consistency Checker automatisch erzeugt.

Über einen Aspekt müssen wir noch nachdenken: Wenn der DEFAULTIPSITELINK nicht gelöscht wird, wird beim Ausfall von alphaDC1 eine neue Replikationstopologie generiert werden, die eine direkte Verbindung zwischen den Standorten BMS und SBR vorsieht. Soll das unterbunden werden, kann der DEFAULTIPSITELINK gelöscht werden. Sofern alle Systeme korrekt arbeiten, wird über den DEFAULTIPSITELINK aber keine Replikation laufen, denn die eingestellten Kosten sprechen dagegen:

• Eine Replikation zwischen SBR und BMS über RGS hat Kosten von 20 (RGS-SBR kostet 10 und RGS-BMS ebenfalls 10).
• Die direkte Verbindung zwischen SBR und BMS über den DEFAULTIPSITELINK kostet 100 – sofern die dortige Standardeinstellung nicht verändert wird.

Active Directory wird immer die günstigsten Kosten wählen. Falls allerdings durch einen Ausfall die Replikation über diesen Weg nicht möglich ist, werden auch teurere Verbindungen genutzt, sofern solche vorhanden sind, sprich: sofern entsprechende Standortverknüpfungen eingetragen sind.

Von der Theorie geht es direkt in die Praxis: Das Anlegen einer Standortverknüpfung ist trivial einfach. In Active Directory-Standorte und -Dienste rufen Sie, wie in Abbildung 8.70 gezeigt, das Anlegen einer IP-Standortverknüpfung auf und tragen in dem sich öffnenden Dialog ein, welche Standorte enthalten sein sollen.

Abbildung 8.70 Das Anlegen einer neuen Standortverknüpfung

Bei der angelegten Standortverknüpfung ist allerdings noch ein wenig Nacharbeit erforderlich. Rufen Sie den Eigenschaftendialog der angelegten Standortverknüpfung auf, und tragen Sie die Kosten ein. Wenn Sie mögen, können Sie auch die Werte für das Replikationsintervall (minimal 15 Minuten, maximal eine Woche) und die Zeiten, in denen über diese Standortverbindung repliziert wird, Ihren Wünschen entsprechend anpassen (Abbildung 8.71).

Nach mehr oder weniger vielen Minuten (entschuldigen Sie die ungenaue Angabe, aber die Zeit hängt von Ihren eingestellten Replikationsintervallen ab), wird die neue Replikationstopologie errechnet und kann beispielsweise in Active Directory-Standorte und -Dienste angeschaut werden. In Abbildung 8.72 können Sie beispielsweise sehen, dass alphaDC1 am Standort RGS sowohl zu dem Domänencontroller am Standort BMS als auch zu dem in SBR Verbindungen hat.

Abbildung 8.71 In den Eigenschaften der angelegten Standortverknüpfungen können weitere Einstellungen vorgenommen werden.

Abbildung 8.72 Kurze Überprüfung: Es funktioniert. »alphaDC1« hat wie gewünscht Verbindung zu den anderen Standorten.

Wohlgemerkt: Wir haben keine Verbindung von Hand angelegt, sondern vorgegeben, welche Wege für Verbindungen genutzt werden sollen. Den Rest hat das Active Directory (bzw. der KCC) selbst erledigt.

Standortverknüpfungsbrücken

Falls ein IP-Netz nicht völlig geroutet ist, ziehen neue Probleme am Horizont auf, die gelöst werden müssen. Betrachten Sie Abbildung 8.73. Dort ist eine Umgebung mit fünf Standorten zu sehen. Da die Standortverknüpfungen transitiv sind, könnte durchaus eine Replikation zwischen Standort C und E geplant werden, d. h. es könnten entsprechende Verbindungen erzeugt werden. Sofern aber kein IP-Routing zwischen diesen Segmenten vorhanden ist, schlägt der Verbindungsaufbau fehl.

Abbildung 8.73 Das Beispielszenario: Wenn das Gesamtnetz nicht komplett geroutet ist, ist die Transitivität der Standortverknüpfungen ein Problem.

Das Problem lässt sich dadurch recht einfach in den Griff bekommen, dass man die Transitivität der Standortverknüpfungen aufhebt. Das hört sich wesentlich komplizierter an, als es tatsächlich ist. In den Eigenschaften des Knotens IP (unterhalb von Inter-Site Transports) deselektieren Sie die Checkbox Brücke zwischen allen Standortverknüpfungen herstellen (Abbildung 8.74). Fertig!

Abbildung 8.74 Um die Transitivität der Standortverknüpfungen abzuschalten, entfernen Sie das Häkchen aus der Checkbox »Brücke zwischen allen Standortverknüpfungen herstellen«.

Abbildung 8.75 Die Standortverknüpfungsbrücke AC–AD ermöglicht Verbindungen zwischen den Standorten C und D.

Die Konsequenz des Ausschaltens der Transitivität ist nun, dass sämtliche Replikationsvorgänge ausschließlich über Standort A laufen. Falls das Netz zwischen Standort C und D geroutet ist und dies bei der Replikation genutzt werden soll, kann man eine Standortverknüpfungsbrücke einrichten (Abbildung 8.75).

Das Einrichten einer Standortverknüpfungsbrücke ist in Abbildung 8.76 gezeigt. Nach dem Aufruf der entsprechenden Funktion können Sie die Standortverknüpfungen auswählen, die in dieser Brücke enthalten sein sollen.

Abbildung 8.76 Einrichten einer Standortverknüpfungsbrücke

Die Standortverknüpfungsbrücke hat keinen eigenen Kostenwert. Ihre Kosten berechnen sich aus der Summe der Kosten der Standortverknüpfungen.

Ob die Standortverknüpfungsbrücke tatsächlich für Verbindungen verwendet wird, hängt einerseits von ihren Kosten und andererseits von den sonstigen Gegebenheiten ab. Der Knowledge Consistency Checker kann Verbindungen über die Brücke legen, er muss es aber nicht tun.

Bridgeheadserver

Bei standortübergreifenden Replikationsverbindungen ist wichtig zu wissen, welcher Server tatsächlich mit entfernten Standorten kommuniziert. Falls zwischen den Standorten Firewalls angeordnet sind, die innerhalb des Netzes nicht sämtliche Verbindungen zulassen, wird es von Interesse sein, jeweils nur einen bestimmten Server für die standortübergreifende Kommunikation »freizuschalten«.

Server, die mit anderen Standorten replizieren, nennt man Bridgeheadserver. Man kann einen Bridgeheadserver erkennen, wenn man sich in Active Directory-Standorte und -Dienste die Replikationspartner anschaut. Derjenige Server, der eine Verbindung zu einem anderen Standort hat, ist ein Bridgeheadserver. Man kann eine Bridgeheadserver-Liste auch professioneller erzeugen, indem man folgenden Befehl an der Kommandozeile aufruft:

repadmin.exe /bridgeheads

Die Ausgabe des Werkzeugs sehen Sie in Abbildung 8.77. Sie erkennen, mit welchen Replikationspartnern ein DC welche Namenskontexte repliziert.

Abbildung 8.77 Mit dem Werkzeug »repadmin.exe« können Sie eine Liste aller Bridgeheadserver erzeugen.

Es gibt drei Möglichkeiten, wie ein Domänencontroller zum Bridgeheadserver wird:

• Durch automatische Auswahl – dann kann jeder beliebige Domänencontroller Bridgeheadserver werden.
• Es ist möglich, DCs als bevorzugte Bridgeheadserver anzugeben. Wenn in einem Standort mindestens ein als bevorzugter Bridgeheadserver gekennzeichneter DC vorhanden ist, wird einer dieser Domänencontroller ausgewählt.
• Wenn manuell eine Verbindung zwischen zwei Systemen an unterschiedlichen Standorten eingerichtet wird, werden diese dadurch ebenfalls Bridgeheadserver.

Die Aufgabenstellung ist nun, dafür zu sorgen, dass nur ein bestimmter Server (oder wenige) Bridgeheadserver wird, um die Firewalls maximal schließen zu können. Daher sind die Varianten zwei und drei betrachtenswert. Abgesehen von Ausnahmefällen sollte man vermeiden, manuell Verbindungen einzurichten, daher betrachten wir die dritte Möglichkeit nicht weiter.

In den Eigenschaften eines Domänencontrollers können Sie, wie in Abbildung 8.78 gezeigt, definieren, dass er für einen bestimmten Transporttyp (im Allgemeinen wird das IP sein) bevorzugter Bridgeheadserver sein soll.

Wenn in einem Standort nur ein einziger Server als bevorzugter Bridgeheadserver definiert ist, wird er auf jeden Fall diese Funktion erhalten – der KCC hat ja auch keine andere Auswahlmöglichkeit. Eine solche Konfiguration ist aber keine gute Idee! Immerhin ist es nicht ausgeschlossen, dass ein Server, hier speziell dieser Domänencontroller, ausfallen könnte. Der Ausfall eines Bridgeheadservers ist im Grunde genommen harmlos, zumindest wenn ein weiterer DC in dem Standort vorhanden ist, der diese Rolle übernehmen könnte. Wenn Sie nur einen Domänencontroller als bevorzugten Bridgeheadserver definiert haben und dieser ausfällt, wird der Standort von der Außenwelt abgeschnitten sein.

Abbildung 8.78 Ein Server kann als bevorzugter Bridgeheadserver definiert werden.

Die Empfehlung ist also, zumindest zwei Domänencontroller als bevorzugte Bridgeheadserver zu definieren.

Wenn es Ihnen egal ist, welcher Server Bridgeheadserver wird, aber einige DCs es auf keinen Fall werden sollen, bräuchten Sie eigentlich eine Negativliste. Die gibt es zwar nicht direkt, sie entsteht aber dadurch, dass alle anderen DCs zu bevorzugten Bridgeheadservern erklärt werden.

Es gibt zwei Anmerkungen zum Thema Bridgeheadserver und globaler Katalog:

• Wenn es an einem Standort einen globalen Katalogserver gibt, sollte dieser einer der bevorzugten Bridgeheadserver sein.
• Wenn ein Standort einen globalen Katalogserver hat, aber nicht mindestens einen Domänencontroller von jeder Domäne der Organisation enthält, dann muss mindestens ein Bridgeheadserver ein globaler Katalogserver sein.

KCC und ISTG (Knowledge Consistency Checker und Intersite Topology Generator)

Die folgenden Funktionen sind in diesem Kapitel bereits erwähnt worden:

• KCC: Knowledge Consistency Checker
• ISTG: Intersite Topology Generator

Diese beiden Funktionen sind dafür verantwortlich, dass die Replikationstopologie optimal ermittelt und aktiviert wird. Der KCC nimmt Anpassungen vor, indem er Verbindungsobjekte löscht und anlegt. Wenn Sie manuell Verbindungsobjekte anlegen, wird der KCC diese zwar nicht löschen, trotzdem ist es im Normalfall empfehlenswert, das Anlegen und Löschen der Verbindungsobjekte dem KCC zu überlassen. Durch Standortverknüpfungen, die Definition von bevorzugten Bridgeheadservern und Standortverknüpfungsbrücken können Sie den KCC dazu bringen, dass er die Topologie so erzeugt, wie Sie es gern hätten.

Der KCC ist eine verteilte Applikation, die auf jedem Domänencontroller ausgeführt wird. Technisch ist der KCC als DLL (Dynamic Link Library) implementiert, Sie werden also keine startbare EXE-Datei finden.

Der KCC modifiziert die Daten in seiner lokalen Active Directory-Datenbank und reagiert auf Änderungen, die im Configuration-Namespace vorgenommen werden. Auch bei sonstigen Änderungen in der Umgebung reagiert der KCC. Fällt beispielsweise ein für die Replikation wichtiger Domänencontroller aus, ändert der KCC die Replikationstopologie und sorgt beispielsweise dafür, dass kein Standort vom Replikationsverkehr ausgeschlossen ist.

Der KCC wird alle 15 Minuten aktiv und überprüft, ob Modifikationen in der Replikationstopologie auf »seinem« jeweiligen Domänencontroller notwendig sind.

In den administrativen Werkzeugen nicht sichtbar sind die Connection Agreements oder auch Replica Links. Hierbei handelt es sich um »Vereinbarungen«, die zwischen zwei gegeneinander replizierenden Domänencontrollern geschlossen werden. Unter anderem wird dort gespeichert, welche Namenskontexte (z. B. Schema, Configuration, Domänennamenskontext) repliziert werden.

KCC aktualisiert diese Connection Agreements bei jedem Durchlauf, also alle 15 Minuten.

Ein KCC pro Domäne hat eine zusätzliche Aufgabe: Er fungiert nämlich als Intersite Topology Generator. Dieser ist, wie der Name bereits sagt, für die standortübergreifende Replikationstopologie verantwortlich. Genauer gesagt, generiert er die von anderen Standorten eingehenden Verbindungsobjekte für alle Domänencontroller »seines« Standorts. Typischerweise hat der erste installierte DC einer Domäne die ISTG-Rolle inne. Dies wird sich dann ändern, wenn er ausfällt; in diesem Fall wird ein neuer ISTG ermittelt (Abbildung 8.79).

Abbildung 8.79 In den Eigenschaften des »NTDS Site Settings«-Objekts eines Standorts ist der ISTG zu sehen (»Standortübergreifende Topologie erstellen«).

Wenn Sie Änderungen vornehmen, die eine Anpassung der Replikationstopologie notwendig machen, wird der KCC diese vornehmen – ohne dass Sie selbst in irgendeiner Form eingreifen müssen. Allerdings kann es mehrere Minuten bis zu Stunden dauern, bis diese Änderungen errechnet, umgesetzt und über die Organisation verteilt worden sind. Sie können in Active Directory-Standorte und -Dienste allerdings die Replikation und die Überprüfung der Replikationstopologie erzwingen. Sie finden diese Befehle in den Kontextmenüs der Verbindungsobjekte bzw. der NTDS Settings-Objekte der Server.

Am Knowledge Consistency Checker können Sie einige kleinere »Tuningmaßnahmen« vornehmen, beispielsweise um Schwellenwerte, ab wann ein Domänencontroller als »nicht verfügbar« eingestuft wird, zu verändern. Bevor Sie zu solchen Maßnahmen greifen, sollten Sie sich aber mehr als absolut sicher sein, was Sie tun, um dem Active Directory nicht irreparablen Schaden zuzufügen!

Überwachung

Trotz aller Maßnahmen, die im Active Directory bereits »eingebaut« sind, ist es denkbar, dass die Replikation teilweise ausfällt und ein Domänencontroller oder sogar ein ganzer Standort nicht mehr replizieren kann. Der Ausfall der Replikation ist im Allgemeinen nicht unternehmensgefährdend, denn das Active Directory steht auch zur Verfügung, wenn keine Replikation stattfindet. Allerdings treten nach einer mehr oder weniger kurzen Zeitspanne mitunter »merkwürdige Effekte« auf. Diese bestehen im einfachsten Fall darin, dass Benutzer sich manchmal anmelden können und in anderen Fällen das angegebene Kennwort abgewiesen wird – das ist ein typischer Fall, wenn die Replikation des Domänennamenskontexts ausgefallen ist, da jetzt keine Kennwortreplikation mehr stattfindet.

Es gibt natürlich Werkzeuge, um festzustellen, ob die Replikation funktioniert. Zum einen können Sie auf Bordmittel zurückgreifen und mit repadmin.exe die einzelnen Domänencontroller abklappern und das Ergebnis des Aufrufs repadmin /showrepl dcname auswerten (Abbildung 8.80).

In einer größeren Umgebung mit unter Umständen mehreren Dutzend Domänencontrollern ist die »manuelle Überwachung« natürlich kein glücklicher Weg. Es gibt aber Werkzeuge, die Ihnen bei der Überwachung helfen können:

• Zuerst möchte ich den Microsoft System Center Operations Manager (SCOM, vormals MOM) nennen. Dieses System kann regelbasiert den Zustand von Servern überwachen und dabei mithilfe eines entsprechenden Management Packs sehr detailliert das Active Directory anschauen – und zwar permanent.
• Auf dem Markt existieren Produkte von unabhängigen Softwareherstellern, die Active Directory untersuchen und überwachen können. Zu nennen wäre hier beispielsweise Spotlight on Active Directory von Quest (www.quest.com).

Zum Abschluss noch eine Anmerkung: Active Directory ist prinzipiell in der Lage, Ausfälle von Systemen abzufedern. Das funktioniert einerseits natürlich nur, wenn entsprechend redundante Systeme vorhanden sind. Andererseits ist es wichtig, dass nicht durch eine nichtoptimale Konfiguration diese Redundanzen sozusagen ausgeschaltet sind. Ein kleines Beispiel: Wenn sich an einem Standort drei Domänencontroller befinden, aber nur einer als bevorzugter Bridgeheadserver eingetragen ist, wird dessen Ausfall dazu führen, dass der komplette Standort für die Replikation nicht erreichbar ist.

Abbildung 8.80 Mit »repadmin.exe« können Sie überprüfen, ob und wann ein Domänencontroller erfolgreich mit seinen Replikationspartnern repliziert hat.

8.2.5 Gruppenrichtlinien

Das Thema »Gruppenrichtlinien« ist so wichtig, dass es in einem eigenen Abschnitt untergebracht ist, und zwar in Abschnitt 8.4.

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.