Microsoft Exchange 2013: OWA mit Zertifikat-basierter Authentifizierung
Mit OWA (Outlook Web App) ist keine Authentifizierung per Zertifikat/Smartcard möglich? Dem ist nicht mehr so. Seit Exchange 2013 SP1 wird von OWA und ECP nativ ADFS-basierte Authentifizierung unterstützt und in ADFS kann granular konfiguriert werden, wer sich woher wie anmelden muss. Lesen Sie in diesem Beitrag, wies geht.
Vor Kurzen war ich bei einem sicherheitsbewussten Kunden. Es kam zur Sprache, dass OWA (Outlook Web App) nicht eingesetzt werde, weil keine Authentifizierung per Zertifikat/Smartcard möglich sei. Nun: Seit Exchange 2013 SP1 wird von OWA und ECP nativ ADFS-basierte Authentifizierung unterstützt und in ADFS kann granular konfiguriert werden, wer sich woher wie anmelden muss.
Die Ausgangslage
- 1 DC mit Windows Server 2012 R2 und den Rollen Certificate Services und Federation Services installiert
- 1 Windows 2012 R2 Server mit Exchange 2013 CU6
- 1 Windows 8.1 Client
Die Konfigurationsschritte:
ADFS Relying Party einrichten
In der ADFS-Management-Konsole muss je ein Relying Party Trust für OWA und ECP erstellt werden:
 |
Microsoft Exchange TrainingsFür mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. |
Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.
Die Daten müssen manuell eingegeben werden. Trusts zwischen zwei ADFS Servern können hingegen oft über die Metadaten-URL des Partnerservers konfiguriert werden:
Die Eingabe des Display-Namens ist nur zu Informationszwecken – sollte aber aussagekräftig sein, da er zum Beispiel bei der Konfiguration eines WAP Server für die Veröffentlichung ins Internet automatisch aufgelistet wird:
Der Trust muss nicht abwärtskompatibel sein:
Die Verschlüsselung der Claims ist auch nicht nötig – die nächste Eingabemaske kann also leer bleiben:
Da für OWA/ECP ein passiver Zugriff über einen Browser verwendet wird, muss WS-Fed gewählt und die entsprechenden URLs eingegeben werden:
Damit der ADFS Server anhand der Webrequests erkennt, welche Trustkonfiguration verwendet werden soll, muss der Identifier (entspricht wiederum der URL) eingegeben werden, respektive wird dieser anhand der WS-Fed URL vom letzten Schritt automatisch übernommen:
Es wird keine Multi-Faktor-Konfiguration benötigt:
Es lässt sich in ADFS noch weiter einschränken, unter welchen Bedingungen ein Zugriff stattfinden darf. Im Assistent stehen aber nur die Optionen «Zugriff für alle» oder «Kein Zugriff» zur Verfügung. Dies kann später manuell verfeinert werden. Im Test wird der Zugriff für alle erlaubt:
In der nächsten Maske muss nichts angepasst werden:
Die Regeln, welche Claims für diesen Trust ausgestellt werden, können sofort oder erst später hinzugefügt werden. In diesem Beispiel öffnen wir den Assistenten sofort:
Insgesamt werden 3 Custom Rules benötigt:
Das Resultat sind die beiden Relying Party Trusts für OWA und ECP. Der Device Registration Service ist standardmässig in ADFS auf Windows Server 2012 R2 schon vorhanden.
ADFS Primary Authentication auf Certificates ändern
In der Grundkonfiguration verwendet ADFS für interne Clients Windows Integrated Authentication und für externe (über Web Application Proxy empfangene Anforderungen) Forms-based Authentication. Um dies zu ändern, muss die Global Primary Authentication geändert werden:
Im folgenden Screenshot ist ersichtlich, dass zwischen Extranet und Intranet unterschieden wird. Technisch wird das erreicht, indem Zugriffe über WAP extern sind und solche direkt über den ADFS Server intern. Dies liesse sich aber auch noch über Issuance Authorization Rules verfeinern – zum Beispiel mit bestimmten IP Ranges, in denen die Clients liegen.
Exchange OWA/ECP Authentisierung von FBA auf ADFS ändern
In Exchange wird für die virtuellen Verzeichnisse von OWA und ECP die Authentisierungsmethode auf ADFS geändert. Dies schliesst alle anderen Verfahren aus. Zuerst ECP anpassen, danach OWA – sonst schlägt die Konfiguration fehl:
IISreset kann mit dem standardmässigen Timeout von 20 Sekunden fehlschlagen, weswegen der Parameter /Timout:120 hinzugefügt wird:
Token-Signing Certificate des ADFS Servers auf Exchange den Trusted Root CA hinzufügen
Der Exchange Server benötigt im Trusted Root Certification Authority Store des Computer Accounts das Token-Signing Zertifikat des ADFS Servers. Dieses kann in der ADFS-Management-Konsole angezeigt und dann exportiert werden:
In Exchange wiederum wird es importiert:
Exchange benötigt nun noch Informationen, damit die ADFS-basierte Authentifizierung klappt: die URL des Services (hier: https://sts.coho-vineyard.com/adfs/ls/), die URLs der lokalen Dienste, die den Service nutzen sollen, sowie den Fingerabdruck des vorher importierten Token-Signing Certificates. Dieser lässt sich mit folgendem PowerShell-Befehl finden und in die Konfiguration kopieren:
Testen des Zugriffs
Das Gerät für den Zugriff muss nicht zwingend Mitglied der Domäne sein. Allerdings benötigt der angemeldete Benutzer ein Zertifikat, das mit den AD-Account und der Zielmailbox korrespondiert. Dieses wurde von der internen CA ausgestellt und mit Private Key exportiert/importiert.
Wenn im Browser die URL von OWA/ECP eingegeben wird, leitet Exchange diesen auf die URL von ADFS um und die Auswahl der Zertifikate wird angezeigt:
Eventuell wird beim ersten Zugriff auf den Private Key um Erlaubnis gefragt:
Danach wird der Browser wieder auf die OWA/ECP URL zurückgeleitet, wo er sich mit dem Token des ADFS Servers anmelden kann.
Falls die Revocation List der CA nicht zugänglich ist, kommt vorher noch diese Warnmeldung
Falls der Client nicht Domänen-Mitglied ist, muss die Revocation List per HTTP(S) zur Verfügung gestellt werden, oder im Browser muss der Revocation Check deaktiviert werden (nicht empfohlen):
Test des Zugriffs mit Smartcard
Da in meiner Testumgebung keine physischen Smartcards und Reader vorhanden sind, bin ich auf virtuelle Smartcards – ein Feature in Windows 8.x – ausgewichen. Nach Eingabe der URL im Browser erscheint ebenfalls die Auswahl, allerdings mit der weiteren Option des Zertifikats auf der Smartcard:
Danach muss für den Zugriff auf den Private Key noch der Pin eingegeben werden:
Fazit
Der Einsatz von ADFS mit Exchange bietet den Vorteil von erweiterten Authentisierungsmethoden, die noch granular angepasst werden könnten (z.B. nur registrierte Geräte, nur bestimmte Benutzergruppen).