Azure AD Application Proxy

Jede Firma hat irgendwelche Webseiten oder Webservices, die sicher veröffentlicht werden müssen. Anstatt sich selbst im Reverse Proxy, öffentliche IP-Adresse, Zertifikat, MultiFaktor-Auth und DoS-Attacken zu kümmern, kann diese Funktion auch Azure übernehmen. Der Azure AD Application Proxy ist vermutlich bei den Administratoren die am wenigsten bekannte Möglichkeit. Es ist Zeit das zu ändern. Denn auch wenn Microsoft die Zusammenhänge und selbst die Konfiguration selbst sehr ausführlich dokumentiert hat, sind Kunden immer wieder überrascht, wenn ich ihnen diese Funktion von Azure vorstelle.

Funktionsweise

Ehe ich die technischen Schritte erläutere, möchte ich eine Lanze für den Azure AD Application Proxy brechen, denn damit können speziell mittlere und kleine Firmen selbst lokal bereit gestellte Webseiten einfach und vor allem Sicher im Internet und für Partner veröffentlichen. Das gilt nicht nur für neue Dienste sondern quasi für jeden Webservice, der auch heute schon On Premises betrieben wird. Ob ein Service im Internet diesen Dienst nutzt, können Sie entweder direkt an der Adresse oder einem CNAME erkennen. Microsoft nutzt die Domain "msappproxy.net" für die Veröffentlichung und wenn Sie einen eigenen Namen nutzen, dann reicht ein CNAME auf diese Adresse. Also muss ich mal schnell die Funktion erklären. Der Service bietet nämlich durchaus etwas mehr als nur ein HTTP-Reverse Proxy, wie es auch heute schon jede bessere Firewall kann.

Die Komponenten sind schnell aufgeführt:

  1. Der Webservice ...
    ... steht wie bisher im internen LAN und ist aus dem Internet nicht erreichbar. Er sollte natürlich dennoch per HTTPS erreichbar sein aber das Zertifikat kann notfalls auch "Self Signed" sein. Besser ist natürlich ein richtiges Zertifikat, denn auch interne Clients sprechen vielleicht den Services von intern direkt an.
  2. On Premises Connector
    Auf einem Server im LAN wird der Azure AD Proxy Connector installiert. Dieser Windows Dienst baut dann von intern eine ausgehende Verbindung zu Azure auf und wartet auf Anfragen durch Azure, die er dann intern an die verschiedenen Webserver weiterreichen kann. Die eigene Firewall muss also weder Reverse-Proxy spielen noch benötigen Sie öffentliche IP-Adressen oder Zertifikate
  3. Azure AD App Proxy
    Dies ist eigentlich "nur" eine Konfiguration in Azure AD, mit der sie einen Service im Internet freigeben und über den bereits installierten Connector zu einem internen Server verbinden. Der AzureAD App Proxy ist der Schlüssel, denn hier können Sie nicht einfach nur die Zugriffe durchreichen, sondern auch eine Authentifizierung gegen ihre eigenes AzureAD oder sogar gegen alle Azure AD Tenants durchführen lassen. Sie können auch die Benutzer und Gruppen schon hier beschränken, die den Dienst überhaupt nutzen dürfen und über Conditional Access noch weitere Kriterien umsetzen.
  4. Der Client
    Der Nutzer des veröffentlichten WebService kann ein Browser im Internet aber auch im Intranet sein. Es kann ein anonymer Client oder ein Firmen-System sein. Letztlich bestimmen Sie ja auf dem AzureAD App Proxy, ob die Anfrage durchkommt
  5. DNS-CNAME
    Sie können den Service natürlich unter "<servicename>.msappproxy.net" ansprechen. Schöner ist aber natürlich ein "sprechender Name" aus ihrer Domain. Das ist auch einfach möglich, indem Sie in ihrer DNS-Zone einen CNAME auf den von Microsoft vergebenen Namen einrichten.

Es klingt so einfach und es ist eigentlich auch so einfach.

Vorteile

Einen Teil der Vorteile habe ich schon aufgezählt aber ich möchte Sie hier noch einmal als Liste zusammenfassen.

  • Eine Ausgehende und keine Eine eingehende Verbindung
    Sie benötigen keine eingehende HTTPS-Veröffentlichung in ihrer Firewall auf einen internen Webserver. Der Connector intern macht eine ausgehende Verbindung auf. Allerdings kann das auch bedeuten, dass eine Fachabteilung mit einer eigenen Azure-Subscription über den Weg interne Dienste ohne Wissen der Firewall veröffentlicht.
  • Keine Public-IP
    Dies ist besonders interessant, wenn Sie nur wenig oder keine freie öffentliche IP-Adresse mehr haben oder ihre IP-Adresse sich doch immer mal wieder verändert. Es macht eine Verfügbarkeit aber auch einfacher, wenn sie einen Backup-Leitung eines anderen Providers haben und kein Provider-Independend Subnetz mit BGP veröffentlichen.
  • Kein öffentliches Zertifikat
    Da die Client-Verbindung
  • PreAuth, Conditional Access, MFA
    Sie können auch "Passthough" auswählen aber die Vorqualifizierung der Nutzer ist ein großer Schutz gegen Angriffe auf Konten, da Azure diese Anmeldungen schon abwehren kann
  • DDoS-Schutz
    Da ihr eigener Webserver immer hinter den Azure-Diensten verborgen ist, haben Sie einen sehr guten DoS-Schutz gleich mit eingebaut.
  • Login Tracking
    Wenn der Azure AD App Proxy die Anmeldungen vorab prüft, dann protokolliert Azure auch diese Vorgänge wie jede andere Anmeldung an einem Office 365 oder Azure Dienst. Das kann für Compliance-Anforderungen und Analysen bei Missbrauch sehr wichtig werden
  • Guest Access
    Die Preauthentifizierung ist nicht auf ihren eigenen Tenant beschränkt. Sie können auch die Anwender anderer Tenants über den Azure AD App Proxy legitimieren
  • OAUTH
    Wenn sich ein Anwender nun schon am AzureAD Ap Proxy authentifiziert hat, dann möchte man vielleicht eine zweite Anmeldung am eigentlichen Backend vermeiden. Das ist über OAUTH-Tokens  möglich. Der Azure AD App Proxy "kennt" ja nun den Benutzer und ihre Backend App ist ebenfalls in Azure AD bekannt. Dann können Sie dem Anwender auch ein passendes Token übermitteln, welches er an den Backend-Service weiterreicht. Ihre BackendApp muss also einfach nur diese Bearer-Tokens decodieren und dem Aussteller vertrauen. Immer mehr Applikationen unterstützen diese Anmeldung.

Das alles gibt es natürlich nicht "kostenfrei".

Kosten

Über die Lizenzseite von Microsoft können Sie direkt sehen, welche Lizenz sie für den Einsatz des Azure AD App Proxy benötigen


Quelle: https://azure.microsoft.com/en-us/pricing/details/active-directory/

Allerdings spreche ich bei jedem Kunden aktiv das Thema "Azure AD P1" an, da ohne diese Funktion auch kein "Conditional Access" nutzbar ist und damit jeder Anwender mit gültigem Benutzernamen und Kennwort auf jedem Client der Welt mal eben Outlook und OneDrive installieren kann und damit Firmendaten per OST-Datei oder OneDrive-Replikation auf einem ungesicherten Endgerät landen könnten. Insofern sollte jeder Office 365 Kunde auch immer Azure AD P1 mit lizenzieren. Azure AD P1 ist übrigens auch in EMS E3 und Microsoft E3 mit enthalten. Irritieren ist dann aber wieder die Anzeige im Azure Portal

Auf der einen Seite wird von AAD Premium aber auch "Basic" gesprochen, was definitiv nicht stimmen kann. Als Trial angeboten bekomme ich aber Azure AD P2 oder EMS E5 (enthält AzureAD P2) aber nicht Azure AD P1. Hier sollten Sie also ganz genau prüfen, welche Lizenz Sie kaufen.

Einrichtung Connector

Die Nutzung von Azure AD App Proxy beginnt mit der Installation des ersten Connectors auf einem Server in der Nähe ihres Dienstes. Es gibt hier verschiedene Überlegungen zu beachten hinsichtlich Netzwerklatenz, Bandbreite, Verfügbarkeit etc. Microsoft hat dazu eine nette Anleitung veröffentlicht:

Sie starten einfach im Azure Portal unter "Active Directory" und dann "Application Proxy":

Bei der Installation müssen Sie Tenant Admin sein, denn der Connector authentifiziert sich über ein Client Zertifikat am Azure AD App Proxy, welches alle 180 Tage automatisch erneuert wird. Bei der Installation kann das initiale Zertiifkat nur als Tenant Admin erstellt werden. Der Connector holt sich dann aus Azure die Konfiguration, d.h. welche Dienste er bereitstellen soll. Für eine bessere Verfügbarkeit können Sie mehrere Connectoren als "Gruppe" zusammenfassen. Dann ist es auch einfacher anstehende Updates mal schnell auszuführen. Es gibt auf dem Connector selbst als keine GUI o.ä. Aber es gibt natürlich eine PowerShell, Eventlogs und Performance Counter:

Einrichtung App Proxy

Nach dem Sie den Connector installiert haben, können Sie direkt auf dem Connector ein "Configure an App" starten:

Im dann folgenden Dialog stellen Sie die zumindest die "internal URL" ein.

Standardmäßig ist eine "Pre Authentication" am Azure AD erforderlich. Die externe URL können Sie natürlich anpassen.

Custom Domains

Im DropDown-Feld können sie jede Domain nutzen, die sie in ihrem Tenant registriert haben. Das Portal weist sie dann schon darauf hin, dass Sie natürlich den entsprechenden DNS-CNAME noch eintragen müssen aber auch, dass Sie ggfls. noch ein Zertifikat bereitstellen müssen.

Für die "Pre Authentication" muss der App Proxy ja den SSL-Tunnel aufbrechen.

Authentifizierung anpassen

Sie haben zwar nun den Connector und die App eingerichtet, aber bezüglich der Authentifizierung gibt es noch etwas zu tun, da aktuell noch niemand diese App nutzen kann. Das Portal springt aber schon auf die passende Seite, auf der Sie nun auch die Benutzer oder Gruppen zulassen müssen.

Im gleichen Zug können Sie steuern, ob die App auf dem Portal der Anwender erscheint, welche "Conditional Access"-Policy angewendet wird und welche Berechtigungen die App bekommt. Hierüber steuern sie, welche Inhalte das OAUTH-Ticket bekommt, welches später an die Applikation weitergereicht werden kann. Unter "Activity" können Sie später nachvollziehen, welche Anwender die App genutzt haben.

Single SignON

Die Enterprise Application kann so konfiguriert werden, dass Sie von den Anwendern schon eine Authentifizierung erfordert. Das macht Sinn, um schon sehr früh zu filtern aber auf der anderen Seite möchte man dem Anwender natürlich eine "doppelte" Anmeldung ersparen. Also sollten dann die erhaltenen Anmeldedaten zum Backend Server weiter gereicht werden. Dazu gibt es gleich eine ganze Menge:

Wenn die Dienste heute schon die Authentifizierung per Kerberos nutzen, dann würde ich den Weg auch für den AzureAD Application Proxy nutzen.

Damit die per Kerberos möglich ist, müssen Sie mehrere Dinge tun

  1. IIS Authentication auf "Windows Integrated"
    Gerade mit Exchange Servern wird intern gerne eine Anmeldung per "Formular" angeboten.
  2. Besorgen Sie sich den SPN des internen Servers
    Bei meinem Exchange Server ist das "HOST/ex01.msxfaq.de".  Mit ADSIEDIT oder SETSPN können Sie für das Zielsystem diesen Eintrag schnell finden
  3. Kerberos Delegation eintragen
    Dann müssen Sie im Active Directory auf dem Computerkonto der AzureAD Connectoren diese Zielserver auf der Karteikarte "Delegation" addieren
  4. SPN in AzureAD eintragen
    Zuletzt tragen Sie den SPN auch noch in der Azure AD Enterprise Application ein

Es kann einige Minuten dauern, bis all die Änderungen aktiv sind aber sollten Sie nach einer Anmeldung am Azure AD Application Proxy direkt zum Zielserver ohne weitere Anmeldung kommen. Im Fehlerfall sehen Sie bei Kerberos dann folgende Seite:

Die Links führen direkt zu den Einstellungen im Azure Portal und folgenden Seiten in der Microsoft Dokumentation

Auf die anderen Anmeldeverfahren gehe ich hier nicht weiter ein und verweise auf die Dokumentation von Microsoft.

Debugging

Auf der Fehlerseite bei Kerberos aber auch einen Link auf im Portal können Sie eine URL auslesen, mit der Sie einen "Debug-mode" aktivieren können.

Die URL ist einfach die Adresse der Application mit einem eigenen Parameter

https://servicename.msxfaq.de/?appproxy=debug

Danach sehen Sie je nach Anwendungsfall oder Fehler ausführlichere Informationen, auf die ich aber nicht weiter hier eingehe.

Einschätzung

Das war nur ein kleiner Appetithappe, um ihnen eine weitere Funktion von Azure vorzustellen, welche alle Firmen mit Azure AD P1 oder P2-Lizenz einfach so nutzen können. Schon heute können Sie die meisten internen Webseiten, die nur nach erfolgter Authentifizierung erreicht werden dürfen, einfach über diesen Weg deutlich sicherer veröffentlichen.

Wenn der Anwender noch nicht im Browser angemeldet ist, dann wird er sich natürlich beim ersten Zugriff authentifizieren müssen. Aber alle weiteren Dienste über den Azure AD App Proxy erfordern keine weitere Authentifizierung an Azure und landen direkt auf der internen Seite. Dort wird allerdings erneut nach Anmeldedaten gefragt, da eine Anmeldung per Kerberos oder NTLM so nicht möglich ist. Sobald aber die Backend-Applikation mit OAUTH umgehen kann, ist keine weitere Anmeldung erforderlich.

Ich erwarte, dass mehr und mehr Firmen im Besitz einer Azure AD P1-Lizenz sind (durch Microsoft 365 E3, EMS E3 oder Einzelkauf) und damit diese elegante Funktion für die sichere Veröffentlichung von internen Webseiten nutzen können.

Weitere Links