Multi-Faktor-Authentisierung mit Mobile App für Remote Desktop Gateway

Um von überall auf meine Testumgebung zugreifen zu können, habe ich auf einem virtuellen Server mit Windows Server 2012 das Remote Desktop Gateway konfiguriert. Lesen Sie in diesem Beitrag, wie das Remote Desktop Gateway geschützt werden kann.

Einführung

Meine Testumgebung besteht aus 4 physischen Servern und 50 bis 70 virtuellen Maschinen – je nach Anforderungen. Um nun von überall auf diese Infrastruktur zugreifen zu können, habe ich auf einem virtuellen Server mit Windows 2012 das Remote Desktop Gateway konfiguriert und dieses über meine Firewall ins Internet publiziert. Da zum Zeitpunkt der Installation nur eine öffentliche IP-Adresse zur Verfügung stand, musste ich einen anderen Port verwenden als TCP443. Dieser war schon besetzt und ein Reverse Proxy mit Content Switching hatte ich noch nicht.

Vorteil des nicht-standardmässigen Ports ist eine etwas grössere Sicherheit – die sogenannte «Security through obscurity». Allerdings leidet die Benutzerfreundlichkeit, da es ja nicht reicht, nur den öffentlichen Namen des Gateways in der Konfiguration anzugeben. Ausserdem sollte man sich nicht nur auf die Geheimhaltung der Zugangspunkte verlassen.

Wie kann die Sicherheit denn noch erhöht werden? Ein starkes Passwort, das oft gewechselt wird, verwende ich bereits. Eine Möglichkeit ist es, zusätzlich zum Passwort einen weiteren Authentisierungsfaktor zu verlangen: Etwas, das ich bin (biometrische Verfahren wie Fingerabdruck oder Retina) oder etwas, das ich habe (Token, Mobiltelefon).

Zum Glück hat Microsoft genau die richtige Lösung parat: Azure-Multi-Faktor-Authentisierung. Der Name mag den Eindruck erwecken, die Verwendung sei auf die Cloud beschränkt. Allerdings ist es problemlos möglich, Server und Services im eigenen Datacenter zu schützen. Die Integration erfolgt über ADFS, IIS, RADIUS, LDAP oder RDS.

In diesem Artikel werde ich aber nur zeigen, wie das Remote Desktop Gateway geschützt werden kann. Die nächste Abbildung zeigt die benötigten Komponenten.

Normalerweise verwendet das RD Gateway eine lokale Instanz des Network Protection Servers (NPS) für die Authentisierung. Wie Sie im Überblick oben sehen, sendet es die Anforderungen stattdessen dem MFA Server, der als RADIUS Target waltet. Wenn der zusätzliche Faktor verifiziert ist, schickt MFA die Antwort an den NPS auf dem Gateway zurück – dieses Mal als RADIUS Client. Dadurch wird die Authentisierung abgeschlossen und die Resource Authorization Policies bestimmen, ob der Benutzer auch wirklich auf die entsprechenden Ziele zugreifen darf.

Aus Benutzersicht sieht der Zugriff wie folgt aus:

1. Remote Desktop Connection starten und Benutzername/Passwort abfragen
2. Während des Verbindungsaufbaus wird eine Push-Notification an die MFA App auf dem Smartphone geschickt.
   
3. Der Benutzer muss nur Verify auswählen.
   
4. Danach wird der Verbindungsaufbau abgeschlossen.
   

Konfigurationsschritte

Azure Multi-Factor Authentication

In Azure Active Directory muss ein «Anbieter für mehrstufige Authentifizierung» konfiguriert werden. Sie können aus zwei Verrechungsformen wählen: Pro aktiviertem Benutzer oder pro 10 Anforderungen. Dies lässt sich nachträglich nicht mehr ändern.

MFA Server on-premise inklusive SDK

Die lokal zu installierende Serverkomponente lässt sich auf der Verwaltungswebseite herunterladen.

Sie werden auf einem Server installiert und mittels Aktivierungscode freigeschaltet. Der Code lässt sich im Portal erstellen.

Benutzer können über die Directory-Integration automatisch hinzugefügt oder manuell erfasst werden. Dabei wird auch festgelegt, welche Methode zur Authentisierung verwendet wird. Hier natürlich Mobile App.

Danach kann im MFA Mangement das Web Service SDK installiert werden.

Im Knoten Mobile App wird die öffentliche Mobile App Web Service URL eingetragen. Natürlich müssen dafür auch die nötigen externen DNS Records erstellt werden.

Die RADIUS-Konfiguration umfasst Client und Server.

Shared Secret und Ports müssen mit der späteren Konfiguration auf dem RD Gateway übereinstimmen.

MFA Web Service

Im Installationsverzeichnis des MFA Servers findet sich auch der Installer für den Mobile App Web Service. Dieser muss auf einem Server installiert werden, der sich über HTTPS nach extern publizieren lässt.

Bei der Installation sollte ein kurzer Name für das virtuelle Directory gewählt werden, da die Benutzer bei der Erstkonfiguration der MFA App diese URL eingeben müssen.

Das Web.config File muss wie folgt ergänzt werden:

Benutzername und Passwort eines Service Accounts, der Mitglied der Gruppe «Phone Faktor Admins» sein muss:

URL, unter der das SDK auf dem MFA Server erreichbar ist:

Remote Desktop Gateway

In den Eigenschaften des RD Gateways wird der CAP Store auf Central konfiguriert und der MFA Server als Ziel angegeben:

Im Knoten RADIUS Clients des NPS auf dem RD Gateway wird der MFA Server konfiguriert:

Für die bereits existierende Remote RADIUS Server Group müssen noch die Timeouts angepasst werden:

Unter Connection Request Policies wird eine Kopie der bestehenden Policy erstellt und wie folgt konfiguriert:

Achtung: Der Friendly-Name muss mit der Konfiguration des RADIUS Clients übereinstimmen!

Smartphone

Auf dem Smartphone muss zuerst die MFA App aus dem entsprechenden Store installiert werden:

Dann kann das Konto hinzugefügt werden. Der Code dazu wird vom Administrator oder vom Benutzer selbst über das User Portal (falls installiert) generiert:

Fazit

Azure MFA bietet vor allem im Zusammenhang mit der mobilen App eine benutzerfreundliche Möglichkeit zur Steigerung der Sicherheit beim Zugriff auf das Unternehmensnetzwerk und dessen Dienste.