Was passiert in einer Gesamtstruktur mit mehreren Domänen GENAU, wenn sich einige, aber nicht alle Infrastruktur-Master in globalen Katalogen befinden?

Es gibt viele TechNet-Artikel wie diesen , die besagen, dass Phantomobjekte nicht aktualisiert werden, wenn ein Infrastruktur-Master auch ein globaler Katalog ist, aber ansonsten gibt es nicht viele detaillierte Informationen darüber, was tatsächlich darin passiert Aufbau.

Stellen Sie sich eine Konfiguration wie diese vor:

|--------------|
| example.com  |
|              |
| dedicated IM |
|--------------|
    |
    |
    |
|-------------------|
| child.example.com |
|                   |
|  IM on a GC       |
|-------------------|

Wo childhat zwei DCs, die beide globale Kataloge sind, was bedeutet, dass sich die Infrastructure Master-Rolle auf einem GC befindet. Und verfügt exampleüber drei DCs mit der Infrastructure Master-Rolle auf einem DC, der kein GC ist.

Ich verstehe, dass es normalerweise am besten ist, einfach alles zu einem GC zu machen und sich nicht um solche Dinge kümmern zu müssen, aber vorausgesetzt, dass dies nicht der Fall ist - was ist das genaue Fehlerverhalten, das von einem solchen Setup erwartet werden kann, und welche Domäne ( s) würde sich dieses Verhalten manifestieren? Das Kind oder die Eltern?

Ein Domänencontroller, der kein globaler Katalog ist, verfügt nicht über eine Kopie (Teilattributsatz oder nicht) von jedem Objekt in der Gesamtstruktur. Daher muss ein solcher DC "Phantom" -Objekte erstellen, um auf reale Objekte aus einer anderen Domäne zu verweisen.

Der Infrastruktur-Master in der Domäne ist für die Aktualisierung dieser Phantomreferenzen auf den anderen Domänencontrollern in der Domäne verantwortlich. Zu diesem Zweck wird zunächst auf einen globalen Katalogserver in seiner Domäne verwiesen, da davon ausgegangen wird, dass globale Kataloge über das umfassendste und aktuellste Wissen zu allen Objekten in der Gesamtstruktur verfügen.

Das Problem ist das. Wenn der Infrastruktur-Master derselbe Server wie der globale Katalog ist, überprüft der IM bei der Aktualisierung (alle zwei Tage) einen GC, der zufällig auch er selbst ist. "Nun, ich sehe hier keinen Unterschied!" Er sagt, weil er bereits auf einem GC ist und es keinen Unterschied gibt, was auf einem GC und was auf dem IM ist ... also sieht es natürlich so aus, als wäre er völlig auf dem neuesten Stand. Das Problem ist jetzt, dass er wieder einschlafen kann, zufrieden, dass es nichts zu tun gibt. Dies bedeutet, dass die anderen Domänencontroller in der Domäne, die keine GCs sind, nicht mit diesen domänenübergreifenden Informationen aktualisiert werden.

Bearbeiten:

Wenn Sie ein Objekt in example.com erstellt haben, wird es in child.example.com auf den GC repliziert. Da child.example.com jedoch einen IM auf einem GC und auch andere DCs hat, die keine GCs sind, würde dieses neue Objekt Lassen Sie niemals ein Phantom dafür auf diesen anderen Domänencontrollern in child.example.com erstellen. Daher können Sie dieses neue Objekt nicht zu ACLs hinzufügen oder es von diesen anderen Domänencontrollern in Sicherheitsgruppen usw. einfügen, da Sie damit keine Principals hinzufügen können, auf die sie keinen Verweis haben. Und das zu Recht, denn dann hätten Sie alle möglichen seltsamen Probleme mit der referenziellen Integrität.

Wenn Sie in child.example.com ein neues Objekt erstellen, wird es in example.com repliziert und es ist in Ordnung, dieses neue Objekt in example.com zu verwenden, da Sie keine DCs im übergeordneten Objekt haben Domäne, auf die der IM nicht ordnungsgemäß repliziert wird.

Aus diesem Grund empfiehlt Microsoft in der Regel, nur alle DCs-GCs zu erstellen, da es dann keine Rolle spielt, ob der IM ordnungsgemäß funktioniert oder nicht, da alle DCs aufgrund ihrer GCs ohnehin über alle aktualisierten Informationen verfügen.

Bearbeiten: Ich wollte auch nur auf diesen Beitrag zurückkommen und erwähnen, dass das Infrastruktur-FSMO absolut nichts tut, wenn der AD-Papierkorb aktiviert ist:

http://myotherpcisacloud.com/post/2013/04/13/AD-Recycle-Bin-and-a-Eulogy-for-the-Infrastructure-Master.aspx