Folgendes Problem aus der Praxis: Ein Unternehmen betreibt intern eine klassische Web-App – vielleicht ein altes SharePoint, ein selbst gehostetes Intranet oder ein HR-Tool – und möchte diese App ohne VPN von außen erreichbar machen, dabei aber trotzdem Single Sign-On (SSO) und Conditional Access (bedingter Zugriff) nutzen. Genau hier setzt der Microsoft Entra Application Proxy an. In meinen Azure-Kursen ist das regelmäßig ein Moment, in dem es bei den Teilnehmern klick macht: Man braucht keinen eingehenden Firewall-Port, keine DMZ-Konfiguration und keine eigene Reverse-Proxy-Infrastruktur. Stattdessen registriert man die App als Enterprise Application (Unternehmensanwendung) im Entra-Portal und schiebt den Traffic sauber durch einen outbound-only Connector. Wie das konkret funktioniert, was Kerberos Constrained Delegation (KCD) damit zu tun hat und wann SAML sinnvoller ist – das zeigt dieser erste Teil der Reihe.
Das Grundprinzip: Enterprise App, Connector und Vorauthentifizierung
Der Microsoft Entra Application Proxy besteht aus zwei Hauptkomponenten: dem Cloud-seitigen Endpunkt im Entra-Portal (früher Azure AD) und dem Application Proxy Connector, einem leichtgewichtigen Windows-Dienst, der on-premises installiert wird – typischerweise auf einem dedizierten Server im Unternehmensnetz. Der Connector baut eine ausgehende HTTPS-Verbindung zur Microsoft Cloud auf. Eingehende Ports in Ihrer Firewall bleiben geschlossen.
Im Entra-Portal legen Sie eine neue Enterprise Application an und wählen dabei die Option „On-premises application“ (lokale Anwendung). Sie geben die interne URL der App an – also die Adresse, unter der der Connector sie erreicht – und eine externe URL, unter der Entra ID die App nach außen publiziert. Diese externe URL endet entweder auf .msappproxy.net oder auf einer eigenen benutzerdefinierten Domain.
Neue Enterprise Application anlegen: Interne und externe URL des Application Proxy eintragen.
Ein zentrales Konzept ist die Vorauthentifizierung (Pre-Authentication). Sie steuert, ob Entra ID den Benutzer bereits authentifiziert, bevor der Request überhaupt die interne App erreicht. Hier haben Sie zwei Optionen:
- Entra ID (empfohlen): Der Benutzer muss sich gegenüber Entra ID ausweisen – inklusive MFA und Conditional Access – bevor der Connector irgendetwas weiterleitet.
- Passthrough: Entra ID reicht den Request direkt an die App durch; die Authentifizierung übernimmt dann die App selbst. Sinnvoll nur für Sonderfälle, etwa wenn die App ein eigenes SAML-IdP-Setup mitbringt.
Merksatz: Wählen Sie immer die Entra-ID-Vorauthentifizierung, solange die App kein eigenes föderiertes Protokoll mitbringt. Nur so greifen Conditional-Access-Richtlinien zuverlässig.
SSO-Varianten im Vergleich: Kerberos, SAML und Header-Based
Sobald die Vorauthentifizierung erledigt ist, stellt sich die nächste Frage: Wie bekommt die Backend-App zu wissen, wer der Benutzer ist? Der Application Proxy unterstützt mehrere SSO-Methoden. In meinen Azure-Kursen zeigt sich dabei, dass die Wahl stark vom Typ der App abhängt.
| SSO-Methode | Geeignet für | Voraussetzung | Typischer Aufwand |
|---|---|---|---|
| Kerberos Constrained Delegation (KCD) | Windows-integrierte Auth (IWA), klassische IIS-Apps | Active Directory, SPN-Konfiguration, Connector muss Domänenmitglied sein | Mittel (AD-Konfiguration erforderlich) |
| SAML-basiertes SSO | Apps mit SAML 2.0-Unterstützung (z. B. ältere SaaS, SAP, Confluence on-prem) | App muss SAML SP sein; Metadaten-Austausch erforderlich | Mittel bis hoch (App-seitige Konfiguration) |
| Header-basiertes SSO | Apps, die Benutzerinfos per HTTP-Header erwarten | App akzeptiert Header wie X-Forwarded-User |
Gering (nur Header-Mapping konfigurieren) |
| Password-based SSO | Legacy-Apps ohne Protokollunterstützung | Anmeldeformular muss erkannt werden | Gering (nur Credentials hinterlegen) |
| Linked SSO (verknüpft) | App bereits über anderen IdP abgesichert | Externe URL wird nur in My Apps angezeigt | Minimal |
Der in der Praxis häufigste Fall für rein on-premises betriebene Windows-Apps ist Kerberos Constrained Delegation. Das Prinzip: Der Benutzer authentifiziert sich bei Entra ID (Token), der Connector holt sich im Namen des Benutzers ein Kerberos-Ticket vom Domain Controller und präsentiert es der Backend-App. Dafür muss der Connector-Server ein Domänenmitglied sein, und Sie müssen im Active Directory einen Service Principal Name (SPN) für die interne App sowie eine KCD-Delegation für das Connector-Konto konfigurieren.
KCD im Active Directory: Der Connector-Computer erhält eingeschränkte Delegierungsrechte für den SPN der Zielanwendung.
Praxistipp: Prüfen Sie den SPN mit setspn -L <Dienstkonto> auf doppelte Einträge. Ein doppelt vergebener SPN ist einer der häufigsten Gründe, warum KCD stillschweigend fehlschlägt.
SAML-Konfiguration für on-premises Apps – wo es knifflig wird
Wer seine App über SAML einbinden möchte, durchläuft im Entra-Portal den vertrauten SAML-Einrichtungsdialog: Entity ID (Bezeichner), Reply URL (ACS-URL), Claims-Mapping. Das Besondere beim Application Proxy: Die Reply URL muss auf die externe Proxy-URL zeigen, nicht auf die interne App-URL. Das wird in der Praxis regelmäßig verwechselt.
Ich hatte mich in diesem Zusammenhang beim ersten Durchlauf selbst vertippt – und stand vor einem klassischen SAML-Fehler 7000: „The reply URL specified in the request does not match.“ Der Fix ist trivial, wenn man es weiß: Im Entra-Portal unter Enterprise Application → Single Sign-On → SAML muss die Reply URL exakt der externen msappproxy.net-URL (oder Custom Domain) entsprechen, und auf der App-Seite muss der Identity-Provider-Metadata-Endpunkt von Entra ID eingetragen sein.
SAML-Grundkonfiguration: Reply URL zeigt auf die externe Application-Proxy-URL, nicht auf den internen Server.
Ein weiteres Detail: Aktivieren Sie im Application-Proxy-Blatt der Enterprise App die Option „Translate URLs in headers“ (URL-Übersetzung in Headern). Damit werden interne Links, die die App in HTTP-Headern oder im HTML-Body ausgibt, automatisch auf die externe URL umgeschrieben. Ohne diese Option können Sessions auseinanderfallen, weil die App plötzlich auf interne Adressen zurückverlinkt, die der externe Client nicht erreicht.
Praxisempfehlung für KMU: Schritt-für-Schritt zum Einstieg
Noch mal in Kürze – kurz, knapp und strukturiert, zum Abhaken:
- Connector installieren: Einen Windows Server 2019/2022 im Unternehmensnetz als Domänenmitglied bereitstellen, den Entra Application Proxy Connector herunterladen und installieren. Der Server braucht ausgehenden HTTPS-Zugriff (Port 443) auf Microsoft-Endpunkte.
- Enterprise App anlegen: Im Entra-Portal eine neue On-premises-Anwendung anlegen, interne und externe URL eintragen, Connector-Gruppe zuweisen.
- Vorauthentifizierung auf „Microsoft Entra ID“ setzen – immer, außer Sie haben einen nachgelagerten SAML-SP.
- SSO-Methode wählen: IIS-App mit Windows-Auth → KCD. App mit SAML-Unterstützung → SAML. Alles andere → Header oder Password.
- Für KCD: SPN anlegen, Delegation im AD konfigurieren, Connector-Konto prüfen.
- Conditional-Access-Richtlinie zuweisen: MFA mindestens für externe Zugriffe erzwingen.
- Testen: My Apps-Portal (
myapps.microsoft.com) aufrufen – die App sollte nach Entra-Anmeldung ohne zweite Passwortabfrage öffnen.
Für KMUs mit einer Handvoll interner Web-Apps ist dieser Ansatz oft die elegantere und sicherere Alternative zum klassischen VPN-Zugang – ohne Zusatzkosten für externe Reverse-Proxy-Produkte. In Teil 2 dieser Reihe schauen wir uns an, wie Sie den Application Proxy mit eigenen Custom Domains und Zertifikaten professionell absichern und wie Connector-Gruppen bei verteilten Standorten helfen. Wer das Thema lieber strukturiert in einem Kurs erarbeiten möchte, findet die passenden Inhalte in meinen Azure-Kursen.