Lokale Apps mit Hilfe des Azure AD App Proxy für externe Nutzer verfügbar machen
Der Azure AD Anwendungsproxy ist ein im Azure Portal konfigurierbarer Azure-Dienst mit dessen Hilfe du einen extern erreichbaren öffentlichen HTTP/HTTPS-Endpunkt in der Azure-Cloud veröffentlichst, der im Hintergrund eine Verbindung mit einer internen Anwendungsserver-URL deiner Organisation herstellt. Auf diese Art veröffentlichte lokale Web-Apps lassen sich per SSO ins Azure AD integrieren, sodass auf gleicher Weise auf sie zugegriffen werden kann, wie auf Microsoft 365 und andere SaaS-Apps. Wie das geht, zeigt dieser Beitrag.
Funktional besteht der Service aus einem in der Cloud ausgeführten Anwendungsproxydienst, sowie einem auf dem jeweiligen lokalen Server zu installierenden Anwendungsproxy-Connector und dem Identitätsanbieter Azure AD selbst. Externe Benutzer (solche, die sich nicht in deinem Unternehmensnetzwerk befinden, aber ein Konto in deinem Azure AD besitzen) können nach dem Anmelden mit einer Anzeige-URL oder über das Portal „myapplication.microsoft.com“ von PCs oder Macs aus auf lokale Web-Anwendungen zugreifen.
Azure AD Anwendungsproxy & Webanwendungen
Der Anwendungsproxy funktioniert mit Web-Anwendungen, die zur Authentifizierung die integrierte Windows-Authentifizierung verwenden (IWA), Web-Anwendungen mit formularbasiertem oder headerbasiertem Zugriff sowie SAML-Authentifizierung, von dir veröffentlichte Web-APIs, hinter einem Remotedesktopgateway gehostete Anwendungen sowie Rich-Client-Apps, die in die Microsoft Authentication Library (MSAL) integriert sind. Damit erlaubt der Anwendungsproxy beispielsweise Remotezugriff und SSO für Remotedesktop, SharePoint-Websites, Tableau, Qlik, OWA und viele deiner branchenspezifischen Anwendungen. Folgende Abbildung zeigt, wie die Azure AD-Authentifizierungsdienste und der Anwendungsproxy SSO für lokale Apps für Benutzer bereitstellen.
Entscheidend ist hierbei der Endpunkt. Hierbei handelt es sich um eine externe URL (sofern Benutzer außerhalb deines Netzwerks auf Anwendungen zugreifen) oder ein Benutzer-Portal bei einem internen Zugriff. Sobald so ein Benutzer einen dieser Endpunkte erreicht, authentifiziert er sich in Azure AD und wird mit Hilfe des Connectors an die lokale Anwendung weitergeleitet.
Letzterer ist ein einfacher, auf einem Windows-Server innerhalb deines Netzwerks ausgeführter Agent, der die Kommunikation zwischen dem Anwendungsproxydienst in der Cloud und der lokalen Anwendung verwaltet und zwar ausschließlich über ausgehende Verbindungen, das heißt, der Connector baut dann von „innen“ heraus über HTTP oder HTTPS eines Tunnel auf.
Hat der Benutzer über den Endpunkt auf die Anwendung zugegriffen, wird er an die Azure AD-Anmeldeseite weitergeleitet (1), wobei je nach Konfiguration Azure AD Conditional Access sicherstellt, dass das nur unter ausgewählten Bedingungen funktioniert. Bei erfolgreicher Anmeldung sendet Azure AD ein Token an das Client-Gerät des Benutzers (2) und der Client sendet das Token weiter an den Anwendungsproxy-Dienst (3), der dann den UPN (User Prinzipal Name) und den SPN (Security Principal Name) aus dem Token extrahiert. Anschließend leitet der Anwendungsproxy die Anforderung an den lokalen Connector (4), der jede weitere Authentifizierung durchführt, die für den Benutzer unter Umständen erforderlich ist (anhängig von der Authentifizierungsmethode) und dann den internen Endpunkt des Anwendungsservers anfordert, um die Anforderung an die lokale Anwendung zu senden (5). Danach schickt der Connector die Antwort des Anwendungsservers an den Anwendungsproxydienst zurück (6) und dieser leitet die Antwort an den Nutzer weiter.
Azure AD Anwendungsproxy: Die Vorteile
Die Vorteile sind immens: Mit der durch den App Proxy durchgeführten „Vor-Authentifizierung“ ist ohne gültiges Token kein Datenverkehr durch den Anwendungsproxydienst zur lokalen Umgebung erlaubt. Das blockiert eine große Anzahl zielgerichteter Angriffe. Mit dem App Proxy kannst du auch solche lokalen Apps mit dem bedingten Zugriff von Azure AD, bzw. allgemein der starken Authentifizierung von Azure AD ausstatten, die das von sich aus gar nicht unterstützten würden. Da keine eingehenden Verbindungen existieren, besteht auch keine Notwendigkeit, Firewall-Ports für eingehende Verbindungen oder Komponenten in der DMZ zu öffnen. Alle Verbindungen sind ausgehende Verbindungen über einen sicheren Kanal. Netter Nebeneffekt ist, dass der gesamte Datenverkehr zur Back-End-Anwendung im Anwendungsproxydienst selbst in der Cloud terminiert wird, während die Sitzung mit dem Back-End-Server wiederhergestellt wird. Der Back-End-Server ist also gar nicht für direkten HTTP-Datenverkehr zugänglich. Du kannst mit dem App Proxy auch solche Anwendungen SSL-gesichert betreiben, die SSL gar nicht unterstützten, was dich wiederrum besser vor DoS-Angriffen schützt.
Azure AD Anwendungsproxy: Lokale Test-Anwendung bereitstellen
Für einen einfachen Test stellen wir eine lokale Web-Anwendung in Form eines WordPress-Blogs zur Verfügung. Am schnellsten und einfachsten funktioniert das mit Docker. Da WordPress als PHP-Anwendung eine MySQL-Datenbank benötigt, bedienen wir uns zu diesem Zweck einer fertigen Docker-Compose-Konfiguration mit je einem Container für die PHP-App und die Datenbank. Sofern bei dir Docker installiert ist, besorge dir vom öffentlichen Docker-Hub das WordPress-Image von Bitnami.
docker pull bitnami/wordpress
Die zugehörige Docker-Compose-Datei zum einfachen Bereitstellen findest du auf GitHub.
curl -sSL https://raw.githubusercontent.com/bitnami/containers/main/bitnami/wordpress/docker-compose.yml > docker-compose.yml
Bearbeite vor der Bereitstellung ggf. die Docker-Compose-Datei und passe das Port-Mapping an deine Verhältnisse an. In unserem Fall ersetzen wir in Zeile 18 und 19 den Host-Port 80 durch 8080 (um nicht mit anderen Web-Anwendungen auf den Host zu „kollidieren“ und den Host-Port 443 durch 8443. Die Bereitstellung des Containers-Paars erfolgt dann mit
docker-compose up -d
Teste deine Web-Anwendung zunächst lokal, hier durch Aufruf von http://ws1:8080 oder https://ws1:8443, wobei „w1“ in unserem Beispiel der Host-Name ist.
Application Proxydienst in Betrieb nehmen
Wenden wir uns nun der Inbetriebnahme des App Proxy zu. Initial aktiviert werden muss das Feature im Azure „Portal / Azure Active Directory“ unter „Anwendungsproxy“. Hier kannst du wahlweise den „Connectordienst herunterladen“ und eine neue „App konfigurieren“.
Lass dich nicht von der Meldung „Der Anwendungsproxy ist für Ihren Mandanten zurzeit deaktiviert“, sowie der Tatsache irritieren, dass die Schaltfläche „Anwendungsproxy aktivieren“ ausgegraut ist. Du musst erst auf mindestens einem Gerät den Connector installieren. Darüber hinaus setzt das Feature eine Azure AD Premium P1- oder P2-Lizenz voraus.
Öffne nun das Azure-Portal auf dem Windows-Server, auf dem du den Connector installieren möchtest (es muss ein „Server“ sein), klicke auf „Connectordienst herunterladen“ und dann auf „Bedingungen akzeptieren und herunterladen“. Optional kannst du direkt auf „App konfigurieren“ klicken und dort auf „Anwendungsconnector herunterladen“. Der Setup-Prozess der Installation ist selbsterklärend.
Nach der Installation kannst du eine lokale App, die den o. g. Voraussetzungen entspricht, im Dialog „Fügen Sie Ihre eigene lokale Anwendung hinzu“ über den Proxydienst verfügbar machen. Dazu benötigst du im einfachsten Fall einen Namen und eine „interne URL“ (dazu muss lokal ein DNS-Name konfiguriert sein), aus der die externe URL abgeleitet wird. Die interne URL ist diejenige deiner lokalen Web-Anwendung. Diese muss vom Server aus erreichbar sein, der den Agenten ausführt. Bei „Vorauthentifizierung“ übernimmst du den Default-Eintrag „Azure Active Directory“, um in jedem Fall von der starken AzureAD-Authentifizierung zu profitieren, insbesondere dann, wenn die lokale Anwendung hier Schwächen aufweist.
Damit ist aber nur sichergestellt, dass du bei der Anmeldung mit einem Azure-AD-Unternehmenskonto bis zur eigentlichen App durchkommst, aber nicht notwendigerweise, dass du dich erfolgreich bei der App authentifizieren kannst, die ja eventuell weitere Anforderungen hat. In unserem bisherigen Beispiel handelt es sich ja ohnehin nur über eine allgemein zugängliche Web-App, „ohne Authentifizierung“, welche du bei dieser Gelegenheit jetzt mit einer vorgelagerten Azure-AD-Authentifizierung ausgestattet hast. Wir werden im Verlauf eine weitere App mit Authentifizierung bereitstellen. In der Regel wirst du ja auch SSO realisieren wollen. Dazu unten mehr. Optional wäre hier noch der Eintrag „Passthrough“, womit du aber auf alle Vorteile der Azure AD-Vorab-Authentifizierung verzichtest.
Wenn du möchtest, kannst du dir bereits die veröffentlichte „Externe URL“ für einen ersten Test notieren. Das musst du aber nicht, denn diese findest du später auch in der Konfiguration der neuen „Unternehmensanwendung“ im Azure AD wieder, welche nun mit „Erstellen“ zusammen mit der zugehörigen App-Registrierung generiert und der Anwendungsproxydienst im Azure AD aktiviert wird. Auf der Connectors-Seite findest du eine neue Connectorgruppe mit dem Namen „Default“ mit einem konfigurierten Connector auf dem angegebenen Windows Server.
Dies darf und sollte kein Domain Controller sein, wie in der Abbildung. Dieser dient im Beitrag lediglich zur Vereinfachung der Demo-Umgebung. Die hier angezeigte öffentlich IP-Adresse ist diejenige, über die der Connector nach „außen“ kommuniziert. In einer NAT-Umgebung z. B. hinter einer Fritzbox handelt es sich um die öffentliche IP-Adresse des Routers. Du kannst und solltest mehrere Connectors auf mehreren Servern bereitstellen, um einen Single-Point-of-Failure zu vermeiden. Microsoft empfiehlt 2 davon.
Nach dem Hinzufügen einer lokalen Anwendung findest du im Azure AD unter „Unternehmensanwendungen“ eine neue „Unternehmensanwendung“ sowie die zugehörige App-Registrierung. Suche jetzt deine neue lokale Unternehmensanwendung.
Von der Übersichtsseite aus kannst du dieser App jetzt z. B. einen ersten Benutzer zuweisen oder die oben erwähnten Features konfigurieren wie SSO oder den Bedingten Zugriff.
Wir wechseln jetzt zunächst der Kontrolle halber zum Untermenü „Anwendungsproxy“. Hier findest du deine bei der Bereitstellung konfigurierte „Interne URL“ wieder, sowie die „externe URL“ mit dem Default-Suffix …-<aad-domain-name>.msappproxy.net>. Du kannst optional einen deiner registrierten benutzerdefinierten Domain-Namen als Suffix verwenden.
Außerdem findest du hier noch einmal die Einstellungen zur Vorauthentifizierung, die zugehörige Connector-Gruppe und ggf. das SSL-Zertifikat. Von hier aus hast du ebenfalls die Möglichkeit, die Anwendung zu testen.
Wechsele nun erneut unter „Azure Active Directory / Unternehmensanwendungen“ zu Ddeiner App (hier „Local-Wordpress) und dort zu „Eigenschaften“. Hier ist zu erkennen, dass zunächst einmal der Schiebeschalter bei „Aktiviert für die Benutzeranmeldung“ per Default auf „Ja“ eingestellt ist. Das bedeutet schlicht und einfach, dass der Zugriff auf diese App nur für diejenigen Benutzer funktioniert, welche diese App zugewiesen haben. Sie funktioniert für niemanden sonst, auch nicht für Benutzer, die in deinem Azure AD generell vorhanden sind. Dies dürfte bei den meisten Unternehmen auch so gewünscht sein. Würdest du den Schalter auf „Nein“ setzen, hätte niemand in deiner Organisation Zugriff, selbst die Benutzer nicht, die diese App explizit zugewiesen haben.
Es gibt zwei Wege, diese App explizit Benutzern oder Gruppen zuzuordnen. Entweder du benutzt dazu die „Übersicht“-Seite deiner Unternehmensanwendung und dort den ersten Eintrag „Benutzer & Gruppen zuweisen“ oder du wechselst in deiner Unternehmensanwendung zu „Benutzer und Gruppen“ und weist dort den oder die berechtigen Benutzer und oder Gruppen zu.
Zum Verifizieren kannst du in das Blade des betreffenden Users der Azure-AD-Benutzerverwaltung und dort zu „Anwendungen“ wechseln, um alle dem Nutzer zugewiesenen Unternehmensanwendungen anzuzeigen.
Navigiere jetzt wieder zurück zum Blade „Eigenschaften“ deiner WordPress-Unternehmens-Anwendung. Teste die Erreichbarkeit deiner lokalen Anwendung aus dem Internet z. B. mit Hilfe der „Externen URL“. Verwende dazu ein privates Browserfenster oder einen anderen Browser, jedenfalls eine Sitzung, in der du noch nicht gegen Azure AD authentifiziert bist. Dabei solltest du zunächst die Azure-AD-Authentifizierung durchlaufen und dann auf dem eben bereitgestellten WordPress-Blog landen; achte auf die URL. Der Zugriff kann übrigens nicht nur durch direkte Navigation zur Anwendungs-URL (Externe URL) erfolgen (hier: “ https://localwordpress-ditde.msappproxy.net/ “ …,
… sondern auch über die hier angezeigte „URL für den Benutzerzugriff“ (hier: „https://localwordpress-ditde.msappproxy.net/“ in der Form https://launcher.myapps.microsoft.com/api/signin/f9ec4304-21b5-4155-b6c1-38248b234bda?tenantId=c0b16408-5768-474a-a327-3f8b7a35972f, welche „nach“ erfolgter AAD-Authentifizierung automatisch zur „URL für den Benutzerzugriff“ auflöst oder über das Portal „Meine Apps“(https://myapplications.microsoft.com).
Es gibt in den Eigenschaften deiner Unternehmensanwendung einen weiteren Schalter mit dem Titel „Zuweisung erforderlich“, der per Default auf „Ja“ steht. In diesem Fall „muss“ der Benutzer diese Anwendung vorher wie beschrieben zugewiesen bekommen haben, bevor er darauf zugreifen kann. Bei „Nein“ könnten sich alle Benutzer deiner Organisation anmelden, sogar andere Apps und Dienste könnten das Zugriffstoken abrufen. Diese Option wirkt sich allerdings nicht darauf aus, ob eine Anwendung im Portal „Meine Apps“ (myapplications.microsoft.com) sichtbar ist. Soll sie dort erscheinen, muss die Anwendung zwingend einem Benutzer oder einer Gruppe zugewiesen sein. Wirksam ist die Option zudem nur für Apps, die in der Unternehmensanwendung unter „Einmaliges Anmelden“ einen der folgenden SSO-Modi konfiguriert haben: SAML, OpenID Connect, OAuth 2.0 oder WS-Verbund für die Benutzeranmeldung, bzw. für Anwendungsproxy-Anwendungen mit aktivierter Azure AD-Vorauthentifizierung sowie Anwendungen oder Dienste, für die andere Anwendungen oder Dienste Zugriffstoken anfordern. Die Option hat keine Auswirkungen auf den Zugriff der Benutzer auf die App, wenn die Anwendung für einen der anderen Modi für Single Sign-On konfiguriert ist. Wir haben für unsere WordPress-Demo-App bisher keinen SSO-Modus konfiguriert, da das Blog selbst ja keine Benutzeranmeldung erfordert. Direkt darunter gibt es noch die Option „Für Benutzer sichtbar“.
Das ist genau die Option, die dafür verantwortlich ist, dass die zugewiesenen Benutzer die Anwendung in „Meine Apps“ und im O365-App-Startfeld sehen. Mit „Nein“, können zugewiesene Benutzer die App immer noch über die direkte URL zugreifen. Schließlich kannst du oben noch ein individuelles Logo für deine App festlegen.
Du hast zwar jetzt erfolgreich eine lokale Web-Anwendung extern verfügbar gemacht und den Vorgang sogar mit einer vorgeschalteten Azure-AD-Authentifizierung verknüpft, allerdings erfordert diese App, da es sich um ein Blog handelt, gar keine Authentifizierung auf Anwendungsseite. Um auch diesen Fall noch zu demonstrieren, erzeugst du auf die gezeigte Art und Weise eine zweite Web-Anwendung mit der lokalen URL http://ws1:8080/wp-admin/, welche den Zugriff auf die Konfigurationsoberfläche von WordPress zur Verfügung stellt, die natürlich eine Authentifizierung mit einem WordPress-User erfordert. Diesen (per Default „wp-admin“) konfigurierst du in der Regel im Verlauf der initialen WordPress-Bereitstellung. Der Nutzer wird in der unterliegenden MySQL-Datenbank gespeichert. Theoretisch könntest du hier auf Single Sign On (SSO) umstellen, was aber bei WordPress etwas aufwendig ist. Hier soll das Interface nur als Beispiel dienen.
Weise auch dieser App einen Azure-AD-Benutzer für die Vor-Authentifizierung zu und teste die App über die „URL für den Benutzerzugriff“ in einer privaten Browser-Sitzung.
Azure AD Anwendungsproxy: Das Ergebnis
Dass das Ergebnis in diesem Fall optisch etwas „unschön“ aussieht, liegt in diesem Fall an WordPress selbst, denn WordPress verwendet die einmal erkannte oder eingestellte IP-Adresse auch beim Ausliefern von Content, d. h. im Quellcode ist immer noch die eigentliche „interne“ IP-Adresse hart verdrahtet, die von außen natürlich auch durch den App Proxy nicht erreichbar ist. Das könnte man in der Praxis entsprechend korrigieren, allerdings handelt es sich hier ja nur um eine Demo.
Interessanter ist das Konfigurieren einer entsprechend „geeigneten“ Anwendung für Single Sign On (SSO) sowie die Kombination mit dem bedingten Zugriff (Conditional Access), aber diesem Thema wenden wir uns in einem Folgebeitrag zu.
Kontakt
„*“ zeigt erforderliche Felder an
powered by Borlabs Cookie