Beim Azure AD-Anwendungsproxy handelt es sich um einen Clouddienst, der es auch ermöglicht Reverse-Proxy-Funktionen für Webanwendungen bereitzustellen, die On-Premises laufen. Der dient dazu als zentrale Steuerzentrale.
Der Azure AD-Anwendungsproxy kann Anfragen aus dem Internet annehmen und an interne Server weiterleiten. Dadurch werden Zugriffe sicherer und unkomplizierter, ohne dass Firewalls im Unternehmen angepasst werden müssen.
(Bild: ra2 studio - stock.adobe.com)
In vielen Unternehmen gibt es Webanwendungen, die On-Premises laufen und bei denen Anwender aus dem Internet auf die internen Dienste zugreifen sollen. Neben der Konfiguration der Firewall muss hier auch ein Rervese-Proxy zum Einsatz kommen, der die Zugriffe aus dem Internet auf diese Dienste steuert.
Das gilt parallel natürlich auch für Webdienste, die über Azure zur Verfügung gestellt werden. Azure AD-Anwendungsproxy kann ältere Webanwendungen genauso sicher im Internet bereitstellen und schützen, wie moderne WebApps On-Premises oder aus der Cloud. Auch mehrere Webanwendungen gleichzeitig sind kein Problem.
Auch On-Premises-Anwendungen profitieren vom Azure AD-Anwendungsproxy
Der Azure AD-Anwendungsproxy ist dazu in der Lage Anfragen aus dem Internet anzunehmen und an interne Server On-Premises weiterzuleiten. Dadurch werden Zugriffe sicherer und unkomplizierter möglich, da die Firewalls im Unternehmen nicht angepasst werden müssen. Die Kommunikation zwischen Clients, Azure AD-Anwendungsproxy und Webanwendungen laufen über Agenten, die auf den Zielservern installiert sind. Alle Zugriffe der Clients laufen daher über eine feste URL, inklusive Domäne, in Microsoft Azure.
Bei dem Connector des Azure AD-Anwendungsproxy handelt es sich um einen der zahlreichen Azure Hybrid-Agenten, die Funktionen aus Azure in lokale Rechenzentren bringen. Für nahezu alle dieser Agenten gilt, dass keinerlei Änderungen an den Firewalls im Unternehmen vorgenommen werden müssen, auch für den Connector des Azure AD-Anwendungsproxy.
Der Vorteil bei der Verwendung von Azure AD-Anwendungsproxy ist zunächst, dass die öffentliche IP-Adresse eines Unternehmens für eine Webanwendung nicht bereitgestellt und auch nicht öffentlich bekannt sein muss. Hier besteht die Gefahr von DoS-Attacken oder anderen Angriffen, die direkt auf die öffentliche IP-Adresse des Unternehmens zielen. Genau diese schützt der Azure AD-Anwendungsproxy.
Schutz vor DDoS-Attacken und moderne Authentifizierungsmethoden für ältere Anwendungen
Azure AD-Anwendungsproxy bringt zusätzlich noch die Möglichkeit in lokale Netzwerke eine Anmeldung an Webanwendungen über Azure AD vorzunehmen. Die eigentliche Authentifizierung erfolgt direkt am Anwendungsproxy, der die Anfragen aus dem Internet über den Agenten auf dem Server ins lokale Rechenzentrum überträgt.
Die Verbindung zwischen den veröffentlichten Diensten im lokalen Rechenzentrum und Azure AD-Anwendungsproxy laufen über einen Connector, der auf den Servern installiert wird. Über diesen Connector erfolgt die komplette Kommunikation zwischen Azure AD-Anwendungsproxy, Client und veröffentlichter Webanwendung. Die öffentliche IP-Adresse des Unternehmens wird dazu genauso wenig benötigt, wie eine Anpassung der Firewall. Gleichzeitig profitieren Unternehmen davon, dass alle Zugriffe über den Anwendungsproxy laufen. Dieser ist zuverlässig vor Malware-Angriffen und DDoS-Attacken geschützt und routet die Zugriffe der Anwender zuverlässig weiter. Der komplette Datenverkehr läuft über den Connector zum Anwendungsproxy. Es gibt keine HTTP/HTTPS-Daten, die über die Firewall laufen.
Zugriff über eigene Internetdomäne
Die Webanwendungen werden über die Domäne "msappproxy.net" bereitgestellt. Die Anwender greifen mit der festgelegten URL des Webdienstes auf Azure zu und der Azure AD-Anwendungsproxy nimmt die Anfrage entgegen, authentifiziert den Benutzer über Azure AD und leitet bei erfolgreicher Authentifizierung die Anfrage an den Webdienst On-Premises oder in Azure weiter. Hier besteht auch die Möglichkeit mit Conditional Access in Azure AD zu arbeiten, also der Überprüfung, ob sich Benutzer am jeweiligen System basierend auf ihrem Aufenthaltsort und Zeit überhaupt anmelden dürfen.
Die Kommunikation erfolgt zwischen Connector auf dem internen Server und Microsoft Azure, die Anwender kommunizieren wiederum zwischen dem Internet und Azure AD-Anwendungsproxy. Wer sich umfassender mit der Einrichtung auseinandersetzen will, findet auf der Seite „Veröffentlichen von lokalen Apps für Remotebenutzer mit dem Azure AD-Anwendungsproxy“ ausführliche Informationen über die Microsoft-Dokumentation.
So funktionieren die Zugriffe von Anwendern über den Azure AD-Anwendungsproxy
Im ersten Schritt geben die Benutzer die URL ein, die für die Webanwendung hinterlegt ist. Das kann zum Beispiel "outlookjoos.msappproxy.net" sein. Der Anwendungsproxy leitet die Anfrage zur Authentifizierung an Azure AD weiter. Wenn sich der Benutzer an Azure AD erfolgreich angemeldet hat, bekommt er ein Anmeldetoken durch Azure AD.
Die Anmeldedaten gehen an den Azure AD-Anwendungsproxy, der diese prüft und bei erfolgreicher Anmeldung die Anforderung des Zugriffs von dem jeweiligen Benutzer an den Anwendungsproxy-Connector weiterleitet. Der Connector läuft auf einem internen Server im Netzwerk. Dabei kann es sich um den gleichen Server handeln, der auch die Webanwendung bereitstellt, es kann sich aber auch um einen anderen Server handeln.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
Wenn die Authentifizierung mit SSO konfiguriert ist, authentifiziert der Connector den Anwender direkt an Active Directory. Ist kein SSO im Einsatz, muss sich der Benutzer für den Zugriff auf die Anwendung nochmal authentifizieren. In den meisten Umgebungen werden die Admins sicher mit der Active Directory-Synchronisierung zwischen AD und Azure AD arbeiten. In diesem Fall melden sich die Benutzer an Azure AD an und erhalten danach Zugriff auf die Webanwendung über den konfigurierten SSO-Zugang.
Nach der erfolgreichen Authentifizierung des Anwenders per SSO oder zusätzlicher manueller Authentifizierung an Active Directory, sendet der Connector die Anforderung des Anwenders an die Webanwendung im internen Netzwerk. Die Antwort der Webanwendung erfolgt jetzt über den Connector zum Anwender.
Praxistipps für den Einsatz des Azure AD-Anwendungsproxy
Damit der Connector auf einem Server installiert werden kann, muss sichergestellt sein, dass ein Registryschlüssel korrekt gesetzt ist, der die HTTP2-Protokollunterstützung für die Kerberos-Delegierung in WinHTTP steuert. Das geht über den folgenden Befehl in der PowerShell:
Auf dem Server, der den Connector für den Azure AD-Anwendungsproxy bereitstellt muss noch TLS 1.2 aktiviert sein. Microsoft empfiehlt an dieser Stelle die Anpassung eines Registryschlüssels:
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2][HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]"DisabledByDefault"=dword:00000000"Enabled"=dword:00000001[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]"DisabledByDefault"=dword:00000000"Enabled"=dword:00000001[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]"SchUseStrongCrypto"=dword:00000001
Der Server, auf dem der Anwendungsproxy-Connector installiert ist, muss in der Lage sein, ausgehende Verbindungen zu den Ports 80 und 443 zu öffnen. Generell sollten die Verbindungen zum Connector nicht durch andere Dienste getrennt werden, sondern immer zwischen Connector-Server und Azure ablaufen.
Die Einrichtung des Azure AD-Anwendungsproxy erfolgt über die Verwaltung von Azure AD im Azure-Verwaltungsportal. Hier kann auch das Azure AD Admin Center zum Einsatz kommen, das über die URL https://aad.portal.azure.com erreicht wird. Die Installationsdateien für den Connector sind über die Schaltfläche "Connectordienst herunterladen" bei "Anwendungsproxy" im Azure AD Admin Center zu finden.