OWA mit WAP und Azure-Multifaktor-Authentisierung veröffentlichen

In diesem Artikel zeige ich, wie OWA und ECP mit der Web-Application-Proxy-Rolle von Windows Server 2012 R2 und Azure-Multifaktor-Authentisierung veröffentlicht werden können.

Wer meine bisherigen Artikel gelesen hat, weiss, dass ich Prä-Authentisierung in der DMZ nicht als zwingend notwendig erachte. Allerdings gibt es eine Ausnahme: Wenn Authentisierung mit mehreren Faktoren verwendet werden soll, bevorzuge ich es, wenn keine zusätzliche Software auf den Exchange Servern installiert werden muss und somit der Reverse Proxy die Aufgabe übernimmt.

Dank der nativen Unterstützung für ADFS Claims für OWA und ECP in Exchange 2013 SP1 ist die Integration nun relativ einfach. Das folgende Schema verdeutlicht, welche Komponenten benötigt werden:

Ich gehe in meiner Beispielumgebung Fabrikam.com davon aus, dass AD und Exchange schon vorhanden sind und korrekt konfiguriert wurden. Insbesondere müssen die URLs für internen bzw. externen Aufruf von OWA und ECP festgelegt und die Zertifikate entsprechend ausgestellt und konfiguriert worden sein. In meinem Beispiel wird Split-DNS verwendet mit mail.fabrikam.com als Namespace und einem Wildcard-Zertifikat. Besonders letzteres vereinfacht die Konfiguration, da auf allen Servern das gleiche Zertifikat verwendet werden kann. Allerdings gelten Wildcard-Zertifikate als unsicherer, da damit jeder FQDN abgedeckt wird. Dem Schutz des Zertifikats und vor allem des privaten Schlüssels gilt es dementsprechend viel Beachtung zu schenken.

Die Installation wird in diesen Schritten durchgeführt:

1. ADFS Server
2. WAP
3. Exchange-Konfiguration
4. Test ADFS-Authentisierung
5. MFA Server
6. Test Multi-Faktor-Authentisierung

Installation und Konfiguration der ADFS-Rolle

Ich werde in meinem Beispiel nur einen ADFS Server installieren. In produktiven Umgebungen ist es ratsam, zur Ausfallsicherheit mindestens zwei Server und einen Loadbalancer einzusetzen. Als Betriebssystem kommt Windows Server 2012 R2 zum Einsatz, da WAP nur mit Version 3.0 von ADFS zusammenarbeitet.

Der ADFS Server muss Mitglied der Domäne sein und WAP/ADFS können nicht auf dem gleichen Server installiert werden.

Nach der Installation kann über den Server Manager die Konfiguration gestartet werden:

Der ausführende Benutzer benötigt Domain-Admin-Rechte. Als Nächstes muss das Zertifikat für die HTTPS-Verbindung angegeben werden. Falls sich dieses nicht schon im Computer-Store befindet, kann es im Wizard importiert werden:

ACHTUNG: Der Federation Service Name wird im Falle eines Wildcard-Zertifikats automatisch mit *.domainname ausgefüllt und der Wizard meldet einen Fehler. Der Federation-Service-Name muss ein gültiger FQDN – unterschiedlich vom Computernamen – und in DNS auflösbar sein.

Der Service Account kann ein Group Managed Service Account sein oder ein normaler Domänenbenutzer. Allerdings ist der GMSA zu bevorzugen, da das Management der Passwortänderungen komplett entfällt und auch keine Probleme auftreten können, wenn ein Admin das Passwort versehentlich ändert. Falls dies der erste GMSA ist, muss zuerst noch ein Schlüssel generiert werden Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

ADFS benötigt eine Datenbank. Für Umgebungen mit maximal 5 Servern kann die Windows Internal Database verwendet werden. Allerdings gibt es dann ein paar Einschränkungen in der Funktionalität (SAML artifact resolution/token replay detection), die für unser Szenario aber nicht relevant sind.

Jetzt müssen die Relying Party Trusts eingerichtet werden – je einer für OWA und ECP. Klicken Sie sich für die Schritt-für-Schritt-Anleitung durch die Bildergalerie. Um die ganzen Bilder mit Beschreibung zu sehen, klicken Sie aufs Bild und gehen danach weiter über die Pfeile.

photos

Damit ist die Konfiguration von ADFS abgeschlossen. Allerdings muss noch sichergestellt werden, dass dem Token-Signing-Zertifikat von allen Exchange Servern vertraut wird. Falls es selbstsigniert ist, kann es aus der ADFS MMC aus angezeigt und als .CER-Datei exportiert werden:

Danach wird es manuell oder per GPO in den Computer Store aller Exchange Server importiert:

Installation und Konfiguration der Web-Application-Proxy-Rolle

Für bestimmte Szenarien mit Kerberos Constraint Delegation muss die WAP-Rolle auf einem Domänenmitglied installiert werden. Da wir aber Claims-based Authentication verwenden, ist dies weder nötig noch erwünscht. Zur Wahrung der Sicherheit sollte das Active Directory nie in die DMZ ausgedehnt werden!

Als Erstes muss ein Zertifikat mit den passenden Namespaces (hier: adfs.fabrikam.com, mail.fabrikam.com – abgedeckt durch ein Wildcard-Zertifikat *.fabrikam.com) installiert werden, da der Wizard keinen Import anbietet wie bei ADFS.

Die Schritt-für-Schritt-Anleitung finden Sie in der Bildergalerie:

photos

Konfiguration von Exchange

Die Exchange-Konfiguration besteht aus zwei Schritten:

Konfiguration der Organisation für ADFS mit diesem Exchange-Management-Shell-Kommando:

Der Thumbprint des Zertifikats wird dabei auf dem ADFS Server mit diesem PowerShell-Befehl ausgelesen und kopiert:

Konfiguration der virtuellen Verzeichnisse für OWA und ECP. Dabei wird ADFSAuthentication auf True gesetzt und alle anderen Verfahren auf False:

IIS muss danach neu gestartet werden. Diese Konfiguration muss auf allen CAS- oder Multirole Servern durchgeführt werden.

Zugriff auf OWA und ECP von intern und extern testen

Nun kann der Zugriff getestet werden. Standardmässig geschieht die Authentisierung in ADFS intern per Windows Integrated Authentication. Achtung: Die ADFS URL muss im Browser in der Zone «Local Intranet» erfasst sein, damit der Browser automatisch Anmeldeinformationen sendet.

Wenn alles korrekt konfiguriert ist, wird keine Passwortabfrage erscheinen, sondern direkt die Mailbox in OWA geöffnet.

Extern wird Forms-based Authentication verwendet, weswegen das Passwort über die ADFS-Seite abgefragt wird:

 

Installation des MFA Servers auf ADFS

Der MFA Server kann von Microsofts Azure-Portal heruntergeladen werden. Dazu muss mindestens ein Testkonto eingerichtet werden. Nach der Anmeldung kann unter «Active Directory» MFA oder «Anbieter für mehrstufige Authentifizierung» konfiguriert werden. Klicken Sie in die Bildergalerie für die Anleitung:

photos

 

Nach Neustart des ADFS-Dienstes können Benutzer aus Active Directory importiert und konfiguriert werden. Dabei ist es natürlich von Vorteil, wenn im AD die Telefonnummern schon eingetragen wurden, aber sie lassen sich auch direkt in der MFA-Konsole hinzufügen.

Dabei können verschiedene Default-Einstellungen vorgenommen werden, wie zum Beispiel die Art der Authentisierung (per Telefonanruf, SMS oder App) oder welche Sprache in der Kommunikation verwendet werden soll.

In Fabrikam wurde nur für den Exchange Admin importiert, da nur eine Telefonnummer zur Verfügung steht.
In ADFS muss jetzt noch definiert werden, für welche Benutzer in welchen Szenarien MFA verwendet werden soll. Dies wird in den Authentication Policies entweder global oder pro Relying Party Trust konfiguriert. Im Falle von Fabrikam geschieht dies global, da für OWA und ECP die gleichen Einstellungen gelten sollen.

Nach der Registrierung des ADFS Adapters steht als Methode WindowsAzureMultiFactorAuthentication zur Verfügung:

Mit der vorliegenden Konfiguration ist Multifaktor-Authentisierung nur bei Zugriff von extern über den WAP nötig. Im LAN wird zur Vereinfachung für die Benutzer weiter Windows Integrated Authentication verwendet.

Test der Multifaktor-Authentisierung

Nach Klick auf «Weiter» wird ein SMS an das konfigurierte Mobiltelefon versendet. Der darin enthaltene Code muss dann in einer Antwort auf das SMS zurückgeschickt werden. Sobald die Antwort verifiziert ist, wird der Browser auf die Mailbox weitergeleitet:

Weitere Informationen

Für die Multifaktor-Authentisierung bietet Microsoft zwei Preismodelle an:

• Pro Benutzer (fixer Betrag pro Monat / unlimitierte Anzahl Authentisierungen)
• Pro Authentisierung (fixer Betrag pro 10 Authentisierungen)

Als alternative Methoden zu SMS werden angeboten:

• Telefonanruf mit Ansage / Drücken der #-Taste als Bestätigung
• App für Windows Phone, iPhones/iPads oder Android-Geräte. Dafür wird aber noch ein spezieller MFA Mobile App Web Service benötigt.

Noch ist es nicht möglich, MFA für Outlook Anywhere, MAPI/HTTP oder ActiveSync zu verwenden. Falls erhöhte Sicherheit der Grund für den Einsatz von mehreren Faktoren der Authentisierung ist, müssen erwähnte Zugriffsmethoden entweder unterbunden oder per VPN und MFA abgesichert werden.