DirectAccess

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

DirectAccess ist eine proprietäre, VPN-ähnliche Lösung von Microsoft unter Windows Server 2008 R2 und 2012. Die Technik basiert komplett auf dem Internet Protocol Version 6 und benutzt für den Zugriff auf IPv4-Server Überbrückungstechnologien, wobei unter Windows Server 2008 R2 für die IPv4-Überbrückung der Betrieb einer UAG-Firewall oder eines NAT64-Geräts nötig war. Bei einer Verbindung von extern werden die IPv6-Daten mittels eines IPsec-Tunnels übertragen. Im Gegensatz zu VPN benötigt DirectAccess kein benutzerseitiges Initiieren einer Verbindung, sondern stellt bereits beim Start des Computers automatisch eine Verbindung zum Unternehmensnetzwerk her, falls sich ein Client außerhalb des Unternehmensnetzwerkes befindet. Durch die automatische Verbindung der Clients zum Netzwerk ist ein Verwalten von externen Computern, sogenanntes „Manage-Out“, für Unternehmen möglich.

Funktionsweise[Bearbeiten | Quelltext bearbeiten]

Beim Start eines Clientcomputers versucht der PC, den sogenannten „Network Location Server“ (NLS) zu erreichen, wobei dieser nichts anderes ist als eine nur im Domänennetzwerk erreichbare Website und von jedem Webserver bereitgestellt werden kann. Falls der Computer den NLS nicht erreichen kann, nimmt der Computer an, dass er sich nicht im Domänennetzwerk befindet, und versucht daraufhin eine IPsec-gesicherte Verbindung zum Unternehmensnetzwerk aufzubauen. Ist keine native IPv6 Verbindung möglich, wird versucht, einen Tunnel mithilfe der Protokolle 6to4, Teredo tunneling, oder IP-HTTPS aufzubauen. Falls diese Verbindung zustande kommt, wird die „Name Resolution Policy Table“ (NRPT) so konfiguriert, dass für den Zugriff auf Unternehmensressourcen die DirectAccess-Verbindung des Unternehmens verwendet wird. Je nach Konfiguration kann auch der gesamte Netzwerkverkehr über das Unternehmensnetzwerk gehen. Wenn keine Verbindung (z. B. bei fehlender Internet-Verbindung) zustande kommt, kann dem Benutzer je nach Einstellung die Anmeldung verweigert oder mithilfe von im Cache gespeicherten Authentifizierungsinformationen dennoch gewährt werden.

Im Vergleich zu anderen "road warrior"-VPN (auch Client2Site) Lösungen bietet diese Variante die benutzerunabhängige Authentifizierung des Gerätes. Bei entsprechender Konfiguration des DirectAccess-Servers ist es ebenfalls möglich den Tunnel bis zum Endpunkt (dem dahinterliegenden Server) durchzuziehen und somit in "Cloud Native"-Szenarien, bei dem die Server nicht im Unternehmen, sondern bei einem Dienstleister im Rechenzentrum stehen, ebenfalls sicher zu verschlüsseln. Außerdem kann aufgrund der von Windows bekannten Authentifizierungsmöglichkeiten eine Verbindung an der Windows Firewall aufgrund von Benutzer- oder Computer-Gruppenzugehörigkeiten erlaubt oder verweigert werden. Zwei weitere wichtige Funktionen sind "Manage-Out", welche die Verwaltung der Clients mittels "PSSession" und "WinRM" erlaubt, sowie die Always-On-Funktion, die automatische benutzerunabhängige Aushandlung eines VPN-Protokolls aufgrund der im aktuellen Netzwerk des Clients vorhandenen Gegebenheiten (IPv6?, IPSec geblockt?, Teredo möglich?, HTTPS-Verbindungen möglich?).

Im Zuge der Einführung von DirectAccess wurde ebenfalls das Protokoll IP-HTTPS entwickelt, welches kurz zusammengefasst eine VPN-Verbindung über eine HTTPS-Verbindung ermöglicht. Für die TLS-Verbindung wird NULL-Encryption verwendet. Was auf den ersten Blick wie ein gefährliches Sicherheitsproblem wirkt, stellt sich bei genauer Betrachtung jedoch als nicht gegeben heraus. Wichtig hierbei ist, dass die Kommunikation mittels HTTPS auf Port 443 lediglich die Aufgaben des Linklayers übernimmt, damit die IPSec verschlüsselte IPv6 Verbindung aufgebaut werden kann.

Anforderungen[Bearbeiten | Quelltext bearbeiten]

Windows Server 2008 R2[Bearbeiten | Quelltext bearbeiten]

Es wird mindestens ein einer Active-Directory-Domäne angehörender Windows Server 2008 R2 mit installiertem DirectAccess mit zwei Netzwerkadaptern (ein Adapter in das Internet und einer ins Intranet) benötigt. Ebenfalls werden zwei öffentliche IPv4-Adressen benötigt. Außerdem muss das Netzwerk über einen DNS-Server, eine PKI-Umgebung und Active Directory verfügen. Für die Interaktion mit reinen IPv4-Servern im internen Netzwerk wird die NAT64-Funktion der Microsoft TMG-Firewall (ehem. UAG-Firewall) oder ein NAT64-Gerät benötigt.[1]

Windows Server 2012[Bearbeiten | Quelltext bearbeiten]

Es wird mindestens ein einer AD-Domäne angehörender Windows Server 2012 mit installiertem DirectAccess benötigt, jedoch werden lediglich noch ein Netzwerkadapter und eine IP-Adresse benötigt. Ebenfalls kann man inzwischen auf eine PKI-Umgebung verzichten, wobei ein DNS-Server sowie Active Directory weiterhin nötig sind. Eine spezielle Firewall ist ebenfalls nicht mehr nötig, da IPv4-Überbrückungstechnologien bereits in Windows Server 2012 integriert sind.[2]

Clients[Bearbeiten | Quelltext bearbeiten]

Clients benötigen Windows 7 Ultimate/Enterprise Edition, Windows 8 Enterprise Edition oder Windows 10 Education/Enterprise Edition.

Andere Betriebssysteme[Bearbeiten | Quelltext bearbeiten]

DirectAccess ist eine proprietäre Lösung von Microsoft, die keine anderen Betriebssysteme unterstützt. Serverseitig gibt es für die Integration von Linux in eine DirectAccess-Infrastruktur jedoch Lösungen von Drittanbietern.[3]

Für die Integration von anderen Betriebssystemen wird die Konfiguration eines VPN-Protokolls schon während der Installation von DirectAccess empfohlen.

Da DirectAccess nur eine Art Abfolge zur Verwendung von standardisierten Tunnel-Protokollen ist, ist eine Implementierung unter anderen Betriebssystemen zumindest theoretisch möglich. Für IP-HTTPs ist das Protokoll auf der Webseite von Microsoft spezifiziert.[4]

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. ↑ Anforderungen für Direct Access bei Windows Server 2008 auf Microsoft TechNet. Abgerufen am 17. Februar 2014.
  2. ↑ Konfigurieren der Infrastruktur eines RAS-Server mit Direct Access auf Microsoft TechNet. Abgerufen am 17. Februar 2014.
  3. ↑ Centrify DirectSecure: DirectAccess Integration. (Memento vom 26. März 2011 im Internet Archive) Abgerufen am 17. Februar 2014.
  4. ↑ MS-IPHTTPS: IP over HTTPS (IP-HTTPS) Tunneling Protocol. Microsoft, abgerufen am 21. Februar 2019 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=DirectAccess&oldid=240365154“