Remote Desktop Gateway weiter nutzen – aber sicherer mit Microsoft Entra Application Proxy
Viele Unternehmen setzen auch heute noch auf ein Microsoft Remote Desktop Gateway, um Mitarbeitenden, Dienstleistern oder Administratoren einen kontrollierten Zugriff auf interne Systeme zu ermöglichen. Technisch ist das oft historisch gewachsen, gut integriert und im Alltag bewährt. Gleichzeitig ist klar: Ein direkt aus dem Internet erreichbares Remote Desktop Gateway gehört zu den besonders schützenswerten Komponenten der Infrastruktur.
Eine pragmatische Möglichkeit, die bestehende Umgebung nicht sofort ablösen zu müssen und dennoch deutlich besser abzusichern, ist die zusätzliche Veröffentlichung über den Microsoft Entra Application Proxy – früher häufig als Azure AD Application Proxy bezeichnet.
Warum das klassische Remote Desktop Gateway ein Risiko sein kann
Das Remote Desktop Gateway ist dafür gedacht, RDP-Verbindungen von außen in interne Umgebungen zu vermitteln. Genau deshalb steht es häufig an einer sicherheitskritischen Stelle: Es ist von außen erreichbar und dient als Einstiegspunkt in interne Ressourcen.
Typische Herausforderungen sind:
- exponierte RDS-/RD-Gateway-Endpunkte im Internet
- Abhängigkeit von Benutzername und Passwort, wenn keine starke Zusatzabsicherung vorhanden ist
- erhöhte Attraktivität für Brute-Force-, Phishing- oder Credential-Stuffing-Angriffe
- schwierige Durchsetzung moderner Zugriffsregeln wie Conditional Access, Gerätestatus oder MFA
Das bedeutet nicht, dass Remote Desktop Gateway grundsätzlich unsicher ist. Es bedeutet aber: Der direkte externe Zugriff sollte heute möglichst nicht mehr allein auf klassischen Netzwerk- und Passwortmechanismen beruhen.
Der bessere Ansatz: RD Gateway hinter Microsoft Entra Application Proxy
Microsoft beschreibt selbst ein Szenario, bei dem Remotedesktopdienste über den Microsoft Entra-Anwendungsproxy veröffentlicht werden. Dabei werden die webbasierten RDS-Endpunkte wie RD Web und RD Gateway über den Application Proxy bereitgestellt, sodass der externe Zugriff zuerst über Microsoft Entra ID läuft.
Der entscheidende Vorteil: Die bestehende RDS-Infrastruktur kann weiter genutzt werden, aber der externe Zugriff wird um eine moderne Identitäts- und Zugriffsschicht ergänzt.
Vereinfacht sieht das Zielbild so aus:
Benutzer extern
↓
Microsoft Entra ID / Conditional Access / MFA
↓
Microsoft Entra Application Proxy
↓
Application Proxy Connector im internen Netzwerk
↓
RD Web / RD Gateway / interne RDS-Ressourcen
Der Application Proxy verwendet einen Connector im internen Netzwerk. Dieser Connector baut ausgehend die Verbindung zum Microsoft-Clouddienst auf; laut Microsoft müssen dafür keine eingehenden Verbindungen zur internen Umgebung geöffnet werden.
Was bringt die zusätzliche App-Proxy-Instanz?
Durch die zusätzliche Instanz vor dem bestehenden Remote Desktop Gateway entsteht eine zweite Schutzebene. Der Zugriff endet nicht mehr direkt am RD Gateway, sondern wird zunächst über Microsoft Entra ID geprüft.
Dadurch lassen sich moderne Sicherheitsfunktionen nutzen, zum Beispiel:
- Multi-Faktor-Authentifizierung vor dem Zugriff auf RDS
- Conditional Access, etwa abhängig von Benutzergruppe, Standort, Risiko oder Gerätestatus
- zentrale Protokollierung und Auswertung der Zugriffe in Microsoft Entra
- kein direkter eingehender Zugriff auf interne Anwendungen über klassische Firewall-Veröffentlichungen
- schrittweise Modernisierung, ohne die bestehende RDS-Landschaft sofort komplett umzubauen
Microsoft hebt hervor, dass lokale Anwendungen über den Application Proxy mit Microsoft Entra ID, Conditional Access und MFA abgesichert werden können.
Typischer Umsetzungsweg
In der Praxis besteht die Einführung meist aus mehreren Schritten:
-
Bestehende RDS-Umgebung analysieren
Zunächst sollte geprüft werden, welche RDS-Komponenten im Einsatz sind: RD Web Access, RD Gateway, Session Hosts, Zertifikate, externe URLs und aktuelle Firewall-Regeln. -
Microsoft Entra Application Proxy vorbereiten
Danach wird der Application Proxy im Microsoft-Entra-Tenant aktiviert und ein Private Network Connector auf einem internen Server installiert. -
RD Web und RD Gateway veröffentlichen
Microsoft beschreibt, dass bei diesem kombinierten Szenario die webseitigen RDS-Endpunkte veröffentlicht und der RDS-Datenverkehr anschließend über den Application Proxy geleitet werden. -
Vorauthentifizierung aktivieren
Für den externen Zugriff sollte Microsoft Entra ID als Vorauthentifizierung genutzt werden. Erst nach erfolgreicher Anmeldung, MFA und Conditional-Access-Prüfung wird der Zugriff zur internen RDS-Umgebung weitergeleitet. -
Conditional Access sauber definieren
Empfehlenswert sind Regeln wie MFA-Pflicht, Einschränkung auf bestimmte Benutzergruppen, Blockieren riskanter Anmeldungen und optional Anforderungen an verwaltete Geräte. -
Alte direkte Veröffentlichungen reduzieren
Sobald der Zugriff über den Application Proxy stabil läuft, sollte geprüft werden, ob direkte externe Firewall-Veröffentlichungen des RD Gateways entfernt oder deutlich eingeschränkt werden können.
Wichtige Einschränkungen
Der Application Proxy ist kein vollständiger Ersatz für ein sauberes RDS-Sicherheitskonzept. Er ergänzt es.
Weiterhin wichtig bleiben:
- aktuelle Windows-Server- und RDS-Patches
- starke Zertifikate und saubere TLS-Konfiguration
- eingeschränkte Benutzer- und Adminrechte
- Netzwerksegmentierung
- Logging und Monitoring
- regelmäßige Überprüfung der veröffentlichten RDS-Ressourcen
Außerdem weist Microsoft darauf hin, dass der Application Proxy vor allem für Remotezugriffe gedacht ist und nicht unnötig für Benutzer im internen Unternehmensnetz verwendet werden sollte, da dies zu unerwarteten Performanceeffekten führen kann.
Fazit
Wer noch ein Microsoft Remote Desktop Gateway im Einsatz hat, muss dieses nicht zwangsläufig sofort ablösen. Eine sinnvolle Zwischen- oder Zielarchitektur kann sein, den externen Zugriff zusätzlich über den Microsoft Entra Application Proxy abzusichern.
Damit bleibt die bestehende RDS-Infrastruktur nutzbar, erhält aber eine moderne Zugriffsschicht mit Microsoft Entra ID, MFA und Conditional Access. Besonders für Unternehmen, die historisch gewachsene Remote-Desktop-Umgebungen betreiben, ist das ein pragmatischer Schritt: weniger direkte Angriffsfläche, bessere Kontrolle und ein klarer Weg hin zu moderner Identitätssicherheit.