Anbindung übers Web – schneller und sicherer als VPN

Direct Access mit Windows Server 2016 und Windows 10

| Autor / Redakteur: Thomas Joos / Andreas Donner

DirectAccess ist in vielen Fällen der bessere VPN-Zugang ins Unternehmen.
DirectAccess ist in vielen Fällen der bessere VPN-Zugang ins Unternehmen. (Bild: Joos / Microsoft)

Mit „Direct Access“ bietet Microsoft bereits seit den Vorgängerversionen von „Windows 10“ und „Windows Server 2016“ die Möglichkeit, Arbeitsstationen über das Internet schnell und sicher an das Firmennetz anzubinden. Vorteil: keine Zusatzkosten und ein wesentlich einfacheres Handling für Anwender all bei anderen VPN-Lösungen.

Im Gegensatz zu VPN-Verbindungen müssen Anwender beim Verbindungsaufbau mit Direct Access keinen VPN-Client öffnen und keine dedizierte VPN-Verbindung aufbauen. Administratoren konfigurieren die Arbeitsstation für Direct Access und stellen die notwendigen Server im Netzwerk zur Verfügung. Anwender arbeiten wie gewohnt.

Sobald eine Arbeitsstation oder ein Notebook erkennt, dass es sich nicht im sicheren internen Netzwerk befindet, baut der Rechner im Hintergrund automatisch eine verschlüsselte Verbindung zum internen Netzwerk auf. Der Anwender kann somit unterwegs vollkommen transparent und in gewohnter Art und Weise mit den gleichen Anwendungen arbeiten, wie im Firmennetzwerk; auf eine Absicherung seiner Verbindung muss er nicht achten.

Sicherheitsrichtlinien und Gruppenrichtlinien werden außerdem auch über das Internet auf den Arbeitsstationen angewendet. Auch Anmeldungen an „Active Directory“ sind möglich. Mit „Windows Server 2012 R2“ und „Windows 8.1“ hat Microsoft die Administration von DirectAccess vereinfacht und den Funktionsumfang erweitert.

Die Einrichtung von Direct Access ist allerdings auch in Windows Server 2016 und Windows 10 noch immer keine Aufgabe, die schnell erledigt ist. Zwar hat Microsoft in den neuen Versionen die Einrichtung deutlich vereinfacht, dennoch sollten Administratoren vorsichtig bei der Konfiguration sein.

Denn mit Direct Access können sich Rechner aus dem Internet mit dem Unternehmensnetzwerk verbinden. Daher sollte hier über entsprechende Maßnahmen auch die Sicherheit der Infrastruktur berücksichtigt werden.

Zur Einrichtung von Direct Access gehören stets auch einige Server- und Client-Konfigurationen sowie Gruppenrichtlinien und Zertifikate. Ganz ausführlich zeigt Microsoft die Einrichtung eines Direct-Access-Servers auf einer eigenen Internet-Seite.

Unternehmen, die Direct Access produktiv einsetzen wollen, sollten den Einsatz der dazugehörigen Server und die Anpassungen der Firewalls gut planen. Microsoft hilft in diesem Fall mit dem Whitepaper „Plan an Advanced Direct Access Deployment“. Alle Möglichkeiten, die Microsoft für den Remote-Zugriff zur Verfügung stellt, sind wiederum auf der Seite „Remote Access and Server Management“zusammengefasst.

Netzwerk für Direct Access vorbereiten

Um Direct Access zu nutzen, muss im Netzwerk auf einem Server die Rolle „Remotezugriff“ installiert werden. Diese verfügt über den Rollendienst „DirectAccess und VPN (RAS)“. Über diesen Dienst wird die Anbindung vorgenommen (siehe: Abbildung 1). Die Installation kann über den Server-Manager oder in der Powershell mithilfe des zugehörigen CMDlets Install-WindowsFeature RemoteAccess -IncludeManagementTools erfolgen.

Die Einrichtung des Dienstes erfolgt erst nach der Installation über den Server-Manager und einen eigenen Assistenten, der im Kontextmenü des Servers zur Verfügung steht (siehe: Abbildung 2). Der Server sollte über mindestens zwei Netzwerkadapter verfügen. Ein Adapter ist über die Firewall mit dem Internet verbunden, die andere Schnittstelle mit dem internen Netzwerk.

Für eine bessere Verwaltung sollten die Server, die Bestandteil des Direct-Access-Netzwerks sind, Mitglied einer eigenen Gruppe in Active Directory sein. Auch die Arbeitsstationen, die sich später über Direct Access verbinden sollen und dürfen, sollten Mitglied einer speziellen Active-Directory-Gruppe sein.

Im Rahmen der Einrichtung können diese Gruppe ausgewählt werden. Im Rahmen der Einrichtung werden dann Gruppenrichtlinien erstellt, die automatisch auf die Computerkonten angewendet werden, welche sich in der Direct-Access-Client-Gruppe befinden. Dadurch wird die Anbindung der Arbeitsstationen weitgehend automatisiert.

Einrichtung von Arbeitsstationen für Direct Access

Damit Direct Access funktioniert, müssen Unternehmen auf Windows 7, Windows 8/8.1 oder besser auf Windows 10 setzen. Die Sicherheit wird durch Zertifikate sichergestellt.

Hier bietet es sich an, entweder auf ein gekauftes Zertifikat zu setzen, oder eine interne Zertifizierungsstelle einzusetzen – zum Beispiel mit den Active-Directory-Zertifikatsdiensten. Im Rahmen der Einrichtung von Direct Access werden auch die Computergruppen festgelegt, die Zugriff auf Direct Access erhalten. Auf Arbeitsstationen müssen keine Anpassungen vorgenommen werden, um Direct Access zu nutzen.

Sobald sich ein Computer in der entsprechenden Computergruppe befindet, wird er durch die dazugehörige Gruppenrichtlinie automatisch angebunden (siehe: Abbildung 3). Wenn sich der Computer nicht mehr im internen Netzwerk befindet, bindet er sich mit Direct Access an. In der Powershell kann die Verbindung mit dem CMDlet Get-DaConnectionStatus getestet werden. In der Eingabeaufforderung kann die Konfiguration mit netsh name show effectivepolicy überprüft werden.

Da die Einrichtung von Direct Access über Gruppenrichtlinien erfolgt, sollten Arbeitsstationen, die diese Funktion nutzen, mindestens einmal im lokalen Netzwerk gestartet werden, damit die Gruppenrichtlinien auch angewendet werden. Im laufenden Betrieb kann das mit gpudapte /force erfolgen.

Nachdem die Anbindung erfolgreich vorgenommen wurde, können Anwender auch mobil sicher auf Ressourcen im internen Netzwerk zugreifen – auch auf Dateifreigaben, wenn das gewünscht ist. Die Verwaltung erfolgt über die Remote-Verwaltungs-Konsole auf dem Direct-Access-Server. Auf den Arbeitsstationen müssen keinerlei Einstellungen vorgenommen oder Tools installiert werden.

Web-Anwendungs-Proxy in Windows Server 2016

Neben Direct Access kann auch der Web-Anwendungs-Proxy (Web Application Proxy, WAP) in Windows Server 2016 ein wertvolles Hilfsmittel sein, wenn es darum geht, Client-Anfragen aus dem Internet auf interne Ressourcen umzuleiten. WAP und DirectAccess lassen sich parallel und ergänzend im Netzwerk einsetzen. Der Web-Anwendungsproxy (WAP) stellt eine sichere Schnittstelle vom internen Netzwerk zum Internet dar – vor allem für die Veröffentlichung von Server-Diensten.

Mit diesem Server-Feature können Unternehmen Web-Dienste wie „Exchange Outlook Web App“ und andere Web-Dienste wie „Sharepoint“ aus dem internen Netzwerk im Internet bereitstellen. Das Feature arbeitet mit den Active-Directory-Verbunddiensten zusammen. Der Web-Anwendungs-Proxy erlaubt die sichere Kommunikation der Anwender aus dem Internet mit Outlook Web App und den Sharepoint-Apps und ist eine ideale Ergänzung zu Direct Access.

In Windows Server 2016 lassen sich Exchange Active-Sync-Geräte stabiler anbinden. Diese verbinden sich über den Web-Anwendungs-Proxy und authentifiziert durch ADFS mit Exchange. In Windows Server 2012 R2 war das durch die nicht kompatible Authentifizierung noch nicht ohne weiteres möglich. Außerdem kann der Web-Anwendungs-Proxy in Windows Server 2016 HTTP-Anfragen automatisch zu HTTPS-Adressen weiterleiten.

Web-Anwendungs-Proxy ist ein Rollendienst der Server-Rolle „Remotezugriff“, genauso wie Direct Access. Rollendienste installieren Administratoren im „Server-Manager“ über Verwalten / Rollen und Features hinzufügen (siehe: Abbildung 4). Der Assistent zur Einrichtung nach der Installation des Rollendienstes startet über das Benachrichtigungs-Center im Server-Manager.

Im ersten Schritt muss bei der Einrichtung des Anwendungs-Proxys der ADFS-Server angegeben werden, der für die Authentifizierung verwendet werden soll. Für Testzwecke kann hier auch mit selbstsignierten Zertifikaten gearbeitet werden. Ein solches Zertifikat wird zum Beispiel in der Powershell erstellt. Die Syntax hierzu lautet: New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname <FQDN des Servers> (siehe: Abbildung 5).

*Thomas Joos schreibt IT-Fachbücher und -artikel. Auf DataCenter-Insider bestückt er seinen eignen Blog mit Tipps und Tricks für Administratoren: „Toms Admin-Blog“.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44765630 / Middleware)