Hallo Exchange-Admins,

mit Windows Server 2012 wurden bekanntlich auch die Web Application Proxy Rolle (ehemals ADFS-Proxy) und die ADFS-Dienste bearbeitet. Mit der aktuellen Windows Server 2016 Version und ADFS 4.0 gibt es weitere Neuerungen.

Eine dieser Neuerungen ist das Veröffentlichen von Webapplikationen, die sich ausschließlich auf HTTP Basic verstehen (ADFS for Rich Clients), wie Exchange Active Sync (EAS). Bisher habe ich EAS in Verbindung mit ADFS immer via PassThroug veröffentlicht.

HTTP Basic is the authorization protocol used by many protocols, including ActiveSync, to connect rich clients, including smartphones, with your Exchange mailbox. For more information on HTTP Basic, see RFC 2617. Web Application Proxy traditionally interacts with AD FS using redirections which is not supported on ActiveSync clients; most rich clients don’t support cookies or state management. Publishing an app using HTTP basic provides support for ActiveSync clients in Web Application Proxy by caching the token that is received from AD FS and serving the token from the cache to overcome this limitation and avoid a high load on AD FS. In this way Web Application Proxy enables the HTTP app to receive a non-claims relying party trust for the application to the Federation Service. See Plan Active Directory.

 

Auch dieser Beitrag baut wieder auf der Basisinstallation auf:

01_Serveraufbau_ADFS_Server_2016

Folgende Voraussetzungen sind geschaffen:

  • ADFS ist auf Server 2016 / 4.0
  • WAP ist auf Server 2016 /4.0
  • Zertifikate korrekt installiert

Den Aufbau einer WAP / ADFS / Exchange-Umgebung könnt ihr hier nachlesen –> Server 2012 R2: Webanwendungsproxy mit Exchange 2013

Exchange Active Sync mit Preauthentification über ADFS:

Das virtuelle Verzeichnis für Active Sync findet ihr auf dem Installationsstandard für Exchange Server 2016 (Bild 2).

Sollten bereits Regeln in der Remote-Zugriffsrolle auf dem WAP für EAS existieren, so müssen diese entfernt werden.

Schritt 1 – ADFS Non Claims Aware Relying Party Trust

Damit im Veröffentlichungsprozess am WAP später eine HTTP Basic Applikation veröffentlicht werden kann, muss diese im ADFS als „Nicht Anspruch unterstützte Vertrauensstellung“ hinzugefügt werden! (Diese deutschen Übersetzungen…..)

Ich bediene mich hier ausschließlich der PowerShell:

  1. Am ADFS Server anmelden
  2. PowerShell öffnen
  3. Add-AdfsNonClaimsAwareRelyingPartyTrust -Name „ActiveSync“ -Notes „Vertrauensstellung fuer EAS“ -Identifier „https://mail.asichel.com/Microsoft-Server-ActiveSync/“ -IssuanceAuthorizationRules ‚=>issue(Type = „http://schemas.microsoft.com/authorization/claims/permit“, Value = „true“);‘
  4. Nun kann die Vertrauensstellung der vertrauenden Seite in der ADFS-Konsole eingesehen werden (Bild 3)

Schritt 2 – „ADFS for Rich Clients“-Regel veröffentlichen

Nachdem die passende vertrauenswürdige Applikation im ADFS-Server erstellt wurde, kann diese nun mit einer Regel im Web-Anwendungsproxy verknüpft bzw. veröffentlicht werden. Ich werde zunächst die Schritte in der grafischen Benutzeroberfläche aufzeigen, da die Optionen mit ADFS 4.0 neu hinzugekommen sind.

  1. Anmelden am WAP-Server
  2. Remote-Zugriffsverwaltung öffnen
  3. Im Aktionsmenü unter Aufgaben „Veröffentlichen“ auswählen (Bild 4)
  4. Assistent zum Veröffentlichen neuer Anwendungen öffnet sich:
    1. Willkommen –> Weiter (Bild 5)
    2. Vorauthentifizierung: „Active Directory Verbunddienste“ auswählen –> Weiter (Bild 6)
    3. Unterstützte Clients: „HTTP Basic“ auswählen –> Weiter (Bild 7)
    4. Vertrauende Seite: „ActiveSync“ auswählen –> Weiter (Bild 8)
    5. Veröffentlichungseinstellungen: URLs angeben / Zertifikat wählen –> Weiter (Bild 9)
    6. Bestätigung / PowerShell-Befehl –> Veröffentlichen –> (Bild 10)
    7. Regel veröffentlicht (Bild 11)
  5. Fertig

Schritt 2 – Alternative PowerShell

Alternativ kann die Regel auch mit der PowerShell erstellt werden. Dazu muss jedoch der passende Thumbprint des Zertifikats bekannt sein!

Add-WebApplicationProxyApplication -BackendServerUrl 'https://mail.asichel.com/Microsoft-Server-ActiveSync/' -ExternalCertificateThumbprint '25D06B048D838EAD0D13FF7D57F7988460CC4D8E' -ExternalUrl 'https://mail.asichel.com/Microsoft-Server-ActiveSync/' -Name 'Exchange EAS' -ExternalPreAuthentication ADFSforRichClients -ADFSRelyingPartyName 'Active Sync'

Somit ist die Regel im Web-Anwendungsproxy veröffentlicht.

12_ADFS_for_RichClients_rule_EAS

Auch der Remote Connectivity Analyzer ist zufrieden (Bild 13), desweiteren wird selbstverständlich auch das Gerät in der User Mailbox angezeigt (Bild 14).

Fazit:

Das Veröffentlichen der Regel für EAS ist einfach umzusetzen, sofern ADFS und WAP bereits im Einsatz sind. Macht man sich die PowerShell zunutze, sind es sogar nur zwei Befehle! Zudem können mit den in ADFS 4.0 eingeführten Zugriffsregeln schnell Benutzergruppen zur Nutzung von EAS berechtigt werden. Einzig die Voraussetzung für Server 2016 ist eine Hürde, da sich diese Funktion in ADFS 3.0 für Server 2012 R2 nicht nachträglich implementieren lässt.

Gruß Andi