Aktivieren der modernen Authentifizierung in Exchange lokal

Artikel
05/06/2023

Übersicht

Mit der Veröffentlichung von Exchange Server 2019 CU13 unterstützt OAuth 2.0 Exchange Server (auch als moderne Authentifizierung bezeichnet) für reine lokale Umgebungen, die AD FS als Sicherheitstokendienst (STS) verwenden. Dieses Dokument enthält die Voraussetzungen und Schritte zum Aktivieren dieses Features.

Die moderne Authentifizierung in Exchange Server 2019 sollte nicht mit der modernen Hybridauthentifizierung verwechselt werden, die Microsoft Entra ID für die moderne Authentifizierung verwendet. Tatsächlich ist HMA immer noch die einzige empfohlene Methode, um die moderne Authentifizierung für alle lokalen und Cloudbenutzer in einer Exchange-Hybridkonfiguration zu aktivieren. Dieses neue Feature ermöglicht die Verwendung der modernen Authentifizierung durch Kunden, die nicht über microsoft Entra ID verfügen oder sich nicht in einer Exchange-Hybridkonfiguration befinden.

Wie funktioniert die moderne Authentifizierung, und gilt dieses Feature für mich?

Mit der modernen Authentifizierung können sich Benutzer mithilfe von AD FS bei Exchange authentifizieren. Wenn die moderne Authentifizierung für einen Benutzer aktiviert ist, wird dessen Outlook-Client an AD FS umgeleitet. Benutzer können sich dann authentifizieren, indem sie Anmeldeinformationen angeben oder eine mehrstufige Authentifizierung durchführen. Sobald AD FS einen Benutzer authentifiziert, generiert es Zugriffstoken. Diese Zugriffstoken werden von Exchange Server überprüft, um Clientzugriff auf das Postfach des Benutzers zu ermöglichen.

Das folgende Diagramm veranschaulicht die Koordination zwischen Exchange Server, AD FS und Outlook zum Authentifizieren eines Benutzers mithilfe der modernen Authentifizierung.

Im obigen Diagramm finden die Schritte 3a, 4a, 5a und 6a statt, wenn die moderne Authentifizierung für den Endbenutzer aktiviert ist. Die Schritte 3b und 4b treten auf, wenn die moderne Authentifizierung für einen Benutzer deaktiviert ist.

In der folgenden Tabelle finden Sie informationen dazu, ob dieses Feature für Sie geeignet ist.

Exchange-Konfiguration	Ist dieses Feature anwendbar?	Hinweise
Lokale Exchange-Organisation mit nur Exchange Server 2019	Ja	Nicht zutreffend
Lokale Exchange-Organisation mit einer Mischung aus Exchange Server 2019, Exchange Server 2016 und Exchange Server 2013	Nein	Exchange Server 2013 wird nicht mehr unterstützt.
Lokale Exchange-Organisation mit einer Mischung aus Exchange Server 2019 und Exchange Server 2016	Ja	Nur Exchange 2019-Server können als Front-End (Clientzugriffsserver) verwendet werden.
Exchange-Hybridorganisation mit HMA	Nein	HMA mit Microsoft Entra ID ist die bevorzugte Lösung. Weitere Informationen finden Sie in der Anleitung zur Verwendung neuer Authentifizierungsrichtlinien.
Exchange-Hybridorganisation ohne HMA	Nein	Verwenden Sie HMA mit Microsoft Entra ID.

Voraussetzungen zum Aktivieren der modernen Authentifizierung in Exchange

Exchange Server 2019 CU13 oder höher

Um die moderne Authentifizierung verwenden zu können, muss exchange Server 2019 CU13 auf allen Servern installiert sein, die für Clientverbindungen verwendet werden.

AD FS 2019 oder höher

Um die moderne Authentifizierung in einer lokalen Exchange-Umgebung zu aktivieren, ist Active Directory-Verbunddienste (AD FS) unter Windows Server 2019 oder höher erforderlich.

Möglicherweise benötigen Sie auch den Webanwendungsproxyserver (unter Windows Server 2019 oder höher), um den Clientzugriff von außerhalb des Unternehmensnetzwerks zu ermöglichen.

Hinweis

Die AD FS-Rolle kann nicht auf einem Exchange-Server konfiguriert werden. Weitere Informationen finden Sie unter Planen der AD FS-Bereitstellungstopologie.

Clientvoraussetzungen

Um die moderne Authentifizierung nutzen zu können, benötigen Benutzer Clientanwendungen wie Outlook oder andere native Betriebssystemclients, die mit der modernen Authentifizierung über AD FS kompatibel sind. Zu Beginn ist dieses Feature für Outlook unter Windows verfügbar. Die Kompatibilität mit ADFS Modern Auth wird jedoch in Zukunft auf andere Outlook-Clients erweitert.

Outlook unter Windows

Unterstützung für moderne Authentifizierung über AD FS ist in den folgenden Versionen von Microsoft Outlook verfügbar:

Outlook in Microsoft 365 Apps:

Kanal	Unterstützt	Version	Build (oder höher)
Insider-Kanal	Ja	2304	16327.20200
Aktueller Kanal	Ja	2304	16327.20214
Monatlicher Enterprise-Kanal	Ja	2304	16327.20324
Halbjährlicher Enterprise-Kanal (Vorschau)	Ja	2402	17328.20184
Halbjährlicher Enterprise-Kanal	Nein	Nicht zutreffend	Nicht zutreffend

Outlook für Windows (Volumenlizenz & Einzelhandel):

Version	Unterstützt	Version	Build (oder höher)
Outlook 2016 (beliebige Version)	Nein	Nicht zutreffend	Nicht zutreffend
Outlook 2019 (beliebige Version)	Nein	Nicht zutreffend	Nicht zutreffend
Outlook 2021 (Einzelhandel)	Ja	2304	16327.20214
Outlook 2021 (Volumenlizenz)	Nein	Nicht zutreffend	Nicht zutreffend

Sie können die Buildnummer Ihres Office überprüfen, indem Sie die hier beschriebenen Schritte ausführen.

Windows-Betriebssystem

Auf dem Windows-Client muss das Update vom 14. März 2023 installiert seinWindows 11 22H2 or later.

Sie können den Windows Update-Verlauf überprüfen, um zu überprüfen, ob KB5023706 installiert ist.

Protokolle, die mit der modernen ADFS-Authentifizierung funktionieren

In der folgenden Tabelle werden die Protokolle beschrieben, auf die mithilfe von ADFS Modern Auth-Token zugegriffen werden kann. Wir arbeiten kontinuierlich daran, ADFS Modern Auth-Unterstützung für weitere Exchange Server-Protokolle hinzuzufügen.

Protokoll	Unterstützte moderne ADFS-Authentifizierung
MAPI über HTTP (MAPI/HTTP)	Ja
Outlook Anywhere (RPC/HTTP)	Nein
Exchange Active Sync (EAS)	Nein (In Bearbeitung)
Exchange-Webdienste (Exchange Web Services, EWS)	Ja
Outlook im Web (OWA)	Ja (anspruchsbasierte Authentifizierung)
Exchange Admin Center (ECP)	Ja (anspruchsbasierte Authentifizierung)
Offline Address Book (OAB)	Ja
IMAP	Nein
POP	Nein

Schritte zum Konfigurieren der modernen Authentifizierung in Exchange Server mit AD FS als STS

Dieser Abschnitt enthält Details zum Implementieren der modernen Authentifizierung in Exchange Server 2019 CU13.

Installieren von Exchange 2019 CU13 auf allen FE-Servern (mindestens)

Alle für Clientverbindungen verwendeten Server müssen auf Exchange 2019 CU13 aktualisiert werden. Dadurch wird sichergestellt, dass anfängliche Clientverbindungen mit Exchange 2019 OAuth verwenden und verbindungen mit Exchange Server 2016 Per Proxy Kerberos verwenden.

Exchange 2019 CU13 fügt Unterstützung für neue Authentifizierungsrichtlinien hinzu, um moderne Authentifizierung auf Benutzerebene zuzulassen oder zu blockieren. Das Blockieren der modernen Authentifizierung wird verwendet, um sicherzustellen, dass Clients, die die moderne Authentifizierung nicht unterstützen, weiterhin eine Verbindung herstellen können.

Die Ausführung /PrepareAD mit Setup ist erforderlich, um Exchange Server mehrere neue Authentifizierungsrichtlinienparameter hinzuzufügen.

BlockModernAuthActiveSync
BlockModernAuthAutodiscover
BlockModernAuthImap
BlockModernAuthMapi
BlockModernAuthOfflineAddressBook
BlockModernAuthPop
BlockModernAuthRpc
BlockModernAuthWebServices

Nach der Installation von CU13 werden die oben genannten Parameter für alle bereits vorhandenen Authentifizierungsrichtlinien (einschließlich der Standardauthentifizierungsrichtlinie) deaktiviert. Dies bedeutet, dass Kunden, die HMA verwenden, ihre bereits vorhandenen Authentifizierungsrichtlinien nicht ändern müssen.

Keine neue Authentifizierungsrichtlinie für Exchange-Hybridkunden erforderlich

Vorhandene Exchange Hybrid-Kunden sollten moderne Hybridauthentifizierung verwenden. Hybridkunden, die HMA verwenden, können die Werte der BlockModernAuth* Parameter bei 0 belassen, um HMA weiterhin zu verwenden. Die beschriebenen Schritte zum Einrichten der modernen Authentifizierung mit AD FS sind nur für Kunden relevant, die Exchange Hybrid nicht verwenden und ausschließlich lokal sind.

Einrichten von Active Directory-Verbunddiensten (AD FS)

Kunden müssen AD FS in der Umgebung installieren und konfigurieren, damit Exchange-Clients die Formularauthentifizierung (OAuth) verwenden können, um eine Verbindung mit Exchange Server herzustellen.

Zertifikatanforderungen für die AD FS-Konfiguration in der Exchange Server-Organisation

ADFS erfordert zwei grundlegende Arten von Zertifikaten (ausführliche Informationen finden Sie in diesem Artikel ):

Ein SSL-Zertifikat (Secure Sockets Layer) für die Dienstkommunikation für verschlüsselten Webdienstdatenverkehr zwischen dem AD FS-Server, Clients, Exchange-Servern und dem optionalen Webanwendungsproxyserver. Es wird empfohlen, ein Zertifikat zu verwenden, das von einer internen oder kommerziellen Zertifizierungsstelle ausgestellt wurde, da alle Clients diesem Zertifikat vertrauen müssen.
Ein Tokensignaturzertifikat für die verschlüsselte Kommunikation und Authentifizierung zwischen dem AD FS-Server, Active Directory-Domänencontrollern und Exchange-Servern. Sie können ein Tokensignaturzertifikat abrufen, indem Sie eines von einer Zertifizierungsstelle anfordern oder ein selbstsigniertes Zertifikat erstellen.

Weitere Informationen zum Erstellen und Importieren von SSL-Zertifikaten in Windows finden Sie unter Serverzertifikate.

Hier ist eine Zusammenfassung der Zertifikate, die wir in diesem Szenario verwenden:

Allgemeiner Name (Common Name, CN) im Zertifikat (in der Übereinstimmung antragsteller, alternativer Antragstellername oder Eines Wildcardzertifikats)	Typ	Auf Servern erforderlich	Kommentare
adfs.contoso.com enterpriseregistration.contoso.com	Von einer Zertifizierungsstelle ausgestellt	AD FS-Server, Webanwendungsproxyserver (optional)	Verbundserver verwenden ein SSL-Zertifikat, um den Webdienstdatenverkehr für die SSL-Kommunikation mit Clients und mit Verbundserverproxys zu schützen. Da das SSL-Zertifikat von Clientcomputern als vertrauenswürdig eingestuft werden muss, empfehlen wir Ihnen, ein Zertifikat zu verwenden, das von einer vertrauenswürdigen ZS signiert wurde. Alle von Ihnen ausgewählten Zertifikate müssen über einen entsprechenden privaten Schlüssel verfügen.
ADFS-Tokensignatur – adfs.contoso.com	Selbstsigniert oder von einer Zertifizierungsstelle ausstellen	AD FS-Server, Webanwendungsproxyserver (optional)	Ein Tokensignaturzertifikat ist ein X509-Zertifikat. Verbundserver verwenden zugeordnete Öffentliche/Private-Schlüsselpaare, um alle von ihnen erzeugten Sicherheitstoken digital zu signieren. Dies umfasst das Signieren von veröffentlichten Verbundmetadaten und Artefaktauflösungsanforderungen. Sie können mehrere Tokensignaturzertifikate im AD FS-Verwaltungs-Snap-In konfigurieren, um einen Zertifikatrollover zu ermöglichen, wenn ein Zertifikat kurz vor dem Ablauf steht. Standardmäßig werden alle Zertifikate in der Liste veröffentlicht, aber nur das primäre Tokensignaturzertifikat wird von AD FS verwendet, um Token tatsächlich zu signieren. Alle von Ihnen ausgewählten Zertifikate müssen über einen entsprechenden privaten Schlüssel verfügen. Sie können ein Tokensignaturzertifikat abrufen, indem Sie eines von einer Unternehmenszertifizierungsstelle oder einer öffentlichen Zertifizierungsstelle anfordern oder ein selbstsigniertes Zertifikat erstellen.
mail.contoso.com autodiscover.contoso.com	Von einer Zertifizierungsstelle ausgestellt	Exchange-Server, Webanwendungsproxyserver (optional)	Dies ist das typische Zertifikat, das zum Verschlüsseln externer Clientverbindungen mit Outlook im Web (und anderen Exchange-Diensten) verwendet wird. Weitere Informationen finden Sie unter Zertifikatanforderungen für Exchange-Dienste.

Bereitstellen und Konfigurieren des AD FS-Servers

Verwenden Sie Windows Server 2019 oder höher, um einen AD FS-Server bereitzustellen. Führen Sie die Folgenden Schritte aus: Bereitstellen eines AD FS-Servers und Konfigurieren und Testen des AD FS-Servers. Stellen Sie sicher, dass Sie die URL der Verbundmetadaten in einem Webbrowser über den Exchange-Server und mindestens einen Clientcomputer öffnen können.

Die URL verwendet die Folgende Syntax:

https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

Beispiel:

https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml

Auswählen der geeigneten SSO-Lebensdauer

Wählen Sie eine geeignete SSO-Lebensdauer aus, damit Endbenutzer sich nicht häufig erneut authentifizieren müssen. Um eine SSO-Lebensdauer zu konfigurieren, öffnen Sie die AD FS-Verwaltung auf dem AD FS-Server, und wählen Sie Edit Federation Service Properties Aktionen aus (auf der rechten Seite des AD FS-Verwaltungsfensters vorhanden).

Geben Sie die Web SSO lifetime (minutes)ein. Dies ist die maximale Zeit, nach der Benutzer sich erneut authentifizieren müssen.

Konfigurieren der Authentifizierungsmethode in AD FS

Um die moderne Authentifizierung in Outlook unter Windows verwenden zu können, müssen Sie primäre Authentifizierungsmethoden konfigurieren. Es wird empfohlen, die Formularauthentifizierung sowohl für Extranet als auch für Intranet auszuwählen, wie unten gezeigt.

Aktivieren der Geräteregistrierung in AD FS

Überprüfen Sie in der Übersicht über die Geräteregistrierung, ob die Geräteregistrierung konfiguriert und die Geräteauthentifizierung aktiviert ist. Dieser Schritt wird empfohlen, um die Anzahl der Authentifizierungsaufforderungen für Benutzer zu reduzieren und zugriffssteuerungsrichtlinien in AD FS zu erzwingen.

Führen Sie alle Schritte zum Konfigurieren der Ermittlung des Geräteregistrierungsdiensts und des SSL-Zertifikats des Device Registration Discovery-Servers aus, wie hier beschrieben.

Erstellen einer AD FS-Anwendungsgruppe für Outlook

Klicken Sie mit der rechten Maustaste auf Application Groups , und klicken Sie auf Add Application Group.
Wählen Sie aus Native Application accessing a web API.
Geben Sie einen Namen wie Outlook ein, und klicken Sie auf Weiter.
Native application pageFügen Sie in für Outlook Folgendes client identifier hinzu, redirect Uri und klicken Sie auf Weiter.
- Clientbezeichner: d3590ed6-52b3-4102-aeff-aad2292ab01c
- Umleitungs-URI (fügen Sie die folgenden beiden URIs hinzu):
  
  urn:ietf:wg:oauth:2.0:oob
  
  ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c
Fügen Sie auf der Configure Web API Registerkarte alle von Ihrer Exchange-Umgebung verwendeten FQDNs hinzu, einschließlich AutoErmittlung, Lastenausgleichs-FQDNs, Server-FQDNs usw. Zum Beispiel:
- https://autodiscover.contoso.com/
- https://mail.contoso.com/
Wichtig

Hier ist es wichtig, sicherzustellen, dass alle clientseitigen URLs abgedeckt sind. Andernfalls funktioniert dies nicht. Schließen Sie die nachfolgenden /'s ein, und stellen Sie sicher, dass die URLs mit https:// beginnen.
Auf der Apply Access Control Policy Registerkarte erlauben Sie allen, mit zu beginnen und dann später bei Bedarf zu ändern. Aktivieren Sie das Kontrollkästchen am unteren Rand der Seite nicht.
Configure Application PermissionsWählen Sie Native Application appin aus, und aktivieren Sie user_impersonation unter Permitted Scopes zusätzlich zu openid, was standardmäßig aktiviert ist.
Schließen Sie den Assistenten ab.

Hinzufügen von Ausstellungstransformationsregeln in der Outlook-Anwendungsgruppe

Fügen Sie für die oben erstellte Anwendungsgruppe OutlookAusstellungstransformationsregeln hinzu. Klicken Sie mit der rechten Maustaste auf die Outlook-Anwendungsgruppe, und wählen Sie Eigenschaften aus.

Bearbeiten Sie , Web API settingsund fügen Sie unter Issuance Transform Rules die folgenden benutzerdefinierten Regeln hinzu:

Anspruchsregelname	Benutzerdefinierte Regel
ActiveDirectoryUserSID	`c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"] => issue(claim = c);`
ActiveDirectoryUPN	`c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(claim = c);`
AppIDACR	`=> issue(Type = "appidacr", Value = "2");`
SCP	`=> issue(Type = "http://schemas.microsoft.com/identity/claims/scope", Value ="user_impersonation");`

Nach dem Hinzufügen der Regeln sollte wie Outlook - Web API Properties folgt aussehen:

Optional kann der Webanwendungsproxy für den Extranetzugriff konfiguriert werden.

Der Webanwendungsproxy ist Teil der Remotezugriffsserverrolle in Windows Server. Es bietet Reverseproxyfunktionen, mit denen Benutzer von außerhalb des Unternehmensnetzwerks auf Ihre Webanwendungen zugreifen können. Der Webanwendungsproxy authentifiziert den Zugriff auf Webanwendungen mithilfe von AD FS und fungiert als AD FS-Proxy.

Wenn Sie den Webanwendungsproxy verwenden möchten, führen Sie die unter Installieren und Konfigurieren des Webanwendungsproxyservers beschriebenen Schritte aus, um ihn zu konfigurieren. Nach der Konfiguration können Sie Regeln für Autodiscover.contoso.com oder veröffentlichen und mail.contoso.com die unter Veröffentlichen einer Anwendung, die OAuth2 verwendet, beschriebenen Schritte ausführen.

Optional kann MFA auch für den Clientzugriff konfiguriert werden.

Informationen zum Konfigurieren von AD FS mit einem MFA-Anbieter Ihrer Wahl finden Sie unter den folgenden Links.
- Konfigurieren von Drittanbieterauthentifizierungsanbietern als primäre Authentifizierung in AD FS 2019
- Konfigurieren von Azure MFA als Authentifizierungsanbieter mit AD FS
Konfigurieren Sie die Zugriffssteuerungsrichtlinie, die MFA erfordert.
- Zugriffssteuerungsrichtlinien in Windows Server 2016 AD FS

Konfiguration der Client-Side modernen Authentifizierung

Es wird empfohlen, die moderne Authentifizierung mit wenigen Benutzern zu testen, bevor sie für alle Benutzer bereitgestellt wird. Sobald eine Pilotgruppe von Benutzern die moderne Authentifizierung verwenden kann, können weitere Benutzer bereitgestellt werden.

Clientupgrade und Betriebssystemupgrade:

Wie im Abschnitt Clientvoraussetzungen beschrieben, wird die moderne Authentifizierung nur für Outlook unter Windows unterstützt. Um die moderne Authentifizierung verwenden zu können, muss der Insider Channel des Outlook-Clients unter Windows 11 OS 22H2 mit dem Update vom 14. März 2023 oder höher installiert werden.
Registrierungsänderungen auf Clientcomputern:

Administratoren müssen Registrierungswerte für Benutzer konfigurieren.

Aktivieren Sie die moderne Authentifizierung, und fügen Sie Ihre AD FS-Domäne als vertrauenswürdige Domäne in Outlook hinzu:
1. Fügen Sie die folgenden Schlüssel hinzu, um eine AD FS-Domäne als vertrauenswürdige Domäne hinzuzufügen:
  - HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://ADFS domain/
  - HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://ADFS domain
  Hinweis
  
  Fügen Sie zwei Schlüssel mit und ohne "/" am Ende der AD FS-Domäne hinzu.
2. Fügen Sie zum Aktivieren der modernen Authentifizierung über AD FS in Outlook unter Windows den folgenden REG_DWORD Wert in hinzu HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\:
  
  Name Wert
  
  EnableExchangeOnPremModernAuth 1
  
  Zur Vereinfachung der Bereitstellung können diese Registrierungsänderungen mithilfe von Gruppenrichtlinien konfiguriert werden. Wenn die Gruppenrichtlinie von Ihrer Organisation nicht verwendet wird, müssen Benutzer ihre Registrierung manuell (oder mit einem von Ihnen bereitgestellten Skript) konfigurieren.

Name	Wert
EnableExchangeOnPremModernAuth	1

Erstellen von Authentifizierungsrichtlinien für Endbenutzer

Es ist möglich, dass alle Benutzer in Ihrer Organisation nicht über E-Mail-Clients verfügen, die die moderne Authentifizierung mithilfe von AD FS unterstützen. In diesem Szenario wird empfohlen, die moderne Authentifizierung für Benutzer zu aktivieren, die Clients unterstützt haben, und Moderne Authentifizierungsbenutzer zu blockieren, die dies nicht getan haben.

Um die moderne Authentifizierung für eine Gruppe von Benutzern zu aktivieren und die moderne Authentifizierung für Ihre verbleibenden Benutzer zu blockieren, müssen Sie mindestens zwei Authentifizierungsrichtlinien erstellen:

Organisationsweite Richtlinie zum Standardmäßigen Blockieren der modernen Authentifizierung.
Zweite Richtlinie zum selektiven Zulassen der modernen Authentifizierung für einige Benutzer.

Erstellen einer Richtlinie auf Organisationsebene, um die moderne Authentifizierung standardmäßig zu blockieren

Nachdem die moderne Authentifizierung aktiviert wurde, versuchen alle Outlook-Clients, OAuth-Token zu verwenden, aber einige Clients (z. B. Outlook für Mac) können OAuth-Token nur von Microsoft Entra ID abrufen. Wenn die moderne Authentifizierung aktiviert ist, können diese Clients keine Verbindung herstellen.

Um dieses Szenario zu vermeiden, können Sie eine Richtlinie auf Organisationsebene festlegen, um die moderne Authentifizierung zu deaktivieren. Im folgenden Beispiel erstellen wir eine neue Authentifizierungsrichtlinie namens Block Modern Auth.

New-AuthenticationPolicy "Block Modern Auth" -BlockModernAuthWebServices -BlockModernAuthActiveSync -BlockModernAuthAutodiscover -BlockModernAuthImap -BlockModernAuthMapi -BlockModernAuthOfflineAddressBook -BlockModernAuthPop -BlockModernAuthRpc

Diese Richtlinie kann auf Organisationsebene mit dem folgenden Befehl festgelegt werden.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

Erstellen einer Authentifizierungsrichtlinie auf Benutzerebene zum Aktivieren der modernen Authentifizierung

Erstellen Sie als Nächstes eine zweite Authentifizierungsrichtlinie, die die moderne Authentifizierung aktiviert. Allen Benutzern mit einem unterstützten Outlook-Client wird diese Authentifizierungsrichtlinie zugewiesen, damit ihr Client die moderne Authentifizierung verwenden kann.

Im folgenden Beispiel erstellen wir eine neue Authentifizierung namens Allow Modern Auth mit dem folgenden Befehl:

New-AuthenticationPolicy "Allow Modern Auth"

Konfigurieren von Exchange Server für die Verwendung von ADFS-OAuth-Token

Überprüfen Sie, ob OAuth für die folgenden virtuellen Verzeichnisse aktiviert ist. Wenn diese Option nicht aktiviert ist, aktivieren Sie OAuth in allen diesen virtuellen Verzeichnissen:

Get-MapiVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
Get-WebServicesVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
Get-OabVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
Get-AutodiscoverVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*
Get-ActiveSyncVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Führen Sie den folgenden Befehl aus:
```
New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml
```
Dieser Befehl ist erforderlich, um ein neues Authentifizierungsserverobjekt in Exchange Server for AD FS zu erstellen. Authentifizierungsserverobjekte sind eine Liste vertrauenswürdiger Aussteller. Es werden nur OAuth-Token von diesen Ausstellern akzeptiert.
Führen Sie den folgenden Befehl aus:
```
Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true
```
Legen Sie den soeben hinzugefügten Authentifizierungsserver als fest DefaultAuthorizationEndpoint. Bei der Ankündigung des Modern Auth-Headers kündigt Exchange Server die Authentifizierungs-URL des DefaultAuthorizationEndpointan. So wissen Clients, welcher Endpunkt für die Authentifizierung verwendet werden soll.
Wir müssen diesen Befehl ausführen, um die moderne Authentifizierung auf Organisationsebene zu aktivieren:
```
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
```
Aktivieren Sie die moderne Authentifizierung für Benutzer mit unterstützten Clients, indem Sie die Authentifizierungsrichtlinie Allow Modern Auth zuweisen:
```
Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"
```

Überprüfen des modernen Authentifizierungsflusses

Nach der ordnungsgemäßen Konfiguration wird benutzern die ADFS-Anmeldeaufforderung angezeigt, wenn sie eine Verbindung mit einem Exchange-Server herstellen.

Auswirkung auf andere Clients, wenn die moderne Authentifizierung für einen Benutzer aktiviert ist

Benutzer, die für die moderne Authentifizierung aktiviert sind und über mehrere Clients verfügen (z. B. Outlook unter Windows und Outlook Mobile), haben für jeden Client unterschiedliche Erfahrungen. Im Folgenden finden Sie eine Zusammenfassung des Verhalten von Clients, wenn die moderne Authentifizierung aktiviert ist. In der folgenden Tabelle wird davon ausgegangen, dass Block Modern Auth auf Organisationsebene angewendet DefaultAuthenticationPolicy wird.

Client	Verhalten
Outlook unter Windows (neue Versionen)	Verwendet standardmäßig moderne Authentifizierung.
Outlook unter Windows (alte Versionen)	Versucht, die moderne Authentifizierung zu verwenden, schlägt jedoch fehl.
Outlook Mac	Versucht, die moderne Authentifizierung zu verwenden, schlägt jedoch fehl. Unterstützung wird später bereitgestellt.
Outlook iOS	Führt ein Fallback auf die Basic-Authentifizierung aus.
Outlook Android	Führt ein Fallback auf die Basic-Authentifizierung aus.
iOS-Mail-App	Führt ein Fallback auf die Basic-Authentifizierung aus.
Gmail-App	Führt ein Fallback auf die Basic-Authentifizierung aus.
OWA/ECP	Verwendet keine Authentifizierungsrichtlinie. Je nachdem, wie es konfiguriert ist, verwendet entweder die moderne Authentifizierung oder die Standardauthentifizierung.
Windows Mail-App	Es wird kein Fallback auf die Basic-Authentifizierung ausgeführt.
Thunderbird-Client	Es wird kein Fallback auf die Basic-Authentifizierung ausgeführt.
PowerShell	Verwendet die Standardauthentifizierung.

Auswirkung auf OWA/ECP, wenn die moderne Authentifizierung für andere Clients aktiviert ist

Kunden können die anspruchsbasierte Authentifizierung von AD FS für Outlook im Web verwenden. Die oben genannten Schritte sind erforderlich, um OAuth für andere Clients zu aktivieren, und wirken sich nicht auf die Konfiguration von OWA/ECP aus.

Verwenden der anspruchsbasierten AD FS-Authentifizierung mit Outlook im Web

Wartezeit nach änderung der Authentifizierungsrichtlinie

Nachdem Sie die Authentifizierungsrichtlinie geändert haben, um die moderne Authentifizierung zuzulassen oder die Legacyauthentifizierung zu blockieren:

Warten Sie 30 Minuten, bis neue Richtlinien von Front-End-Servern gelesen werden.

oder
Führen Sie eine IIS-Zurücksetzung auf allen Front-End-Servern durch.

Migrieren zur modernen Hybridauthentifizierung nach der Aktivierung der modernen Authentifizierung für Exchange Server

Kunden, die die moderne Authentifizierung mit AD FS verwenden und sich später für die Konfiguration von Exchange Hybrid entscheiden, sollten zur modernen Hybridauthentifizierung wechseln. Ausführliche Migrationsschritte werden einer zukünftigen Version dieses Dokuments hinzugefügt.

Erneuern von Zertifikaten

Auswerten der aktuellen Zertifikatkonfiguration

Wenn es um Clientverbindungen mit Exchange Server geht, sollte das Zertifikat ausgewertet werden, das an die Front-End-IIS-Website gebunden ist. Für einen AD FS-Server ist es ideal, sicherzustellen, dass alle in Get-AdfsCertificate zurückgegebenen Zertifikate aktuell sind.

Führen Sie in der Exchange-Verwaltungsshell folgendes aus, um das relevante Zertifikat auf einem Exchange-Server zu identifizieren:

Import-Module WebAdministration
(Get-ChildItem IIS:SSLBindings | Where-Object {($_.Sites -ne $null) -and ($_.Port -eq "443")}).Thumbprint | ForEach-Object {Get-ExchangeCertificate $_ | Where-Object {$_.Services -Match "IIS"} | Format-Table Thumbprint, Services, RootCAType, Status, NotAfter, Issuer -AutoSize -Wrap}

Führen Sie in PowerShell die folgenden Schritte aus, um aktive Zertifikate auf einem AD FS-Server zu überprüfen:
```
Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap
```

Aktualisieren von Zertifikaten auf Exchange Server

Wenn festgestellt wird, dass das Exchange-Zertifikat für die Clientkonnektivität aktualisiert werden muss, muss ein neues Zertifikat ausgestellt und auf die Exchange-Server importiert werden. Anschließend sollte das Zertifikat mindestens für IIS aktiviert werden. Bewerten Sie basierend auf Ihrer Konfiguration, ob andere Dienste für das neue Zertifikat aktiviert werden sollen.

Im Folgenden finden Sie ein Beispiel zum Erstellen, Abschließen, Aktivieren und Importieren eines neuen Zertifikats auf allen Servern basierend auf dem vorhandenen Zertifikat in der Exchange-Verwaltungsshell:

Generieren Sie eine neue Zertifikatanforderung in der Exchange-Verwaltungsshell basierend auf Ihrem vorhandenen Zertifikat:

$txtrequest = Get-ExchangeCertificate <Thumbprint> | New-ExchangeCertificate -GenerateRequest -PrivateKeyExportable $true

Stellen Sie eine Variable bereit, die den gewünschten Ausgabepfad Ihrer neuen Zertifikatanforderung enthält:
```
$requestFile = "C:\temp\CertRequest.req"
```
Erstellen Sie die Zertifikatanforderungsdatei:
```
[System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))
```
Hinweis

Der Ordnerpfad für die Zertifikatanforderung muss bereits vorhanden sein.
Geben Sie die Anforderungsdatei für Ihre Zertifizierungsstelle (ZS) weiter. Die schritte, die zum Abrufen eines abgeschlossenen Zertifikats erforderlich sind, variieren je nach Ihrer Zertifizierungsstelle.

Hinweis

.p7b ist das bevorzugte Format für die abgeschlossene Anforderung.
Stufen Sie eine Variable ein, die den vollständigen Pfad der abgeschlossenen Anforderung enthält:
```
$certFile = "C:\temp\ExchangeCert.p7b"
```

Importieren Sie die Anforderung auf den Server, der die Anforderung ursprünglich generiert hat:

Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes($certFile)) -PrivateKeyExportable $true

Stufenvariable für das Kennwort zum Schutz des abgeschlossenen Zertifikats:
```
$pw = Read-Host "Enter password" -AsSecureString
```

Exportieren Sie die Zertifikatbinärdatei in eine Variable:

$binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

Stufenvariable für den gewünschten Ausgabepfad des abgeschlossenen Zertifikats:
```
$certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"
```
Exportieren Sie die abgeschlossene Anforderung, um sie auf andere Server zu importieren:
```
[System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)
```
Aktivieren Sie die Dienste, die an das Zertifikat gebunden werden sollen:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS
```
Hinweis

Möglicherweise müssen Sie dem obigen Beispiel basierend auf Ihrer vorherigen Zertifikatkonfiguration weitere Dienste hinzufügen.
Überprüfen Sie, ob das Zertifikat wie beabsichtigt funktioniert, indem Sie einen Client für alle Clientnamespaces mit einer Hostdatei an den Server weiterleiten.
Importieren Sie das Exchange-Zertifikat auf allen anderen Exchange-Servern:
```
Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>
```
Hinweis

Das Einschließen des -PrivateKeyExportable Parameters ist beim Importieren auf andere Exchange-Server optional.
Aktivieren Sie das Exchange-Zertifikat für die erforderlichen Exchange-Dienste auf allen anderen Exchange-Servern:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>
```
Hinweis

Möglicherweise müssen Sie dem obigen Beispiel basierend auf Ihrer vorherigen Zertifikatkonfiguration weitere Dienste hinzufügen.

Aktualisieren des Zertifikats für AD FS

Abhängig vom Zertifikattyp, der für AD FS aktualisiert werden muss, bestimmt, ob Sie die unten beschriebenen Schritte ausführen müssen.

Service-Communications-Zertifikat

In diesem Beispiel wird die PowerShell bereitgestellt, die zum Importieren eines Zertifikats im .pfx Format erforderlich ist, z. B. das Zertifikat, das durch Ausführen der Exchange Server-Zertifikatschritte generiert wird. Stellen Sie sicher, dass Sie auf dem primären AD FS-Server angemeldet sind.

Stellen Sie eine Variable bereit, die das Kennwort für das Zertifikat enthält:
```
$pw = Read-Host "Enter password" -AsSecureString
```
Stellen Sie eine Variable bereit, die den vollständigen Pfad für das Zertifikat enthält:
```
$certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"
```

Importieren Sie das Zertifikat in den persönlichen Speicher der LocalMachine:

Import-PfxCertificate -FilePath $certificate -CertStoreLocation Cert:\LocalMachine\my -Password $pw

Aktualisieren Sie das Service-Communications-Zertifikat:
```
Set-AdfsSslCertificate -Thumbprint <Thumbprint>
```

Token-Signing- und Token-Decryption zertifikate

Führen Sie die Schritte aus, die in der Dokumentation Abrufen und Konfigurieren von TS- und TD-Zertifikaten für AD FS beschrieben sind.