Freigeben über

Aktivieren der modernen Authentifizierung in Exchange lokal

GILT FÜR:no-img-162016 yes-img-192019 yes-img-seSubscription Edition

Übersicht

Ab Exchange Server 2019 CU13 unterstützt OAuth 2.0 Exchange Server (auch bekannt als Modern Authentication) für reine lokale Umgebungen, die AD FS als Sicherheitstokendienst (Security Token Service, 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 hybriden modernen Authentifizierung (Hybrid Modern Authentication, HMA) verwechselt werden, die Microsoft Entra ID für die moderne Authentifizierung verwendet. Tatsächlich ist HMA immer noch die 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 für Organisationen, 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. Exchange Server überprüft diese Zugriffstoken, um Clientzugriff auf das Postfach des Benutzers bereitzustellen.

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

Ein Diagramm, das den Exchange Server 2019-Handshakeworkflow für moderne Authentifizierung zeigt. Im vorherigen Diagramm werden die Schritte 3a, 4a5a und 6a ausgeführt, wenn die moderne Authentifizierung für den Endbenutzer aktiviert ist. Die Schritte 3btreten 4b 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-organization mit nur Exchange Server 2019 Ja Nicht zutreffend
Lokale Exchange-organization 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-organization 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 Hybrid organization 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 Hybrid organization 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 moderne Authentifizierung verwenden zu können, muss auf allen Servern, die für Clientverbindungen verwendet werden, Exchange Server 2019 CU13 installiert sein.

AD FS 2019 oder höher

Um die moderne Authentifizierung in einer lokalen Exchange-Umgebung zu aktivieren, ist Active Directory-Verbunddienste (AD FS) (AD FS) auf Windows Server 2019 oder höher erforderlich. Es wird nicht unterstützt, die AD FS-Rolle auf einem Exchange Server zu installieren und zu konfigurieren. Weitere Informationen finden Sie unter Planen der AD FS-Bereitstellungstopologie.

Möglicherweise benötigen Sie auch Web Anwendungsproxy Server (ab Windows Server 2019), um den Clientzugriff von außerhalb des Unternehmensnetzwerks zu ermöglichen. Weitere Informationen finden Sie im Abschnitt (Optional) Konfigurieren von Web Anwendungsproxy für Extranetzugriff konfiguriert werden kann.

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.

Outlook unter Windows

Unterstützung für moderne Authentifizierung über AD FS ist in den folgenden Versionen von Microsoft Outlook for Windowsverfügbar. Der Microsoft Outlook Windows-Client verwendet ab der Buildnummer 16.0.17628.10000die neueste MSAL library für die Authentifizierung. Um sicherzustellen, dass Sie den aktuellsten Authentifizierungsstapel verwenden, wird empfohlen, die neueste Version zu installieren:

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 Ja 2402 17328.20452

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 (Volume) Nein Nicht zutreffend Nicht zutreffend
Outlook 2024 (Einzelhandel) Ja 2410 18129.20158
Outlook 2024 (Volume) Ja 2408 17932.20162

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

Outlook für Mac

Unterstützung für die moderne Authentifizierung über AD FS ist in Outlook for Mac (Microsoft 365) über Microsoft 365 verfügbar, beginnend mit der Buildnummer 16.95.4 (25040241). Beachten Sie, dass die moderne Authentifizierung über AD FS derzeit in eigenständigen Versionen wie Outlook 2024 for Macnicht unterstützt wird.

Windows-Betriebssystem

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

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

Screenshot: Updateverlauf eines Computers, auf dem Windows 11 22H2 ausgeführt wird

Apple-Plattformen

Unterstützung für die moderne Authentifizierung über AD FS ist in der Apple Mail App ab macOS Sequoia und iOS 17.6.1verfügbar.Outlook for Mac (Microsoft 365)macOS Sequoia

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 zu mehr Exchange Server Protokollen hinzuzufügen.

Protokoll Unterstützte moderne ADFS-Authentifizierung
MAPI über HTTP (MAPI/HTTP) Ja
Outlook Anywhere (RPC/HTTP) Nein
Exchange Active Sync (EAS) Ja
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. Dieser Ansatz stellt sicher, dass anfängliche Clientverbindungen mit Exchange 2019 OAuth verwenden und verbindungen per Proxy mit Exchange Server 2016 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 mehrere neue Authentifizierungsrichtlinienparameter zu Exchange Server hinzuzufügen.

  1. BlockModernAuthActiveSync
  2. BlockModernAuthAutodiscover
  3. BlockModernAuthImap
  4. BlockModernAuthMapi
  5. BlockModernAuthOfflineAddressBook
  6. BlockModernAuthPop
  7. BlockModernAuthRpc
  8. BlockModernAuthWebServices

Nach der Installation von CU13 oder höher sind die Parameter für alle bereits vorhandenen Authentifizierungsrichtlinien (einschließlich der Standardauthentifizierungsrichtlinie) deaktiviert. Das bedeutet, dass Sie die bereits vorhandenen Authentifizierungsrichtlinien nicht ändern müssen, wenn Sie bereits HMA verwenden.

Keine neue Authentifizierungsrichtlinie für Exchange Hybrid erforderlich

Vorhandene Exchange-Hybridkonfigurationen sollten moderne Hybridauthentifizierung (Hybrid Modern Auth, HMA) verwenden. Hybridinstallationen, 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 Organisationen relevant, die Exchange Hybrid nicht verwenden und ausschließlich lokal sind.

Einrichten von Active Directory-Verbunddienste (AD FS) (AD FS)

Sie müssen AD FS in der Umgebung installieren und konfigurieren, damit Exchange-Clients Forms-Authentifizierung (OAuth) verwenden können, um eine Verbindung mit Exchange Server herzustellen. Weitere Informationen finden Sie in der Prüfliste: Einrichten eines Verbundservers , um Ihre AD FS-Konfiguration zu unterstützen.

Das AD FS-Feature kann installiert werden, indem Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten auf dem neuen Server ausführen, der zum AD FS-Server wird:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

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

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

  1. 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 Web Anwendungsproxy-Server. Es wird empfohlen, ein Zertifikat zu verwenden, das von einer internen oder kommerziellen Zertifizierungsstelle ausgestellt wurde, da alle Clients diesem Zertifikat vertrauen müssen.
  2. 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,
Web Anwendungsproxy Server (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,
Web Anwendungsproxy Server (optional)		 Ein Tokensignaturzertifikat ist ein X509-Zertifikat. Verbundserver verwenden zugeordnete Öffentliche/Private-Schlüsselpaare, um alle von ihnen erzeugten Sicherheitstoken digital zu signieren. Dieser Prozess 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,
Web Anwendungsproxy Server (optional)		 Dieses Zertifikat 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 Schritte unter Bereitstellen eines AD FS-Servers und Konfigurieren und Testen des AD FS-Servers aus. Stellen Sie sicher, dass auf die Verbundmetadaten-URL in einem Webbrowser sowohl vom Exchange-Server als auch von mindestens einem Clientcomputer aus zugegriffen werden kann.

Die URL verwendet die folgende Syntax: https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

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

Konfigurieren der Authentifizierungsmethode in AD FS

Um die moderne Authentifizierung in Outlook unter Windows verwenden zu können, müssen Sie konfigurieren Primary Authentication Methods. Es wird empfohlen, Forms Authentication sowohl für als auch ExtranetIntranetauszuwählen. Diese Konfiguration kann durch Ausführen der folgenden Befehle in einem PowerShell-Fenster auf dem AD FS-Server erfolgen:

Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider FormsAuthentication
Set-AdfsGlobalAuthenticationPolicy -PrimaryExtranetAuthenticationProvider FormsAuthentication

Auswählen der geeigneten SSO-Lebensdauer

Wählen Sie eine geeignete SSO-Lebensdauer (Single Sign-On) aus, damit Endbenutzer sich nicht häufig erneut authentifizieren müssen. Um die aktuelle Konfiguration der SSO-Lebensdauer zu überprüfen, öffnen Sie ein neues PowerShell-Fenster auf dem AD FS-Server, und führen Sie den folgenden Befehl aus:

Get-AdfsProperties | Format-List SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMins, DeviceUsageWindowInDays, KmsiEnabled, PersistentSsoEnabled, BrowserSsoEnabled

Verwenden Sie das Cmdlet Set-AdfsProperties , um die entsprechenden Werte für SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMinsund DeviceUsageWindowInDayszu konfigurieren. Diese Einstellungen sollten angepasst werden, um einmaliges Anmelden zu aktivieren und dessen Ablauf zu definieren. Abhängig vom SSO-Modus, zKeep Me Signed In (KMSI). B. oder Device registration, müssen Sie möglicherweise auch und PersistentSsoEnabledaktivierenKsmiEnabled. Weitere Informationen zum einmaligen Anmelden von ADFS finden Sie in der Dokumentation zu AD FS 2016 Single Sign-On Einstellungen.

Konfigurieren der Geräteregistrierung in AD FS

Es wird empfohlen, das Device Registration Feature in AD FS zu aktivieren, um von einer verbesserten SSO-Erfahrung zu profitieren. Um zu aktivieren Device Registration, führen Sie die Schritte aus, die in der Dokumentation Konfigurieren eines Verbundservers mit dem Geräteregistrierungsdienst beschrieben sind.

Führen Sie als Nächstes alle Schritte zum Konfigurieren Device Registration Service Discovery von und aus Device Registration Discovery Server SSL certificate, wie in der Dokumentation zum Konfigurieren der Geräteregistrierung beschrieben.

Um die Geräteregistrierung verwenden zu können, müssen Endbenutzer ihr Gerät mit einem Arbeitsplatz verbinden. Weitere Informationen finden Sie in den folgenden Dokumentationen:

Überprüfen Sie, ob die Geräteregistrierung konfiguriert und die Geräteauthentifizierung aktiviert ist, indem Sie überprüfen Device Registration Overview. Dieser Schritt wird empfohlen, um die Anzahl der Authentifizierungsaufforderungen für Benutzer zu reduzieren und Access Control Richtlinien in AD FS zu erzwingen.

Konfigurieren von KSMI in AD FS

Wenn Sie dies lieber nicht verwenden Device Registration möchten oder dies nicht tun können, können Sie stattdessen das Keep Me Signed In Feature aktivieren. AD FS erstellt dann unmittelbar nach der Benutzerauthentifizierung ein persistentes Cookie, sodass keine erneute Authentifizierung in nachfolgenden Sitzungen erforderlich ist, sofern das Cookie gültig bleibt.

Die Ablaufzeit des Aktualisierungstokens entspricht der Lebensdauer des persistenten SSO-Cookies für Keep me signed in. Die Lebensdauer des persistenten SSO-Cookies beträgt standardmäßig einen Tag mit maximal sieben Tagen. Andernfalls entspricht die Lebensdauer des Aktualisierungstokens der Sitzungs-SSO-Cookies (standardmäßig 8 Stunden). Weitere Informationen zu KSMI finden Sie in der Dokumentation zu DEN AD FS-Einstellungen für einmaliges Anmelden .

KMSI ist standardmäßig deaktiviert und kann durch Festlegen der AD FS-Eigenschaft KmsiEnabled auf Trueaktiviert werden. Führen Sie die folgenden Schritte in einem PowerShell-Fenster auf Ihrem AD FS-Server aus:

Set-AdfsProperties -EnableKmsi $true

Wenn KMSI deaktiviert ist, lautet der Standardzeitraum für einmaliges 8 hoursAnmelden. Der Zeitraum für einmaliges Anmelden kann mithilfe der -Eigenschaft SsoLifetimekonfiguriert werden. Die -Eigenschaft wird in Minuten gemessen, sodass ihr Standardwert lautet 480:

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

Wenn KMSI aktiviert ist, lautet der Standardzeitraum für einmaliges 24 hoursAnmelden. Der Zeitraum für einmaliges Anmelden mit aktiviertem KMSI kann mithilfe der Eigenschaft KmsiLifetimeMinskonfiguriert werden. Die -Eigenschaft wird in Minuten gemessen, sodass ihr Standardwert lautet 1440:

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

Erstellen der ADFS-Outlook-Anwendungsgruppe

Wenn Sie zum ersten Mal die moderne AD FS-Authentifizierung in Exchange lokal konfigurieren, führen Sie die Schritte in diesem Abschnitt des Leitfadens aus. Wenn Sie über eine vorhandene Konfiguration der modernen AD FS-Authentifizierung verfügen, die vor der Unterstützung für andere Clients als Microsoft Outlook for Windowseingerichtet wurde, lesen Sie die Schritte im Abschnitt Aktualisieren der vorhandenen AD FS Outlook-Anwendungsgruppe dieser Dokumentation. Die folgenden PowerShell-Befehle müssen über ein PowerShell-Fenster auf Ihrem AD FS-Server ausgeführt werden. Wenn Sie nicht beabsichtigen, iOS- und macOS-Anwendungen wie die native Apple Mail-App zu verwenden, können Sie das Erstellen der nativen AD FS-Clientanwendung für iOS und macOS überspringen. Es wird jedoch empfohlen, sie der Vollständigkeit halber zu erstellen.

Zunächst erstellen wir die ADFS Application Group:

New-AdfsApplicationGroup -Name "Outlook" -ApplicationGroupIdentifier "Outlook" -Disabled:$false

Als Nächstes erstellen wir drei weitere Scopes - EAS.AccessAsUser.All, EWS.AccessAsUser.All und :offline_access

Add-AdfsScopeDescription -Name "EAS.AccessAsUser.All" -Description "EAS scope"
Add-AdfsScopeDescription -Name "EWS.AccessAsUser.All" -Description "EWS scope"
Add-AdfsScopeDescription -Name "offline_access" -Description "Offline Access"

Nun erstellen wir zwei Native Client Applications - Outlook - Native application und :iOS and macOS - Native mail application

Add-AdfsNativeClientApplication -Name "Outlook - Native application" -ApplicationGroupIdentifier "Outlook" -Identifier "d3590ed6-52b3-4102-aeff-aad2292ab01c" -RedirectUri @("ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c","msauth.com.microsoft.Outlook://auth","urn:ietf:wg:oauth:2.0:oob")
Add-AdfsNativeClientApplication -Name "iOS and macOS - Native mail application" -ApplicationGroupIdentifier "Outlook" -Identifier "f8d98a96-0999-43f5-8af3-69971c7bb423" -RedirectUri @("com.apple.mobilemail://oauth-redirect","com.apple.preferences.internetaccounts://oauth-redirect/","com.apple.Preferences://oauth-redirect/")

Im nächsten Schritt erstellen Web Api Applicationswir . Wir erstellen eine Anwendung pro URI, die in Ihrer Exchange Server-Umgebung verwendet wird. Wenn Sie z. B. und mail.contoso.comverwenden, autodiscover.contoso.com müssen Sie zwei Web Api Applicationserstellen. Ersetzen Sie die URIs im folgenden Beispiel durch die URIs, die Sie in Ihrem Setup verwenden. Es ist wichtig, dass alle clientseitigen URIs abgedeckt sind. Schließen Sie die nachgestellte / ein, und stellen Sie sicher, dass die URIs mit https://beginnen:

# Replace the URIs with your URIs
$exchangeServerServiceFqdns = @("https://autodiscover.contoso.com/","https://mail.contoso.com/")

$issuanceTransformRules = @"
@RuleName = "ActiveDirectoryUserSID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
 => issue(claim = c);

@RuleName = "ActiveDirectoryUPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(claim = c);

@RuleName = "AppIDACR"
 => issue(Type = "appidacr", Value = "2");

@RuleName = "SCP"
 => issue(Type = "scp", Value = "user_impersonation");

@RuleName = "SCPEAS"
 => issue(Type = "scp", Value = "EAS.AccessAsUser.All");

@RuleName = "SCPEWS"
 => issue(Type = "scp", Value = "EWS.AccessAsUser.All");

@RuleName = "offlineaccess"
 => issue(Type = "scp", Value = "offline_access");
"@
foreach ($fqdn in $exchangeServerServiceFqdns) {
    Add-AdfsWebApiApplication -Name "Outlook - Web API ($((New-Guid).ToString("N")))" -ApplicationGroupIdentifier "Outlook" -Identifier $fqdn -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
}

Als letzten Schritt fügen wir die Clientberechtigungen für alle Native Client Applications in der vorhandenen Web Api Applicationshinzu:

$clientRoleIdentifier = @("f8d98a96-0999-43f5-8af3-69971c7bb423","d3590ed6-52b3-4102-aeff-aad2292ab01c")
(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    [string]$serverRoleIdentifier = $_.Identifier
    foreach ($id in $clientRoleIdentifier) {
        Grant-AdfsApplicationPermission -ClientRoleIdentifier $id -ServerRoleIdentifier $serverRoleIdentifier -ScopeNames "winhello_cert","email","profile","vpn_cert","logon_cert","user_impersonation","allatclaims","offline_access","EAS.AccessAsUser.All","EWS.AccessAsUser.All","openid","aza"
    }
}

Aktualisieren der vorhandenen AD FS-Outlook-Anwendungsgruppe

Wichtig

Überspringen Sie die Schritte in diesem Abschnitt, wenn Sie nicht über eine vorhandene AD FS-Outlook-Anwendungsgruppe verfügen, die konfiguriert wurde, bevor die Unterstützung für andere Clients als Microsoft Outlook for Windows eingeführt wurde.

Wenn Sie über eine vorhandene Ad FS Outlook-Anwendungsgruppenkonfiguration verfügen, die eingerichtet wurde, bevor die Unterstützung für andere Clients als Microsoft Outlook for Windows eingeführt wurde, führen Sie die hier beschriebenen Schritte aus, um die Unterstützung für andere Plattformen zu aktivieren. Die folgenden PowerShell-Befehle müssen über ein PowerShell-Fenster auf Ihrem AD FS-Server ausgeführt werden.

Zunächst erstellen wir drei zusätzliche Scopes - EAS.AccessAsUser.All, EWS.AccessAsUser.All und :offline_access

Add-AdfsScopeDescription -Name "EAS.AccessAsUser.All" -Description "EAS scope"
Add-AdfsScopeDescription -Name "EWS.AccessAsUser.All" -Description "EWS scope"
Add-AdfsScopeDescription -Name "offline_access" -Description "Offline Access"

Jetzt erstellen wir eine neue Native Client Applications - iOS and macOS - Native mail application:

Add-AdfsNativeClientApplication -Name "iOS and macOS - Native mail application" -ApplicationGroupIdentifier "Outlook" -Identifier "f8d98a96-0999-43f5-8af3-69971c7bb423" -RedirectUri @("com.apple.mobilemail://oauth-redirect","com.apple.preferences.internetaccounts://oauth-redirect/","com.apple.Preferences://oauth-redirect/")

Wir aktualisieren die vorhandene Native Client Application - Outlook - Native application. Stellen Sie sicher, dass Sie den TargetName durch den Zielnamen ersetzen, den Sie in der vorhandenen Konfiguration verwenden:

Set-AdfsNativeClientApplication -TargetName "Outlook - Native application" -RedirectUri @("ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c","msauth.com.microsoft.Outlook://auth","urn:ietf:wg:oauth:2.0:oob")

Im nächsten Schritt müssen wir einen Web Api Application für jeden Identifier (URI) erstellen, der in Ihrer Exchange Server-Umgebung verwendet wird und in Ihrer aktuellen Konfiguration der modernen ADFS-Authentifizierung vorhanden ist:

$duplicateFqdnHashSet = New-Object System.Collections.Generic.HashSet[string]
$issuanceTransformRules = @"
@RuleName = "ActiveDirectoryUserSID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
 => issue(claim = c);

@RuleName = "ActiveDirectoryUPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(claim = c);

@RuleName = "AppIDACR"
 => issue(Type = "appidacr", Value = "2");

@RuleName = "SCP"
 => issue(Type = "scp", Value = "user_impersonation");

@RuleName = "SCPEAS"
 => issue(Type = "scp", Value = "EAS.AccessAsUser.All");

@RuleName = "SCPEWS"
 => issue(Type = "scp", Value = "EWS.AccessAsUser.All");

@RuleName = "offlineaccess"
 => issue(Type = "scp", Value = "offline_access");
"@
(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    if ($_.Identifier.Count -gt 1) {
        Write-Host "[+] More than one identifier was found in Web Api Application: $($_.Name)" -ForegroundColor Yellow
        $_.Identifier | Select-Object -Skip 1 | ForEach-Object {
            Write-Host "[+] Identifier $_ must be added to a new Web Api Application and will now be removed from the existing one" -ForegroundColor Yellow
            [void]$duplicateFqdnHashSet.Add($_)
        }

        Set-AdfsWebApiApplication -TargetName $_.Name -Identifier ($_.Identifier)[0] -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
    }
}

foreach($identifier in $duplicateFqdnHashSet) {
    Write-Host "[+] Creating a new Web Api Application for: $identifier" -ForegroundColor Yellow
    Add-AdfsWebApiApplication -Name "Outlook - Web API ($((New-Guid).ToString("N")))" -ApplicationGroupIdentifier "Outlook" -Identifier $identifier -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
    Write-Host "[+] Done!`r`n" -ForegroundColor Green
}

Als letzten Schritt fügen wir die Clientberechtigungen für alle Native Client Applications in der vorhandenen Web Api Applicationshinzu:

$clientRoleIdentifier = @("f8d98a96-0999-43f5-8af3-69971c7bb423","d3590ed6-52b3-4102-aeff-aad2292ab01c")
$requiredScopes = @("winhello_cert","email","profile","vpn_cert","logon_cert","user_impersonation","allatclaims","offline_access","EAS.AccessAsUser.All","EWS.AccessAsUser.All","openid","aza")

(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    [string]$serverRoleIdentifier = $_.Identifier
    Write-Host "[+] Processing Server Role: $serverRoleIdentifier" -ForegroundColor Yellow
    foreach ($id in $clientRoleIdentifier) {
        Write-Host "[+] Processing Client Role: $id" -ForegroundColor Yellow
        $permissionEntry = Get-AdfsApplicationPermission | Where-Object { $_.ClientRoleIdentifier -eq $id -and $_.ServerRoleIdentifier -eq $serverRoleIdentifier }
        if ($null -eq $permissionEntry) {
            Write-Host "[+] No Application Permission found for Client Role: $id - Server Role: $serverRoleIdentifier" -ForegroundColor Yellow
            Grant-AdfsApplicationPermission -ClientRoleIdentifier $id -ServerRoleIdentifier $serverRoleIdentifier -ScopeNames $requiredScopes
        } else {
            Write-Host "[+] Application Permission found - validating Scopes" -ForegroundColor Yellow
            $missingScopesList = New-Object System.Collections.Generic.List[string]
            $requiredScopes | ForEach-Object {
                if ($_ -in $permissionEntry.ScopeNames) {
                    Write-Host "[+] Scope: $_ is already set!" -ForegroundColor Green
                } else {
                    Write-Host "[+] Scope: $_ is missing and must be added" -ForegroundColor Yellow
                    $missingScopesList.Add($_)
                }
            }

            if ($missingScopesList.Count -ge 1) {
                Write-Host "[+] The following Scopes will be added: $([string]::Join(", ", $missingScopesList))" -ForegroundColor Yellow
                Set-AdfsApplicationPermission -TargetClientRoleIdentifier $id -TargetServerRoleIdentifier $serverRoleIdentifier -AddScope $missingScopesList
                Write-Host "[+] Done!`r`n" -ForegroundColor Green
            } else {
                Write-Host "[+] There is nothing to do!`r`n" -ForegroundColor Green
            }
        }
    }
}

Entfernen einer vorhandenen AD FS-Outlook-Anwendungsgruppe

Achtung

Durch Ausführen der Schritte in diesem Abschnitt wird die vorhandene Ad FS-Outlook-Anwendungsgruppenkonfiguration entfernt.

Wenn Sie über eine vorhandene Ad FS Outlook-Anwendungsgruppenkonfiguration verfügen und diese entfernen möchten, führen Sie die hier beschriebenen Schritte aus, um die vorhandene Konfiguration zu löschen. Alle folgenden PowerShell-Befehle müssen über ein PowerShell-Fenster auf Ihrem AD FS-Server ausgeführt werden.

Zunächst löschen wir die ADFS Application Group:

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

Als letzten Schritt löschen wir die benutzerdefiniert Scopes , die hinzugefügt wurden:

Remove-AdfsScopeDescription -TargetName "EAS.AccessAsUser.All"
Remove-AdfsScopeDescription -TargetName "EWS.AccessAsUser.All"
Remove-AdfsScopeDescription -TargetName "offline_access"

(Optional) Konfigurieren von Web-Anwendungsproxy kann für Extranetzugriff konfiguriert werden

Web Anwendungsproxy ist Teil der Remotezugriffsserverrolle in Windows Server. Es bietet Reverseproxyfunktionen, mit denen Benutzer von außerhalb des Unternehmensnetzwerks auf Ihre Webanwendungen zugreifen können. Web Anwendungsproxy 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 Web Anwendungsproxy Servers 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) Konfigurieren der MFA für den Clientzugriff

  1. Informationen zum Konfigurieren von AD FS mit einem MFA-Anbieter Ihrer Wahl finden Sie unter den folgenden Links.

  2. Konfigurieren Sie Access Control Richtlinie, die MFA erfordert.

Erstellen von Authentifizierungsrichtlinien für Endbenutzer

Es ist möglich, dass nicht alle Benutzer in Ihrem organization über E-Mail-Clients verfügen, die moderne Authentifizierung über AD FS unterstützen. In diesem Szenario wird empfohlen, die moderne Authentifizierung für Benutzer mit unterstützten Clients zu aktivieren und für diese Benutzer zu blockieren.

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

Wichtig

Die neuen Authentifizierungsrichtlinien werden verfügbar, sobald Active Directory mithilfe des Exchange 2019 CU13-Mediums oder höher vorbereitet wurde.

  • Eine organization-weite Richtlinie zum Standardmäßigen Blockieren der modernen Authentifizierung
  • Eine sekundäre Richtlinie zum selektiven Zulassen der modernen Authentifizierung für bestimmte Benutzer

Die folgenden PowerShell-Befehle müssen über ein EMS-Fenster (Exchange Management Shell) auf Ihrem Exchange-Server ausgeführt werden.

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

Sobald die moderne Authentifizierung aktiviert ist, versuchen alle Outlook-Clients, OAuth-Token zu verwenden. Einige Clients, die nicht mit der modernen Authentifizierung von AD FS kompatibel sind, können jedoch nur OAuth-Token aus Microsoft Entra ID abrufen. Daher können diese Clients keine Verbindung herstellen, wenn die moderne Authentifizierung aktiviert ist.

Um dieses Szenario zu verhindern, können Sie eine organization-weite Richtlinie implementieren, um die moderne Authentifizierung zu deaktivieren. Im Beispiel erstellen wir eine neue Authentifizierungsrichtlinie mit dem Namen 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. Weisen Sie diese Richtlinie allen Benutzern mit unterstützten Outlook-Clients zu, damit ihre Clients die moderne Authentifizierung verwenden können.

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

New-AuthenticationPolicy "Allow Modern Auth"

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

  1. Überprüfen Sie, ob OAuth für die folgenden virtuellen Verzeichnisse aktiviert ist. Wenn es nicht aktiviert ist, aktivieren Sie OAuth es für alle diese virtuellen Verzeichnisse:

    Get-MapiVirtualDirectory | Format-List Server, *auth*
Get-WebServicesVirtualDirectory | Format-List Server, *auth*
Get-OabVirtualDirectory | Format-List Server, *auth*
Get-AutodiscoverVirtualDirectory | Format-List Server, *auth*
Get-ActiveSyncVirtualDirectory | Format-List Server, *auth*

    Die Ausgabe wird wie folgt angezeigt. Das Hauptdetail, auf das sie sich konzentrieren müssen, ist OAuth, wie bereits erwähnt:

    Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

    Wenn OAuth auf einem Server oder einem der fünf virtuellen Verzeichnisse fehlt, müssen Sie es mithilfe der entsprechenden Befehle hinzufügen, bevor Sie fortfahren: Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OabVirtualDirectory, Set-AutodiscoverVirtualDirectory und Set-ActiveSyncVirtualDirectory.

  2. 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 für AD FS zu erstellen. Authentifizierungsserverobjekte sind eine Liste vertrauenswürdiger Aussteller. Es werden nur OAuth-Token von diesen Ausstellern akzeptiert.

  3. Führen Sie den folgenden Befehl aus:

    Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true

    Legen Sie den soeben hinzugefügten Authentifizierungsserver als fest DefaultAuthorizationEndpoint. Beim Ankündigen 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.

  4. Wir müssen diesen Befehl ausführen, um die moderne Authentifizierung auf organization Ebene zu aktivieren:

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

  5. 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"

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. Überprüfen Sie, ob Ihr Client die moderne ADFS-Authentifizierung unterstützt. Weitere Informationen zu den unterstützten Clients finden Sie im Abschnitt Clientvoraussetzungen .

Microsoft Windows

Aktivieren Sie die moderne Authentifizierung, und fügen Sie Ihre AD FS-Domäne als vertrauenswürdige Domäne in Outlook hinzu:

  1. Erstellen Sie die folgenden Registrierungsschlüssel, um Ihre AD FS-Domäne zu einer vertrauenswürdigen Domäne zu machen. Stellen Sie sicher, dass Sie beide Schlüssel mit und ohne am / Ende der AD FS-Domäne hinzufügen:

    • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain/
    • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain

    Sie können PowerShell verwenden, um die Registrierungsschlüssel zu erstellen oder mithilfe eines Gruppenrichtlinie bereitzustellen. Führen Sie die folgenden Befehle in einem PowerShell-Fenster auf jedem Clientcomputer aus. Ersetzen Sie durch your-ADFS-domain Ihre AD FS-Domäne.

    New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains" -Force
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain/")
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain")

  2. Fügen Sie zum Aktivieren der modernen ADFS-Authentifizierung in Microsoft Outlook for Windows den EnableExchangeOnPremModernAuthREG_DWORD Wert unter hinzu HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\.

    Sie können PowerShell verwenden, um den Registrierungswert zu erstellen oder über eine Gruppenrichtlinie bereitzustellen. Führen Sie den folgenden Befehl in einem PowerShell-Fenster auf jedem Clientcomputer aus.

    Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord

Apple macOS

Um die moderne Authentifizierung für Microsoft Outlook unter unterstützten Versionen von Apple macOS zu aktivieren, müssen Sie die Einstellungen für die Microsoft Outlook-Anwendung ändern.

Öffnen Sie ein Terminalfenster, und führen Sie den folgenden Befehl aus, und host1 ersetzen Sie dabei durch den FQDN Ihres AD FS-Servers. Stellen Sie sicher, dass Sie das Protokoll nicht einschließen oder Schrägstriche am Ende des FQDNs hinzufügen. Wenn Ihr AD FS-Server beispielsweise über https://fs.contoso.com/erreichbar ist, verwenden Sie fs.contoso.com. Wenn Sie über mehrere AD FS-Namespaces verfügen, fügen Sie diese durch ein Leerzeichen getrennt hinzu.

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

Für verwaltete Geräte können Administratoren eine Mobile Geräteverwaltung -Lösung (MDM) verwenden, um eine Liste von AD FS-FQDNs zentral zu verwalten und auf Clientgeräte zu pushen. In der folgenden Tabelle sind die Konfigurationseinstellungen aufgeführt, die zum Steuern dieses Features über MDM erforderlich sind:

Einstellungen Werte
Ziel-App Outlook Mac
Konfigurationsschlüssel trustedauthorities
Werttyp String
Konfigurationswert <ADFS FQDNs>

Ü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 moderne Authentifizierung aktiviert ist

Benutzer, die für die moderne Authentifizierung aktiviert sind und mehrere Clients (z. B. und Outlook Mobile) verwenden, Outlook on Windows haben unterschiedliche Verhaltensweisen für jeden Client. In der folgenden Zusammenfassung beschreiben wir das Clientverhalten, wenn die moderne Authentifizierung aktiviert ist, wobei davon ausgegangen Block Modern Auth wird, dass als DefaultAuthenticationPolicy auf der organization-Ebene angewendet wird.

Client Verhalten
Outlook für Windows (klassisch) Verwendet standardmäßig moderne Authentifizierung.
Outlook für Windows (neu) Versucht, die moderne Authentifizierung zu verwenden, schlägt jedoch fehl.
Outlook für Mac Verwendet moderne Authentifizierung, wenn sie auf dem Client aktiviert ist.
Outlook iOS Greift auf die Basic-Authentifizierung zurück.
Outlook Android Greift auf die Basic-Authentifizierung zurück.
iOS-Mail-App Verwendet moderne Authentifizierung.
macOS Mail-App Verwendet moderne Authentifizierung.
Gmail-App Greift auf die Basic-Authentifizierung zurück.
OWA/ECP Verwendet keine Authentifizierungsrichtlinie.
Je nach Konfiguration wird entweder die moderne Authentifizierung oder die Standardauthentifizierung verwendet.
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

Möglicherweise verwenden Sie die anspruchsbasierte Authentifizierung von AD FS für Outlook im Web. Die genannten Schritte sind erforderlich, um OAuth für andere Clients zu aktivieren, und wirken sich nicht darauf aus, wie OWA/ECP konfiguriert wird.

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 dem Aktivieren der modernen Authentifizierung für Exchange Server

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

Erneuern von Zertifikaten

Auswerten der aktuellen Zertifikatkonfiguration

Wenn es um Clientverbindungen mit Exchange Server geht, ist das Zertifikat, das ausgewertet werden sollte, 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.

  1. 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}

  2. 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.

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

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

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

  2. Stellen Sie eine Variable bereit, die den gewünschten Ausgabepfad Ihrer neuen Zertifikatanforderung enthält:

    $requestFile = "C:\temp\CertRequest.req"

  3. 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.

  4. 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.

  5. Stufen Sie eine Variable ein, die den vollständigen Pfad der abgeschlossenen Anforderung enthält:

    $certFile = "C:\temp\ExchangeCert.p7b"

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

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

  7. Stufenvariable für das Kennwort zum Schutz des abgeschlossenen Zertifikats:

    $pw = Read-Host "Enter password" -AsSecureString

  8. Exportieren Sie die Zertifikatbinärdatei in eine Variable:

    $binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

  9. Stufenvariable für den gewünschten Ausgabepfad des abgeschlossenen Zertifikats:

    $certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"

  10. Exportieren Sie die abgeschlossene Anforderung, um sie auf andere Server zu importieren:

    [System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)

  11. Aktivieren Sie die Dienste, die an das Zertifikat gebunden werden sollen:

    Enable-ExchangeCertificate <Thumbprint> -Services IIS

    Hinweis

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

  12. Überprüfen Sie, ob das Zertifikat wie beabsichtigt funktioniert, indem Sie einen Client für alle Clientnamespaces mit einer Hostdatei an den Server weiterleiten.

  13. 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.

  14. 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 vorherigen 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 Schritte zum Exchange Server Zertifikats generiert wird. Stellen Sie sicher, dass Sie auf dem primären AD FS-Server angemeldet sind.

  1. Stellen Sie eine Variable bereit, die das Kennwort für das Zertifikat enthält:

    $pw = Read-Host "Enter password" -AsSecureString

  2. Stellen Sie eine Variable bereit, die den vollständigen Pfad für das Zertifikat enthält:

    $certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"

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

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

  4. 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.

Hinweis

Die Verwendung des standardmäßigen selbstsignierten Zertifikats für Token-Signing in der anspruchsbasierten Authentifizierung von AD FS für Outlook im Web erfordert, dass das Zertifikat auf den Exchange-Servern installiert ist.