WAP - Web Application Proxy

Wer alles nur mit drei Buchstaben (WAP) abkürzt, wird mit Mehrfachbedeutungen leben müssen. Mit Windows 2012R2 packt Microsoft die Funktion "Web Application Proxy" als Funktion mit in den IIS, über die interne Webseiten und andere auf HTTP basierende Dienste veröffentlicht werden können. Damit bietet Microsoft eine Alternative zum auslaufenden TMG/UAG-Produkt. Diese Seite beschreibt den Web Application Proxy mit den Schwerpunkten Exchange, Lync und Sharepoint.

Vorgeschichte

Woraus WAP aufbauen, kann ich gar nicht genau sagen, das diese Funktion in Windows 2012R2 als Rolle addiert wurde. Es gibt aber zwei bzw. drei Vorgänger, die eine ähnliche Funktion unter Windows bereit gestellt haben.

  • TMG
    Das Thread Management Gateway ist seit Ende 2012 nicht mehr verfügbar aber war gerade für kleine Firmen eine AllInOne-Firewall, die als Webproxy und NAT-Gateway nach extern als auch als Reverse Proxy zur sicheren Veröffentlichung von Webseiten dienen konnte
  • UAG
    Das unified Access Gateway war der "Große" Brüder, des TMG, der neben einer Portallösung für Webseiten auch OWA etc. veröffentlichen konnte und die NAT64/DNS64 Funktion für Direct Access auf Windows 2008R2 nachgerüstet hat.
  • IIS ARR Application Request Routung
    Diese IIS-Application ist ein Add-on, welche es auch erlaubt hat, Zugriffe auf virtuelle Verzeichnisse über das Add-on umzuschreiben und die Daten von einem Backend Server zu holen.

Der neue Web Application Proxy stellt eine Teilmenge der TMG Webveröffentlichung dar, der aber ADFS zur Authentifizierung nutzt und nicht mehr direkt die Domäne fragen kann. Eine kleine Komplexitätssteigerung, die meiner Meinung nach eher negativ zu beurteilen ist, wenn man nicht auf eine Preauthentication verzichten will. Sie ist aber nicht so flexibel wie ARR, welches per RegEx auch die URLs filtern und umschreiben kann. 

Funktionsweise

Der Wep Application Proxy nimmt Anfragen auf einem Interface an und gibt diese an einen nachgelagerten Backend-Server weiter. Idealerweise nutzt eine Firma z.B. SplitDNS (Siehe DNS) und nutzt den gleichen Namen für einen Dienst von intern und extern. So kann der Anwender von Extern über den Reverse Proxy mit angepasster Authentifizierung laufen, während er intern z.B. per Kerberos/NTLM automatisch angemeldet wird:

Wer also mehrere Dienste veröffentlichen will, sollte jedem Dienst einen eigenen Namen geben und diesen individuell veröffentlichen.

So umgeht man auch die Probleme, wenn sich durch die Übersetzung z.B. URLs ändern müssten. Der WAP unterstützt zwar ein Rewriting, aber das ist immer problembehaftet, da immer mehr Dienste auch URLs. z.B. in JavaScript oder XML-Paketen einbetten, die ein Proxy nicht mehr durch eine einfache Text-Ersetzung lösen kann. Denkbar ungünstig sind also Veränderungen des Hostname, der URL oder Ports, wie im folgenden Beispiel dargestellt:

Der WAP stellt selbst auch keine "Portalseite" bereit um dem Anwender z.B. eine Liste der für ihn verfügbaren Applikationen zu liefern. Hier liegt er hinter dem früheren UAG oder anderen kommerziellen "Portallösungen", die aber alle auch deutlich mehr kosten.

Vorarbeiten ADFS 3

Viele Anleitungen zu WAP sind so verfasst, dass die Vorauthentifizierung per ADFS möglich ist.

Microsoft's Web Application Proxy is a remote access role für Windows Server 2012 R2 that can be used to support a browser- and device-based authentication scheme in conjunction with Active Directory Federation Services, according to Greg Taylor, principal program manager lead für the Exchange customer adoption team at Microsoft. WAP currently supports preauthentication just für Outlook Web App Users. It doesn't support Users of Microsoft's Outlook Anywhere or Exchange ActiveSync protocols, he explained.
Quelle: Microsoft Releases Application Request Router 3.0 (http://redmondmag.com/articles/2013/07/31/application-request-router-3.0.aspx)

Web Application Proxy must always be deployed with AD FS. This enables you to leverage the features of AD FS, such as, single sign-on (SSO).
Quelle: Web Application Proxy Overview (http://technet.microsoft.com/en-us/library/dn280944.aspx)

Genauer sollte es aber heißen, dass Sie ADFS zwingend installiert haben müssen, damit sie WAP nutzen können

"You must deploy AD FS on a server running Windows Server 2012 R2 in your organization before you can deploy Web Application Proxy. "
Quelle: http://technet.microsoft.com/en-us/library/dn383650.aspx

Auch wenn sie nur Webseiten veröffentlichen wollen, die alle keine "Preauthentication" benötigen, so müssen wie dennoch WAP mit einem ADFS-Server verbinden. Und für den Fall, dass Sie das Zitat überlesen haben sollten: Es muss natürlich ein ADFS 3.0 Server sein, der zwingend einen Windows 2012R2 Server voraussetzt. Eine allzu schnelle Ablösung von TMG wird damit gebremst. Zumindest wenn Sie noch nicht für Windows 2012 CALs und Server gesorgt haben. Mit einem Server kommen Sie nicht hin.

Wer schon Office 365 mit ADFS einsetzt, wird dann in der Regel den bestehenden ADFS-Server einfach aktualisieren. Das geht mit einem Inplace Update am einfachsten.

Zuerst sollten Sie die lokalen Einstellungen sichern.

Add-PSSnapin Microsoft.adfs.PowerShell

# ab Windows 2013 ist die ADFS-Verwaltung ein Modul
PS C:\> Import-Module ADFS

md c:\adfsbackup
cd c:\adfsbackup
Get-ADFSCertificate | Out-File ".\certificates.txt"
Get-ADFSProperties | Out-File ".\properties.txt"
copy $ENV:Programfiles"\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config"
Get-ADFSEndpoint | Out-File ".\endpoints.txt"
Get-ADFSClaimDescription | Out-File ".\claimtypes.txt"
Get-ADFSClaimsProviderTrust | Out-File ".\cptrusts.txt"
Get-ADFSRelyingPartyTrust | Out-File ".\rptrusts.txt"

Speziell wenn Sie eine virtuelle Umgebung haben, sollten Sie die Snapshot-Funktion auch nutzen. Mein erstes InPlace-Update ist fehlgeschlagen und ich war sehr froh über den Snapshot/Checkpoint. Updates können auch fehlschlagen.

Einfacher ist es natürlich mit einem frischen Windows 2012R2 Server zu beginnen und ADFS einzurichten. für den Wep Application Proxy sind dazu nur wenige Schritte erforderlich:

  • Installation:
    ADFS Rolle installieren
  • Konfiguration per Assistent
    • SSL-Zertifikat auswählen (ggfls installieren)
      Federationname und Federation Displayname angeben
    • Dienstkonto vorgeben
      Seit Windows 2012 könne das auch "managed Accounts" sein.
    • Pfad für SQL-Datenbank angeben
      Bei einer Farm muss es ein SQL-Server sein, beim Single Server reicht auch die lokale Windows Internal Database (WID)

Damit ist dieser ADFS-Server natürlich noch nicht für Office 365 fertig.

Basiseinrichtung

Die Funktion "Web Application Proxy" sollten Sie nicht mit IIS ARR Application Request Routung verwechseln. Dieses gibt es kostenfrei zum Download während WAP Bestandteil von Windows 2012R2 ist. Es ist als Teil der "Remote Access"-Rolle, quasi direkt neben VPN und Direct Access zu finden:

Eventuell erforderliche Abhängigkeiten installiert das Setup gleich mit. Nach dem erfolgreichen Abschluss können Sie direkt den Assistenten starten:

Konfiguration per Assistent

Die Erstkonfiguration von WAP erfolgt ebenfalls über einen Assistenten und besteht nur aus ein paar Schritten.

Zuerst geben sie den Namen des internen ADFS-Servers an, der von WAP genutzt wird. Der Assistent möchte auf dem ADFS-Server gleich ein paar erforderliche Einstellungen vornehmen, wozu sie entsprechende Anmeldedaten eingeben müssen.

Als nächstes müssen Sie ein Zertifikat auswählen, welches den Namen des ADFS-Proxy Service enthält. Sie haben richtig gelesen. Die WAP-Installation installiert automatisch auch einen ADFS-Proxy mit.

Zum Schluss sehen Sie noch die PowerShell-Befehlszeile, mit der Sie die Konfiguration z.B.: als Teil eines Recovery-Vorgangs oder bei der Installation weiterer WAP-Proxies automatisieren können.

Ein Blick auf den "Operational Status" des Servers zeigt, dass nicht nur der Web Application Proxy, sondern auch noch ein ADFS Proxy den Weg auf den Server gefunden hat.

Nun wird auch klar, warum der Assistent ein Zertifikat für den ADFS-Proxy benötigt hat, welche auf den Namen des ADFS-Federation Servers ausgestellt wurde.

Webseite veröffentlichen

Die Installation ist erfolgt und nun können Sie über den Assistenten oder per PowerShell die Anwendungen "veröffentlichen". Die passende Konsole ist die "Remote Access Management Console", die sie auch für die Konfiguration von Direct Access und VPN nutzen.

Beim ersten Schritt müssen Sie sich entscheiden, ob der Client schon per ADFS vorab authentifiziert werden soll oder der Zugriff einfach so nach innen weiter gegeben werden soll:

Ich wähle erst mal den "Pass-Through"-Weg um z.B. Exchange OWA zu veröffentlichen.

Man kann geteilter Meinung sein, ob eine Authentifizierung gleich vorne oder erst auf dem Exchange Server erfolgen soll. Ein Angreifer kann so oder so Konten sperren und ob ein Exchange Server nun besser ungültige Zugriffe ablehnen kann als ein vorgelagerter Web Application Proxy sei mal dahin gestellt. Der WAP hat leider keine Zusatzfunktionen wie URL-Filterung oder DoS-Schutzfunktionen um übereifrige Anfragen oder Angriffsmuster zu blockieren.

Aber halt: Sie können per WAP nur HTTPS-Anwendungen veröffentlichen. Ein entsprechender Versuch wird schon vom Assistenten verhindert.

Daher müssen Sie auf dem Server erst mal SSL-Zertifikate installieren, die die Namen der Hosts enthalten, die sie später über diesen Server auch veröffentlichen möchten. Ebenso geht der Web Application Proxy erst mal davon aus, dass Sie mit "Split DNS" arbeiten und der externe Hostname und der interne Hostname identisch ist.

Bei der Veröffentlichung kann dann erst mal nicht viel mehr eintragen werden. Achten Sie aber darauf, dass die URLs mit einem "/" enden, da ansonsten die Veröffentlichung später nicht gelingt:

Und als Wink für zukünftige Veröffentlichungen wird auch gleich die PowerShell-Befehlszeile ausgegeben.

Danach erscheint die veröffentlichte Anwendung in der Übersicht.

Die Sache mit der PowerShell sollten Sie sich genau anschauen, denn ich habe bei Windows 2012R2 noch keinen Weg gefunden, Einstellungen per GUI wieder zu ändern. Sie können diese nur löschen und neu anlegen. Auch kann eine Backend-URL nur genau einmal veröffentlicht werden. Zudem überprüft WAP die HostHeader. Der öffentliche Name muss also auch auf jeden Fall "passen".

Microsoft Dienste veröffentlichen

Die meisten Firmen, die z.B.: ihren TMG die WAP ablösen wollen, nutzen diesen zur Veröffentlichung von folgenden Diensten

  • Exchange Webdienste
    bestehend aus OWA, ActiveSync, Autodiscover, EWS
  • Sharepoint und andere Webseiten
  • Lync Dienste
    Lyncdiscover, WebApp, DialIn, Meet und Lync Webservices
  • Office Web Apps
    Damit Lync Meetings auch Powerpoint nutzen, Exchange OWA Benutzer die Anlagen anzeigen und Anwender per Browser mit Office-Dateien arbeiten können

Alle Dienste können natürlich selbst eine Authentifizierung durchführen, so dass Sie diese transparent allein über die URL erreichbar machen können. Sie können aber auch mit ADFS eine Vorauthentifizierung erzwingen.

Configuring Windows 2012 R2 Web Application Proxy to publish Lync 2013
http://www.youtube.com/watch?v=iKpi8UomRDo

Im Fall eines Falles können Sie immer eine "PassThrough"-Veröffentlichung aufsetzen.

Einschränkungen

"Kost nichts - Taug nichts" ist man versucht zu sagen und der Web Application Proxy hat zumindest in der Version 2012R2 erst eine Basisfunktion. Der Funktionsumfang ist im wesentlichen:

  • SSL-Terminierung mit Filterung nach Hostheader und URL-Pfad
    Das erschwert Attacken durch falsche Hostnamen oder ungültige URLs aber den Schutz hier schätze ich eher niedrig ein. Ein ernst gemeinter Angriff versucht erst die Dienste zu ermitteln, die auf einem Server laufen um diese gezielt zu knacken.
  • Preauthentication mit ADFS
    Dienste, die ADFS unterstützen, also Webbrowser, MSOFBA-Clients wie Word, Excel, Powerpoint und Apps die den "Web Authentication Broker" nutzen, können so von eigentlichen Service abgehalten werden. Hier ist auch eine Multi Faktor-Authentifizierung möglich, da der ADFS-Server dies ermöglicht.

Allerdings muss man mit Einschränkungen leben, z.B.

  • SSL Only
    Aus Sicherheitsüberlegungen ist es natürlich gut, dass alle Verbindungen per SSL abgesichert sein müssen. Das ist schon aufgrund des optional verwendeten ADFS-Tokens ratsam. Aber es gibt durchaus Verbindungen wie z.B. LyncDiscover und AutoDiscover, die in bestimmen Umgebungen auch über "http" genutzt werden und wenn es nur für ein Redirect auf eine andere https-Adresse ist.
  • URL-Pfade müssen passen
    Der interne und externe Pfad muss identisch sein. Es ist also nicht möglich extern https://owa.firma.tld/exchange intern auf https://owa.firma.tld/owa zu veröffentlichen.
  • HostHeader
    Auch die Nutzung alternativer Hostheader ist nicht immer möglich, da WAP zwar die Request und Reply-Header umschreibt aber es vielleicht auch Webapplikationen gibt, die Links in Seiten nicht vom angefragten Hostheader abhängig machen und damit nicht ersetzt werden.
  • Versteckter ADFS-Proxy
    Die ADFS-Proxy-Funktion ist zwangsweise mit installiert, aber sie ist weder als Veröffentlichung im WAP sichtbar noch im IIS. Er ist nur im Eventlog und als Rolle sichtbar aber ich habe kein Log gefunden, welches versuchte Zugriffe ähnlich dem IIS protokolliert.

Damit sind einfache Aufgaben zu lösen aber im Vergleich zum TMG und anderen Lösungen fehlen. Zu einer "Schutzlösung" fehlt mir allerdings noch ein paar Funktionen wie z.B.:

  • DoS-Schutz
    Ein Angreifer kann auch über ADFS-Vorauthentifizierung ein internes Konto einfach sperren, zumindest wenn es keine Multi-Faktor-Authentifizierung genutzt wird, was aber gerade mit ActiveSync und RPC/HTTP nicht einfach ist. Aber ADFS 2012R2 kennt mittlerweile eine "Extranet Lockout Protection"
    (Siehe auch http://blogs.technet.com/b/rmilne/archive/2014/05/05/enabling-adfs-2012-r2-extranet-lockout-protection.aspx)
  • URL Filter/Normalisierung
    Zwar veröffentlicht WAP nur die angegeben URLs aber eine weitergehende Filterung der URL-Parameter, wie dies z.B. per RegEx bei IIS ARR möglich ist, gibt es nicht. Der TMG konnte z.B. Request-Größen, HighBits etc. filtern.
  • URL Replace für Body
    Sollte eine interne Applikation absolute URL-Pfade im Body oder XML-Antworten enthalten, dann konnte TMG diese auch ersetzen
  • Load Balancing
    Wenn ein Service intern durch mehrere Server als Farm bereit gestellt wird, dann muss mit WAP zusätzlich noch eine Lastverteilung konfiguriert werden, die sich aber nicht an der Source-IP orientieren kann, da hier ja der WAP-Server erscheint. Sowohl TMG als auch IIS ARR haben diese Funktion schon an Bord.
  • NTLM oder Radius-Authentifizierung
    TMG ist nicht auf ADFS angewiesen, sondern kann direkt das AD aber auch Radius-Server nutzen. Warum will Microsoft unbedingt überall ADFS-Tokens einbauen, zumal ihre eigene Software (z.B. selbst Outlook 2013) dies noch gar nicht kann. (Stand Nov 2013). Verständlich, dass WAP dann auch keine Authentifizierung filtern kann
  • Nur Kerberos und ADFS-Backends
    Wenn WAP den User per ADFS authentifiziert, dann hat der Client nur ein ADFS-Token. Der WAP-Server hat aber keine Anmelddaten. Nur mit eingerichtetem Kerberos Contraints Delegation kann eine automatische "Durchauthentifizierung" an den nachfolgenden Server erfolgen. Voraussetzung sind hierzu Windows 2012 DC, die vom WAP-Server erreichbar sind um ein Kerberos Ticket zu bekommen. Ein Durchgeben von "BasicAuth"-Credentials ist nicht vorgesehen.
  • Logging
    Die WAP-Funktion nutzt wie Direct Access den HTTP.SYS-Treiber aber ist nicht im IIS verankert. Ich habe noch kein Logging analog zum IIS gefunden.

Wenn Microsoft allerdings die WAP-Plattform strategisch sieht, dann ist durchaus denkbar, dass zukünftige Versionen oder gar Service Packs das ein oder andere fehlende Modul nachrüsten.

Aktuell wirkt das alles auf mich als noch nicht fertig. Mir wäre ein auf die Reverse-Proxy-Funktion abgespeckter TMG lieber gewesen. Aber eine schon geschlachtete Kuh kann man ja schlecht wieder beleben.

Weitere Links

Web Application Proxy (WAP) and Application Request Routing (ARR)
https://www.youtube.com/watch?v=xspsDhs7WUo

Teched2014 NA: Introducing Web Application Proxy in Windows Server 2012 R2: Enable Work from Anywhere
https://www.youtube.com/watch?v=9ijqPphzQtw