Der Azure Active Directory-Anwendungsproxy ermöglicht das Veröffentlichen von unternehmensinternen Anwendungen im Internet, so dass Remotemitarbeiter sicher auf sie zugreifen können. Im Vergleich mit anderen Lösungen ist er sehr kompakt aufgebaut, dafür umso einfacher einzurichten und in Betrieb zu nehmen. Nicht zuletzt ist Azure AD Application Proxy quasi kostenlos, da Bestandteil der Azure AD Subscription.
In diesem Artikel zeigen wir die allgemeine Funktionsweise und richten einen Connector ein, der zum Betrieb notwendig ist. Dabei interessiert uns im Besonderen, wie sich der Azure AD Application Proxy im Vergleich mit klassischem Load Balancing schlägt und wo er idealerweise eingesetzt wird.
Microsoft bietet uns mit dem Azure AD Application Proxy eine besonders kompakte und einfach zu administrierende Möglichkeit unternehmensinterne Webseiten und WebApps den Mitarbeitern zur Verfügung zu stellen, ohne dass dafür eine Inbound-Verbindung hergestellt werden muss. Die Kommunikation des Clients geschieht ausschließlich mit dem Application Proxy Service, der wiederum vom Connector aus dem Firmennetzwerk heraus kontaktiert wird und die Webseiten bzw. WebApps über den Application Proxy Service an den Client ausliefert. Dabei bleibt dem Client die wahre Zieladresse des angesprochenen Webservers verborgen.
Reverse Proxys, wie der Azure AD Application Proxy, funktionieren anders als klassisches Load Balancing, dienen aber ebenfalls dazu dem Nutzer von Außerhalb Zugriff auf firmeninterne Rechner zu ermöglich, allerdings ohne dafür die Firewall konfigurieren zu müssen, weil es sich um eine Outbound-Verbindung handelt. Da der Client von außen keinen direkten Zugriff auf die firmeninternen Server hat, sondern lediglich mit dem Proxy spricht, sorgt der Reverse Proxy für erhöhte Sicherheit, weil er sie quasi aus der Schusslinie nimmt.
Weitere Argumente für die Verwendung eines Reverse Proxy sind das Cachen von Inhalten. Besonders immer wieder angeforderte Inhalte, wie zum Beispiel Bilddateien, können direkt vom Proxy ausgeliefert werden, ohne die Server zu belasten. Der trotzdem noch nötige Traffic kann vom Reverse Proxy auf die Server verteilt werden. Nicht zuletzt kann er sich dem SSO annehmen. Auch SSL verschlüsselte Verbindungen können beschleunigt werden, da sich der Reverse Proxy um die Verschlüsselung kümmern kann. All dies entlastet die Webserver beträchtlich.
Der Nachteil von Azure AD Application Proxy im direkten Vergleich mit klassischem Load Balancing dürfte sicher sein, dass man auf das Load Balancing deutlich weniger, bis gar keinen Einfluss nehmen kann. Zudem beherrschen Load Balancer deutlich mehr Protokolle, als nur HTTP. Schließlich findet das klassische Load Balancing auf den OSI-Schichten 3 bis 7 statt, wohingegen ein Reverse Proxy ausschließlich das HTTP-Protokoll benutzt. Wobei man hier nicht unerwähnt lassen darf, dass es auch verschiedene hybride Lösungen auf dem Markt gibt. Nicht zuletzt schließen sich ein Reverse Proxy und Loud Balancing nicht gegenseitig aus.
Wenige Optimierungsmöglichkeiten (Cache, FEO, Rewrite … der Anwendung)
Unklares Load Balancing, wenn sich mehrere Server hinter dem Connector befinden.
Siehe: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-application-proxy-wildcard
Kein URL-Filterung (Blacklisting von speziellen Pfaden, zum Beispiel generellen Zugriff auf app01.domain.de erlauben, aber nicht auf alles unterhalb, wie app01.domain.de/geheim).
Die Anwendung schickt ihre Antwort an den Connector, welche zum Application Proxy Service und schließlich zum User zurückgeschickt wird.
Den Managed Browser nutzen: Diese Lösung ergibt nur Sinn, wenn man Usern den Zugriff auf die Anwendung über den Intune Managed Browser empfiehlt oder verlangt.
Die MyApps-Erweiterung nutzen: Diese Lösung setzt voraus, dass eine Browser-Erweiterung auf dem Client installiert wurde. Diese ist für praktisch alle populären Browser erhältlich und sie kann alle published URLs verarbeiten.
Das Link Translation Setting nutzen: Dabei handelt es sich um eine Einstellung auf der Seite des Admins, die für den User unsichtbar ist. Damit kann man HTML und CSS-URLs verarbeiten. Hard-coded interne URLS, zum Beispiel von einem Javascript erzeugt, funktionieren nicht.
Im folgenden Tutorial zeigen wir wie einfach es ist einen Connector zu installieren und mit dem Azure AD Application Proxy eine Web-App zu publishen. Ziel ist es, den Connector zu installieren, eine interne WebApp zu konfigurieren, KCD vorzubereiten und die AAD Enterprise App mit dem Application Proxy zu publishen, inkl. KCD SSO.
Zuallererst installieren wir den Connector auf unserem Zielserver. Dazu melden wir uns im Azure Portal an, wo wir ihn downloaden können. Die Installation selbst geht praktisch vollautomatisch vor sich, ohne dass eine besondere Interaktion unsererseits nötig wäre.
Als nächstes legen wir auf unserem Domain Controller einen neuen Service Account an.
Nun wenden wir uns dem Server zu, auf dem wir den IIS installieren. Dabei darauf achten, dass wir die Windows Authentication mitinstallieren, die per default nicht ausgewählt ist. Sobald dies geschehen ist, setzen wir die Identity des Application Pools im IIS Manager auf den Service Account.
In diesem Prozess setzen wir die useAppPoolCredentials auf true, was wir entweder in der GUI erledigen können:
Oder in der Shell. Diese im Administrator-Modus starten und ins Verzeichnis c:\windows\system32\inetsrv wechseln für den Befehl:
appcmd.exe set config -section:system.webserver/security/authentication/windowsAuthentication -useAppPoolCredentials:true
Als nächsten Schritt setzen wir den Service Principal Name (SPN) mit den Befehlen
setspn -a HTTP/servername domain.de\testusername
und
setspn -a HTTP/servername.domain.de domain.de\testusername
Alternativ lässt sich der SPN natürlich auch in der GUI mit dem ADSI-Editor auf dem Domain-Controller setzen:
Nun gilt es auf dem Server, auf dem der Connector läuft, dem SPN die Delegation zu erlauben:
Mit diesem Tool können wir überprüfen, ob der Connector den Anwendungsproxydienst erreicht: https://aadap-portcheck.connectorporttest.msappproxy.net/
Zusätzlich vergewissern wir uns, dass die beiden Dienste „Microsoft AAD Application Proxy Connector“ und „Microsoft AAD Application Proxy Connector Updater“ laufen.
Jetzt melden wir uns am Azure Portal als Administrator an um eine On-premises Application zu publishen:
Wir geben die Daten des internen Web-Servers ein. Dazu gehören die interne URL, mit der man innerhalb des Unternehmensnetzwerks auf die Anwendung zugreifen kann. Daraus generiert wird auch automatisch die externe URL. Unter Präauthentication geben wir das gewünschte Verfahren an, wie der Anwendungsproxy die Benutzer überprüfen soll, bevor diese Zugriff auf die Application erhalten. In unserem Fall wählen wir das Azure Active Directory (AAD). Zuletzt geben wir noch die gewünschte Connectorgruppe an, die wir vorerst auf Default belassen. Möglich ist auch Passthrough zu wählen, wenn sich die Nutzer nicht am AAD authentifizieren sollen. In diesem Fall empfehlen sich weitere Authentifizierungsverfahren am Back-End.
Berechtigen einen User für die App:
Und nehmen die SSO-Einstellungen vor. Hierbei genau auf Groß- und Kleinschreibung achten, die Eingabe ist case sensitive!
Haben wir keinen Fehler gemacht, meldet sich der Web-Server und wir haben unsere erste On-premises Web-App veröffentlicht:
MELDE DICH GERNE.
Zum detaillierter Updateprozess hast du weitere Fragen. Dann melde dich gerne bei mir
MATTHIAS BRAUN | Cloud Architekt
