Windows Server 2008 R2 Server Core: Sichern von Zweigstellenverbindungen
Paul Yu
Nur wenige Umgebungen sind schwieriger zu unterstützen als eine externe Zweigstelle. Die Einrichtung und Verwaltung sicherer Verbindungen sind mit einer Unmenge technischer und prozeduraler Probleme verbunden. Dasselbe lässt sich über jedes Rechenzentrum sagen, mit dem eine externe Zweigstelle verbunden ist.
Externe Zweigstellen sind oft geografisch weit verstreut, und in der Regel gibt es mehrere Zweigstellen. Jede Zweigstelle verfügt über eine relativ kleine Benutzerbasis, die über langsame Netzwerkverbindungen mit dem Rechenzentrum verbunden sind, und in den seltensten Fällen ist ein qualifizierter IT-Manager vor Ort. Jeder dieser Faktoren stellt für sich genommen ein Problem dar. In der Kombination stellen sie mit Sicherheit ein IT-Problem dar.
Obwohl die meisten Umgebungen von Zweigstellen ähnliche Charakteristika (wie die hier aufgeführten) aufweisen, gibt es auch organisationsspezifische Anforderungen, die bestimmen, wie die Umgebung arbeitet. Die Bedeutung von Sicherheit oder der Grad, zu dem Technologieressourcen zentralisiert sind, kann von Zweigstellenstruktur zu Zweigstellenstruktur verschieden sein. Ungeachtet dessen, wie die Zweigstellen arbeiten, bietet Windows Server 2008 R2 neue Möglichkeiten zur Bereitstellung aktualisierter Technologien, die grundlegend verändern, wie Domänencontroller (DCs) in Remoteumgebungen bereitgestellt und genutzt werden können.
Eine sichere Lösung
Der Sicherung von Zweigstellenbereitstellungen ist ein gängiges Szenario für Active Directory-Domänendienste (AD DS). Die speziellen Charakteristika und Einschränkungen von Remoteumgebungen entsprechen gut den Anforderungen von AD DS. Windows Server 2008 R2 verfügt über eine beträchtliche Menge neuer Features und aktualisierter Konzepte für die Bereitstellung von AD DS. Lassen Sie uns untersuchen, wie sich Windows Server 2008 R2 in dieser Art von Umgebung auf sichere Weise bereitstellen lässt. Wir gehen auf typische Charakteristika von Zweigniederlassungen, wichtige architektonische Entwurfselemente und empfohlene Bereitstellungsoptionen ein, die der Bereitstellung von Windows Server 2008 R2 eigen sind.
Der bemerkenswerteste Aspekt von Windows Server 2008 R2 hat mit schreibgeschützten Domänencontrollern (Read-Only Domain Controller, RODC) zu tun. Im Allgemeinen werden RODCs an Standorten bereitgestellt, die DC-Dienste erfordern, aber nicht über die entsprechenden physischen Sicherheitsmaßnahmen verfügen. Dank der verbesserten Sicherheits- und Verwaltungsfunktionen kann in vielen Zweigstellenumgebungen durch den Austausch vorhandener DCs durch RODCs den Anforderungen in Bezug auf AD DS mehr als Genüge geleistet werden. Bei Standorten, an denen aktuell keine DCs vorhanden sind, stellen RODCs eine gute Gelegenheit dar, AD DS in die Umgebung einzuführen.
Ein weiterer wichtiger Faktor ist hier die aktualisierte Version von Server Core, eine Installationsoption in Windows Server 2008 R2, die eine minimale Umgebung für die Ausführung spezieller, unterstützter Serverrollen, z. B. die DC-Rolle, bereitstellt. Bei Auswahl der Option Server Core wird nur die Teilmenge der Binärdateien installiert, die für die installierte Serverrolle erforderlich ist, und in diesem Fall wäre das der RODC. Diese minimale Installation resultiert in einer kleineren Angriffsfläche, geringerem Wartungsaufwand und einer einfacheren Verwaltung. Sie trägt auch dazu bei, dass zur Ausführung des RODC-Servers weniger Ressourcen erforderlich sind.
Weil viele dieser Faktoren zu einer Minderung der Einschränkungen beitragen können, die üblicherweise mit Zweigstellenumgebungen verbunden sind, stellen Windows Server 2008 R2 Server Core und RODCs eine bestechende Option für alle Remoteumgebungen dar. In den folgenden Überlegungen zur Bereitstellung werden die Bereitstellungs- und Konfigurationsoptionen, die den Server Core- und RODC-Komponenten eigen sind, ausführlich besprochen.
Genau diese Konfiguration wird recht häufig verwendet, obwohl sie unter Umständen nicht die Zweigstellenanforderungen jeder Organisation erfüllen kann. Beispielsweise werden die meisten wichtigen Aspekte dieser Konfiguration bereits im aktuellen Handbuch für bewährte Methoden für das Windows Server 2008 Security Compliance Management Toolkit beleuchtet.
Es folgt eine Analyse wichtiger Bereitsstellungsaspekte im Hinblick auf die Einrichtung einer sicheren Windows Server 2008 R2-Server-Core-RODC-Lösung für Zweigstellenumgebungen. Hierbei wird auf Lösungsannahmen, wichtige Entwurfselemente, Infrastrukturvoraussetzungen und andere detaillierte Bereitstellungsoptionen eingegangen.
Vorläufige Entwurfsplanung
Wie bei jeder DC-Bereitstellung müssen Sie vor der Bereitstellung einige wichtige Entwurfsentscheidungen treffen. Zu diesen Entscheidungen gehören unter Anderem die Bewertung der Hardwarevoraussetzungen, die Wahl einer Softwareupgradestrategie, die Festlegung des RODC-Serverbuilds und die Identifizierung der DC-Upgradereihenfolge. Diese Entscheidungen bestimmen den gesamten Bereitstellungsprozess und die verfügbaren Konfigurationen.
Im Hinblick auf die Hardwarebewertung müssen Sie ermitteln, ob die vorhandene DC-Hardware den empfohlenen Systemvoraussetzungen entspricht. Da es gut dokumentierte Spezifikationen gibt, sollte dies für die meisten Organisationen kein Problem darstellen. Was die unterstützten Softwareupgradepfade betrifft, sind einige Optionen verfügbar, die von Version zu Version, Edition zu Edition und bei den verschiedenen Installationsoptionen von Windows unterschiedlich sind.
Server Core erfordert eine Neuinstallation der Zweigstellen-DCs. Es ist bei dieser Installationsoption nicht möglich, ein Upgrade durchzuführen. Was die installierten Serverrollen betrifft, wird aus Sicherheitsgründen allgemein empfohlen, dass alle Serverrollen und Dienste, die für den RODC-Betrieb nicht unbedingt erforderlich sind, aus dem Serverbuild entfernt werden. Diese RODC-Lösung bedingt, dass die RODCs von Windows Server 2008 R2 Server Core keine anderen Dienste oder Serverrollen hosten als den globalen Katalog und den DNS-Server. Dieser Ansatz wird von Unternehmen immer häufiger verfolgt.
Die Reihenfolge, in der die DCs bereitgestellt werden, ist ein weiterer wichtiger Aspekt dieses Prozesses. Die empfohlene Reihenfolge erfordert, dass die Active Directory-Domänendienste zuerst in Rechenzentren auf makellos erstellten Windows Server 2008 R2-Mitgliedsservern für jede Domäne installiert werden, wobei mit der Gesamtstruktur-Stammdomäne begonnen wird und dann alle maßgeblichen Betriebsmasterrollen für die einzelnen Domänen auf diese DCs übertragen werden. Danach wird mit der Bereitstellung von Rechenzentrenstandorten und der vollständigen Stilllegung der älteren DCs an diesen Standorten fortgefahren. Auf diese Weise lassen sich AD DS an einem großen, gut verwalteten Standort leichter stabilisieren. Zudem wird dadurch auch der RODC-Bereitstellungsprozess an sich vereinfacht. Sobald die DCs der Rechenzentren ersetzt wurden, können Sie mit den DCs der Zweigstellen beginnen.
Vorbereitung der Windows Server 2008 R2-Gesamtstruktur und -Domänen
Bevor Sie auch nur einen Windows Server 2008 R2-DC in der vorhandenen Umgebung bereitstellen können, müssen Sie die Active Directory-Gesamtstruktur und die Domänen vorbereiten, indem Sie Adprep.exe ausführen. Zuerst aktualisieren Sie mit dem Befehl adprep /forestprep das Gesamtstrukturschema auf dem DC, der die Schemabetriebsmasterrolle enthält. An diesem Punkt können Sie die Gesamtstruktur mit dem Befehl adprep /rodcprep aktualisieren und auf die RODC-Installation vorbereiten. Um die einzelnen untergeordneten Domänen vorzubereiten, müssen Sie den Befehl adprep /domainprep /gpprep auf dem DC ausführen, der die Infrastrukturmasterrolle hostet.
Zuletzt müssen Sie mindestens einen nicht schreibgeschützten DC, auf dem Windows Server 2008 R2 ausgeführt wird, in derselben Domäne bereitstellen, der die RODCs angehören werden. Nur als Randbemerkung: Bei Umgebungen, in denen Sie die Windows Server 2008-Version der Adprep.exe-Befehle ausgeführt haben, erfordert ein Upgrade auf Windows Server 2008 R2, dass Sie alle Befehle mit der R2-Version ausführen, ausgenommen den Befehl adprep /rodcprep, der keine Änderungen gegenüber der Windows Server-2008-Version bewirkt.
RODC-Platzierung
Von der architektonischen Entwurfsperspektive her gesehen, haben sich die Überlegungen bezüglich der RODC-Platzierung mit der Einführung der Kennwortreplikationsrichtlinie (PRP) geändert. Beispielsweise müssen RODCs in der Lage sein, eine Domänenpartitionsreplikation mit einem beschreibbaren DC unter Windows Server 2008 R2 einzurichten. Weil in den meisten Zweigstellenumgebungen Hub-and-Spoke-Netzwerktopologien eingesetzt werden, sind die RODC-AD DS-Sites sehr wahrscheinlich durch eine einzelne sehr kostengünstige Verbindung mit dem Rechenzentrum verbunden, in dem sich die beschreibbaren DCs mit Windows Server 2008 R2 befinden.
In Fällen, in denen dies nicht zutrifft, können zusätzliche beschreibbare DCs an zwischengelagerten Standorten bereitgestellt, neue Standortverbindungsbrücken bereitgestellt oder neue Standortverbindungen erstellt werden, um den Aufbau von Replikationsverbindungen zu steuern. Zudem müssen Sie sicherstellen, dass keine anderen DCs am gleichen AD DS-Standort wie der RODC platziert werden. Diese Bedingung ist bei den meisten Zweigstellenumgebungen, die in der Regel über eine minimale Anzahl von Servern verfügen, nicht von Bedeutung. Bei Standorten mit mehreren DCs ist die Bereitstellung von RODCs möglicherweise einfach keine akzeptable Lösung.
Zwischenspeicherung von Anmeldeinformationen
Das vielleicht wichtigste Sicherheitselement ist das Modell der Zwischenspeicherung von Anmeldeinformationen. Das ist eine kritische Entwurfskomponente, die sorgfältig eingerichtet werden muss, bevor mit der Zweigstellenbereitstellung begonnen wird. Für viele Umgebungen ist das Modell, in dem nur wenige Konten zwischengespeichert werden können, wahrscheinlich am gebräuchlichsten und passendsten.
Dieser Ansatz, bei dem nur lokale Konten an einem RODC-Standort für die Zwischenspeicherung der Anmeldeinformationen konfiguriert werden, stellt geeignete Bedingungen im Hinblick auf den Grundsatz bezüglich der geringsten Rechte und der Dienstverfügbarkeit bereit. Ein Nachteil dieses Ansatzes besteht darin, dass er einen erhöhten Verwaltungsaufwand zur Folge hat, da hier jeder RODC über eine eigene PRP verfügt und die Konten je nach Bedarf für den Betrieb bereitgestellt bzw. deren Bereitstellung aufgehoben werden muss.
Wie Benutzer, die häufig auf Geschäftsreise sind, behandelt werden, ist ein weiterer Entwurfsaspekt, der in vielen Zweigstellenumgebungen erwartungsgemäß berücksichtigt werden muss. Häufig enthalten Zweigstellenumgebungen Benutzer und Ressourcen, deren Konten wegen der Dienstverfügbarkeit auf bestimmten RODCs zwischengespeichert werden müssen. Idealerweise werden diese Konten ähnlich wie die Konten neuer Mitarbeiter im Vorhinein bereitgestellt. Da die Reisetätigkeit häufig unregelmäßig und nicht vorhersehbar ist, kommt diese Option oft nicht in Frage, insbesondere wenn eine große Anzahl von Ressourcen gegeben ist, die viele RODC-Standorte aufsuchen kann.
Um auf dieses Problem einzugehen, könnten Sie den RODC-PRPs zusätzliche Konten hinzufügen. In extremen Fällen, in denen einer Gruppe von Konten in allen RODC-PRPs Zugriff gewährt wird, können Sie auch die Standardgruppe "Zulässige RODC-Kennwortreplikationsgruppe" nutzen. Diese Gruppe sollte allerdings sehr vorsichtig verwendet werden, da alle Mitglieder dieser Sicherheitsgruppe auf allen RODCs zwischengespeichert werden können.
Eine andere Überlegung betrifft die Frage, wann zwischenspeicherbare Konten eigentlich zwischengespeichert werden. Standardmäßig geschieht dies erst nach der ersten Anmeldung bei einem RODC, wenn die Authentifizierungsanforderung an einen beschreibbaren Windows Server 2008 R2-DC weitergeleitet wird und die Anmeldeinformationen auf dem RODC repliziert werden. Weil in Zweigstellenumgebungen mit vorhandenen DCs wahrscheinlich andere Anforderungen bezüglich der Dienstverfügbarkeit erfüllt werden müssen, ist die Option zur Vorgabe von Anmeldeinformationen auf RODCs hier unter Umständen kritisch.
Dies ist möglicherweise während der ersten Bereitstellung eines RODC wichtig, wenn die Anmeldeinformationen für alle Konten am RODC-Standort erst zwischengespeichert werden müssen. Sobald die PRP konfiguriert und die Konten als zwischenspeicherbar gekennzeichnet wurden, können auf dem RODC zuvor ausgefüllte Kennwörter verwendet werden. Allerdings muss darauf hingewiesen werden, dann beim Einsatz dieser beiden Optionen traditionell für die Vorgabe von Kennwörtern einige Einschränkungen gelten. Gegenwärtig ist bei Verwendung der Konsole Active Directory-Benutzer und Computer oder des Befehls repadmin der Einsatz von Sicherheitsgruppen nicht zulässig.
Da es möglicherweise nicht praktikabel ist, die Kennwörter jeweils für einzelne Konten oder für kleine auf Organisationseinheiten basierende Gruppen im Vorhinein auszufüllen, können Sie in Skripts Sicherheitsgruppen verwenden. Um beispielsweise dieselbe Sicherheitsgruppe zu nutzen, die auf einem bestimmten RODC das Zwischenspeichern von Anmeldeinformationen autorisiert, können Sie folgendes Skript verwenden:
For /F %%a in ('"dsquery group dc=corp,dc=contoso,dc=com -name <Groupname>| dsget group -members"') do (Repadmin /rodcpwdrepl <RODCname> <RWDCname> %%a)
Gestaffelte RODC-Installation
Von den beiden DC-Installationsmethoden, die in Windows Server 2008 R2 zur Verfügung stehen, ist die gestaffelte Installation der direkten Installation vorzuziehen. Die alternative Methode der direkten Installation entspricht dem traditionellen Prozess früherer Windows-Versionen. Bei der gestaffelten Installation wird die Administratorrolle aufgeteilt. Diese Aufteilung der Administratorrolle ist ein Feature in Windows Server 2008 R2, mit dem die Fähigkeit, RODC-Server zu installieren und zu verwalten, an Administratoren, die keine Dienstadministratoren sind, delegiert wird, ohne diesen Active Directory-Rechte zu gewähren.
Vom Sicherheitsstandpunkt her gesehen, entfällt bei der gestaffelten Installation die Anforderung, an Zweigstellenstandorten, die nicht sicher sind, Anmeldeinformationen mit stark erweiterten Berechtigungen zu verwenden. Daher sind Argumente, die für eine Bereitstellung von DCs im Rechenzentrum zur Unterstützung von externen Niederlassungen sprechen, möglicherweise nicht mehr zutreffend. Bei der gestaffelten Installation wird der RODC-Installationsvorgang in zwei Phasen unterteilt.
In der ersten Phase muss ein AD DS-Dienstadministrator vorab ein Computerkonto für den RODC erstellen und Konfigurationseinstellungen bereitstellen, wie z. B. den Computernamen, den entsprechenden AD DS-Standort, die zu installierenden Serverrollen, die PRP-Konfiguration und ARS-Delegation. Als bewährte Methode gilt, dass der delegierte Administrator durch eine Sicherheitsgruppe repräsentiert werden sollte und die Anmeldeinformationen der einzelnen Mitglieder auf dem RODC zwischengespeichert werden sollten. In der zweiten Phase verwendet der delegierte RODC-Serveradministrator seine Anmeldeinformationen als Nicht-AD DS-Dienstadministrator, um einen Arbeitsgruppenserver mit dem vorab erstellten RODC-Konto zu verknüpfen und die RODC-Heraufstufung abzuschließen.
Quelle für die RODC-Heraufstufung
Als Quelle der RODC-Heraufstufung wird in dieser Konfiguration die Installationsoption Installieren von Medium in Verbindung mit der gestaffelten Installation verwendet. Mit dieser Option wird die Datenmenge, die während der Installation von AD DS auf dem RODC repliziert werden muss, erheblich verringert. Beim Einsatz von Ntdsutil.exe auf einem beschreibbaren DC mit Windows Server 2008 R2 sind vier Typen von Installationsmedien verfügbar. Von diesen vier sind hier nur zwei relevant, nämlich RODC und RODC mit SYSVOL.
Das RODC-Medium ähnelt dem Medium für eine vollständige Installation, enthält jedoch keine zwischengespeicherten geheimen Schlüssel wie Kennwörter. In Bezug auf die Zweigstellensicherheit ist dies ein wichtiges Feature. Als einzige Anforderung zur Erzeugung von RODC-Medien muss lediglich ein beschreibbarer Windows Server 2008 R2-DC installiert worden sein. Das zweite Installationsmedium, RODC mit SYSVOL, erfordert allerdings viel mehr hinsichtlich der Infrastruktur. Mit Ntdsutil.exe kann das Medium für RODC mit SYSVOL zwar erstellt werden, zum Einsatz dieses Mediums in der Installation ist jedoch die DFS-Replikation (Distributed File System Replication) für die SYSVOL-Replikation erforderlich, und dies setzt wiederum eine Domänenfunktionsebene in Windows Server 2008 R2 voraus.
Da die meisten Organisationen mit Zweigstellen diese Bedingung höchstwahrscheinlich nicht erfüllen können, ist diese Option zum Einsatz von Medien wahrscheinlich erst nach Abschluss der ersten Bereitstellung verfügbar. Nachdem dieser Meilenstein erreicht wurde, wird durch die Migration zur DFS-Replikation und den Einsatz der beiden Installationsmedien RODC und RODC mit SYSVOL die Verzeichnisreplikation erheblich minimiert. Zudem wird dadurch die Installation künftiger Zweigstellen-DCs viel effizienter.
Ausführen von DCPROMO
Der Assistent für die Installation von Active Directory-Domänencontroller steht nicht zur Verfügung, wenn Sie diese Konfiguration bereitstellen, da die RODCs hier unter Windows Server 2008 R2 Server Core ausgeführt werden. Während der eigentlichen RODC-Heraufstufung können Sie das nicht gebrauchen. Neben der gestaffelten Installation mit der Option Installieren von Medium wird daher eine Datei mit Dcpromo.exe zur unbeaufsichtigten Installation der DC-Rolle verwendet. Was Sicherheit und Verwaltbarkeit betrifft, so fördert dieser Lösungsaspekt sichere und konsistente DC-Erstellungsverfahren, die zur Aufrechterhaltung der AD DS-Sicherheit und -Konfiguration innerhalb der gesamten Zweigstellenumgebung beitragen.
Zudem können automatisierte, berechenbare und wiederholbare Erstellungsverfahren die Möglichkeit minimieren, dass durch manuelle Eingriffe unbefugte Software, Dienste und Konfigurationen in den Buildprozess eingefügt werden. Es folgt ein Beispiel für die Verwendung des Befehls ccpromo und eine einfache Beispielantwortdatei:
DCPROMO /unattend:c:\unattend.txt
[DCINSTALL]
ReplicaDomainDNSName=corp.contoso.com
UserDomain=corp
UserName=corp\<delegated RODC security group>
Password=*
ReplicationSourcePath=C: \IFM
Safemodeadminpassword=<password>
Es muss unbedingt beachtet werden, dass alle PRP-Standardwerte explizit hinzugefügt werden müssen, wenn manuelle PRP-Konfigurationen in die Antwortdatei aufgenommen und nicht während der Voraberstellung des RODC-Kontos im Rahmen der gestaffelten Installation angegeben wurden. Durch das explizite Hinzufügen von manuellen PRP-Konfigurationen zur Antwortdatei wird die PRP-Standardkonfiguration im Grunde genommen durch die in der Antwortdatei angegebene Konfigurationen ersetzt.
Replikation
Weil Windows Server 2008 R2-RODCs eine unidirektionale Replikation ermöglichen, wird durch den Austausch vorhandener Zweigstellen-DC durch RODCs die Arbeitslast derjenigen Bridgeheadserver in Rechenzentren verringert, die normalerweise die eingehende Replikation für Zweigstellen-DCs verarbeiten. Für Zweigstellenumgebungen ist dies ein bedeutender Faktor. Die Skalierbarkeit wird dadurch erhöht, und die Gesamtanzahl der im Rechenzentrum erforderlichen Server wird reduziert.
RODCs sorgen auch für eine gleichmäßige automatische Verteilung ausgehender Verbindungsobjekte unter den Bridgeheadservern am Hubstandort, und das ist etwas, wofür in Windows Server 2003 ein zusätzliches Tool wie Adlb.exe erforderlich war. Aus diesem Grund wird empfohlen, vor der Bereitstellung von RODCs alle DCs in Rechenzentren auf Windows Server 2008 R2 zu aktualisieren. Damit wird sichergestellt, dass für eingehende Replikationsverbindungen ein gleichmäßig verteilter Lastenausgleich stattfindet. Dadurch sind keine alternativen Maßnahmen zur Behandlung von Problemen mit der Überlastung von Rechenzentren-Bridgeheadservern während der RODC-Bereitstellung notwendig.
Diese ausführliche Entwurfs- und Bereitstellungsanleitung kann eine sichere Bereitstellung von Windows Server 2008 R2 Server Core-RODCs in Zweigstellen erleichtern. Da auf typische Charakteristika von Zweigstellen, wichtige architektonische Entwurfselemente und empfohlene Bereitstellungsoptionen eingegangen wird, können sie als Grundlage für künftige bewährte Methoden für die RODC-Bereitstellung an Zweigstellen dienen.
Paul Yu* (Paul.Yu@microsoft.com) ist seit 10 Jahren als Senior Consultant für Microsoft Consulting Services tätig und stellt Wirtschaftsunternehmen und Unternehmen der öffentlichen Hand Unternehmensinfrastrukturlösungen von Microsoft bereit.*