Die Besonderheit einer Exchange Hybrid-Konfiguration ist, so zu konfigurieren, dass ein SSO (Single Sign-On) für jeden Benutzer möglich ist, egal wo sein Postfach liegt. Auch wenn manche Postfächer in der Cloud liegen (Exchange Online) wird die Authentifizierung und Autorisierung durch das On-Premises (lokale) Active Directory mit Unterstützung von AD FS (AD Federation Service) ermöglicht. AD FS 4.0 (2016) bietet viel mehr Möglichkeiten sowohl für die Konfiguration von Authentifizierung als auch Autorisierung.

Der Kurs wird mit einer echten Azure Subscription On-Premise Domäne (<Tenant Verzeichnis>.onMicrosoft.com) und Office 365 E3 praktiziert, sodass On-Premises Postfächer in Azure Office 365 hin und zurück verschoben werden können:

• On-Boarding Mailbox Move » Verschieben On-Premises Mailbox auf Exchange Online
• Off-Boarding Mailbox Move » Verschieben Exchange Online Mailbox zurück zu On-Premises

Für den Kurs wird ein Public SSL Zertifikat für die Sicherung des HTTP-Transports zwischen On-Premises und Azure Office 365 Komponenten eingesetzt.

Exchange Hybrid erlaubt die Nutzung von Global Address Lists (GAL) und Free/Busy für alle Postfach-Benutzer (On-Premises und Exchange Online). Auch auf die bestehenden On-Premises Public Folder kann von allen Benutzern zugegriffen werden. Durch die Verzeichnissynchronisation (DirSync) durch AADConnect werden ausgewählte AD Benutzerobjekte des lokalen AD Forests/On-Premises Domäne in die angelegte Azure Federation Domäne <Tenant Verzeichnis>.onMicrosoft.com repliziert. Wie wir im Kurs noch sehen werden, steckt hinter dieser Federated Domäne eine OU in einer Microsoft Domäne (z.B. EURPR01A005.Prod.Outlook.com). Die Federated Domäne wird auch als Azure AD Verzeichnis oder Tenant bezeichnet.

Damit SSO möglich ist, wird in dieser Enterprise Umgebung neben Azure AD Connect eine hochverfügbare AD FS Struktur (AD FS Serverfarm + WAP Farm) verwendet, die zusammen mit Active Directory und Azure AD für die SSO Authentifizierung der Benutzer zuständig ist. Die On-Premises AD FS (Claims Provider) arbeiten mit dem Microsofts ACS (AD Access Control) als Relying Party zusammen, um die Authentifizierung und Autorisierung auf Exchange Objekte zu ermöglichen. Der ACS Authorization Server wird nach und nach durch den neuen EvoSts Auth Server ersetzt.

Für die Autorisierung wird das Protokoll OAuth2 eingesetzt. Dieses neue Autorisierungsprotokoll kann mit allen webbasierten Clients und Access Token Formaten arbeiten, wobei das neue sehr kompakte JSON Web Token (JWT) eingesetzt wird. Das OAuth 2.0 Authorization Framework (RFC6749) ist äußerst flexibel, wenn es darum geht, Zugriff auf fremde Ressourcen durch Delegation zu ermöglichen. Man könnte dies mit der Kerberos Delegation in einem Double-Hop Szenario vergleichen, wo die geschätzte Ressource nicht lokal, sondern irgendwo remote liegt. Während Kerberos innerhalb eines AD Forests und Trusted Forests beschränkt ist, kann OAuth 2.0 zusammen mit AD FS für alle Webbasierten Anwendungen wie EWS eingesetzt werden. Der Zugriff kann von überall erfolgen, egal ob der Benutzer On-Premises in einer Trusted AD Umgebung ist oder von der Cloud wie Facebook, Google Open ID, Windows Live ID kommt. Die notwenigen Trusts der „fremden“ Parteien werden über X.509 Zertifikat geregelt.

In einer AD FS Welt ist eine Claims Based Web Application (CBWA) nicht für die Authentification zuständig. Sie überlässt diese Aufgabe durch den Relying Party Trust einem AD FS Server (Security Token Server), der die Authentifizierung im Namen des Benutzers an einem Domain Controller durchführt. Nach der Authentifizierung bekommt der Benutzer (Browser bzw. Anwendung) ein Security Token (SAML 1.x oder 2.0) mit den notwendigen Claims um auf die CWBA zuzugreifen. Wenn jedoch Zugriff auf z.B. den Terminkalender eines anderen Benutzers für Free/Busy benötigt wird, ist ein Federation Protokoll wie WS-Federation oder SAML ungeeignet. Hier kommt das neue OAuth2 Authorization Protokoll ins Spiel. In einem OAuth2 Szenario ist der AD FS 4.0 ein Authorization Server, der für die OAuth2 Clients die Access Token und Refresh Token ausstellt. Bei OAuth2 sind vier Parteien beteiligt: Vereinfacht dargestellt, muss der User-Agent (Web Browser, Smart-Client) eines Benutzers (OAuth2 Resource Owner) zuerst für den OAuth2 Client (Web Server, Web Service) einen Authorization Grant (code) für den Zugriff auf eine geschützte Resource (Terminkalender) vom OAuth2 Authorization Server holen. Mit diesem Authorization Code kann der Client (Web Server) das gewünschte OAuth2 Access Token (JSON Web Token) und optional das Refresh Token vom OAuth2 Authorization Server bekommen, mit dem der Client auf die geschützte Resource auf einem OAuth2 Resource Server zugreifen kann. Damit die Authentifizierung und Autorisierung durch eine einzige Benutzeranmeldung funktioniert, arbeiten der On-Premises AD FS Server und der Microsofts OAuth2 Authorization Server (ACS/EvoStS) ständig zusammen. Es ist ziemlich komplex, wenn man versucht, die verschiedenen „Flows“ zwischen diesen Komponenten zu analysieren.

Im späteren Verlauf des Kurses werden wir die Authentifizierung von ADFS zur Pass-Through Authentication umstellen, um die Authentifizierungsanfragen über den Azure Service Bus von Azure AD nach On-Premises AD durchzureichen. Somit wird statt ADFS, Web Application Proxy und SQL nur noch ein Agent auf einem Server (standardmäßig auf dem AAD Connect Server) benötigt, um die Authentifizierung durchzuführen. Empfohlen werden hier mindestens drei Agents, um eine gewisse Ausfallsicherheit zu erzielen.

Nachdem die Authentifizierung vom lokalen ADFS zu Microsoft Azure umgestellt wurde, kann Azure Conditional Access voll genutzt werden. Durch Microsoft Intune wird die Compliance der Hybrid Azure AD Joined Windows 10 Clients bestimmt. Nur Compliance und Managed Geräte lassen Benutzer mit bestimmten Zugriffsprotokollen (z.B. OWA, EAS usw.) auf ihr eigenes Postfach zugreifen. Um dieses Zusammenspiel von Microsoft Intune und On-Premise Ressourcen zu ermöglichen, muss sowohl das Device Writeback als auch der Intune Connector eigerichtet sein.

Durch die Zusammenarbeit mit Exchange Online kann der bisherige eingehende Mail Flow via MX-Records auch anders gestaltet werden. Wenn die mächtigen Schutzmechanismen von EOP (Exchange Online Protection) gegen Viren, Spams, etc. genutzt werden sollen, kann der eingehende Mail Flow zu EOP umgeleitet werden. In der Regel besitzen Enterprise Unternehmen diverse Mechanismen, um E-Mails zu schützen. Für kleinere Unternehmen kann der EOP Einsatz sehr sinnvoll sein. Alle eingehende E-Mails werden zuerst durch EOP geschleust, bevor diese an die On-Premises und Online Postfächer geleitet werden.

Das SSO (Single-Sign On) Problem beim Zugriff auf ein Office 365 Postfach wurde erst mit der Verfügbarkeit der „Modern Authentication“ (Mitte Mai 2016) durch die Neuimplementierung der Office 365 Authentication an Azure AD auf ADAL (Active Directory Authentication Library) beseitigt. Wenn man sich On-Premises mit einem Office 365 Postfach anmelden möchte, kommt immer ein Anmelde-Fenster (ohne Modern Authentication). Das geschieht sowohl bei einem Domain Member mit Postfach in Azure als auch bei einem Benutzer, der an einem via Workplace Join eingeklinkten Gerät arbeitet. Für Outlook 2016 ist die Modern Authentication standardmäßig aktiviert, lediglich ist nur noch eine Aktivierung in Exchange Online notwendig. Für Outlook 2013 wird ein Registry-Key benötigt.

Office 365 Groups sind eine neue Art von Gruppe (Unified Group). Sie vereinen (unify) sämtliche Office 365 Dienste (Exchange Shared Mailbox, OneDrive, Microsoft Teams, etc.) und stellen diese Dienste ihren Mitgliedern zur Verfügung. Standardmäßig können Office 365 Gruppen von jedem Benutzer, dessen in Exchange Online liegt, erstellt werden. Daher ist es ratsam, von Anfang an eine passende Email Address Policy „groups.<domain>.de“ zu definieren. Möchte man die Verwaltung von Office 365 Gruppen auf Administratoren beschränken, so können Azure AD Settings das Erstellen von Office 365 Gruppen für Benutzer tenant-weit verbieten. Außerdem ist es per Azure AD Policy möglich, Gastkonten aus fremden Email Umgebungen (web.de, gmail etc.) den Zutritt zu Office 365 Gruppen zu ermöglichen. Gastkonten haben nur eingeschränkten Zugriff auf Office 365 Gruppen, können per Azure AD Setting jedoch auch komplett verboten werden.

Aufbau der Exchange Hybrid Infrastruktur:

• SSL Public Zertifikat » bereits vorhanden, anzeigen der Subject Alternate Name (SAN)
• Azure Subscription und Office Subscription » wird demonstriert, wie es gemacht wird.
• Aufbau des internen AD FS mit NLB
• Aufbau des WAP (Web Application Proxy) mit NLB
• Aufbau und Konfiguration AAD Connect (DirSync) mit Staging Server
• Hybrid Configuration Wizard (HCW)
• Überprüfen und untersuchen der angelegten Objekte (Connectors, Accepted Domains, E-Mail Policy etc.)
• Analyse der OAuth2 Konfiguration: Authorization Server ACS & EvoSts
• Umstellung der Authentifizierung von AD FS zu Pass-Through Authentication

Praktische Übungen:

• Mailbox Flow (Centralize On-Premises) und via EOP (Exchange Online Protection)
• Onboarding Mailbox Move – Postfach (On-Premises) in Exchange Online verschieben
• Offboarding Mailbox Move – Postfach (Exchange Online) – zurück zu On-Premises
• Anlegen eines neuen Postfachs in Exchange Online und danach verschieben in On-Premises
• Anlegen von Ressource Postfächern,Share Mailbox, Address Lists, Distribution Groups (Distribution Lists)
• Office 365 Groups Administration und Gastzugriff
• Terminkalender Free/Busy
• Zugriff auf Public Folder
• Umleitung On-Premises (Centralized) Mail Flow auf EOP
• Azure Conditional Access
• Monitoring & Troubleshooting – Reports