Web Application Proxy

Web Application Proxy: Architektur, Betrieb und Ablöse-Strategien

Der Web Application Proxy ist der unscheinbare Bruder von ADFS. Er steht in der DMZ, reicht Authentifizierungs-Requests durch und macht dabei den Job, ohne dass jemand viel über ihn nachdenkt — bis er ausfällt. Dann lernen Admins schnell, was alles an ihm hängt. Microsoft hat WAP mittlerweile als deprecated markiert, was ihn für viele Kunden gleichzeitig wichtiger und kürzer wichtig macht. Dieser Artikel erklärt, wie WAP funktioniert, wann Pre-Authentication überhaupt greift, wie du ihn mit einem Kemp-LoadMaster sauber betreibst oder durch diesen vollständig ersetzt, warum die Domain-Mitgliedschaft eine echte Sicherheits-Entscheidung ist — und welche Ablöse-Strategien sich heute lohnen.

Was der Web Application Proxy eigentlich ist

Der Web Application Proxy, kurz WAP, ist eine Windows-Server-Rolle, die seit Server 2012 R2 verfügbar ist. Funktional ist er ein Reverse Proxy — er nimmt Anfragen aus dem Internet entgegen und leitet sie ins interne Netz weiter, ohne dass externe Clients je direkt mit den internen Servern kommunizieren. Damit erfüllt der WAP zwei Hauptaufgaben: Schutz interner Systeme durch eine zusätzliche Vermittlungsschicht in der DMZ, und Pre-Authentication für ADFS-geschützte Anwendungen — wobei dieser zweite Punkt einen wichtigen Vorbehalt hat, den wir gleich genauer ansehen.

Im Microsoft-Ökosystem ist WAP eng mit ADFS verzahnt. Wer ADFS extern verfügbar macht, ohne den ADFS-Server selbst direkt aus dem Internet erreichbar zu machen, kommt am WAP nicht vorbei. WAP kann zwar auch ohne ADFS betrieben werden — als reiner Reverse Proxy für interne Web-Apps —, aber der eigentliche Mehrwert entsteht erst in Kombination mit Federation. Außerhalb der ADFS-Welt gibt es heute deutlich mächtigere Reverse-Proxy-Produkte wie F5 BIG-IP, Sophos UTM oder NGINX Plus, die schon lange das ursprüngliche WAP-Versprechen weiter denken.

Die DMZ-Architektur in der Praxis

Eine produktive WAP-Topologie folgt einem klaren Drei-Zonen-Modell: Internet, DMZ und internes Netzwerk werden durch zwei Firewalls voneinander getrennt. Der WAP sitzt in der DMZ, die ADFS-Farm im internen Netz. Diese Trennung ist nicht akademisch — sie ist der eigentliche Sicherheitsgewinn, den der WAP bietet.

Abb.: Die Standard-DMZ-Topologie mit drei Zonen, zwei Firewalls und dem WAP als Vermittler. Externe User erreichen den WAP über HTTPS, der WAP kommuniziert nach innen mit der ADFS-Farm — kein direkter Zugriff vom Internet auf die ADFS-Server.

Ein paar Details, die in der Praxis oft unterschätzt werden. Erstens: Der WAP braucht zwei Netzwerk-Interfaces — eines in der externen DMZ-Zone, eines in der internen oder mittleren Zone, in der die ADFS-Server stehen. Manche Installationen kürzen das ab und stellen den WAP mit nur einem Interface auf, was die Trennung praktisch aufweicht. Zweitens: Auf der externen Firewall muss Port 443 (HTTPS) eingehend offen sein, auf der internen Firewall Port 443 in Richtung ADFS-Farm und Port 80 für Certificate Revocation Lists. Drittens: Mindestens zwei WAP-Server gehören zur produktiven Topologie, weil ein einzelner WAP zum Single Point of Failure wird — sobald er ausfällt, ist die externe Authentication tot.

Der WAP selbst hat ein erstaunlich schlankes Aufgabenprofil. Er authentifiziert nicht selbst, er hat keine eigene User-Datenbank, er ist kein vollwertiger Identity Provider. Er ist im Kern ein HTTPS-Reverse-Proxy mit optionaler Pre-Authentication-Logik — nicht mehr und nicht weniger. Genau diese Schlankheit ist sowohl seine Stärke als auch seine Schwäche: Stärke, weil die Angriffsfläche klein bleibt. Schwäche, weil moderne Reverse-Proxys wie F5 oder Kemp deutlich mehr leisten.

 

Info: Warum WAP überhaupt entwickelt wurde Vor dem WAP gab es bei Microsoft den Threat Management Gateway (TMG) als DMZ-Proxy für ADFS — ein deutlich mächtigeres Produkt mit Web Application Firewall, URL-Filtering und mehr. Microsoft hat TMG 2012 abgekündigt und mit WAP einen schlanken Nachfolger gebaut, der bewusst weniger kann. Die Idee war: Lieber ein einfaches, sicheres Produkt, das ausschließlich die ADFS-Vermittlung gut macht, als ein überladenes Konstrukt mit großer Angriffsfläche. Aus heutiger Sicht ist diese Entscheidung gemischt zu bewerten — die Schlankheit wurde erkauft mit fehlender Erweiterbarkeit, und der WAP altert mittlerweile sichtbar.

Die Trust-Beziehung zwischen WAP und ADFS

Damit der WAP überhaupt etwas Sinnvolles tun kann, muss er der ADFS-Farm vertrauen — und die ADFS-Farm muss den WAP als legitimen Vermittler akzeptieren. Diese gegenseitige Vertrauensbeziehung wird als Proxy Trust bezeichnet und ist ein eigenes Setup-Verfahren, das beim Einrichten des WAP einmal durchlaufen wird.

Abb.: Die Trust-Beziehung zwischen WAP und ADFS mit den fünf typischen Einrichtungsschritten — plus die häufigsten Trust-Probleme und der PowerShell-Befehl zur Reparatur.

Der Trust wird über das PowerShell-Cmdlet `Install-WebApplicationProxy` aufgebaut, das beim WAP-Setup automatisch oder später manuell ausgeführt wird. Dabei muss der WAP zwei Dinge wissen: den Federation Service Name der ADFS-Farm (zum Beispiel `adfs.firma.de`), und gültige Credentials eines ADFS-Service-Kontos, mit denen die initiale Trust-Beziehung etabliert wird. Nach erfolgreicher Einrichtung speichert der WAP einen eigenen Trust-Token, mit dem er sich gegenüber dem ADFS authentifiziert.

Die häufigste Quelle für Trust-Probleme in der Praxis ist das Service Communication Certificate des ADFS. Dieses Zertifikat muss auf jedem WAP installiert sein, damit der WAP die ADFS-Antworten validieren kann. Wenn das Zertifikat auf der ADFS-Seite rotiert wird — sei es automatisch durch Auto-Cert-Rollover oder manuell —, muss das neue Zertifikat auch auf den WAPs eingespielt werden. Vergessen das die Admins, fällt die WAP-Authentication aus, sobald das alte Zertifikat abläuft. Klassischer nächtlicher Komplettausfall der externen Authentication, oft erst Tage nach der eigentlichen Cert-Rotation, weil ein altes Cert noch in einem Cache liegt.

Zwei Publishing-Modi: wann Pre-Authentication überhaupt greift

Bevor wir tiefer in die Pre-Authentication einsteigen, muss ein zentraler Punkt klargestellt werden, der in vielen Diskussionen und auch in Microsoft-Dokumentationen unter den Tisch fällt: Pre-Authentication am WAP greift nicht in allen Konfigurationen. Der WAP kennt nämlich zwei grundsätzlich verschiedene Publishing-Modi, und nur in einem davon kommt das Pre-Authentication-Konzept überhaupt zum Tragen.

Abb.: Die zwei Publishing-Modi des WAP: ADFS-Publishing veröffentlicht nur das Login-Portal selbst — Pre-Authentication greift nicht. Application Publishing veröffentlicht eine Anwendung hinter ADFS — hier wird Pre-Authentication zum Sicherheits-Mehrwert.

Modus 1: ADFS-Publishing

Im ADFS-Publishing-Modus veröffentlicht der WAP das ADFS selbst — genauer gesagt das ADFS-Login-Portal (`adfs.firma.de/adfs/ls`). Externe User landen über den WAP direkt auf dem Login-Formular, geben dort ihre Credentials ein, machen MFA, bekommen ein Token. Der WAP ist in diesem Modus nichts anderes als ein HTTPS-Reverse-Proxy für das ADFS-Portal — er reicht die Anfrage durch, terminiert SSL, routet zur internen Farm, fertig.

Pre-Authentication greift in diesem Modus nicht — und kann logisch auch gar nicht greifen. Der Grund ist simpel: Das Backend, an das der WAP weiterreicht, ist ja selbst der Authentication-Endpoint. Der WAP kann unmöglich „vorab prüfen“, ob der User authentifiziert ist, denn die Authentifizierung soll erst passieren. Pre-Authentication setzt voraus, dass es ein Token gibt, das geprüft werden kann — und das Token entsteht im ADFS, also genau im Backend.

Was der WAP im ADFS-Publishing-Modus dennoch leistet: HTTPS-Termination und Reencryption, Routing zur ADFS-Farm, optional IP-basiertes Filtering (etwa Geo-Blocking), und HTTP-Header-Modifikation. Das ist nicht nichts — aber es ist auch deutlich weniger Sicherheits-Mehrwert als oft behauptet wird. Wer einen WAP nur für ADFS-Publishing betreibt, betreibt im Wesentlichen einen HTTPS-Reverse-Proxy.

Modus 2: Application Publishing

Hier wird es interessant. Im Application-Publishing-Modus veröffentlicht der WAP eine andere Anwendung hinter ADFS — typischerweise eine SharePoint-Farm, ein Exchange OWA, eine SAML-fähige Web-Anwendung oder eine Partner-Applikation. In diesem Modus ist der WAP der Türsteher: Er nimmt den Request entgegen, erkennt das fehlende oder ungültige Token, schickt den User zum ADFS-Login, prüft das zurückkommende Token, und gibt erst dann den Weg zum Backend frei.

Hier greift Pre-Authentication tatsächlich und liefert echten Sicherheits-Mehrwert. Brute-Force-Angriffe auf die Anwendung werden am WAP abgefangen. DoS-Versuche treffen den WAP, nicht das Backend. Vulnerability-Scans laufen ins Leere, weil der WAP ungültige Requests verwirft. Die Anwendung sieht ausschließlich vorauthentifizierte Zugriffe.

 

Warnung: Die meisten WAP-Setups laufen nur im ADFS-Publishing-Modus Bei Audit-Reviews fällt immer wieder auf: Viele Unternehmen betreiben einen WAP ausschließlich für das ADFS-Publishing, um externe Microsoft-365-Logins zu ermöglichen. Andere Anwendungen wurden längst direkt cloud-angebunden oder über andere Wege geschützt. In dieser Konfiguration ist der WAP ein reiner HTTPS-Vermittler ohne Pre-Auth-Schutz. Das ist nicht per se falsch — die DMZ-Trennung selbst hat schon Wert. Aber wer denkt, der WAP würde „die Authentication absichern“, irrt sich. Die Absicherung passiert im ADFS, der WAP reicht nur weiter. Diese Erkenntnis ist auch wichtig für die Ablöse-Strategien: Wenn der WAP nur ADFS published, ist er besonders einfach zu ersetzen.

Pre-Authentication bei Application Publishing im Detail

Wer Application Publishing nutzt, bekommt vom WAP einen echten Sicherheits-Mehrwert. Der Flow läuft in sieben Schritten ab, und jeder Schritt löst ein konkretes Problem.

Abb.: Pass-Through versus ADFS-Pre-Authentication im direkten Vergleich. Bei Pass-Through reicht der WAP einfach durch, bei Pre-Authentication prüft er die Authentication beim ADFS, bevor das Backend überhaupt einen Request sieht.

Im Pass-Through-Modus (linke Seite der Skizze) verhält sich der WAP wie ein simpler HTTP-Reverse-Proxy: Er empfängt den Request, leitet ihn weiter, gibt die Antwort zurück. Das Backend muss die Authentication selbst übernehmen. Dieser Modus ist einfach zu konfigurieren und funktioniert mit fast jeder Anwendung, hat aber gravierende Sicherheitsnachteile — das Backend ist effektiv von außen ansprechbar.

Im ADFS-Pre-Authentication-Modus (rechte Seite) ändert sich das Spiel grundlegend. Der WAP nimmt den initialen Request entgegen, erkennt aber sofort: Hier fehlt ein gültiges Token. Statt durchzureichen, leitet er den User-Browser per HTTP-302-Redirect zur ADFS-Login-Seite. Erst nachdem der User dort erfolgreich authentifiziert hat — inklusive eventueller MFA und Conditional-Access-Prüfungen — und ein gültiges SAML-Token zurück zum WAP geschickt wurde, wird der ursprüngliche Request an das Backend weitergeleitet. Das Backend sieht ausschließlich vorauthentifizierte Zugriffe.

Der Sicherheitsgewinn ist erheblich: Brute-Force-Angriffe werden am WAP abgefangen, nicht im internen Netz. Extranet Smart Lockout kann am ADFS greifen, ohne dass interne Konten gesperrt werden. MFA wird zwangsläufig vor dem Backend-Zugriff durchgesetzt. Conditional Access Policies in Form von ADFS-Claim-Rules können bewerten, ob der Zugriff überhaupt erlaubt ist.

Praxis-Empfehlung: Pre-Authentication immer aktivieren, wenn die Anwendung es unterstützt. Pass-Through ist nur in Spezialfällen sinnvoll — etwa bei Legacy-Apps mit eigenen Auth-Mechanismen, die sich nicht föderieren lassen.

Domain-Mitgliedschaft: Workgroup oder Domain-Joined

Eine der häufigsten Diskussionen in WAP-Architektur-Workshops: Soll der WAP Mitglied der internen Domain sein oder als Workgroup-Server stehen? Die Antwort ist nicht so eindeutig, wie sie auf den ersten Blick scheint, und sie hat echte Sicherheitskonsequenzen, nicht nur Betriebs-Bequemlichkeit.

Abb.: Workgroup-WAP versus Domain-Joined-WAP im Vergleich. Beide Varianten haben Vor- und Nachteile — die Sicherheitsperspektive spricht klar für Workgroup, der Betriebs-Aufwand für Domain-Joined.

Die Workgroup-Variante (Microsoft-Empfehlung)

Microsoft selbst empfiehlt offiziell, DMZ-Server als Workgroup-Mitglieder zu betreiben — also nicht in die produktive interne Domain aufzunehmen. Diese Empfehlung folgt aus dem Tier-Modell, das Microsoft als Best Practice für AD-Sicherheit definiert hat: Tier-0-Systeme (Domain Controller, ADFS, PKI) gehören in eine eigene Sicherheitszone, Tier-1-Systeme (Server-Workloads) in eine andere, Tier-2-Systeme (Workstations) in eine dritte. Wenn ein Server in der DMZ Mitglied der produktiven Domain ist, bricht er diese Trennung — der externe Angriffsvektor reicht plötzlich bis ins Tier-1-Modell oder schlechter.

Die konkrete Konsequenz: Wird ein Workgroup-WAP kompromittiert, hat der Angreifer Zugriff auf den Server selbst, aber nicht direkt auf AD-Credentials, Kerberos-Tickets oder Gruppen-Memberships. Er muss erst einen weiteren Angriffsschritt finden, um in die interne Domain zu kommen. Das ist nicht unmöglich, aber deutlich aufwendiger als bei einem Domain-Joined-Server, wo das Computer-Konto und gespeicherte Tickets gleich mitgeliefert werden.

Die Domain-Joined-Variante (verbreitet, aber problematisch)

In vielen produktiven Setups sind WAPs trotzdem Mitglieder der internen Domain. Die Gründe sind meist pragmatisch: zentrale Verwaltung über Group Policies, einheitliches Patch-Management über WSUS, vertrautes Windows-Konzept. Aus operativer Sicht ist Domain-Joined deutlich einfacher — die Trust-Einrichtung mit ADFS läuft glatter, das Logging über AD-basierte SIEM-Connectoren funktioniert nativ, der lokale Admin braucht nicht für jeden Server separate Konten.

Sicherheitstechnisch ist das ein erheblicher Kompromiss. Ein Domain-Joined WAP in der DMZ ist effektiv ein Tier-Modell-Verstoß. Im Falle einer Kompromittierung — sei es durch eine Web-Vulnerability, eine Phishing-Kampagne gegen den lokalen Admin, oder ein Supply-Chain-Angriff — bringt der WAP die volle AD-Mitgliedschaft mit. Computer-Konto, Service-Accounts, eventuell sogar Domain-User-Sessions, die noch in Speicher oder Logon-Cache stehen.

Ein gangbarer Kompromiss in größeren Umgebungen ist eine dedizierte DMZ-Domain in einem separaten Forest. Damit hast du die zentralen Verwaltungsvorteile einer AD-Domain, ohne die Tier-Trennung zur produktiven Welt aufzugeben. Aufwand und Lizenzkosten sind nicht trivial — typischerweise zwei zusätzliche Domain Controller plus Trust-Konfiguration —, aber für sicherheitskritische Umgebungen ist es die saubere Mittellösung.

 

Warnung: Tier-Modell-Verstöße sind real, nicht akademisch Der häufigste Einwand gegen die Workgroup-Variante lautet: „ist doch nur Theorie, wir haben da nie was gehabt“. Das ist solange richtig, wie nichts passiert. Wer die letzten Jahre die Berichte zu Identity-Disastern verfolgt hat — SolarWinds, Hafnium, mehrere große Ransomware-Wellen —, weiß: Sobald ein DMZ-Server kompromittiert ist und AD-Mitglied war, dauert es in der Regel weniger als 24 Stunden, bis der Angreifer Domain-Admin-Rechte hat. Die Tier-Trennung ist nicht akademisch — sie ist die Differenz zwischen „ein Server muss neu aufgesetzt werden“ und „der ganze Tenant ist verloren“. Wer einen Domain-Joined-WAP betreibt, sollte das bewusst tun und die zusätzlichen Härtungsmaßnahmen kennen.

Hochverfügbarkeit mit Kemp-LoadMaster

Sobald die WAP-Topologie über einen einzigen Server hinauswächst — und das sollte bei jeder produktiven Umgebung der Fall sein —, brauchst du einen Load Balancer davor. Microsoft bietet mit Network Load Balancing (NLB) eine Bordmittel-Lösung, die für kleine Setups reicht. In ernsthaften Produktiv-Umgebungen ist NLB allerdings nicht erste Wahl, weil es weder TLS-Inspection noch Sophistikation beim Health-Check noch Layer-7-Funktionen mitbringt. Hier kommen dedizierte Load Balancer wie Kemp LoadMaster ins Spiel — eine gerade im deutschsprachigen Raum sehr verbreitete Lösung, die deutlich mehr leistet als reine Lastverteilung.

Abb.: Kemp-LoadMaster vor einer WAP-Farm: Lastverteilung, SSL-Termination, Health-Checks, optional WAF und ESP-Pre-Authentication. Die Syslog-Daten können mit ADFS-Logs korreliert werden — der End-to-End-Trace zeigt jeden Hop.

Die Basis-Konfiguration

In der Standard-Konfiguration steht der Kemp-LoadMaster zwischen Internet und WAP-Farm. Er nimmt HTTPS-Anfragen auf Port 443 entgegen und verteilt sie auf die WAP-Server im Pool. Die zentrale Konfigurations-Einheit bei Kemp ist der Virtual Service — eine virtuelle Adresse, hinter der die echten Server-Adressen verborgen sind. Externe DNS-Einträge zeigen auf den Virtual Service, intern verteilt Kemp dann auf die WAPs.

Wichtige Einstellungen, die in der Praxis oft falsch konfiguriert werden:

• Persistence: Bei ADFS-Authentication ist Source-IP-Persistence sinnvoll, mit mindestens 30 Minuten Timeout. Ohne Persistence kann es zu inkonsistentem Verhalten kommen, wenn ein User mitten in der Authentication zwischen WAPs wechselt
• Scheduling Method: Round Robin reicht für die meisten Setups. Wer ungleichmäßige WAP-Hardware hat, kann mit weighted Round Robin arbeiten
• Health-Check: Ein HTTPS-GET auf den Pfad `/adfs/probe/` ist die empfohlene Methode. ADFS antwortet hier mit HTTP 200, sobald die Dienste erreichbar sind. Intervall 10 Sekunden, Timeout 5 Sekunden, bei drei Fehlversuchen wird der WAP als down markiert
• Connection Timeout: Mindestens 300 Sekunden, weil ADFS-basierte Authentication-Flows bei MFA-Prompts mehrere Minuten dauern können

SSL-Termination — die wichtige Entscheidung

Eine zentrale Architektur-Entscheidung bei jedem Load-Balancer-Setup: Wo wird SSL terminiert? Zwei Varianten sind sinnvoll, eine wird oft fälschlich gewählt.

SSL-Reencryption ist die empfohlene Variante. Der Kemp terminiert SSL, prüft den Traffic auf Layer 7 (was nur unverschlüsselt möglich ist), und verschlüsselt anschließend neu zum WAP. Du bekommst Inspektion und Verschlüsselung im internen Pfad — der saubere Weg. Pass-Through-SSL ist die Alternative, bei der Kemp den TLS-Stream unverändert bis zum WAP durchreicht. Einfacher zu konfigurieren, aber keine Layer-7-Inspektion möglich. Die dritte Variante — Edge-Termination ohne Reencryption — ist sicherheitstechnisch problematisch: zwischen Load Balancer und WAP läuft der Traffic unverschlüsselt. In Tier-0-relevanten Umgebungen ein Tabu.

 

Praxis-Tipp: Kemp-Konfiguration nicht beim WAP-Setup vergessen Ein häufiges Versäumnis: Die Kemp-Konfiguration wird erst nach dem WAP-Setup angepasst — und dann mit den falschen Default-Werten in Produktion gestellt. Empfehlung: Konfiguration von Anfang an mit folgenden Werten anlegen: Persistence Source IP mit 1.800 Sekunden (30 Min), Connection Timeout 300 Sekunden, Health-Check auf `/adfs/probe/` alle 10 Sekunden, SSL-Reencryption aktiviert, gleichbleibende Cipher-Suite zwischen Kemp und WAP. Wer das beachtet, hat 80 Prozent der typischen Performance- und Stabilitäts-Probleme von vornherein ausgeschlossen.

Kemp LoadMaster als vollwertiger WAP-Ersatz

Eine in deutschen Unternehmen häufig gestellte Frage, die selten klar beantwortet wird: Kann Kemp den WAP nicht gleich vollständig ersetzen, statt parallel mit ihm zu laufen? Die Antwort ist eindeutig: Ja, mit dem Edge Security Pack (ESP) macht Kemp alles, was der WAP kann — und in den meisten Punkten mehr. Für Umgebungen, in denen Kemp ohnehin als Load Balancer im Einsatz ist, kann der WAP komplett herausgenommen werden.

Abb.: Kemp als vollwertiger WAP-Ersatz: Topologie vor und nach der WAP-Entfernung, plus eine direkte Funktions-Matrix zwischen WAP und Kemp ESP. Die meisten Funktionen liefert Kemp gleichwertig oder besser.

Was Kemp ESP funktional kann

Das Edge Security Pack ist eine Lizenz-Erweiterung des LoadMasters, die ihn von einem reinen Layer-4/7-Load-Balancer zu einer vollwertigen Authentication-Gateway-Lösung macht. Funktional deckt ESP alles ab, was der WAP leistet, und mehrere zusätzliche Dinge:

• SAML 2.0 Pre-Authentication: Kemp kann direkt gegen ADFS oder gegen Entra ID als SAML-Identity-Provider authentifizieren. Funktional gleichwertig zum WAP, oft mit besseren Logging-Möglichkeiten
• LDAP- und Forms-Based Authentication: Kemp kann mit dem internen Active Directory direkt sprechen und ein eigenes Login-Formular bereitstellen — diese Option hat der WAP gar nicht
• Kerberos Constrained Delegation (KCD): Für Backends, die nur Windows-Integrated Authentication sprechen, kann Kemp Kerberos-Tickets im Namen des Users besorgen und an die Anwendung weiterreichen. Das ist auch der WAP-Weg, funktional gleichwertig
• Web Application Firewall (WAF): Layer-7-Inspektion auf SQL-Injection, XSS und OWASP-Top-10-Angriffsmuster. Diese Funktion hat der WAP überhaupt nicht — und sie ist heute Compliance-relevant
• Geo-IP-Filtering, Rate Limiting, IP-Reputation: Funktionen, die der WAP entweder gar nicht oder nur in sehr eingeschränkter Form anbietet
• Single Sign-On über mehrere Anwendungen hinweg: Kemp kann einen einmal authentifizierten User für mehrere Backend-Anwendungen weiterverwenden, mit unterschiedlichen Authentifizierungs-Methoden je Backend

Wann der Wechsel zu Kemp-Only Sinn ergibt

Drei Szenarien machen die WAP-Ablösung durch Kemp besonders attraktiv. Erstens: Kemp ist im Haus, mit aktiver Wartung und ESP-Lizenz. Dann liegt die Funktion bereits brach und der WAP ist effektiv redundant. Zweitens: Eine größere ADFS-Umgebung mit mehr als nur dem Standard-Microsoft-365-Login — also mit veröffentlichten Anwendungen, Partner-Federation und komplexen Authentication-Anforderungen. Hier zahlt sich Kemps Flexibilität aus. Drittens: Eine geplante Modernisierung der DMZ-Architektur, in der Microsoft-Komponenten reduziert werden sollen — die Microsoft-Deprecation des WAP unterstreicht diesen Pfad.

Die Vorteile sind handfest. Ein DMZ-Server weniger zu betreiben. Eine deprecated-Microsoft-Komponente weniger im Stack. Ein deutlich umfangreicheres Funktions-Set. Bessere Logging- und Monitoring-Möglichkeiten. Aktive Roadmap statt End-of-Life-Pfad. Lizenztechnisch ist Kemp mit ESP nicht günstig, aber wenn die ESP-Lizenz ohnehin vorhanden ist, gibt es schlicht keinen Grund, den WAP weiter zu betreiben.

Was du beim Wechsel beachten musst

Eine WAP-zu-Kemp-Migration ist kein triviales Plug-and-Play, aber gut planbar. Die wichtigsten Schritte:

• Inventarisierung aller WAP-Veröffentlichungen: Welche Anwendungen sind heute über den WAP exponiert? Welcher Authentication-Modus läuft (Pass-Through, SAML, KCD)? Welche speziellen Header-Modifikationen sind konfiguriert?
• Kemp-Konfiguration aufbauen: Pro WAP-veröffentlichter Anwendung wird ein Virtual Service auf Kemp angelegt. Authentication-Methode in ESP konfigurieren. Health-Check für die Backend-Anwendung einrichten
• ADFS-Trust mit Kemp einrichten: Statt des WAP-Proxy-Trust wird auf ADFS-Seite eine SAML-Relying-Party für Kemp angelegt. Kemp und ADFS tauschen Federation-Metadaten aus
• Cutover über DNS: Externe DNS-Einträge werden vom WAP auf den Kemp Virtual Service umgeleitet. Der WAP läuft zunächst weiter als Fallback, kann nach erfolgreicher Beobachtungsphase abgeschaltet werden

 

Info: Wann Kemp den WAP NICHT ersetzen sollte Es gibt Szenarien, in denen der Wechsel nicht sinnvoll ist. Erstens: Kein Kemp im Haus oder keine ESP-Lizenz — dann ist die Kostenrechnung anders, oft ist Entra Application Proxy günstiger. Zweitens: Sehr spezielle WAP-Features wie bestimmte MS-OFBA-Konfigurationen (Office Forms-Based Authentication für ältere Office-Versionen), die in Kemp nur mit Workarounds nachbildbar sind. Drittens: Wenn die ADFS-Migration nach Entra ID ohnehin in den nächsten zwölf Monaten geplant ist — dann lohnt der Wechsel-Aufwand möglicherweise nicht mehr. In diesen Fällen den WAP einfach auslaufen lassen und im Rahmen der Migration komplett auflösen.

Typische Betriebsprobleme — und wie du sie vermeidest

In der täglichen Praxis bringt der WAP eine eigene Sammlung an Stolperfallen mit. Die häufigsten Klassiker, sortiert nach Häufigkeit und Schaden:

Abgelaufene Zertifikate

Der unangefochtene Spitzenreiter aller WAP-Probleme. Mehrere Zertifikate müssen koordiniert verwaltet werden — das öffentliche SSL-Zertifikat des WAP, das Service Communication Certificate des ADFS auf dem WAP, eventuell weitere Zertifikate für veröffentlichte Anwendungen. Wenn eines davon abläuft, ist die externe Authentication tot. Vorbeugung: zentraler Cert-Manager (eigene Skripte oder Tools wie der ADFS Diagnostiker mit Zertifikats-Monitor), Alarmierung bei 60 Tagen Restlaufzeit, dokumentierter Rollover-Prozess.

Gebrochene Trust-Beziehung

Wenn der Proxy Trust zwischen WAP und ADFS kaputt geht, sind die Symptome eindeutig: externe Logins schlagen fehl, in den WAP-Eventlogs erscheinen Fehler wie „Could not communicate with the federation server“. Häufigste Ursachen: das Service Communication Certificate wurde auf dem ADFS rotiert, aber auf dem WAP nicht aktualisiert. Oder das Service-Konto, das beim WAP-Setup verwendet wurde, hat seinen Passwort-Wechsel hinter sich. Reparatur über `Install-WebApplicationProxy` mit aktualisierten Credentials — siehe Skizze zur Trust-Beziehung weiter oben.

DNS- und Routing-Probleme

Der WAP muss den Federation Service Name (`adfs.firma.de`) auflösen können, und zwar in die interne Adresse der ADFS-Farm, nicht in die externe. Wenn die DNS-Konfiguration in der DMZ nicht stimmt, oder Split-DNS nicht korrekt eingerichtet ist, läuft die Kommunikation im Kreis. Vorbeugung: dedizierte DNS-Einträge in der DMZ-Zone, mit den internen Adressen der ADFS-Farm.

Performance-Probleme unter Last

Bei Login-Stürmen — etwa morgens, wenn alle Mitarbeiter gleichzeitig ihre Microsoft-365-Sessions starten — kann der WAP zum Bottleneck werden. Symptome: lange Antwortzeiten, vereinzelt Timeouts. Vorbeugung: Sizing nach Microsoft-Empfehlung (etwa 1 WAP pro 30.000 gleichzeitige User), HTTP/2 aktivieren, ausreichend RAM (mindestens 8 GB pro WAP), und CPU-Cores, die zur Last passen. Bei wirklich großen Umgebungen ist eine separate WAP-Farm pro Geo-Region sinnvoll.

Microsofts Deprecation-Entscheidung und ihre Folgen

Microsoft hat den Web Application Proxy mit Windows Server 2022 als deprecated feature markiert. Das bedeutet zunächst: Keine neuen Funktionen, keine neuen Roadmap-Investitionen. Es bedeutet nicht sofortiges End-of-Life — der WAP wird in absehbarer Zeit weiter mitgeliefert und auch sicherheitsgepatcht. Aber: der mittelfristige Pfad zeigt klar in eine andere Richtung. Microsoft empfiehlt für Neu-Installationen explizit Alternativen wie den Entra Application Proxy oder direkte Cloud-Authentication.

Was das praktisch heißt: Wer heute eine produktive WAP-Umgebung betreibt, muss nicht morgen migrieren. Wer aber neu plant, sollte WAP nicht mehr als Default-Wahl betrachten. Und wer ohnehin in der ADFS-zu-Entra-ID-Migration steckt, sollte den WAP-Ausstieg als integralen Bestandteil dieses Projekts planen.

Ablöse-Pfade: was kommt nach dem WAP

Drei realistische Ablöse-Pfade haben sich in den letzten Jahren herauskristallisiert. Welcher davon zu deiner Umgebung passt, hängt von deiner ADFS-Strategie, deinem Cloud-Reifegrad und deinen Legacy-Anwendungen ab.

Abb.: Drei Ablöse-Pfade für den WAP: Entra Application Proxy als primärer Pfad, direkte Cloud-Auth als sauberer Zielzustand, Alternative Reverse Proxys wie Kemp oder F5 für komplexere Setups.

Pfad 1: Entra Application Proxy

Microsofts Cloud-Reverse-Proxy. Statt einen WAP in der DMZ zu betreiben, installierst du einen Connector-Agent im internen Netz, der eine ausgehende Verbindung zur Entra-Cloud aufbaut. Externe Requests laufen über die Microsoft-Cloud rein, werden dort authentifiziert und durch den Connector ins interne Netz geroutet. Vorteile: keine DMZ-Server mehr nötig, Conditional Access voll integriert, native SSO mit Entra ID. Nachteile: Cloud-Abhängigkeit für externe Logins, komplexere Header-Konfiguration, Premium-Features kosten Lizenzgebühren. Empfehlung: Für die meisten Mittelstands- und Enterprise-Kunden der primäre Ablöse-Pfad.

Pfad 2: Direkte Cloud-Authentication

Der sauberste Pfad, weil er den WAP komplett auflöst. Anwendungen werden direkt an Entra ID angebunden, Federation wird durch Password Hash Sync oder Pass-Through Authentication ersetzt, jede App bekommt ihre eigene Entra-ID-Registrierung mit nativer OIDC- oder SAML-Anbindung. Vorteile: vollständige Migration weg von WAP, deutlich reduzierte DMZ-Server-Anzahl, modernste Auth-Mechanismen, Conditional Access voll nutzbar. Nachteile: Apps müssen migrierbar sein — Legacy-Apps mit Kerberos- oder Windows-Auth funktionieren nicht direkt, hier braucht es weiterhin den Entra Application Proxy oder andere Brücken-Lösungen. Empfehlung: Der saubere Zielzustand mittelfristig.

Pfad 3: Alternative Reverse Proxys (Kemp, F5, NGINX)

Wenn ohnehin eine kommerzielle Reverse-Proxy-Lösung im Einsatz ist — Kemp LoadMaster mit ESP, F5 BIG-IP APM, Sophos UTM oder NGINX Plus —, kann der WAP durch diese ersetzt werden. Wie im vorherigen Abschnitt detailliert beschrieben, ist gerade Kemp mit ESP funktional ein vollwertiger Ersatz, oft sogar leistungsfähiger als der WAP. Vorteile: funktional oft mächtiger als WAP, integrierte WAF, kein Microsoft-Lock-In, geeignet auch für Nicht-ADFS-Apps. Nachteile: Lizenzkosten je nach Produkt, neue Konfiguration und Know-how nötig, ADFS-Trust muss neu eingerichtet werden. Empfehlung: Wenn Kemp, F5 oder vergleichbares ohnehin im Haus ist — dann ist das der naheliegende Pfad.

Fazit: WAP ist nicht tot, aber auf der Zielgeraden

Der Web Application Proxy bleibt für die nächsten Jahre eine wichtige Komponente in vielen Microsoft-Umgebungen. Wer ihn betreibt, sollte ihn ernst nehmen — mit sauberer Topologie, klarem Verständnis der Publishing-Modi, durchdachter Domain-Mitgliedschafts-Entscheidung, ordentlich konfigurierter Hochverfügbarkeit über einen Kemp-LoadMaster oder vergleichbares Produkt, und einem klaren Plan, was nach WAP kommt.

Die wichtigsten Take-aways: Erstens, der WAP ist kein Set-and-Forget — Zertifikatsmanagement, Trust-Pflege und Monitoring sind Pflichtaufgaben. Zweitens, Pre-Authentication greift nur beim Application Publishing — wer den WAP nur für ADFS-Veröffentlichung betreibt, bekommt davon nichts. Drittens, die Domain-Mitgliedschafts-Entscheidung ist eine echte Sicherheitsfrage, nicht nur eine Betriebsbequemlichkeit. Viertens, Kemp mit ESP ist nicht nur Lastverteiler, sondern ein vollwertiger WAP-Ersatz, wenn die Lizenz ohnehin vorhanden ist. Fünftens, die Microsoft-Deprecation ist real — wer heute neu plant, sollte alternative Pfade evaluieren.

Wer in seiner Umgebung WAP betreibt und einen strukturierten Blick auf den aktuellen Zustand werfen möchte: Das ADFS-Diagnostiker-Werkzeug liefert eine vollständige Inventarisierung der WAP-Konfiguration, Zertifikats-Restlaufzeiten, Trust-Status, Health-Check-Ergebnisse und eine End-to-End-Login-Trace-Funktion mit Kemp-Korrelation. Beratung zur sauberen WAP-Ablösung im Rahmen einer ADFS-zu-Entra-ID-Migration ist ebenfalls als strukturiertes Beratungsformat verfügbar — vom Health-Check der bestehenden Topologie bis zum konkreten Migrations-Wellenmodell.

 

Weiterführende Inhalte Übergeordnete Seite zu ADFS mit Architektur, Claims, Migration: ADFS in der Praxis. Detailseite zur Beratung mit dem Fünf-Phasen-Modell, Detailseite zum ADFS Diagnostiker mit den 14 Modulen, ADFS-Schulungen-Detailseite mit dem zweitägigen Migrations-Workshop. Das geplante Buch ADFS in der Praxis behandelt den WAP im Detail in Teil II (Planung, Installation, Betrieb) und Teil III (Trusts, Claim Rules und Integration).