Windows 7 und Windows Server 2008 R2

Artikel
08/30/2016

BranchCache und DirectAccess: Verbesserung der Zweigstellenumgebung

Gary Olsen

Während die breite Öffentlichkeit erst jetzt einen Blick auf Windows Server 2008 R2 und Windows 7 werfen kann, konnten Insider bereits seit Mai mit RC-Code (Release Candidate) bzw. seit August mit der RTM-Version (Release to Manufacturing) arbeiten. Gleichgültig, zu welcher Gruppe Sie gehören, Sie sind wahrscheinlich mit Reklame überschüttet worden. Vielleicht wurden Sie wie ich beispielsweise zu einer "Windows 7-Party" eingeladen, bei der das Produkt vorab vorgestellt wurde. (Mein Schwiegersohn hat eine solche Party eigentlich nur deswegen veranstaltet, weil er die Software kostenlos von Microsoft bekommen wollte.) Auch wenn Sie von diesem Reklamerummel verschont blieben, so konnten sie wahrscheinlich nicht den vielen Medienberichten entrinnen, in denen die neuen Features dieser Produkte, die beide auf einer neuen Codestruktur basieren und ein neues Betriebssystem darstellen, hoch gelobt oder infrage gestellt wurden.

BranchCache und DirectAccess, wohl die Kronjuwelen dieser Produktversionen, sind beachtenswert. Mit BranchCache versucht Microsoft, den Mitarbeitern von Zweigstellen dieselbe Umgebung für die Bearbeitung von Dateien zu bieten, die ihren Kollegen in der Unternehmenszentrale zur Verfügung steht. Mit DirectAccess wendet sich Microsoft an Remotebenutzer, die über virtuelle private Netzwerke (VPN) eine Verbindung mit dem Unternehmensnetzwerk herstellen.

Wie bei Microsoft üblich, ist nur das Positive der neuen Produkte erhältlich. In diesem Fall können nur BranchCache- und Windows 7-Clients sowie 2008 R2-Server implementiert werden. Sehen wir uns diese Neuerungen nun etwas detaillierter an.

BranchCache

BranchCache verbessert die Zweigstellenumgebung, indem häufig verwendete Datei in einem lokalen Zwischenspeicher auf einem Server unter Windows Server 2008 R2 oder auf Arbeitsstationen von Benutzern abgelegt werden, sodass die Benutzer nicht über die Netzwerkfreigaben eines zentralen Speicherorts auf Dateien zugreifen müssen. BranchCache ist großartig, allerdings sind auch einige Punkte zu beachten.

Die IT-Abteilung kann BranchCache in den Modi "Gehosteter Cache" und "Verteilter Cache" bereitstellen (siehe Abbildung 1). Da der Modus mithilfe der Gruppenrichtlinien konfiguriert wird, müssen zwei Richtlinien implementiert und die Struktur der Organisationseinheiten entsprechend geplant werden, wenn in einer Niederlassung der gehostete Cachemodus und in einer anderen Niederlassung der verteilte Cachemodus verwendet werden soll. Microsoft empfiehlt für Standorte mit 50 oder weniger Clients die Bereitstellung im Modus "Verteilter Cache". Allerdings sind dabei die Geschwindigkeit und die Bandbreite der WAN-Verbindung sowie andere Faktoren zu berücksichtigen. Für den Modus "Verteilter Cache" sind größere Festplatten und möglicherweise mehr Arbeitsspeicher und andere Ressourcen erforderlich. Ab einem gewissen Punkt wird es daher vorteilhafter sein, den Modus "Gehosteter Cache" zu verwenden, insbesondere dann, wenn am Standort bereits ein 2008 R2-Server vorhanden ist. Außerdem kann der Modus "Verteilter Cache" nur in einem lokalen Subnetz verwendet werden. Wenn an einem Standort mehrere Subnetze eingerichtet wurden, dann muss in jedem Subnetz ein Client Dateien zwischenspeichern, damit diese von den anderen zu diesem Subnetz gehörigen Computern heruntergeladen werden können. Im Modus "Gehosteter Cache" können dagegen mehrere Subnetze an einem Standort bedient werden. Dies wäre also ein weiterer Grund, sich für den gehosteten Cachemodus zu entscheiden.

Abbildung 1 Eine Zweigniederlassung kann BranchCache entweder im verteilten oder im gehosteten Cachemodus nutzen.

Im Modus "Verteilter Cache" befinden sich keine Dateiserver in der Zweigniederlassung. Stattdessen sind per Richtlinie alle Computer BranchCache-Clients, d. h., sie können alle Dokumente zwischenspeichern, die von anderen Computern in der Zweigniederlassung heruntergeladen werden können, sofern es die aktuellste Version ist.

Nehmen wir beispielsweise an, Caroline fordert das Dokument Reports.docx von einem mit BranchCache ausgestatteten Dateiserver in der Unternehmenszentrale an. BranchCache sendet Metadaten, welche den Inhalt der Datei beschreiben. Mithilfe von Hashwerten in den Metadaten wird dann im lokalen Subnetz nach dem Dokument gesucht. Wird es dort nicht gefunden, dann wird eine Kopie auf dem lokalen Festplattenlaufwerk ihres Computers zwischengespeichert. Etwas später muss Tyler das Dokument Reports.docx verändern. Daher fordert er von der Netzwerkfreigabe des Dateiservers in der Unternehmenszentrale eine Kopie zum Bearbeiten an. Der Dateiserver gibt die Metadaten zurück, und der Client sucht dann nach dem Inhalt, den er auf Carolines Computer findet und von diesem herunterlädt. Dieser Datenaustausch erfolgt auf sichere Weise, da ein Verschlüsselungsschlüssel verwendet wird, der von den Hashwerten in den Metadaten abgeleitet wurde. Am nächsten Tag muss Abigail dasselbe Dokument abändern. Es wird wieder der gleiche Vorgang ausgeführt, allerdings öffnet sie die Kopie, die auf Tylers Computer zwischengespeichert wurde. Wieder werden die Versionsinformationen auf dem Server verwaltet. Die Clients kontaktieren den Server, um festzustellen, ob an ihrem Standort eine Kopie der neuesten Version vorhanden ist.

Dies ist eines von drei BranchCache-Szenarien, die ins Spiel kommen, wenn die Benutzer verschiedene Dokumente bearbeiten. Die anderen beiden Szenarien lassen sich wie folgt beschreiben:

Ein Mitarbeiter einer Zweigniederlassung fordert vom Dateiserver in der Unternehmenszentrale ein Dokument an, das auf keinem lokalen Computer zwischengespeichert wurde. Der Benutzer erhält eine Kopie, die dann im lokalen Cache zwischengespeichert wird.
Ein Mitarbeiter einer Zweigniederlassung fordert vom Dateiserver ein Dokument an, das am lokalen Standort zwischengespeichert wurde, der betreffende Computer ist jedoch ausgeschaltet. Der Client erhält vom Dateiserver eine neue Kopie und speichert diese auf seinem PC zwischen. Bei künftigen Anforderungen wird auf diese zuletzt zwischengespeicherte Kopie verwiesen.

In beiden Fällen werden die Dokumente auch auf dem Dateiserver in der Unternehmenszentrale gespeichert. Daher erhält Caroline das Dokument vom Server in der Unternehmenszentrale, wenn sie später zurückkommt und auf das Dokument zugreifen möchte, aber Abigails Computer, auf dem sich jetzt die neueste Version befindet, ausgeschaltet ist.

Beim Modus "Gehosteter Cache" konfiguriert die IT-Abteilung in der Zweigniederlassung einen Windows 2008 R2-Dateiserver mit BranchCache, indem sie das BranchCache-Feature darauf installiert und eine Gruppenrichtlinie konfiguriert, welche die Clients anweist, den Modus "Gehosteter Cache" zu verwenden. Das für den Modus "Verteilter Cache" beschriebene Verfahren gilt auch hier, allerdings werden die Dateien auf einem lokal konfigurierten BranchCache-Server statt auf den Computern einzelner Benutzer zwischengespeichert.

Hinweis: Wenn eine Datei von einem Dateiserver mit BranchCache-Funktion angefordert wird, werden an jeden Client die vom Dateiserver in der Unternehmenszentrale verwalteten Inhaltsmetadaten gesendet. Auf diese Weise wird ermittelt, ob ein lokaler Client oder Server (je nach verwendetem Cachemodus) über die neueste Kopie verfügt.

Der Server mit BranchCache-Funktion in der Zweigniederlassung kann auch zu anderen Zwecken verwendet werden, beispielsweise als Web- oder WSUS-Server (Windows Server Update Services). In diesen Fällen sind bestimmte Punkte zu berücksichtigen, die im Microsoft BranchCache Deployment Guide (Bereitstellungshandbuch) und im Microsoft BranchCache – Handbuch für Erstanwender beschrieben werden.

BranchCache-Konfiguration

Um BranchCache konfigurieren zu können, müssen Sie wissen, wie Gruppenrichtlinienobjekte funktionieren und wie diese in Ihrer Organisationsstruktur konfiguriert werden müssen, damit sie sich auf die Computer an den einzelnen Standorten auswirken. Denken Sie daran, dass auf allen am BranchCache-Szenario beteiligten Servern Windows Server 2008 R2 und auf allen Clients Windows 7 ausgeführt werden muss. Im Folgenden wird die Vorgehensweise beschrieben:

Schritt 1. Installieren Sie mit dem Server-Manager das BranchCache-Feature.

Schritt 2. Wenn Sie BranchCache auf einem Dateiserver nutzen, müssen Sie neben BranchCache auch die Rolle Dateidienste für Remotedateien installieren (siehe Abbildung 2).

Abbildung 2 Bei einer BranchCache-Installation müssen die Rollen "Dateidienste" und "BranchCache für Remotedateien" aktiviert werden.

Schritt 3. Konfigurieren Sie ein BranchCache-Gruppenrichtlinienobjekt. Wechseln Sie zu Computerkonfiguration | Richtlinien | Administrative Vorlagen | Netzwerk | BranchCache. Hier werden fünf mögliche Einstellungen angezeigt:

BranchCache aktivieren. Diese Option muss für alle BranchCache-Funktionen aktiviert werden (siehe Abbildung 3). Beachten Sie, dass der lokale Windows 7-Client Dateien lokal zwischenspeichert, wenn BranchCache aktiviert wird, ohne dass gleichzeitig die Richtlinieneinstellungen für die Modi "Gehosteter Cache" und "Verteilter Cache" deaktiviert werden. Das ist nützlich, wenn sich mehrere Benutzer einen Computer teilen.

Abbildung 3 Aktivieren Sie in der Gruppenrichtlinien-Verwaltungskonsole BranchCache für die Zwischenspeicherung in Zweigniederlassungen.

BranchCache-Modus "Verteilter Cache" festlegen. Diese Einstellung gilt für alle Clients im Gruppenrichtlinienobjekt.
BranchCache-Modus "Gehosteter Cache" festlegen. Geben Sie den Server an, der für BranchCache als Host fungieren soll. Diese Rollen schließen sich gegenseitig aus. Für einen Standort kann nur ein Server als Host konfiguriert werden.
BranchCache für Netzwerkdateien konfigurieren. Wenn diese Option nicht konfiguriert oder deaktiviert wird, gilt der vordefinierte Latenzschwellenwert von 80 ms. Dauert die Dateianforderung länger als 80 ms, dann wird die Datei im Cache zwischengespeichert. Aktivieren Sie diese Einstellung, und legen Sie den gewünschten Latenzwert fest.
Prozentuale Speicherplatzbelegung durch Clientcomputercache festlegen. In der Standardeinstellung liegt die Größe bei 5 Prozent der Festplattenkapazität des Benutzers. Sie müssen hier wahrscheinlich verschiedene Einstellungen ausprobieren, um den Wert zu ermitteln, bei dem sowohl für den Cache als auch für den Benutzer ausreichend Speicherplatz verfügbar ist. Das kann problematisch sein, wenn Festplattenkonfigurationen vorliegen, die sich stark in der Größe unterscheiden, da hier einige Konfigurationen eine größere Cachekapazität als andere Konfigurationen besitzen.

Set Disk Space

Schritt 4. Konfigurieren Sie die Gruppenrichtlinienobjekteinstellung LanMan-Server in der BranchCache-Richtlinie. Wechseln Sie im gleichen Bereich des Gruppenrichtlinienobjekts von Schritt 3 zur Einstellung LanMan-Server, und sehen Sie sich die Eigenschaften von Hashveröffentlichung für BranchCache an. Es sind drei Optionen verfügbar:

Hashveröffentlichung für keinen freigegebenen Ordner zulassen.
Hashveröffentlichung für alle freigegebenen Ordner zulassen.
Hashveröffentlichung nur für freigegebene Ordner mit aktiviertem BranchCache zulassen.

Auf Servern, welche die Serverrolle Dateidienste unter 2008 R2-Servern ausführen und die als BranchCache-Server fungieren sollen, muss auch die Rolle BranchCache für Netzwerkdateidienste ausgeführt und die Hashveröffentlichung aktiviert werden. BranchCache wird für Dateifreigaben jeweils einzeln aktiviert. Die Hashveröffentlichung kann auf einem einzelnen Server (beispielsweise in einer Serverkonfiguration ohne Domänenzuordnung) oder über Gruppenrichtlinien für Servergruppen aktiviert werden. Folglich kann BranchCache für alle freigegebenen Ordner, einige freigegebene Ordner oder für keinen freigegebenen Ordner aktiviert werden.

Schritt 5. Konfigurieren Sie die Gruppenrichtlinienobjekt-Einstellung in der Windows-Firewall, um über TCP-Port 80 eingehende Anforderungen zuzulassen (die dem Clientcomputer zugeordnet werden).

Schritt 6. Sobald Sie dies konfiguriert haben und eine Dateifreigabe mit den Dateien der Benutzer vorhanden ist, wechseln Sie zu Server-Manager | Dateidienste | Freigabe- und Speicherverwaltung. Im mittleren Bereich werden die Freigaben aufgeführt. Klicken Sie mit der rechten Maustaste auf die gewünschte Freigabe, wählen Sie Eigenschaften aus, und klicken Sie auf Erweitert. Aktivieren Sie auf der Registerkarte Zwischenspeichern die Option BranchCache (siehe Abbildung 4). Hinweis: Wenn die Option BranchCache nicht verfügbar ist, wurde das Feature BranchCache nicht richtig installiert, oder die Richtlinie wurde, wie oben erwähnt, deaktiviert.

Abbildung 4 Über die Freigabe- und Speicherverwaltung die gemeinsame Nutzung von Dateien mit BranchCache aktivieren.

BranchCache-Clientkonfiguration

Alle Windows 7-Clients sind in der Standardeinstellung für BranchCache aktiviert, sodass auf dem Client selbst nichts aktiviert werden muss. Dennoch sind zwei Schritte erforderlich, die mit dem Client zu tun haben:

Konfigurieren der Firewalleinstellungen. Dies wurde zwar weiter oben erwähnt, aber für den Modus "Gehosteter Cache" gelten andere Anforderungen. Schlagen Sie hierzu in den BranchCache-Dokumenten von Microsoft nach, die am Ende dieses Artikels aufgeführt sind.
Clients müssen Bestandteil einer Organisationseinheit sein, die über eine Richtlinie verfügt, mit der BranchCache aktiviert und der zu verwendende Cachemodus definiert wird. Auch hierzu finden Sie in den am Ende dieses Artikels aufgeführten BranchCache-Dokumenten von Microsoft weitere Informationen.

BranchCache: die Vorzüge

Folgendes schätze ich besonders an BranchCache:

Wenn der Benutzer angemeldet ist, kann ich den intelligenten Hintergrundübertragungsdienst BITS (Background Intelligent Transfer System) auch dann für Dateiübertragungen im Hintergrund nutzen, wenn die Anwendung vorhanden ist. Dies ist besonders für Zweigniederlassungen von Vorteil, die über langsame Netzwerkverbindungen miteinander verknüpft sind. Wenn ein System neu gestartet werden muss, wird die Dateiübertragung nach dem Neustart fortgesetzt. Dies funktioniert natürlich nur dann, wenn die Anwendungen BITS unterstützen.
BranchCache kann mit dem Befehlszeilenprogramm Netsh konfiguriert werden und ist im TechNet unter BranchCache für Windows Server R2 gut dokumentiert.
Sie können die BranchCache-Leistung mithilfe von Leistungsindikatoren für den Client, Dateiserver und Cachehost überwachen. Diese Leistungsindikatoren sind nicht nur bei der Leistungsdiagnose hilfreich, sondern meines Erachtens lässt sich auch nur durch das Beobachten dieser Leistungsindikatoren feststellen, ob ein Client tatsächlich eine zwischengespeicherte Kopie erhält.
Die BranchCache-Umgebung kann über Gruppenrichtlinien gesteuert werden.

BranchCache: die Schwachstellen

BranchCache findet sicherlich seinen Platz, beachten Sie jedoch folgende Punkte:

Weil der Modus "Verteilter Cache" im Grunde genommen jede Arbeitsstation in einen Dateiserver verwandelt, sind bei Clientcomputern, die viele häufig verwendete Dateien hosten, möglicherweise Leistungseinbußen spürbar. Hier muss durch Tests ermittelt werden, welche Auswirkungen dieser Cachemodus tatsächlich hat.
Gelegentlich ist bei Clients zusätzlicher Festplattenspeicher erforderlich, damit ausreichend Speicherplatz zum Zwischenspeichern verfügbar ist.
Clients, die Dateien zwischenspeichern, werden jetzt mit anderen Clients um Netzwerkressourcen konkurrieren.
Während der ersten Zwischenspeicherung oder wenn eine Datei nicht im Cache verfügbar ist, können Verzögerungen auftreten. Da nur Windows 7-Clients und Windows Server 2008 R2-Server BranchCache unterstützen, kann es noch einige Zeit dauern, bis dieses Feature vollständig eingeführt ist.

Wenn sich die Installation eines Dateiservers in der Zweigniederlassung rechtfertigen lässt, dann stellt sich die Frage, warum kein DFS-Server verwendet wird. Statt mit zwischengespeicherten Dateien herumzuhantieren, können Sie die Dateien mithilfe der DFS-Replikation replizieren und mit DFS einen Namespace verwalten. Das Zwischenspeichern von Netzwerkdateien kann Vorteile bieten, und möglicherweise funktioniert BranchCache auch mit DFS-Freigaben. Vielleicht finden Sie auch eine Leistungsschranke, bei der das Zwischenspeichern effizienter als die DFS-Replikation ist. Andererseits beansprucht eine volle DFS-Konfiguration den Server stärker als BranchCache. Es geht also darum, dass Sie Ihre Anforderungen genau untersuchen und die beim Einsatz von BranchCache verfügbaren Optionen überprüfen müssen. Natürlich ist jede Umgebung anders und was in einigen Zweigniederlassungen Probleme verursacht, kann in anderen einwandfrei funktionieren. Es gibt keine in allen Situationen passende Universallösung.

DirectAccess

Mit DirectAccess geht Microsoft auf das mäßige VPN-Verhalten ein, mit dem die Benutzer seit Windows 2000 zurechtkommen mussten, obwohl seit der ersten Implementierung viele Dinge verbessert wurden. Ein mit DirectAccess konfigurierter Client kann von einem Remotestandort auf eine Intranetsite zugreifen, ohne dass manuell eine VPN-Verbindung eingerichtet werden muss. Außerdem können IT-Abteilungen, die darüber sehr erfreut sind, Remotecomputer über eine Internetverbindung statt über das VPN verwalten. Sogar ohne DirectAccess können Remotebenutzer das neue Feature zur automatischen Wiederherstellung einer VPN-Verbindung nutzen. Wenn ich also zu Hause arbeite, dabei mit dem Intranet meiner Firma verbunden bin und die Internetverbindung getrennt wird, dann stellt das VPN die Verbindung automatisch wieder her, sobald die Internetverbindung wieder verfügbar ist, ohne mich aufzufordern, die Verbindung wiederherzustellen und meine Anmeldedaten erneut einzugeben, was ich häufig sogar mehrfach tun musste, als es DirectAccess noch nicht gab.

Für den Benutzer ist DirectAccess eigentlich unsichtbar. Wenn ein Benutzer auf einem Client, auf dem DirectAccess aktiviert wurde, auf die Intranetverknüpfung klickt, dann handhabt DirectAccess den Aufbau und die Trennung der Verbindung. Es ist nicht mehr erforderlich, dass die Benutzer den Verbindungs-Manager öffnen, ihre Anmeldeinformationen eingeben, warten, bis die Verbindung hergestellt wurde, usw.

Solange die Remoteverbindung besteht, verfügt der Benutzer standardmäßig über eine "Split-Tunneling"-Konfiguration (siehe Abbildung 5). Dies ermöglicht den gleichzeitigen Zugriff auf das Intranet, das lokale Netzwerk (zur Nutzung von lokalen Geräten, z. B. Drucker) und das Internet. In einem typischen VPN-Szenario ohne Split-Tunneling muss für den Aufbau einer Verbindung mit dem Internet zuerst eine Verbindung mit dem Intranet hergestellt und das Gateway des Unternehmensnetzwerks passiert werden. Außerdem habe ich keinen Zugriff auf mein lokales Netzwerk, obwohl sich dieses Problem umgehen lässt. DirectAccess ist also darauf ausgelegt, Remotebenutzern eine Umgebung zur Verfügung zu stellen, die stärker ihrer firmeninternen Arbeitsumgebung ähnelt als dies bei traditionellen VPN-Verbindungen möglich ist.

Abbildung 5 DirectAccess ermöglicht eine Split-Tunneling-Konfiguration für gleichzeitige Verbindungen mit Unternehmensnetzwerk und Internet.

Aus der Sicht der IT-Abteilung sind Patches, Richtlinien und andere Aktualisierungen einfach – und sicher über IPsec-Verbindungen – anzuwenden, sobald der Computer mit dem Internet verbunden ist (vergessen Sie nicht, dass DirectAccess stets aktiviert ist, wenn es installiert wurde).

DirectAccess-Anforderungen

In einer einfachen DirectAccess-Konfiguration befindet sich der DirectAccess-Server im Umkreisnetzwerk und stellt Remotebenutzern Verbindungen zu internen Ressourcen bereit, wozu Anwendungsserver, Zertifizierungsstellen, DNS und Domänencontroller gehören. Zertifizierungsstellen und Anwendungsserver müssen so konfiguriert werden, dass sie IPv6-Daten akzeptieren. Folgende grundlegende Komponenten sind für eine DirectAccess-Konfiguration erforderlich:

In der Active Directory-Domäne können DirectAccess-Clients nur auf Domänencontroller unter Windows 2008 oder 2008 R2 zugreifen.
Durch die Definition von Gruppenrichtlinien müssen DirectAccess-Einstellungen erzwungen werden, die folgende Aufgaben erfüllen:
- Identifizieren der DirectAccess-Clients.
- Konfigurieren der Richtlinientabelle für die Namensauflösung.
- Entfernen des ISATAP-Protokolls (Intra-Site Automatic Tunneling Address Protocol) aus der globalen Einschränkungsliste des DNS.

Der DirectAccess-Server muss folgende Voraussetzungen erfüllen:
- Er muss Mitglied einer Active Directory-Domäne sein.
- Er muss unter Windows Server R2 ausgeführt werden.
- Auf dem Server müssen zwei Netzwerkadapter konfiguriert werden (ein Adapter für Intranet- und der andere für Internetverbindungen).
- Er muss über zwei aufeinander folgende statische IPv4-Adressen verfügen, die extern aufgelöst werden können.

Er muss mit der DirectAccess-Verwaltungsfunktion (über den Server-Manager) installiert und mit dem Setup-Assistenten konfiguriert werden.

Der IIS/Webserver ermöglicht Funktionalität, die bestimmt, ob Intranetressourcen erreichbar sind. Anwendungsserver müssen entsprechend konfiguriert werden, sodass sie Clients mit DirectAccess Zugriff gewähren.
Zum Einsatz mit der erforderlichen Zertifizierungsstelle installieren Sie die Active Directory-Zertifikatdienste und stellen Zertifikate für die Authentifizierung aus.
Im gesamten Intranet müssen entweder ein natives IPv6-Netzwerk oder Übergangstechnologien verfügbar sein.
Der Client authentifiziert sich mit IPsec-Richtlinien für eine sichere Authentifizierung und DirectAccess-Verbindungsverschlüsselung, bevor sich der Benutzer anmeldet.
Sie finden die notwendigen Firewallausnahmen im Microsoft DirectAccess – Handbuch für Erstanwender.

Wie Sie sehen, ist DirectAccess nichts für schwache Nerven. Zweifellos wird allein die IPv6-Anforderung schon Bedenken aufkommen lassen – und von den meisten Organisationen die Implementierung von Übergangstechnologien erfordern. Allerdings verfügt 2008 R2 über die erforderlichen Komponenten. Außerdem müssen über eine PKI-Infrastruktur Sicherheitsfunktionen aktiviert, Authentifizierungsdienste bereitgestellt und die IPv6-Identifizierung gegenüber Anwendungsservern eingerichtet werden. Bevor Sie den Setup-Assistenten für DirectAccess ausführen, müssen Sie zudem die Sicherheitsgruppen konfigurieren, Firewallrichtlinien definieren, den DNS einrichten und einige andere Voraussetzungen erfüllen.

DirectAccess-Server

Der DirectAccess-Server erfüllt einige Funktionen, die über den im Server-Manager verfügbaren Setup-Assistenten für DirectAccess definiert werden (siehe Abbildung 6).

Abbildung 6 Die Einrichtung von DirectAccess über den Server-Manager einleiten.

Der DirectAccess-Assistent führt die folgenden vier grundlegenden Aufgaben aus:

Identifizieren von Clients, auf denen DirectAccess aktiviert werden soll. Sie können hier Sicherheitsgruppen aus anderen Domänen oder Gesamtstrukturen auflisten, sofern Vertrauensstellungen konfiguriert wurden. Sie müssen die entsprechenden Sicherheitsgruppen definieren, bevor Sie den Assistenten ausführen.
Definieren der Verbindungen und Sicherheit(szertifikate) für den DirectAccess-Server. Sie geben an, welche Netzwerkschnittstelle der Internetverbindung und welche der Intranetverbindung zugeordnet ist. Installieren Sie die Zertifizierungsstelle, und erstellen Sie die Zertifikate, bevor Sie den Setup-Assistenten für DirectAccess ausführen. Definieren Sie überdies eine Smartcard-Richtlinie.
Identifizieren von DNS, Domänencontroller und optional eines Verwaltungs- oder anderen Infrastrukturservers für die DirectAccess-Umgebung. Sie müssen auch einen Server mit hoher Verfügbarkeit als Netzwerkadressenserver festlegen. Der DirectAccess-Server kann diese Rolle übernehmen.
Identifizieren der Anwendungsserver, die entsprechend konfiguriert wurden, sodass sie Clients mit DirectAccess Zugriff gewähren. In der Standardeinstellung wird keine zusätzliche End-to-End-Authentifizierung durchgeführt, Sie können jedoch auf IPsec-Richtlinien basierende Sicherheitsoptionen auswählen.

DNS und die Richtlinientabelle für die Namensauflösung

Wie oben bereits erwähnt, können DirectAccess-Clients direkt auf das Intranet zugreifen. Um dies zu ermöglichen, müssen Sie die Richtlinientabelle für die Namensauflösung (Name Resolution Policy Table, NRPT) implementieren, in der die DNS-Server pro DNS-Namespace statt pro Netzwerkschnittstelle definiert sind. Ich vergleiche dies mit der bedingten Weiterleitung bei DNS-Servern unter Windows 2003 und 2008, wo DNS-Namespaces unter Angabe der für den Verbindungsaufbau mit dem Server zu verwendenden IP-Adresse definiert werden können. Die Richtlinientabelle für die Namensauflösung ermöglicht es Clients, die normale DNS-Iteration zu umgehen und direkt auf den DirectAccess-Server zuzugreifen.

So funktioniert die Richtlinientabelle für die Namensauflösung (siehe Abbildung 7):

Bei einer Anforderung mit einer Namensabfrage wird ein konfigurierter Namespace für das Firmenintranet zugeordnet, der auf den DirectAccess-Server verweist.
Die Richtlinientabelle für die Namensauflösung enthält die IP-Adresse und den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des DirectAccess-Servers. Wenn die IP-Adresse verwendet wird, dann wird die Verbindung mit dem DNS-Server aus Sicherheitsgründen verschlüsselt.
Wenn der vollqualifizierte Domänenname verwendet wird, muss er über das Internet aufgelöst werden, und es muss der DNS-Server des Unternehmens gefunden werden.
Falls der Client eine Namensauflösung für einen Namespace anfordert, der nicht in der Richtlinientabelle für die Namensauflösung definiert ist (beispielsweise www.microsoft.com), wird der Name wie gewöhnlich über das Internet aufgelöst.

Abbildung 7 Die Richtlinientabelle für die Namensauflösung ermöglicht die Definition von DNS-Servern pro DNS-Namespace statt pro Schnittstelle.

Die Richtlinientabelle für die Namensauflösung wird während der DirectAccess-Installation auf der Seite Infrastrukturserver-Setup konfiguriert, und der Assistent trägt die IPv6-Adresse des DNS-Servers ein. In der Namensauflösungsrichtlinie, einer neuen Gruppenrichtlinieneinstellung für 2008 R2, werden spezielle Richtlinieneinstellungen wie IPsec, DNS-Server und die Art und Weise definiert, wie die Namensauflösung fortgesetzt wird, wenn der Namespace nicht im abgefragten Netzwerk gefunden wird. Sie finden diese Einstellung unter Computerkonfiguration | Windows-Einstellungen| Namensauflösungsrichtlinie (beachten Sie, dass Sie Domänennamespaces mit einem vorangestellten Punkt "." angeben müssen, z. B. .emea.corp.net).

Sie können den Inhalt der Richtlinientabelle für die Namensauflösung mit dem Netsh-Befehl Netsh name show policy verfügbar machen.

Damit werden die definierten Namespaces angezeigt.

Firewallausschlüsse

Die Firewallausschlüsse hängen davon ab, wie Sie das IPv6-Netzwerk implementieren und ob Sie Übergangstechnologien einsetzen. Außerdem muss für alle Datei- oder Anwendungsserver, mit denen Remoteclients Verbindungen herstellen, die Windows-Firewall entsprechend konfiguriert werden. Abbildung 8 und Abbildung 9 unten zeigen Firewallausschlüsse für die Firewall auf der Internet- bzw. Intranetseite des DirectAccess-Servers. Offensichtlich müssen nur Ausschlüsse für die verwendeten Technologien festgelegt werden. (Beachten Sie, dass in Abbildung 9 der Eintrag IPv4+NAT-PT aufgeführt wird, obwohl dieses Protokoll von Windows 2008 R2 nicht implementiert wird.)

Abbildung 8 Firewalleinstellungen für die Internetfirewall

Übergangstechnologie	Zuzulassendes Protokoll
Teredo	UDP 3544
IPv6-zu-IPv4	IP-Protokoll 41
IP-HTTPS	TCP 443
Systemeigener IPv6-Datenverkehr	ICMPv6, Protokoll 50

Abbildung 9 Firewalleinstellungen für die Intranetfirewall

Protokoll	IPv6-Technologie
Protokoll	ISATAP	Systemeigener IPv6-Datenverkehr	IPv4 + NAT-PT
Protokoll 41	X
TCP		X	X
UDP		X	X
ICMPV6		X
Gesamte IPv6-Konnektivität		X
UDP 500 IKE/AuthIP		X	X

Konnektivität – IPv6

Weil IPv6 zulässt, dass DirectAccess-Clients ununterbrochen mit Ressourcen im Unternehmensnetzwerk verbunden bleiben, muss das Protokoll auf allen ausgeführt werden. Auch wenn Sie über ein vollständig implementiertes IPv6-Netzwerk verfügen, kann für die Remotekonnektivität der Einsatz einer Übergangstechnologie erforderlich sein, die es dem DirectAccess-Client erlaubt, Verbindungen mit IPv4-Ressourcen herzustellen, indem IPv6-Daten in IPv4-Paketen gekapselt werden. Zu diesen Technologien gehören IPv6-zu-IPv4, IP-HTTPS und Teredo. Auch ISATAP ist eine Kapselungstechnologie, wird jedoch nur intern verwendet. Ich werde dies hier nicht in allen Einzelheiten beschreiben; in Abbildung 10 sind jedoch grundlegende Konnektivitätsoptionen dargestellt.

Abbildung 10 Bevorzugte Verbindungsoptionen für DirectAccess-Clients

Wenn dem Client Folgendes zugewiesen wird:	Bevorzugte Verbindungsmethode:
Global weiterleitbare IPv6-Adresse	Global weiterleitbare IPv6-Adresse
Öffentliche IPv4-Adresse	IPv6-zu-IPv4
Private (NAT) IPv4-Adresse	Teredo
Wenn der Client mit den oben genannten Methoden keine Verbindung herstellen kann	IP-HTTPS

* Quelle: Microsoft*

Auf der Intranetseite ohne nativen IPv6-Datenverkehr lässt DirectAccess den Einsatz von ISATAP zu, womit aus einer IPv4-Adresse eine IPv6-Adresse generiert und eine eigene Nachbarkennung implementiert wird. Die Verwendung von ISATAP ermöglicht es DirectAccess-Clients, auf Ressourcen in einem IPv4-Netzwerk zuzugreifen. Wenn beispielsweise ein ISATAP-Client hochgefahren wird, muss er einen ISATAP-Router finden. Er stellt hierzu eine DNS-Abfrage nach ISATAP.<Domänennname>. Im Fall von Corp.net würde er also nach ISATAP.corp.net suchen. Windows 2008 DNS implementiert GlobalQueryBlockList, ein zusätzliches Sicherheitsfeature, das standardmäßig ISATAP beinhaltet. Deswegen werden alle ISATAP.<Domänenname>-Anforderungen ignoriert. Sie müssen daher ISATAP aus der Liste entfernen. Verwenden Sie hierzu den DNSCMD-Befehl, oder legen Sie einen entsprechenden Registrierungseintrag fest.

Geben Sie an der Befehlszeile dnscmd /config /globalqueryblocklist wpad ein, und drücken Sie die EINGABETASTE. Damit wird eine GlobalQueryBlockList-Liste definiert, die lediglich den Eintrag WPAD enthält (folglich wird ISATAP entfernt). Sie können hierzu auch den Registrierungsschlüssel

HKLM:\System\Current Control Set\Services\DNS\Parameters anzeigen. Bearbeiten Sie GlobalQueryBlockList, und entfernen Sie ISATAP.

Sie können IPv6-zu-IPv4 auch auf einzelnen Hosts oder über ein gesamtes Netzwerk hinweg implementieren und IPv6-Pakete über ein IPv4-Netzwerk übertragen. Für die IPv6-zu-IPv4-Implementierung für ein gesamtes Netzwerk ist interessanterweise nur eine IPv4-Adresse erforderlich. Der Datenaustausch zwischen IPv4- und IPv6-Host ohne IPv4 wird nicht unterstützt.

Auch Teredo ermöglicht die Weiterleitung von IPv6-Paketen an IPv4-Netzwerke, wird jedoch nur verwendet, wenn sich der Client hinter einem NAT-Server (Netzwerkadressübersetzung) befindet, der nicht für IPv6 konfiguriert wurde. Die IPv6-Pakete werden hier in dem IPv4-Datagramm gespeichert, das eine Weiterleitung vom NAT zulässt.

In Windows 7 und Server 2008 R2 wurde ein Protokoll mit dem Namen IP-HTTPS implementiert, das IPv6-Pakete in einem IPv4-HTTPS-Paket verpackt. IP-HTTPS hat zwar ein etwas schlechteres Leistungsverhalten als die anderen Protokolle, aber Sie können zusätzliche IP-HTTPS-Server hinzufügen, um das Leistungsverhalten etwas zu verbessern. IP-HTTPS ist ein recht einfaches Protokoll, das es ermöglichen soll, die IPv6-over-IPv4-Netzwerkverbindungen einzurichten.

Beim Entwurf der DirectAccess-Clientkonfiguration können Sie entweder DNS oder die Richtlinientabelle für die Namensauflösung verwenden, um Internet- und Intranetdatenverkehr voneinander zu trennen. Sie können aber auch das sogenannte Force-Tunneling nutzen und den gesamten Datenverkehr durch den Tunnel leiten. Force-Tunneling, das IP-HTTPS erfordert, wird über die Gruppenrichtlinieneinstellung Computerkonfiguration\Richtlinien\Administrative Vorlagen\Netzwerk\Netzwerkverbindungen\Gesamten Datenverkehr über das interne Netzwerk weiterleiten aktiviert. Diese Richtlinie muss dann auf die DirectAccess-Clients angewendet werden. Wie oben bereits erwähnt, können DirectAccess-Clients auf lokale Ressourcen zugreifen, während sie mit dem Intranet verbunden sind. Das gilt auch für IP-HTTPS-Clients. Wenn der Benutzer allerdings versucht, auf Internetsites zuzugreifen, dann würde der Datenverkehr über das Intranet geleitet.

Sicherlich sind die IPv6-Anforderung und die komplexe Konfiguration Nachteile von DirectAccess, jedoch werden sie durch die höhere Benutzerfreundlichkeit und die einfache Remoteclientverwaltung für IT-Abteilungen leicht aufgewogen.

Vielversprechend

Die Anzahl von Telearbeitern nimmt zu, die von einer Zweigniederlassung, von zu Hause oder von unterwegs auf das Unternehmensintranet zugreifen. BranchOffice und DirectAccess sind für Zweigniederlassungen und andere Telearbeiter sehr vielversprechend, und für IT-Manager und Administratoren wäre es ratsam, sich näher mit diesen Features zu beschäftigen. Beide sind weder schnell noch einfach zu installieren, und es sind einige Optionen und Features verfügbar. Außerdem funktionieren diese Features nur bei Windows 7-Clients und Windows Server 2008 R2-Servern, was sich definitiv auf den Implementierungszeitraum auswirkt. IT-Manager und Administratoren sollten die verfügbare Microsoft-Dokumentation studieren und die Features in einer Testumgebung konfigurieren, um eine erfolgreiche Umsetzung sicherzustellen.