Azure AD Application Proxy: Funktionsweise, Installation des Connectors und Vergleich mit klassischen Reverse Proxys

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.

Azure AD Application Proxy im Vergleich mit klassischem Load Balancing

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.

Voraussetzungen für Azure AD Application Proxy:

  • Basic- oder Premium-Abonnement für Microsoft Azure AD, sowie ein Azure AD-Verzeichnis, für das man als globaler Admin agiert.
  • Windows Server 2012 R2 oder höher, auf dem der Anwendungsproxy-Connector installiert werden soll. Dieser Server muss eine Verbindung zum Anwendungsproxydienst in der Cloud und zu den unternehmensinternen Anwendungen herstellen können.
  • Ausgehende Ports 80 und 443 in der Firewall müssen offen sein.
  • Um die Zertifikate überprüfen zu können, muss der Zugriff auf folgende vier URLs möglich sein: mscrl.microsoft.com:80, crl.microsoft.com:80, ocsp.msocsp.com:80 und www.microsoft.com:80
  • Um den Connector zu registrieren müssen zusätzlich die beiden Adressen login.windows.net und login.microsoftonline.com erreichbar sein.

Traffic Flow:

  1. Der User greift auf die Anwendung über den Application Proxy Service zu und wird zur Azure AD Anmeldeseite geleitet ums sich zu authentifizieren. (Möglich sind SSO mit Corporate Device; SSO für interne Anwender, alle Azure AD Authentifizierungsmethoden, wie Föderation mit ADFS oder Passthrough etc…)
  2. Nach erfolgreicher Anmeldung wird ein Token generiert und zum Client Device geschickt.
  3. Der Client schickt den Token zum Application Proxy Service, der sich den User Principal Name (UPN) und den Security Principal Name (SPN) vom Token ausliest, um daraufhin die Anfrage an den Application Proxy Connector zu leiten.
  4. Bei konfiguriertem Single-Sign-On kümmert sich der Connector um die weiteren für den User nötigen Authentifizierungen.
  5. Der Connector sendet die Anfrage zur On-Prem-Application.
  6. Die Antwort wird über den Application Proxy Service und den Connector zum User geschickt.

Vorteile

Simpel:

Einfache Integration, meist keine Änderungen an den Apps nötig.
Automatisches Scaling des Application Proxy Service; die Connectoren müssen händisch hinzugefügt werden.

Sicher:

Authentifizierung und Authentifizierung beim AAD inkl. dessen Analytics.
Keine Inbound Firewall.
„Remote as a Service“

  • Cloud Methoden zum Identity Schutz sowie DDOS-Schutz.

Client Cert Outbound Connection vom Connector zum Azure AD.

Günstig:

Insofern man bereits AAD benutzt.

Nachteile:

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).

Unterschied zwischen Frontend- und Backend-Authentication

Frontend:

  • Alle AAD Methoden (inkl. Conditional Access und MFA) wie Passthrough, Föderation usw. werden unterstützt.

Backend:

  • Kerberos Constrained Delegation (KCD).
  • Header based: Benötigt 3rd Party Tool PingAccess (und zugehörige Lizenzen, 20 Anwendungen frei für Azure Premium-Kunden), welches die Token vom AAD in Header umwandeln kann (vergleichbar mit dem Basic Authorization Header).
  • Password Vaulting (Für Apps, die nur form based können): Einmalige Anmeldung per Hand, woraufhin die Credentials im AAD gespeichert werden können und ein Browser PlugIn diese künftig zum SSO verwenden kann.
  • Oder auf Wunsch auch kein SSO.

Kurzer Exkurs zu Kerberos Constrained Delegation (KCD)

  1. Der User verwendet die URL um die On-premises Anwendung über den Application Proxy aufzurufen.
  2. Der Application Proxy leitet die Anfrage zum Azure AD Authentication Service zur Präauthentifizierung weiter. Zu diesem Zeitpunkt wendet Azure AD alle anwendbaren Authentifizierungs- und Autorisierungsrichtlinien an, wie zum Beispiel die Multifaktor-Authentifizierung. Wurde der User erfolgreich validiert, erzeugt Azure AD einen Token und schickt ihn zum User.
  3. Der User übergibt den Token an den Application Proxy.
  4. Der Application Proxy bestätigt den Token und holt sich den User Principal Name (UPN) und sendet daraufhin die Anfrage, den UPN und den Service Principal Name (SPN) an den Connector über einen doppelt authentifizierten (client certificate authentication), sicheren Kanal.
  5. Der Connector stößt eine Kerberos Constrained Delegation (KCD) Aushandlung mit dem On-premises AD an, der sich als Benutzer ausgibt, um ein Kerberos-Token an die Anwendung zu übergeben.
  6. Active Directory sendet den Kerberos Token für die Anwendung an den Connector.
  7. Der Connector sendet die Original-Anfrage zum Application-Server und benutzt dazu den vom AD empfangenen Kerberos Token.

Die Anwendung schickt ihre Antwort an den Connector, welche zum Application Proxy Service und schließlich zum User zurückgeschickt wird.

Wie geht man mit internen URLs um?

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.

Connector Einrichten und On-premises Application publishen:

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:

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp

Blog-Post teilen

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on whatsapp
WhatsApp

Neueste Beiträge

Das könnte Sie auch interessieren