DirectAccess mit Windows Server 2008 R2

Inzwischen steht jeder Administrator eines Firmennetzes vor der Aufgabe, den Firmenmitarbeitern einen Zugang zum Firmennetz von Zuhause oder unterwegs zu ermöglichen. Es existieren daher zahlreiche Möglichkeiten, einen VPN-Zugang zu realisieren. Einige setzen auf spezielle Hardware, andere nutzen eine proprietäre VPN-Software oder bauen auf die Möglichkeiten des Betriebssystems. Keiner dieser Ansätze schaffte es aber bisher, die vielfältigen Anforderungen an eine VPN-Lösung vollständig zu erfüllen:

• Sichere Authentifizierung von Client und Server

• Ende-zu-Ende Verschlüsselung des gesamten Datenverkehrs

• Verwaltung des VPN-Zugangs über das Active-Directory

• Verwendung der gleichen Zugangskennwörter wie im Firmen-Netz

• Intelligentes Routing des Netzwerkverkehrs

• Zugang auf den Remote-Client, auch wenn niemand angemeldet ist

• Transparente Nutzung innerhalb und außerhalb des Firmennetzes

• Einfache Einrichtung und Administration

Microsoft hat im Windows Server 2008 R2 jetzt mit DirectAccess eine Lösung vorgestellt, die das Zeug dazu hat, all diese Anforderungen abzudecken. DirectAccess ermöglicht eine permanente Verbindung von Windows-Clients mit dem Firmennetz, unabhängig davon, wo sich die Client-Rechner befindet. Entscheidend ist nur, dass die Rechner eine Verbindung zum Internet haben.

Die DirectAccess-Verbindung besteht, sobald der Rechner läuft, also auch dann, wenn noch kein Benutzer angemeldet ist. Dies macht es möglich, vor dem Zugriff auf das Firmennetz die Einhaltung der Firmen-Policies zu überwachen und wenn nötig im Hintergrund aktuelle Software-Updates einzuspielen. Eine der kritischsten Sicherheitslücken für Firmen-Netze, nämlich die Notebooks der reisenden Mitarbeiter, ist damit geschlossen. Remote-Clients können dank DirectAccess jetzt genauso sicher konfiguriert werden wie die stationären PCs in der Firma.

Völlig transparenter VPN-Zugang

Der Zugriff auf das Firmennetz erfolgt für den Benutzer völlig transparent, er bemerkt (außer möglicherweise durch die Zugriffsgeschwindigkeit) nicht, ob er sich mit seinem Rechner im Firmennetz oder außerhalb davon befindet.

Dank intelligentem Routing ist es mit einer DirectAccess Verbindung auch nicht mehr so, dass alle Zugriffe ins Internet erst umständlich über das Firmen-Netz geroutet werden. Stattdessen erfolgt der Zugriff auf öffentliche Web-Seiten direkt über die Internet-Verbindung des Clients. Dieses Verhalten kann der Administrator allerdings über die Policies auch abschalten und so den kompletten Traffic kontrollieren.

Dabei ist DirectAccess im Grunde genommen nicht einmal eine völlig neue Technologie. Es ist die intelligente Kombination zahlreicher bestehender Protokolle und Technologien und ihre nahtlose Einbindung in Windows Server 2008 R2 und Windows 7 unter einer einfachen Administrationsoberfläche.

Voraussetzungen

Voraussetzung für DirectAccess ist Windows 7 auf den Client-Rechnern und Windows Server 2008 R2 auf dem DirectAccess-Server. Weiterhin funktioniert DirectAccess nur im Rahmen einer Active Directory Struktur, die Client-Rechner müssen also Mitglied in einer Firmen-Domäne sein.

Eine weitere Voraussetzung ist das Vorhandensein von zwei öffentlichen IPv4-Adressen, die auf die zwei notwendigen Netzwerkschnittstellen des DirectAccess-Servers geroutet werden müssen. Zu einer Adresse baut der Client einen Infrastructure-Tunnel auf, über den er sich Authentifiziert und auf DNS- und Active-Directory-Server zugreift. Der zweite dient dann dem eigentlichen Nutzdatenverkehr.

Die Rolle des DirectAccess Servers kann von einem Domaincontroller übernommen werden, wenn nur mit einem geringen Netzwerkverkehr gerechnet wird. Bei höherem Aufkommen empfiehlt es sich, einen separaten Server für diese Aufgabe abzustellen.

Bevor man daran gehen kann, den DirectAccess Server zu konfigurieren, muss eine Reihe von Voraussetzungen geschaffen sein.

• Im Firmennetz muss eine Domäne konfiguriert sein und mindestens einer der Domänencontroller, die Benutzerkonten verwalten, muss unter Windows Server 2008 oder höher laufen.

• Im Firmennetz muss eine Public-Key Infrastruktur vorhanden sein, d.h. auf mindestens einem der Domänencontroller müssen die Active Directory Zertifikatdienste installiert sein.

• Über den Domänen-Policy-Editor muss die automatische Anforderung und Registrierung von Computerzertifikaten für die Client-Rechner konfiguriert sein.

• Ein Verteilungspunkt für Zertifikatssperrlisten muss so konfiguriert sein, dass er über das Internet erreichbar ist.

• Auf den Client-Rechnern muss Windows 7 installiert sein, sie müssen Mitglied der Domäne sein.

• Die Computerkonten der DirectAccess-fähigen Client-Rechner müssen Mitglied in einer AD-Sicherheitsgruppe sein.

• Die Internetfirewall muss so konfiguriert sein, dass sie DirectAccess- und Teredo-Datenpakete passieren lässt.

• Eine HTTPS-basierte URL muss im internen Netzwerk erreichbar sein. Wenn nicht bereits eine entsprechende URL existiert, die nur im internen Netz erreichbar ist, muss eine solche eingerichtet werden. Über diese URL erkennt der Client-Rechner, ob er sich innerhalb oder außerhalb des Firmennetzes befindet.

• Auf allen DNS-Servern, die unter Windows Server 2008 oder höher laufen, muss der Name „ISATAP“ aus der globalen Abfragesperrliste entfernt werden.

Die genauen Schritte zur Gewährleistung all dieser Voraussetzungen sind in der DirectAccess-Hilfe detailliert beschrieben. Aber die bloße Aufzählung der Punkte zeigt schon, dass das Aufsetzen eines DirectAccess-Zugangs sicher einige Zeit in Anspruch nimmt.

Einrichtung

Der erste Schritt zur Einrichtung von DirectAccess besteht in der Installation des Features „DirectAccess“ im Server-Manager. Danach findet sich dort unter dem Knoten „Features“ der neue Punkt „DirectAccess“.

Das Setup von DirectAccess prüft beim Start alle Voraussetzungen und weigert sich, weiterzumachen, solange nicht alle notwendigen Voraussetzungen erfüllt sind. Wenn es erfolgreich durchgelaufen ist, öffnet sich die sehr übersichtlich gehaltene Konfigurationsoberfläche von DirectAccess.

Die eigentliche Konfiguration von DirectAccess besteht nun aus den abgebildeten vier Schritten:

1. Identifizieren der DirectAccess-fähigen Clients über die Angabe der Sicherheitsgruppe, in der sich diese Rechnerkonten befinden.

2. Angabe der Verbindung- und Policy-Einstellungen auf dem DirectAccess-Server.

3. Identifikation der für DirectAccess notwendigen Infrastruktur-Server (AD-Server, DNS).

4. Angabe der über DirectAccess erreichbaren Anwendungsserver.

Wenn bis dahin alles gut gegangen ist, haben die Client-Rechner jetzt einen ständigen Zugang zum Firmen-Netz.

Grundlagen

Um zu einer funktionierenden VPN-Lösung zu kommen ist es nicht unbedingt nötig, alle Technologien und Protokolle zu kennen, die sich hinter DirectAccess verbergen. Aber ist es aber von großem Nutzen, die Zutaten zu DirectAccess einmal kennengelernt zu haben, um ermessen zu können, was DirectAccess leistet und wo seine Grenzen sind.

DirectAccess basiert vollständig auf IPv6 und nutzt dessen immensen Adressraum, um jeden Client direkt adressieren zu können. Über IPSec werden Tunnels vom Client zum DirectAccess-Server aufgebaut, der seinerseits die Daten-Pakete zu den verschiedenen Rechnern im Firmennetz weiterleitet. Somit ist aus Sicht des Clients das Firmennetz ein IPv6-Netzwerk. Wäre jetzt die Welt um zwanzig Jahre weiter und das Internet wie auch alle Firmen-Netze würden bereits unter IPv6 laufen, so wäre die Geschichte hier zu Ende. Tatsächlich ist das Internet heute noch weitgehend ein reines IPv4-Netz und auch Firmennetze, dich durchgängig IPv6 sprechen, müssen mit der Lupe gesucht werden.

Es bedarf also einer Reihe von Übergangs-Protokollen, die gewährleisten, dass der DirectAccess-Client die Welt als IPv6-Netz sieht:

• 6to4 und ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) ermöglichen die Übertragung von IPv6 Datenpaketen über IPv4.

• Teredo (benannt nach dem Schiffsbohrwurm Teredo Navalis) ermöglicht den Zugriff auf ein IPv6 Netzwerk hinter einem NAT-Router. IPv6 Datenpakete werden mit UDP über IPv4 gekapselt. Teredo wird nur dann gebraucht, wenn Clients hinter einem NAT-Router das 6to4-Protokoll nicht nutzen können. Das Teredo-Protokoll ist auf einen Teredo-Server und ein Teredo-Relay angewiesen, die beide unterschiedliche öffentliche IP-Adressen brauchen. Teredo wird von Netzwerk-Administratoren manchmal kritisch gesehen, da es mit viel Aufwand virtuelle Löcher durch die NAT-Router bohrt und die Firmen-Firewalls den Teredo-Verkehr nicht überwachen können. Besonders vorsichtige Admins sperren daher den UDP-Port 3544, den Teredo nutzt.

• IP-HTTPS ist die letzte Möglichkeit für den Datenaustausch via DirectAccess, wenn alle anderen Protokolle versagen. Hier wird über HTTPS (Port 443) ein IP-Tunnel zum DirectAccess-Server aufgebaut, über den die IPv6 Datenpakete transportiert werden. IP-HTTPS belastet die Server-CPU relativ stark und ist aufgrund seines Protokoll-Overheads auch nicht sehr performant.

• NAT-PT wird schließlich im Firmennetz eingesetzt, um auch den Zugang zu Servern und Anwendungen herzustellen, die kein IPv6 sprechen. Zu diesem Zweck werden IPv6-Adressen von NAT-PT innerhalb eines DNS-Namensraums in IPv4 Adressen übersetzt.

Die eingesetzten Protokolle stellen sicher, dass der Client-Rechner (fast) immer einen Zugang zum Firmennetz bekommt, ohne dass sich der Benutzer um irgendwelche Details zu kümmern hat. Das verwendete Protokoll auf Client-Seite (6to4, Teredo oder IP-HTTPS) wird anhand der vorgefundenen Netzwerk-Topologie selbständig gewählt.

Fazit

Mit DirectAccess versucht Microsoft einen neuen VPN-Standard für Windows-Netzwerke zu etablieren. Als großen Vorteil baut DirectAccess unabhängig vom User-Login einen gesicherten Tunnel auf, sobald der Client einen irgendwie gearteten Internetzugang hat. Remote Management und Network Access Protection werden so auch für herumvagabundierende Mitarbeiter möglich. Der User soll von all dem nichts bemerken und auch durch Firewalls im Hotel und am Airport hindurch im Firmennetz arbeiten können.

Da DirectAccess konsequent auf IPv6 basiert, ist es zwar zukunftssicher, muss derzeit aber durch Übergangsprotokolle an die real existierende IPv4-Welt angepasst werden. Da es zudem nur in der Kombination Windows Server 2008 R2 mit Windows 7 Client läuft, dürfte es noch etwas dauern, bis es sich großflächig durchsetzt. (ala)