Der Infrastrukturmaster ist dafür verantwortlich, die Integrität der Objektreferenzen zwischen domänenübergreifenden Objekten innerhalb einer Gesamtstruktur aktuell zu halten. Beispielsweise bei domänenübergreifenden Gruppenmitgliedschaften.


Fügt man in einem Single-Domain Forest ein Sicherheitsprinzipal, wie es ein Benutzer, eine Gruppe oder ein Computer darstellt, zu einer Gruppe hinzu, wird der Distinguished Name (DN) des Sicherheitsprinzipals ins member Attribut (Forward-Link) der Gruppe hinzugefügt. Das AD erstellt im Gegenzug ohne ein zusätzliches Objekt einen Back-Link (das memberOf Attribut im Sicherheitsprinzipal) und referenziert damit das Sicherheitsprinzipal, das zur Gruppe hinzugefügt wurde. Benennt man ein Sicherheitsprinzipal um, verschiebt oder löscht es, wird automatisch das member Attribut der Gruppe aktualisiert. Da der Infrastrukturmaster seine Aufgabe erst in einem Multi-Domain Forest wahrnimmt, befindet er sich in einem Single-Domain Forest in einem inaktiven Zustand, da es für ihn keine Arbeit gibt.


Möchte man aber innerhalb eines Multi-Domain Forest beispielsweise den BenutzerA aus der DomäneA zur GruppeB aus der DomäneB hinzufügen, so hat das AD ein Problem. Denn das AD kann keinen Back-Link zu einem Objekt erstellen, das sich in einer anderen Domäne und somit in einer anderen Domänenpartition befindet. Das AD löst dieses Problem durch das Erstellen eines Phantomobjekts. Mit Phantomobjekten (nicht zu verwechseln mit Tombstones, Lingering Objects oder Foreign Security Principals) ist es möglich, Objekte in anderen Domänen innerhalb der Gesamtstruktur zu referenzieren. Innerhalb der AD-Datenbank wird eine Referenz auf das Objekt als ein Zeiger auf das Phantomobjekt repräsentiert. Phantomobjekte werden also erst dann erstellt, wenn in der Gesamtstruktur mehr als eine Domäne existiert und zwischen zwei Objekten, die sich in verschiedenen Domänen befinden, eine Verknüpfung besteht!


Phantomobjekte werden aber nur vom Infrastrukturmaster erstellt. Deshalb ist es der Infrastrukturmaster aus der DomäneB, der ein Phantomobjekt für BenutzerA erstellt. Das Gruppenobjekt „GruppeB“ verweist mit dem Phantomobjekt auf das Benutzerobjekt „BenutzerA“. Dabei enthält das Phantomobjekt eine minimale Menge an Informationen, damit ein DC das ursprüngliche Objekt (BenutzerA) an seinem ursprünglichen Ort referenzieren kann. Jedes Phantomobjekt in der AD-Datenbank enthält vom referenzierten Objekt die folgenden Informationen: objectGUID, objectSID (für Verweise auf Sicherheitsprinzipale) und den DN des Objekts.


Der Infrastrukturmaster ist auch für die Verwaltung eines Phantomobjekts verantwortlich. Wenn das Sicherheitsprinzipal (BenutzerA), auf das sich ein Phantomobjekt bezieht, umbenannt, verschoben oder gelöscht wird, aktualisiert der Infrastrukturmaster das Phantomobjekt. Dazu vergleicht der Infrastrukturmaster in regelmäßigen Abständen die Phantomobjekte mit den Informationen vom globalen Katalog (GC). Stellt der Infrastrukturmaster dabei eine Abweichung fest, aktualisiert er das Phantomobjekt. Die Aktualisierung repliziert er dann zu seinen Replikationspartnern innerhalb der Domäne, die ebenfalls eine Kopie des Phantoms besitzen. Ohne diese Vorgehensweise würden die eigentlichen Änderungen an den referenzierten Objekten (z.B. BenutzerA wird umbenannt) nicht an das gegenüberliegende Objekt (GruppeB) übertragen werden.


Da der globale Katalog regelmäßig Aktualisierungen für alle Objekte in der Gesamtstruktur erhält, sind die Daten auf dem GC stets auf dem aktuellen Stand. Dadurch das ein GC bereits über ein Teilreplikat aller Objekte in der Gesamtstruktur besitzt, speichert er auch keine Phantomobjekte. Denn er kennt bereits jedes Objekt aus allen Domänen innerhalb der Gesamtstruktur und somit existieren keine Verweise auf Objekte, die ein GC nicht kennt. Daher darf der Infrastrukturmaster in einem Multi-Domain Forest nicht einem GC zugewiesen werden, denn er würde keine Unterschiede erkennen. Der Infrastrukturmaster leistet seine Arbeit innerhalb seiner Domäne ausschließlich an DCs, die kein GC sind.


Wird allerdings in einem Multi-Domain Forest auf jedem DC in der Domäne, in der auf dem Infrastrukturmaster der GC aktiviert wurde ebenfalls der GC aktiviert, werden auf keinem der DCs dieser Domäne jemals Phantomobjekte erstellt. Daher erübrigt sich das Aktualisieren der Phantomobjekte. Denn alle DCs dieser Domäne kennen bereits durch das Aktivieren des GC alle Objekte in der Gesamtstruktur und somit hat der Infrastrukturmaster nichts zu tun. In solch einem Fall wird der Infrastrukturmaster ebenfalls in einen inaktiven Zustand versetzt.


Die FSMO-Rollen verschieben



Übrigens wird das Entfernen eines Phantomobjekts nicht vom Infrastrukturmaster, sondern vom Garbage Collection Prozess durchgeführt.


Weitere Details zu Phantomobjekten liefert der folgende Artikel:


Phantome im Active Directory


 



Wenn der AD-Papierkorb in der Gesamtstruktur aktiviert ist


Ist allerdings der AD-Papierkorb aktiviert, der sich erst ab dem Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“ aktivieren lässt, ist die Funktion des Infrastrukturmasters nicht mehr länger an einen einzelnen DC gebunden! Die Aufgabe des Infrastrukturmasters ist jetzt auf alle DCs in der Gesamtstruktur verteilt. Jeder DC in einem Multi-Domain Forest ist für die Aktualisierung seiner domänenübergreifenden Objektverweise, sprich, für das Phantomobjekt das sich in seiner lokalen AD-Datenbank befindet, verantwortlich. In dem Fall, dass das referenzierte Sicherheitsprinzipal umbenannt, verschoben oder gelöscht wird, aktualisiert jeder DC sein Phantomobjekt.


Wenn also der AD-Papierkorb aktiviert ist, hat der Infrastrukturmaster keine Aufgaben mehr und es ist irrelevant, welcher DC die FSMO-Rolle des Infrastrukturmaster innehat!


Der Active Directory-Papierkorb im Windows Server 2008 R2



 


Weitere Informationen:
Verknüpfte Attribute
Die verknüpften Attribute abfragen
Lingering Objects (veraltete Objekte)
Globaler Katalog (Global Catalog – GC)
Was passiert in der AD-Datenbank wenn ein Objekt gelöscht wird?
Phantoms, tombstones and the infrastructure master
7.1.5.5 Infrastructure FSMO Role

Comments are closed, but trackbacks and pingbacks are open.