Direkter Draht: Direct-Access-Nachfolger Always On VPN
Im Mai 2018 hat Microsoft schließlich angekündigt, nicht weiter in Direct-Access-Entwicklungen zu investieren. Das bedeutet natürlich nicht das sofortige Ende von Direct Access, sondern vielmehr, dass es zukünftig keine neuen Features mehr dafür geben wird. Selbstverständlich stehen aber noch eine lange Zeit Bugfixes und Sicherheitsupdates bereit, Direct Access lässt sich also heute noch lange nicht als veraltet bezeichnen. Es bleibt sogar für Clients vor Windows 10 die einzige Wahl, um über Microsofts VPN einen Zugang zum Unternehmensnetzwerk zu bekommen.
Hürden bei Direct Access
Direct Access weist einige kleine Einschränkungen auf, die einem Einsatz nicht grundsätzlich im Wege stehen, vorher aber je nach Einsatzumgebung einige Steine in den Weg legen. Direct Access wurde ursprünglich für die Verwendung mit IPv6 konzipiert. Um auch von Clients erreichbar zu sein, die allein über IPv4 mit dem Internet verbunden sind, musste dann ein weiterer Tunnel wie 6to4 oder Teredo Tunneling zum Einsatz kommen. Für Windows Server 2012 ändert ein Update diese deutliche Einschränkung. Eine weitere Limitierung ist, dass Clients zwingend Teil einer Windows-Domäne sein müssen. Nicht-Domänen-Computer haben keinen Zugriff mit Direct Access.
Wenn Sie in Ihrem Unternehmen Windows 7 für mobile Geräte einsetzen, können Sie mit diesen nicht auf Always On VPN wechseln. Allerdings ist es möglich, sich mit diesen Clients zu einem Always-On-VPN-Server zu verbinden, solange dort der Kompatibilitätsmodus für Direct Access aktiviert ist. Im Gegensatz zu vielen anderen VPN-Lösungen erlaubt Direct Access die Verbindung zum VPN-Server ohne Benutzerinteraktion. Sobald ein Benutzer angemeldet ist und eine Verbindung ins Internet besteht, wird das VPN aktiviert. Diese Transparenz ist einer der Vorteile von Direct Access. Wenn Ihre Clients bereits alle mit Windows 10 ausgestattet sind oder Sie eine entsprechende Migration planen, können Sie bei Ihren VPN-Planungen statt auf Direct Access auf Always On VPN setzen.
Nahtloses Always On VPN
Im Gegensatz zu Direct Access verspricht Microsoft mit Always On VPN eine neue Umsetzung eines Enterprise-VPN für moderne Infrastrukturen. Wenn auch nicht offiziell so dargestellt, handelt es sich bei Always On VPN im Grunde um das "neue Direct Access". Ähnlich wie der Vorgänger bietet es dieselbe User Experience und integriert sich nahtlos und für den Benutzer genau so transparent in das bestehende System. Always On VPN ermöglicht eine direkte Integration in das Active Directory und Gruppenrichtlinien. Auch das Azure Active Directory wird ohne zusätzlichen Aufwand unterstützt. Durch die Verzahnung mit der Mobile Device Management Platform beziehungsweise Microsoft Intune lassen sich die mobilen Geräte in Ihrem Unternehmen für die VPN-Nutzung komfortabel konfigurieren und überschauen.
Über den RADIUS-Server des Microsoft Network Policy Servers (NPS) erlaubt Always On VPN auch die Durchsetzung weiterer Anforderungen an Clients. Conditional Access stellt gemeinsam mit dem Azure Active Directory dann sicher, dass nur Clients, die entsprechende Compliance-Anforderungen erfüllen, auch Zugang zum internen Netzwerk erhalten. Microsoft empfiehlt für den Einsatz als RADIUS-Server natürlich die eigene Implementierung des NPS. Allerdings ist es aufgrund der Unabhängigkeit von der Infrastruktur auch möglich, alternative RADIUS-Server wie FreeRADIUS, ClearBox oder Pulse-Secure einzusetzen.
Dank der Infrastruktur-Unabhängigkeit erlaubt Always On VPN auch die Nutzung von Third-Party-VPN-Servern wie Palo Alto, Checkpoint oder Cisco, solange mindestens IPSec mit IKEv2 für den Schlüsseltausch verwendet wird. Always On VPN unterscheidet grundsätzlich zwei Tunnel-Typen: den Device-Tunnel und den User-Tunnel. Der Device-Tunnel erlaubt eine Verbindung des Geräts zum VPN, auch bevor sich ein Benutzer an dem Gerät anmeldet. Ein User-Tunnel wird erst mit dem Login des Benutzers aufgebaut.
Ein Device-Tunnel ist praktisch für die Remote-Administration (manage out) der Geräte. So können schon vor der Benutzeranmeldung eine Verbindung aufgebaut, Gruppenrichtlinien aktualisiert oder Software-Updates installiert werden. Auch für den Login des Benutzers bietet dies Vorteile. Bei einem User-Tunnel steht der firmeninterne Active-Directory-Server für den Login noch nicht zur Verfügung. Ein Benutzer muss sich also vor der ersten Verwendung zunächst innerhalb des Unternehmensnetzes einmalig am Gerät anmelden, damit die Credentials zwischengespeichert werden können. Ansonsten ist eine Anmeldung ohne Verbindung zum Active Directory nicht möglich.
Dieser Schritt ist mit dem Device-Tunnel nicht mehr erforderlich. Allerdings gibt es bei der Verwendung des Device-Tunnels auch Einschränkungen. Er erfordert zwingend IKEv2 und erlaubt keinen Fallback auf SSTP (Secure Socket Tunneling Protocol), so wie dies beim User-Tunnel möglich ist. Glücklicherweise kann neben einem Device-Tunnel auch ein weiterer User-Tunnel vom selben Gerät aufgebaut werden. So steht SSTP für User-Tunnel als Fallback bereit, wenngleich die Vorteile des Device-Tunnels dann nicht mehr nutzbar sind.
Der Vorteil von SSTP als Tunnel-Protokoll für User-Tunnel ist die meist einfachere Nutzung hinter Firewalls. Während IKEv2 auf den UDP-Ports 500 und 4500 läuft, die erst für den Datenverkehr freigegeben werden müssen, verwendet SSTP den in den meisten Firewalls bereits freigegebenen Port 443. Dies ist auch ein weiterer Vorteil beim Einsatz von Load Balancern vor mehreren VPN-Endpunkten. Nicht alle Load Balancer unterstützen "Port following", also die Nutzung unterschiedlicher Ports für denselben Client auf demselben Endpunkt. Das ist aber bei IKEv2 zwingend notwendig, da auf Port 500 die Verbindungsparameter ausgehandelt werden, die dann auf Port 4500 genutzt werden. Eine Weitergabe dieser Verbindungsparameter an den Prozess auf einem anderen Endpunkt ist nicht möglich.
Betrieb vorbereiten
Vor der Installation des VPN-Servers sollten Sie in Ihrer Domäne einige Vorbereitungen treffen. In unserem Beispiel installieren wir alle Funktionen, also VPN-Endpunkt, RADIUS-Server und Active Directory, auf einem Server, das macht die Integration besonders leicht. In Ihrem Unternehmens-Setup haben Sie mit Sicherheit aufgrund unterschiedlicher Anforderungen mehrere Server, die verschiedene Funktionen übernehmen. Sie müssen dann entsprechend Ihrer Umgebung die Konfigurationen anpassen. Der Testserver ist ein Windows Server 2016 mit konfiguriertem Active Directory, DNS-Server und Zertifizierungsstelle.
In den Gruppenrichtlinien wurde die automatische Registrierung von Zertifikaten für Computer und Benutzer aktiviert. Diese Einstellung konfigurieren Sie dann im GPO-Editor unter "Richtlinien / Windows-Einstellungen / Sicherheitseinstellungen / Richtlinien für öffentliche Schlüssel". Aktivieren Sie dort die Einstellung "Zertifikatdienstclient / Automatische Registrierung" und wählen Sie die Optionen "Abgelaufene Zertifikate erneuern, ausstehende Zertifikate aktualisieren und gesperrte Zertifikate entfernen" sowie "Zertifikate, die Zertifikatvorlagen verwenden, aktualisieren", wie in Bild 1 dargestellt.
Für die einfache Zuordnung von Einstellungen und für die Zugriffsberechtigungen auf die Zertifikatvorlagen erstellen Sie noch eine Gruppe "VPN Benutzer" im Active Directory und fügen dort alle berechtigten Benutzerkonten hinzu. Gleiches machen Sie für die Gruppen "VPN Server" und "NPS Server". Erstellen Sie nun in der Konsole der Zertifizierungsstelle (certsrv.msc) eine Zertifikatvorlage für Ihre VPN-Benutzer. Klicken Sie dafür mit der rechten Maustaste auf Zertifikatvorlagen und wählen Sie den Punkt Verwalten aus. Im Verwaltungsfenster kopieren Sie dafür die existierende Benutzervorlage und vergeben unter "Allgemein" einen entsprechenden Namen, etwa "VPN Benutzer Authentifikation". Entfernen Sie den Haken bei "Zertifikat in Active Directory veröffentlichen". Unter Sicherheit erlauben Sie nun den Zugriff für die Gruppe "VPN Benutzer", die sie weiter oben angelegt haben, und wählen zusätzlich den Zugriff auf "Registrieren" und "Automatisch registrieren" mit aus. Unter Kompatibilität wählen Sie "Windows Server 2012 R2" bei Zertifizierungsstellen und "Windows 8.1/Windows Server 2012 R2" bei Zertifikatempfänger. Unter Kryptographie wählen Sie "Für Anforderungen muss einer der folgenden Anbieter verwendet werden" und setzen einen Haken bei "Key Storage Provider".
| Seite 1 von 2 | Nächste Seite >> |
dr/Matthias Wübbeling
