Active Directory.pdf - Gattner

Entwerfen der Standorttopologie 195
Einer der wichtigsten Faktoren für die Entscheidung, ob ein Domänencontroller an einem Unternehmensstandort
aufgestellt wird, ist die physische Sicherheit des Domänencontrollers. Wenn die physische
Sicherheit des Domänencontrollers nicht gewährleistet werden kann, sollten Sie keinen
beschreibbaren Domänencontroller am Standort aufstellen. Der Einsatz eines RODC kann einige dieser
Sicherheitsbedenken verringern, Sie sollten jedoch dennoch alles daran setzen, dass auch RODCs
physisch abgesichert sind.
Hinweis Beim Erstellen eines AD DS-Entwurfs für ein Unternehmen gilt die allgemeine Regel, alles so einfach
wie möglich zu halten, für alles – nur nicht für Standorte. Bei der Planung der Gesamtstruktur, Domäne
oder OU-Struktur sollte Einfachheit eines Ihrer obersten Gebote sein. Die Erstellung zusätzlicher Standorte
für alle Unternehmensstandorte, die über langsame Netzwerkverbindungen miteinander verbunden sind,
bietet jedoch erhebliche Vorteile, ohne den Verwaltungsaufwand wesentlich zu erhöhen. Dies ist wohl der
einzige Punkt im AD DS-Entwurfsvorgang, an dem die einfachste Lösung nicht die beste Lösung ist.
Nachdem Sie festgelegt haben, wie viele AD DS-Standorte benötigt werden, erstellen Sie im nächsten
Schritt den Entwurf für die einzelnen Standorte. Jeder Standort in AD DS ist mit einem oder mehreren
IP-Subnetzen verknüpft. Während Sie den Entwurf für die einzelnen Standorte erstellen, sollten
Sie daher festlegen, welche Subnetze in jeden Standort einbezogen werden. Wenn Sie entscheiden,
dass an einem Unternehmensstandort kein Domänencontroller eingesetzt wird, müssen Sie festlegen,
zu welchem logischen Standort dieser Unternehmensstandort gehört, und dieses IP-Subnetz dem entsprechenden
Standort hinzufügen. Auf diese Weise wird sichergestellt, dass die Clients am Remotestandort
sich mit den nächstgelegenen Domänencontrollern verbinden.
Praxistipp: Subnetzdefinitionen in Active Directory
Subnetze werden in Active Directory ausschließlich zum Definieren der Standorte in Active Directory
verwendet, denen eine Reihe von Computern angehört. Die Subnetzdefinitionen entsprechen
nicht dem tatsächlichen Layer-3-Routing innerhalb des Unternehmens. Hierbei handelt es sich um ein
häufiges Missverständnis – der Aufbau des Layer-3-Routings muss nicht mit den Subnetz-/Standortdefinitionen
in Active Directory übereinstimmen. Zweitens wählt Active Directory das spezifischere
Subnetz. Das heißt, wenn Sie zwei Subnetzobjekte in Active Directory definiert haben –
10.1.0.0/16 und 10.1.2.0/24 – und einen Client mit der IP-Adresse 10.1.2.5, so wird das zweite
Subnetzobjekt verwendet.
Eines der gängigen Ereignisse, die das Ereignisprotokoll auf Domänencontrollern in großen Unternehmen
füllen, ist die NetLogon-Warnung Nr. 5807. Diese tritt in einigen Szenarios auf. In einem
Szenario haben die Active Directory-Administratoren einfach keine Subnetze für ihre Standortobjekte
definiert. Im zweiten Beispiel – das gängigere Szenario – kommuniziert das Team, das Active
Directory ausführt, nicht gut genug mit den Netzwerkadministratoren, die Subnetze im Netzwerk
bereitstellen. In großen Unternehmen ändert sich die Subnetzkonfiguration möglicherweise häufig,
und die Active Directory-Standortspezifikationen werden eventuell nicht beibehalten. Die Lösung,
die ich verwende und empfehle, besteht darin, sehr weit reichende Übernetzwerke an den Hubstandorten
zu definieren. Beispielsweise würde ich in einem Hub-and-Spokes-Netzwerkentwurf mit
einem Hub, der private IP-Adressen im Bereich 10.0.0.0/8 verwendet, den Wert 10.0.0.0/8 mit dem
Hubstandort verknüpfen. Auf diese Weise ist garantiert, dass jeder Client, der von einer beliebigen
10.0.0.0-IP-Adresse kommt, dem Subnetz in Active Directory entspricht.
Sie können dieses Prinzip auch auf Unternehmen mit mehreren Hubstandorten anwenden. In
Abbildung 5.17 wird ein Beispiel dargestellt.