Exchange On-Premises: Modern Authentication

In den letzten Artikeln haben wir uns bereits über die Multi Faktor Authentifizierung (kurz MFA) in der Office365 Welt unterhalten. Dank der guten Integration ist es ein leichtes, von den zusätzlichen Sicherheitsfunktionen zu profitieren und beispielsweise den eigenen Tenant mittels „Conditional Access“ abzusichern. In diesem Beitrag möchte ich diese Thematik in Hinblick auf eine On-Premises Exchange Organisation beleuchten. Viele Unternehmen betreiben aus verschiedensten Gründen den Exchange in der eigenen Infrastruktur und verzichten auf Exchange Online. Auch diese Unternehmen können von Modern Authentication profitieren und ihren Zugriff auf die lokale Exchange Umgebung zusätzlich absichern. Welche Voraussetzungen hierfür gelten und wie sich diese zusätzliche Schicht implementieren lässt, schauen wir uns in den folgenden Zeilen etwas genauer an.

 

Modern Authentication Grundlagen

Was ist MA?

Bevor wir in die Umsetzung einsteigen, sollten wir vorab ein paar grundsätzliche Fragen klären. Was ist eigentlich Modern Authentication und wie kann man davon profitieren? Unter Modern Authentication versteht Microsoft grundsätzlich drei Säulen:

  • Authentifizierung: Multi Faktor Authentifizierung, Client-Zertifikatauthentifizierung, …
  • Autorisierung: Microsofts hauseigene Implementierung des OAuths Standards
  • Bedingter Zugriff: Zugriff auf bestimmte Ressourcen anhand verschiedener Regelsätzen und Metriken

Es ist also ein Sammelbegriff, welcher die „moderne“ Authentifizierungs-, Autorisierungs- und Zugriffssteuerung vereint. Microsoft gibt uns als Administrator bildlich gesprochen eine Werkzeugkiste an die Hand, mit welcher wir die Sicherheit unserer Applikationen (Office365 als auch On-Premises) erhöhen können. Somit können wir die einfache Benutzername/Passwort Authentifizierung durch neue Standards wie z.b. MFA erweitern.

 

Wie funktioniert MA?

Da ich in diesem Beitrag hauptsächlich die Funktion der Modern Authentication bei einer Exchange On-Premises Umgebung beleuchten möchte, reduziere ich meine Ausführung auch genau darauf. MA funktioniert neben Exchange auch mit Skype for Business On-Premises. Die Authentifizierung funktioniert dort grundsätzlich ähnlich unterscheidet sich aber im Detail etwas.

Aktiviert man MA innerhalb einer Exchange On-Premises Umgebung, so findet die Authentifizierung des Users auch weiterhin in der On-Premises Umgebung statt. Die Autorisierung verlagert sich dabei allerdings in die Microsoft Azure Welt. Meldet sich ein Nutzer im Outlook an, so wird sein Request durch den Autodiscover-Record auch weiterhin am On-Premises Exchange terminieren. Die eigentliche Autorisierung, bei der auch ein spezieller Token ausgestellt wird, findet in Azure statt. Zum besseren Verständnis schauen wir uns das anhand eines Beispiels ein.

 

In unserem Beispiel möchten wir mittels Outlook auf unser On-Premises Exchange Postfach zugreifen. Unser Azure AD Connect arbeitet dabei mittels Password-Hash Synchronization oder Pass-Through Authentication. Der Weg über ADFS (Active Directory Federation Services) beinhaltet noch weitere Schritte, die ich hier nicht näher aufführe. Wer mit den vorhin genannten Schlagwörtern auf Anhieb nichts anfangen kann, kann sich folgende Anleitung aus dem Hause Microsoft anschauen: Authentication for Azure AD hybrid identity solutions – Active Directory | Microsoft Docs

Die Authentifizierung und Autorisierung findet dabei in folgenden Schritten statt.

  1. Outlook erreicht über den Autodiscover-Record den lokalen Exchange und teilt diesem mit, welche Authentifizierungsmethoden der Client unterstützt. Da unser Client ein Outlook 2013 (oder neuer) ist, teilt er dem Exchange über den Header mit, dass er unter anderem auch „OAUTH“ unterstützt. Die Anfrage findet in Form einer „Bearer Challenge“ statt.
  2. Wenn unser Exchange bereits Modern Authentication unterstützt, antwortet er dem Client wie gewohnt mit einer 401 (Unauthorized) Challenge-Response. Dieser 401-Challenge-Response beinhaltet außerdem den „WWW-Authenticate: Bearer“ Header und die Autorisierungsstelle (authorization_uri). Somit weiß der Client, dass der Server Modern Authentication unterstützt und bei welchem Server er sich dafür authentifizieren muss.
  3. Der Client stellt nun eine Verbindung zum OAUTH Server her (evoSTS Microsoft Service). Je nach Konfiguration des Conditional Access wird nun der Benutzername, Passwort und die Multi Faktor Authentifizierung abgefragt. Nach erfolgreicher Validierung aller Parameter geht es zum nächsten Schritt. Ansonsten wird dieser Vorgang wiederholt oder ggf. abgebrochen. Da unsere Nutzer in der Azure AD Cloud residieren, arbeitet der evoSTS (Security Token Service) eng mit dem Azure-AD zusammen.
  4. Konnte die Authentifizierung erfolgreich beendet werden, sendet der evoSTS dem Client einen entsprechenden Bearer-Token zu.
  5. Der Client meldet sich nun mit dem soeben empfangenen Bearer-Token beim lokalen Exchange Server.
  6. Der Exchange validiert diesen Token und gibt den Zugriff frei.

Man merkt, dass die Schritte 2-5 durch die Modern Authentication zusätzlich hinzugekommen sind. Außerdem sollte auffallen, dass die Authentifizierung nun eng mit den Microsoft Diensten verknüpft ist. Das bedeutet, wenn der evoSTS Dienst ein Problem hat, können sich auch Exchange On-Premises Nutzer nicht mehr anmelden. Administratoren haben allerdings die Möglichkeit diese Modern Authentication temporär wieder zu deaktivieren. Somit meldet sich der Client erneut beim Exchange und lässt die Schritte mit den Azure-Services aus. Solche Szenarien sollten aber bestenfalls bereits im Vorfeld ausgiebig getestet werden.

 

Was verändert sich für den Nutzer?

Wir wissen nun, wie der technische Ablauf der Modern Authentication aussieht. Doch was ändert sich für den Nutzer? Im Grunde nicht all zu viel. Normalerweise erscheint bei der Einrichtung eines Exchange Postfaches im Outlook das standardmäßige und altbekannte „Windowsanmeldefenster“. Dieses wird nun durch einen Mini-Webbrowser ersetzt. Ich denke, jeder ist schonmal in Berührung mit dem Office365-Authentifizierungsfenster gekommen. Hierüber würde auch die MFA gesteuert werden, falls diese aktiviert ist.

 

Nachdem wir nun die theoretischen Grundlagen geklärt haben, schauen wir uns auf der nächsten Seite die Umsetzung an.

You may also like...

Abonnieren
Benachrichtige mich bei
guest
2 Comments
Älteste
Neuste Meist bewertet
Inline Feedbacks
View all comments
J. E. Klasek
J. E. Klasek
1 Jahr zuvor

Schöne Übersicht, leider nur etwas getrübt durch die Falschschreibung von „on-premises“ (das „s“ fehlt überall). 😉

2
0
Hinterlass' doch deine Meinung zu diesem Artikelx