Azure AD Application Proxy (AAP) hat in vielen Unternehmen während der Pandemie Einzug gehalten, um interne Anwendungen schnell und sicher daheimbleibenden Mitarbeitern zur Verfügung zu stellen. Sicherheit schafft die Integration des AppProxy mit Conditional Access, das Multifaktor-Authentifizierung (MFA) erzwingen kann und den Zugriff von vertrauten, verwalteten und als "gesund" markierten Geräten sicherstellt. Die Architektur macht Deployments einfach: Der Proxy vollzieht seine Arbeit mit ausschließlich ausgehenden Netzwerkverbindungen zur Cloud – die zentrale IT muss also keine Firewalls aufbohren [1].

Viele Anwendungen bedienen sich weiterhin einer "Vollwertclient"-Architektur, wonach der Client über besondere oder nicht offene Protokolle mit dem Backend spricht – oder das Backend nicht einfach veröffentlicht werden kann. In anderen Anwendungsfällen, gerade wenn der Client nicht auf dem Gerät des Benutzers verbleiben, sondern ebenfalls zur Verfügung gestellt werden soll, enden die Standardszenarien eines klassischen HTTP-Proxy. Ein Trick als Ausweg: Über die Veröffentlichung einer Session auf einem Session- oder VM-Host lassen sich auch ganze Anwendungen publizieren – sofern die Lösung die Session via Gateway oder Proxy per HTTPS zugänglich macht. Wer also die Citrix- oder Remote-Desktop-Umgebung via AppProxy veröffentlichen kann, ist auch in der Lage, diese Szenarien abzubilden.

Sie verändern also die Aufgabe dahingehend, als dass Sie Clients Zugang zu einem Sessionserver bereitstellen, Diesen stellen Sie möglichst einfach, mit Single Sign-on (SSO), aber natürlich geschützt zur Verfügung. Der Sessionserver erlaubt dann Zugriff auf Clients, die nicht über HTTP-Protokolle mit dem Backend sprechen müssen.

Die Umsetzung mit Microsoft-Technologie sieht dazu Remote Desktop Services (RDS) vor, die zusammen mit dem AAP, der die RDS veröffentlicht, SSO bereitstellen und mit Hilfe von Conditional Access schützen. Das erlaubt dem IT-Team neben dem komfortablen Zugriff auf die Dienste via SSO auch, mit dem Regelwerk aus Conditional Access Richtlinien zu definieren, die bekannte und für gesund empfundene Geräte oder MFA für die Verbindung erzwingen.

Im einfachsten Fall, für einen Proof-of-Concept, reicht ein Azure-AD-Tenant und ein Server, der sowohl RDS als auch den Application-Proxy-Agenten betreibt. Für eine Produktionsumgebung sollten Sie die Empfehlungen von Microsoft für die von Ihnen angestrebte Session- und Benutzeranzahl befolgen. Die Remote Desktop Services bestehen aus mehreren Rollen – für die Veröffentlichung mit AppProxy sollte der Fokus auf der RD-Web-Access-Rolle liegen, die Session-zu-HTTP-Translation übernimmt. AAP bildet für uns die Brücke zwischen Clients, die vom Home Office eine Verbindung erstellen, und dem internen Netzwerk, wo die Session-Hosts und Web Access stehen. Die Server sollten, um SSO zu ermöglichen, ebenfalls alle in einem Windows-AD Mitglied sein.

Ebenfalls auf der Beschaffungsliste: Ein TLS/SSL-Zertifikat für die RD Web App, das mit Private Key in Azure AD (AAD) und für den Remote-Desktop-Dienst zum Einsatz kommt. Wenn Sie die RD-Dienste (in unserem Workshop-Beispiel via "https://websession.contoso.com") erreichen wollen, benötigen Sie für diese Adresse das geeignete Zertifikat. Dieses nutzen Sie dann auch für die Installation der RD-Rollen auf Windows Server. Ebenso sollten Sie in der Lage sein, einen neuen CNAME für die Zieldomäne anzulegen, sodass Sie die URL der RDS zur eindeutigen Veröffentlichungs-URL, die Sie von Azure AD erhalten, umleiten können.

Für das Setup starten Sie am besten klein: In einer Testumgebung können Sie alle benötigten Serverrollen für Remote Desktop und den Application Proxy auf einem Server hinterlegen. Wenn Sie planen, das Setup danach langsam zu erweitern, können Sie auch mit mehreren Servern starten. Die RD-Web-Access- und RD-Gateway-Rolle lassen sich auf einem Server konzentrieren, während Sie die restlichen Remote-Desktop-Rollen auf einen anderen oder mehrere Server verteilen.

Sie starten das RD-Setup, indem Sie den Server Manager aufrufen und "Add roles and features" in der Übersicht auswählen. Abhängig von der Zielarchitektur wählen Sie "Standard deployment" für mehrere Server, die sich verschiedene Rollen teilen, oder "Quick Start", wonach die ersten RDS-Rollen auf einem Server landen, die RD-Gateway-Rolle aber noch nicht mit dabei ist. Fahren Sie mit "Quick Start" für ein einfaches Deployment fort, die Gateway-Rolle installieren Sie anschließend. Für die Veröffentlichung von Anwendungen, die in virtuellen Sessions geteilt werden, wählen Sie "Session-based desktop deployment".

 Ist die Basisinstallation abgeschlossen, sehen Sie auf den Zielservern im Server Manager im linken Menü "Remote Desktop Services" in "Overview" eine Grafik, die die installierten Rollen zeigt. Für "RD Gateway" und "RD Licensing" können Sie neue Server hinzufügen, während die anderen Rollen bereits installiert sind. Überprüfen Sie hier, ob alle Rollen vorhanden sind.

Ist das Gateway schon installiert, wählen Sie "Tasks" und "Edit Deployment Properties" und überprüfen, ob der Name des Servers in FQDN-Form für das selbstsignierte SSL-Zertifikat stimmt. In "Logon Method" sollten Sie sicherstellen, dass "Password Authentication" und der Haken für "Use RD Gateway credentials for remote computers" gesetzt sind. Bei einer RD-Gateway-Neuinstallation klicken Sie vor Abschluss des Dialogs auf "Configure certificates" – ist der RD Gateway schon vorhanden, überprüfen Sie in der Sektion "Certificates", ob alle SSL-Zertifikate für alle Rollen hinterlegt sind.

Für jede Rolle können Sie über die Schalter "Create new certificate…" und "Select existing certificate…" SSL-Zertifikate für die interne und externe Vertrauensstellung via SSL konfigurieren. Mit "Select existing certificate…" wählen Sie das Zertifikat im PFX-Format – also mit privatem Schlüssel – unter Angabe des Passworts aus und erlauben dessen Nutzung für die jeweilige Rolle. Das Hinzufügen des Zertifikats müssen Sie allerdings für alle Rollen wiederholen, sodass am Ende jeder Rollenzeile in der Spalte "State" "Success" steht.

Ist noch keine App für den RD-Zugriff konfiguriert, müssen Sie eine "Collection" erstellen, in der Sie die Apps veröffentlichen. Haben Sie das "Quick"-Deployment gewählt, ist das schon geschehen, inklusive Veröffentlichung von Paint und dem Taschenrechner als Beispielanwendungen. Ansonsten müssen Sie im Server Manager in "Remote Desktop Services" unter "Collections" eine neue Collection erstellen.

Wenn Sie, wie im Beispiel, intern wie extern den gleichen DNS-Namen gewählt haben, müssen Sie den Namen intern im DNS registrieren: "websession.contoso. com" sollte per CNAME auf den Namen der Maschine mit dem RD Web Access und RD Gateway zeigen.

Um die Präauthentifizierung für die Konfiguration mit dem AppProxy vorzubereiten, müssen Sie schließlich die Collection via PowerShell anpassen. Das folgende PowerShell-Kommando stellt die Collection auf Pre-Authentication um und horcht dabei auf den öffentlichen DNS-Namen, der auch vom Internet aus genutzt wird. Beachten Sie das Hochkomma zwischen der URL und dem "Require pre-authentication"-Teil:

Ist der Dienst lokal verfügbar, können Sie nun beginnen, mit dem AppProxy die Veröffentlichung nach außen zu konfigurieren. Sie haben dabei zwei Optionen: Entweder richten Sie eine einfache Veröffentlichung ein oder Sie lassen AAD eine Präauthentifizierung durchführen, mit der Sie dann weitere Regeln über Conditional Access durchsetzen.

Wenn Sie noch keinen AppProxy-Agenten in Ihrem lokalen Netzwerk installiert haben, den Sie für die Veröffentlichung nutzen können, sollten Sie im AAD-Portal (als Administrator eingeloggt) unter "Application Proxy / Download connector service" den Agenten herunterladen. Die Installationsdatei übertragen Sie entweder auf den RD-Host oder einen anderen Windows-Server, der eine Netzwerkverbindung sowohl zum Internet ausgehend als auch zum Remote-Desktop-Server hat. Nach dem Start des Installers fragt dieser Sie mit einer Logon-Maske für AAD nach Berechtigungen für die Registrierung des Connectors in der Cloud. Sie können hier einen Benutzer angeben, der der "Application Administrators"-Rolle angehört. Es muss nicht zwingend der Global Administrator sein.

Kurze Zeit nach der Installation sollten Sie, wenn Sie das Azure-AD-Portal neu laden, in "Application Proxy" nachsehen und den Agenten mit einem grünen Pfeil versehen wiederfinden. Dies zeigt Ihnen, dass die Verbindung steht. Was nun folgt, ist das Erstellen der Veröffentlichung in AAD. Klicken Sie zunächst auf "Enterprise Applications" und "+ New application". Unter der Rubrik "on-premises applications" sehen Sie den Vorschlag "Add an on-premises application", den Sie annehmen. Nun startet der Assistent für eine AppProxy-Veröffentlichung. Geben Sie den Anwendungsnamen an sowie die interne und externe URL, die ja jeweils die gleiche URL sein sollte. Im Auswahlfeld für "external URL" ist die Tenant-spezifische "<Tenant-Name>.msappproxy.net"-Domäne vorausgewählt, Sie können aber jede Domäne auswählen, für die Sie in AAD eine Domänenregistration inklusive Validierung vorgenommen haben. Damit lassen sich auch interne Domänenadressen nutzen, sofern die internen Domänen im Internet auflösbar sind. Wählen Sie schließlich "Azure Active Directory" als Option für "Pre Authentication". Die restlichen Voreinstellungen sind korrekt.

Am Ende des Dialogs sehen Sie eine Information, die besagt, dass Sie einen CNAME-Eintrag für die Zieldomäne erzeugen müssen. Dies ist zur Umleitung von "websession.contoso.com" nach "websession-contosotenant.msappproxy.net" erforderlich und vermeidet Zertifikatsfehler. Sobald Sie die AppProxy-Anwendung mit "+Add" gespeichert haben, sollten Sie diesen CNAME mit einer TTL von 3600 Sekunden im öffentlichen DNS, den die Clients außerhalb des Netzwerkes aufsuchen, anlegen. Sobald die Anwendung registriert ist, lohnt es sich, in den App-Einstellungen unter "Overview" die "Application ID" und die "Object ID" zu notieren – diese brauchen Sie gleich nochmal, falls Sie den HTML-5-Webclient veröffentlichen wollen.

In "Properties" überprüfen Sie, ob "User assignment required?" auf "Yes" steht – dann prüft das AAD vor der Präauthentifizierung, ob ein Administrator dem Benutzer die RD-Dienste zugewiesen hat und ob ein Zugriff überhaupt gewünscht ist. Sie haben nun mehrere Hebel, den Zugriff auf die Dienste einzuschränken. Sie können sowohl auf Gateway- als auch AAD-Ebene bestimmen, welche Mitarbeiter mit RD Web Access Verbindung aufnehmen dürfen. Das definieren Sie dann unter "Users and Groups".

Um den HTML-5-Webclient für Remote Desktop Services zu nutzen, der eine moderne Benutzeroberfläche für Mitarbeiter bietet und nicht mehr auf einem ActiveX-Add-in basiert, installieren Sie diesen via PowerShell auf dem RD-Web-Access-Server. Hier bietet es sich an, ebenfalls die URL anzupassen, die Sie in AppProxy freigegeben haben, damit Mitarbeiter dann automatisch auf die HTML-5-Variante weitergeleitet werden. Führen Sie für die Installation folgende PowerShell-Kommandos auf dem RD-Web-Access-Server aus:

Wenn Sie das Brokerzertifikat im dritten Schritt importieren, müssen Sie das Zertifikat Ihrer Veröffentlichung ohne privaten Schlüssel, im CER-Format, angeben. Sollten Sie "PowershellGet" noch nicht auf dem Server installiert haben, holen Sie dies zunächst nach:

Mit der initialen Freigabe in AppProxy wird eine Freigabe im Pfad "https://websession.contoso.com/RDWeb" angelegt, die automatisch immer das traditionelle Webinterface startet. Sollten Sie auf den HTML-5-Webclient umsteigen wollen, können Sie via PowerShell die URL im AppProxy umstellen. Dazu benötigen Sie das AAD-PowerShell-Modul und Application-Administrator-Berechtigungen:

Die AppID, nach der Sie suchen, ist die Application-ID, die während der AppProxy-Veröffentlichung erstellt wurde und mit dem Enterprise-Application-Objekt in "Properties" hinterlegt ist.

Anschließend passen Sie, wenn das App-Objekt die neue Homepage akzeptiert hat, das dazugehörende Enterprise-Application-Objekt an. Dafür nehmen Sie diesmal die Objekt-ID der Enterprise-Application, zum Beispiel:

Geben Sie dem AAD ein paar Minuten Zeit, um die Änderungen zu übernehmen, und testen Sie die Verbindung erneut. Dazu öffnen Sie ein Inkognito-Fenster und wechseln Sie zu"https://myapplications.microsoft.com" für einen Benutzer, der auf die RD-Dienste zugreifen können soll. Melden Sie sich mit gültigen Daten an und wählen Sie dann aus der Liste der veröffentlichten Anwendungen die RD-Dienste aus. Sie sollten (mit SSO) sofort zum HTML-5-Webclient gelangen.

Bestehende Remote-Desktop-Implementierungen lassen sich relativ einfach mit AppProxy veröffentlichen. Wichtig sind die richtigen Zertifikate und die Anpassung des internen und externen Namens für die Webkomponenten. Im Veröffentlichungsmodus "Azure Active Directory" als Präauthentifizierung ist es nun möglich, die gesamte RD-WebApp als Anwendung mit Conditional Access zu schützen. Gleichzeitig ist durchsetzbar, dass alle Mitarbeiter entweder eine Multifaktor-Authentifizierung nutzen oder alternativ von einem bekannten, gesunden Gerät arbeiten müssen, wenn sie sich mit Remote Desktop über die Veröffentlichung verbinden wollen.