Abilitazione dell'autenticazione moderna in Exchange locale

2025-05-09

SI APPLICA A: no-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition

Panoramica

A partire da Exchange Server 2019 CU13, Exchange Server supporta OAuth 2.0 (noto anche come Modern Authentication) per ambienti locali puri che usano ADFS come servizio token di sicurezza. Questo documento fornisce i prerequisiti e i passaggi per abilitare questa funzionalità.

L'autenticazione moderna in Exchange Server 2019 non deve essere confusa con l'autenticazione moderna ibrida (HMA), che usa Microsoft Entra ID per l'autenticazione moderna. In effetti, HMA è ancora il metodo consigliato per abilitare l'autenticazione moderna per tutti gli utenti locali e cloud in una configurazione ibrida di Exchange. Questa nuova funzionalità consente l'uso dell'autenticazione moderna per le organizzazioni che non hanno Microsoft Entra ID o non si trovano in una configurazione ibrida di Exchange.

Come funzionerà l'autenticazione moderna e questa funzionalità è applicabile a me?

Con l'autenticazione moderna, gli utenti possono eseguire l'autenticazione in Exchange usando ADFS. Quando l'autenticazione moderna è abilitata per un utente, il client di Outlook viene reindirizzato ad ADFS. Gli utenti possono quindi eseguire l'autenticazione fornendo credenziali o eseguendo l'autenticazione a più fattori. Dopo aver autenticato un utente, ADFS genera token di accesso. Exchange Server convalida questi token di accesso per fornire l'accesso client alla cassetta postale dell'utente.

Il diagramma seguente illustra il coordinamento tra Exchange Server, ADFS e Outlook per autenticare un utente usando l'autenticazione moderna.

Nel grafico precedente i passaggi 3a, 4a5a e 6a vengono eseguiti quando l'autenticazione moderna è abilitata per l'utente finale. 4b I passaggi 3bsi verificano quando l'autenticazione moderna è disabilitata per un utente.

Fare riferimento alla tabella seguente per valutare se questa funzionalità è applicabile all'utente.

Configurazione di Exchange	Questa funzionalità è applicabile?	Osservazioni
Organizzazione di Exchange locale con solo Exchange Server 2019	Sì	N/D
Organizzazione di Exchange locale con combinazione di Exchange Server 2019, Exchange Server 2016 e Exchange Server 2013	No	Exchange Server 2013 non è disponibile.
Organizzazione di Exchange locale con combinazione di Exchange Server 2019 e Exchange Server 2016	Sì	Solo i server Exchange 2019 possono essere usati come server Front-End (Accesso client).
Organizzazione ibrida di Exchange con HMA	No	HMA che usa Microsoft Entra ID è la soluzione preferita. Fare riferimento alle indicazioni sull'uso di nuovi criteri di autenticazione.
Organizzazione ibrida di Exchange senza HMA	No	Usare HMA con Microsoft Entra ID.

Prerequisiti per abilitare l'autenticazione moderna in Exchange

Exchange Server 2019 CU13 o versione successiva

Per usare l'autenticazione moderna, tutti i server usati per le connessioni client devono avere installato Exchange Server CU13 2019.

ADFS 2019 o versione successiva

Per abilitare l'autenticazione moderna in un ambiente Exchange locale, è necessario Active Directory Federation Services (ADFS) in Windows Server 2019 o versioni successive. Non è supportato installare e configurare il ruolo ADFS in un Exchange Server. Per altre informazioni, vedere Pianificare la topologia di distribuzione di AD FS.

Potrebbe anche essere necessario il server Application Proxy Web (Windows Server 2019 o versione successiva) per abilitare l'accesso client dalla rete aziendale esterna. Per altre informazioni, vedere la sezione (Facoltativo) Configurare Application Proxy Web per Extranet Access.

Prerequisiti client

Per usare l'autenticazione moderna, gli utenti richiedono applicazioni client, ad esempio Outlook o altri client del sistema operativo nativi, compatibili con l'autenticazione moderna tramite ADFS.

Outlook per Windows

Il supporto per l'autenticazione moderna tramite ADFS è disponibile nelle versioni seguenti di Microsoft Outlook for Windows. Il client Windows di Microsoft Outlook, a partire dal numero di 16.0.17628.10000build, utilizza la versione più recente MSAL library per l'autenticazione. Per assicurarsi di usare lo stack di autenticazione più aggiornato, è consigliabile installare la versione più recente:

Outlook in Microsoft 365 Apps:

Canale	Supportato	Versione	Compilazione (o versione successiva)
Canale Insider	Sì	2304	16327.20200
Canale corrente	Sì	2304	16327.20214
Canale Enterprise mensile	Sì	2304	16327.20324
Canale Enterprise semestrale (Anteprima)	Sì	2402	17328.20184
Canale Enterprise semestrale	Sì	2402	17328.20452

Outlook per Windows (volume license & retail):

Versione	Supportato	Versione	Compilazione (o versione successiva)
Outlook 2016 (qualsiasi versione)	No	N/D	N/D
Outlook 2019 (qualsiasi versione)	No	N/D	N/D
Outlook 2021 (vendita al dettaglio)	Sì	2304	16327.20214
Outlook 2021 (volume)	No	N/D	N/D
Outlook 2024 (vendita al dettaglio)	Sì	2410	18129.20158
Outlook 2024 (volume)	Sì	2408	17932.20162

È possibile controllare il numero di build di Office seguendo i passaggi indicati qui.

Outlook per Mac

Il supporto per l'autenticazione moderna tramite ADFS è disponibile in fino a Outlook for Mac (Microsoft 365) Microsoft 365 a partire dal numero di 16.95.4 (25040241)build . Si noti che l'autenticazione moderna tramite ADFS non è attualmente supportata nelle versioni autonome, ad Outlook 2024 for Macesempio .

Sistema operativo Windows

Il client Windows deve essere Windows 11 22H2 or later e deve avere installato l'aggiornamento del 14 marzo 2023 .

È possibile esaminare Windows Update cronologia per verificare che KB5023706 sia installato.

Piattaforme Apple

Il supporto per l'autenticazione moderna tramite ADFS è disponibile nell'app Apple Mail a partire da macOS Sequoia e iOS 17.6.1e a Outlook for Mac (Microsoft 365) partire da macOS Sequoia.

Protocolli che funzionano con l'autenticazione moderna di ADFS

La tabella seguente descrive i protocolli a cui è possibile accedere usando i token di autenticazione moderna di ADFS. Stiamo lavorando continuamente per aggiungere il supporto dell'autenticazione moderna di ADFS a protocolli più Exchange Server.

Protocollo	Autenticazione moderna di ADFS supportata
MAPI su HTTP (MAPI/HTTP)	Sì
Outlook Via Internet (RPC/HTTP)	No
Exchange Active Sync (EAS)	Sì
Servizi Web Exchange (EWS)	Sì
Outlook sul Web (OWA)	Sì (autenticazione basata sulle attestazioni)
Exchange Amministrazione Center (ECP)	Sì (autenticazione basata sulle attestazioni)
Rubrica offline (Rubrica offline)	Sì
IMAP	No
POP	No

Procedura per configurare l'autenticazione moderna in Exchange Server usando ADFS come servizio token di sicurezza

Questa sezione fornisce informazioni dettagliate su come implementare l'autenticazione moderna in Exchange Server 2019 CU13.

Installare Exchange 2019 CU13 in tutti i server FE (almeno)

Tutti i server usati per le connessioni client devono essere aggiornati a Exchange 2019 CU13. Questo approccio garantisce che le connessioni client iniziali a Exchange 2019 usino OAuth e le connessioni proxy a Exchange Server 2016 usi Kerberos.

Exchange 2019 CU13 aggiunge il supporto per i nuovi criteri di autenticazione per consentire o bloccare l'autenticazione moderna a livello di utente. Il blocco dell'autenticazione moderna viene usato per garantire che i client che non supportano l'autenticazione moderna possano ancora connettersi.

L'esecuzione /PrepareAD con il programma di installazione è necessaria per aggiungere diversi nuovi parametri dei criteri di autenticazione a Exchange Server.

BlockModernAuthActiveSync
BlockModernAuthAutodiscover
BlockModernAuthImap
BlockModernAuthMapi
BlockModernAuthOfflineAddressBook
BlockModernAuthPop
BlockModernAuthRpc
BlockModernAuthWebServices

Dopo l'installazione di CU13 o versione successiva, tutti i criteri di autenticazione preesistenti (inclusi i criteri di autenticazione predefiniti) hanno i parametri disabilitati. Ciò significa che se si usa già HMA non è necessario modificare i criteri di autenticazione preesistenti.

Non sono necessari nuovi criteri di autenticazione per Exchange Ibrido

Le configurazioni ibride di Exchange esistenti devono usare l'autenticazione moderna ibrida (HMA). Le installazioni ibride che usano HMA possono lasciare i valori dei BlockModernAuth* parametri in per continuare a 0 usare HMA. I passaggi descritti per configurare l'autenticazione moderna con ADFS sono rilevanti solo per le organizzazioni che non usano Exchange Hybrid e sono puramente locali.

Configurare Active Directory Federation Services (ADFS)

È necessario installare e configurare ADFS nell'ambiente per consentire ai client exchange di usare l'autenticazione Forms (OAuth) per connettersi a Exchange Server. Fare riferimento all'elenco di controllo: Configurazione di un server federativo per facilitare la configurazione di ADFS.

La funzionalità ADFS può essere installata eseguendo il comando seguente da una finestra di PowerShell con privilegi elevati nel nuovo server che diventa il server ADFS:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Requisiti dei certificati per la configurazione di ADFS nell'organizzazione Exchange Server

ADFS richiede due tipi di certificati di base (vedere questo articolo per informazioni dettagliate):

Certificato SSL (Secure Sockets Layer) di comunicazione del servizio per il traffico crittografato dei servizi Web tra il server ADFS, i client, i server Exchange e il server Application Proxy Web facoltativo. È consigliabile utilizzare un certificato rilasciato da un'autorità di certificazione interna o commerciale poiché tutti i client devono considerare attendibile tale certificato.
Certificato di firma del token per la comunicazione e l'autenticazione crittografate tra il server ADFS, i controller di dominio di Active Directory e i server Exchange. È possibile ottenere un certificato di firma del token richiedendone uno da una CA o creando un certificato autofirmante.

Per ulteriori informazioni sulla creazione e importazione dei certificati SSL in Windows, vedere Certificati server.

Ecco un riepilogo dei certificati in uso in questo scenario:

Nome comune (CN) nel certificato (in Soggetto, nel Nome alternativo soggetto o in una corrispondenza con caratteri jolly nel certificato)	Tipo	Obbligatorio nei server	Commenti
adfs.contoso.com enterpriseregistration.contoso.com	Rilasciato da un'autorità di certificazione	Server ADFS, Server Application Proxy Web (facoltativo)	I server federativi usano un certificato SSL per proteggere il traffico dei servizi Web per le comunicazioni SSL con i client e con i proxy del server federativo. Poiché il certificato SSL deve essere considerato attendibile dai computer client, è consigliabile usare un certificato firmato da una CA attendibile. Tutti i certificati selezionati devono avere una chiave privata corrispondente.
Firma del token ADFS - adfs.contoso.com	Autofirma o problema da parte di un'autorità di certificazione	Server ADFS, Server Application Proxy Web (facoltativo)	Un certificato di firma del token è un certificato X509. I server federativi usano coppie di chiavi pubbliche/private associate per firmare digitalmente tutti i token di sicurezza che producono. Questo processo include la firma dei metadati federativi pubblicati e delle richieste di risoluzione degli artefatti. È possibile avere più certificati di firma dei token configurati nello snap-in Gestione ADFS per consentire il rollover del certificato quando un certificato è vicino alla scadenza. Per impostazione predefinita, tutti i certificati nell'elenco vengono pubblicati, ma solo il certificato di firma del token primario viene usato da ADFS per firmare effettivamente i token. Tutti i certificati selezionati devono avere una chiave privata corrispondente. È possibile ottenere un certificato di firma del token richiedendone uno a una CA aziendale o a una CA pubblica o creando un certificato autofirmante.
mail.contoso.com autodiscover.contoso.com	Rilasciato da un'autorità di certificazione	Server Exchange, Server Application Proxy Web (facoltativo)	Questo certificato è il certificato tipico usato per crittografare le connessioni client esterne a Outlook sul web (e ad altri servizi di Exchange). Per ulteriori informazioni, vedere Requisiti dei certificati per i servizi Exchange.

Distribuire e configurare il server ADFS

Usare Windows Server 2019 o versioni successive per distribuire un server ADFS. Seguire la procedura descritta in Distribuire un server ADFS e configurare e testare la documentazione del server ADFS . Assicurarsi che sia possibile accedere all'URL dei metadati di federazione in un Web browser sia dal server Exchange che da almeno un computer client.

L'URL usa questa sintassi: https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

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

Configurare il metodo di autenticazione in ADFS

Per usare l'autenticazione moderna in Outlook in Windows, è necessario configurare .Primary Authentication Methods È consigliabile scegliere Forms Authentication sia per che ExtranetIntranet. Questa configurazione può essere eseguita eseguendo i comandi seguenti da una finestra di PowerShell nel server ADFS:

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

Scegliere la durata dell'accesso SSO appropriata

Scegliere una durata single Sign-On (SSO) appropriata in modo che gli utenti finali non siano tenuti a ripetere l'autenticazione di frequente. Per convalidare la configurazione corrente della durata dell'accesso Single Sign-On, aprire una nuova finestra di PowerShell nel server ADFS ed eseguire il comando seguente:

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

Usare il cmdlet Set-AdfsProperties per configurare i valori appropriati per SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMinse DeviceUsageWindowInDays. Queste impostazioni devono essere modificate per abilitare l'accesso SSO e definirne la scadenza. A seconda della modalità SSO, ad Keep Me Signed In (KMSI) esempio o Device registration, potrebbe essere necessario abilitare KsmiEnabled e PersistentSsoEnabled. Per altre informazioni sull'accesso Single Sign-On di ADFS, vedere la documentazione di AD FS 2016 Single Sign On Settings.

Configurare la registrazione del dispositivo in ADFS

È consigliabile abilitare la Device Registration funzionalità in ADFS per trarre vantaggio da un'esperienza SSO migliorata. Per abilitare Device Registration, seguire i passaggi descritti nella documentazione Configurare un server federativo con il servizio registrazione dispositivi .

Completare quindi tutti i passaggi per configurare Device Registration Service Discovery e Device Registration Discovery Server SSL certificate, come descritto nella documentazione relativa alla configurazione della registrazione del dispositivo .

Per usare la registrazione del dispositivo, gli utenti finali devono aggiungere il dispositivo a un'area di lavoro. Altre informazioni sono disponibili nella documentazione seguente:

Verificare che la registrazione del dispositivo sia configurata e che l'autenticazione del dispositivo sia abilitata controllando .Device Registration Overview Questo passaggio è consigliato per ridurre il numero di richieste di autenticazione per gli utenti e può essere utile per applicare criteri di Controllo di accesso in ADFS.

Configurare KSMI in ADFS

Se si preferisce non usare Device Registration o non è possibile farlo, è invece possibile abilitare la Keep Me Signed In funzionalità. ADFS crea quindi un cookie permanente immediatamente dopo l'autenticazione dell'utente, eliminando la necessità di riautenticazione nelle sessioni successive, a condizione che il cookie rimanga valido.

L'ora di scadenza del token di aggiornamento è uguale alla durata del cookie SSO permanente per Keep me signed in. La durata persistente dei cookie SSO è di un giorno per impostazione predefinita con un massimo di sette giorni. In caso contrario, la durata del token di aggiornamento è uguale alla durata del cookie SSO della sessione (8 ore per impostazione predefinita). Altre informazioni su KSMI sono disponibili nella documentazione sulle impostazioni di Accesso Single Sign-On di AD FS .

KMSI è disabilitato per impostazione predefinita e può essere abilitato impostando la proprietà KmsiEnabled ADFS su True. Assicurarsi di eseguire i passaggi seguenti da una finestra di PowerShell nel server ADFS:

Set-AdfsProperties -EnableKmsi $true

Con KMSI disabilitato, il periodo di accesso Single Sign-On predefinito è 8 hours. Il periodo di Single Sign-On può essere configurato usando la proprietà SsoLifetime. La proprietà viene misurata in minuti, quindi il valore predefinito è 480:

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

Con KMSI abilitato, il periodo di accesso Single Sign-On predefinito è 24 hours. Il periodo di accesso Single Sign-On con KMSI abilitato può essere configurato usando la proprietà KmsiLifetimeMins. La proprietà viene misurata in minuti, quindi il valore predefinito è 1440:

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

Creare il gruppo di applicazioni di Outlook ADFS

Se questa è la prima volta che si configura l'autenticazione moderna di ADFS in Exchange locale, seguire i passaggi descritti in questa sezione della guida. Se è stata configurata una configurazione dell'autenticazione moderna di ADFS esistente prima del supporto per client diversi da Microsoft Outlook for Windows, vedere la procedura descritta nella sezione Aggiornare il gruppo di applicazioni di Outlook ADFS esistente di questa documentazione. I comandi di PowerShell seguenti devono essere eseguiti da una finestra di PowerShell nel server ADFS. Se non si prevede di usare applicazioni iOS e macOS, ad esempio l'app Apple Mail nativa, è possibile ignorare la creazione dell'applicazione client nativa ADFS per iOS e macOS. Tuttavia, è consigliabile crearli per motivi di completezza.

In primo luogo, si creerà :ADFS Application Group

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

Verranno quindi creati altri tre Scopes - EAS.AccessAsUser.Allelementi , EWS.AccessAsUser.All e 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"

Ora vengono creati due Native Client Applications - Outlook - Native application e :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/")

Come passaggio successivo, viene creato Web Api Applications. Viene creata un'applicazione per URI usata nell'ambiente Exchange Server. Se si usano, ad esempio, autodiscover.contoso.com e mail.contoso.com, è necessario creare due Web Api Applications. Assicurarsi di sostituire gli URI nell'esempio seguente con gli URI usati nella configurazione. È importante assicurarsi che tutti gli URI rivolti al client siano coperti. Includere l'oggetto / finale e assicurarsi che gli URI inizino con https://:

# 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"
}

Come ultimo passaggio, vengono aggiunte le autorizzazioni client per tutti gli Native Client Applications elementi in esistente Web Api Applications:

$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"
    }
}

Aggiornare il gruppo di applicazioni di Outlook ADFS esistente

Importante

Ignorare i passaggi descritti in questa sezione se non si dispone di un gruppo di applicazioni di AdFS Outlook esistente, configurato prima dell'introduzione del supporto per i client diversi da Microsoft Outlook for Windows .

Se si dispone di una configurazione del gruppo di applicazioni di Outlook ADFS esistente, configurata prima del supporto per client diversi da quelli Microsoft Outlook for Windows introdotti, seguire questa procedura per abilitare il supporto per altre piattaforme. I comandi di PowerShell seguenti devono essere eseguiti da una finestra di PowerShell nel server ADFS.

Prima di tutto vengono creati tre elementi aggiuntiviScopes - EAS.AccessAsUser.All, EWS.AccessAsUser.All e :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"

A questo momento si sta creando un nuovo Native Client Applications - iOS and macOS - Native mail applicationoggetto :

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/")

Aggiorniamo l'oggetto esistente Native Client Application - Outlook - Native application. Assicurarsi di sostituire TargetName con il nome di destinazione usato nella configurazione esistente:

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")

Come passaggio successivo, è necessario crearne uno Web Api Application per ogni Identifier URI che viene usato nell'ambiente Exchange Server ed è presente nella configurazione corrente dell'autenticazione moderna di ADFS:

$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
}

Come ultimo passaggio, vengono aggiunte le autorizzazioni client per tutti gli Native Client Applications elementi in esistente Web Api Applications:

$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
            }
        }
    }
}

Rimuovere il gruppo di applicazioni di Outlook ADFS esistente

Attenzione

Seguendo i passaggi descritti in questa sezione, viene rimossa la configurazione esistente del gruppo di applicazioni di AdFS Outlook.

Se si dispone di una configurazione del gruppo di applicazioni di Outlook ADFS esistente e si vuole rimuoverla, seguire questa procedura per eliminare la configurazione esistente. Tutti i comandi di PowerShell seguenti devono essere eseguiti da una finestra di PowerShell nel server ADFS.

Prima di tutto, si eliminerà :ADFS Application Group

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

Come ultimo passaggio, viene eliminata l'personalizzata Scopes aggiunta:

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

(Facoltativo) Configurare Application Proxy Web può essere configurato per Extranet Access

Application Proxy Web fa parte del ruolo del server di Accesso remoto in Windows Server. Fornisce funzionalità proxy inverso per consentire agli utenti di accedere alle applicazioni Web dall'esterno della rete aziendale. Web Application Proxy preautentica l'accesso alle applicazioni Web tramite ADFS e funziona come proxy ADFS.

Se si prevede di usare il proxy dell'applicazione Web, seguire la procedura descritta in Installare e configurare il server Application Proxy Web per configurarlo. Una volta configurate, è possibile pubblicare regole per Autodiscover.contoso.com o/e mail.contoso.com seguendo i passaggi indicati in Pubblicare un'applicazione che usa OAuth2.

(Facoltativo) Configurare l'autenticazione a più fattori per l'accesso client

Fare riferimento ai collegamenti seguenti per configurare ADFS con un provider MFA di propria scelta.
- Configurare i provider di autenticazione di terze parti come autenticazione primaria in AD FS 2019
- Configurare Azure MFA come provider di autenticazione con AD FS
Configurare i criteri di Controllo di accesso che richiedono l'autenticazione a più fattori.
- Criteri di Controllo di accesso in Windows Server 2016 AD FS

Creare criteri di autenticazione per gli utenti finali

È possibile che non tutti gli utenti dell'organizzazione dispongano di client di posta elettronica che supportano l'autenticazione moderna tramite ADFS. In questo scenario è consigliabile abilitare l'autenticazione moderna per gli utenti con client supportati e bloccarla per gli utenti senza.

Per abilitare l'autenticazione moderna per un set specifico di utenti e bloccarla per gli utenti rimanenti, è necessario creare almeno due criteri di autenticazione.

Importante

I nuovi criteri di autenticazione diventano disponibili non appena Active Directory viene preparato usando il supporto di Exchange 2019 CU13 o versione successiva.

Criteri a livello di organizzazione per bloccare l'autenticazione moderna per impostazione predefinita
Criteri secondari per consentire in modo selettivo l'autenticazione moderna per utenti specifici

I comandi di PowerShell seguenti devono essere eseguiti da una finestra di Exchange Management Shell (EMS) nel server Exchange.

Creare criteri a livello di organizzazione per bloccare l'autenticazione moderna per impostazione predefinita

Dopo aver abilitato l'autenticazione moderna, tutti i client di Outlook tentano di usare i token OAuth. Tuttavia, alcuni client non compatibili con l'autenticazione moderna di ADFS possono recuperare solo i token OAuth da Microsoft Entra ID. Pertanto, questi client non sono in grado di connettersi se è abilitata l'autenticazione moderna.

Per evitare questo scenario, è possibile implementare criteri a livello di organizzazione per disabilitare l'autenticazione moderna. Nell'esempio viene creato un nuovo criterio di autenticazione denominato Block Modern Auth.

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

Questo criterio può essere impostato a livello di organizzazione usando il comando seguente.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

Creare criteri di autenticazione a livello di utente per abilitare l'autenticazione moderna

Creare quindi un secondo criterio di autenticazione che abilita l'autenticazione moderna. Assegnare questo criterio a tutti gli utenti con client Outlook supportati per consentire ai client di usare l'autenticazione moderna.

Nell'esempio viene creata una nuova autenticazione denominata Allow Modern Auth usando il comando seguente:

New-AuthenticationPolicy "Allow Modern Auth"

Configurare Exchange Server per l'uso dei token OAuth di ADFS

Verificare se OAuth è abilitato nelle directory virtuali seguenti. Se non è abilitato, abilitarlo OAuth per tutte queste directory virtuali:
```
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*
```
L'output viene visualizzato come segue. Il dettaglio principale su cui concentrarsi è OAuth, come indicato in precedenza:
```
Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
```
Se OAuth manca da un server o da una qualsiasi delle cinque directory virtuali, è necessario aggiungerla usando i comandi pertinenti prima di procedere: Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OabVirtualDirectory, Set-AutodiscoverVirtualDirectory e Set-ActiveSyncVirtualDirectory.
Eseguire il comando qui riportato:
```
New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml
```
Questo comando è necessario per creare un nuovo oggetto server di autenticazione in Exchange Server per ADFS. Gli oggetti server di autenticazione sono un elenco di autorità emittenti attendibili. Vengono accettati solo i token OAuth di questi emittenti.
Eseguire il comando qui riportato:
```
Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true
```
Impostare il server di autenticazione appena aggiunto come DefaultAuthorizationEndpoint. Quando si annuncia l'intestazione Modern Auth, Exchange Server annuncia l'URL di autenticazione di DefaultAuthorizationEndpoint. Questo è il modo in cui i client sanno quale endpoint usare per l'autenticazione.
È necessario eseguire questo comando per abilitare l'autenticazione moderna a livello di organizzazione:
```
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
```
Abilitare l'autenticazione moderna per gli utenti con client supportati assegnando i Allow Modern Auth criteri di autenticazione:
```
Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"
```

Client-Side configurazione dell'autenticazione moderna

È consigliabile testare l'autenticazione moderna con pochi utenti prima di distribuirla a tutti gli utenti. Quando un gruppo pilota di utenti può usare l'autenticazione moderna, è possibile distribuire più utenti. Verificare che il client supporti l'autenticazione moderna di ADFS. Per altre informazioni sui client supportati, vedere la sezione Prerequisiti client .

Microsoft Windows

Abilitare l'autenticazione moderna e aggiungere il dominio ADFS come dominio attendibile in Outlook:

Creare le chiavi del Registro di sistema seguenti per rendere il dominio ADFS un dominio attendibile. Assicurarsi di aggiungere entrambe le chiavi con e senza / alla fine del dominio ADFS:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain/
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain
È possibile usare PowerShell per creare le chiavi del Registro di sistema o distribuirle con l'aiuto di un Criteri di gruppo. Eseguire i comandi seguenti da una finestra di PowerShell in ogni computer client. Sostituire your-ADFS-domain con il dominio ADFS.
```
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")
```
Per abilitare l'autenticazione moderna di ADFS in Microsoft Outlook for Windows aggiungere il EnableExchangeOnPremModernAuthREG_DWORD valore in HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\.

È possibile usare PowerShell per creare il valore del Registro di sistema o distribuirlo tramite un Criteri di gruppo. Eseguire il comando seguente da una finestra di PowerShell in ogni computer client.
```
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord
```

Apple macOS

Per abilitare l'autenticazione moderna per Microsoft Outlook nelle versioni supportate di Apple macOS, è necessario modificare le preferenze per l'applicazione Microsoft Outlook.

Aprire una finestra terminale ed eseguire il comando seguente, sostituendo host1 con il nome di dominio completo del server ADFS. Assicurarsi di non includere il protocollo o aggiungere barre alla fine del nome di dominio completo. Ad esempio, se il server ADFS è raggiungibile tramite https://fs.contoso.com/, usare fs.contoso.com. Se sono presenti più spazi dei nomi ADFS, aggiungerli separati da uno spazio.

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

Per i dispositivi gestiti, gli amministratori possono usare una soluzione Mobile Gestione dispositivi (MDM) per gestire centralmente ed eseguire il push di un elenco di FQDN ADFS nei dispositivi client. La tabella seguente descrive le impostazioni di configurazione necessarie per controllare questa funzionalità tramite MDM:

Impostazioni	Valori
App di destinazione	`Outlook Mac`
Chiave di configurazione	`trustedauthorities`
Tipo valore	`String`
Valore di configurazione	`<ADFS FQDNs>`

Verificare il flusso di autenticazione moderna

Una volta configurata correttamente, gli utenti riscontrano la richiesta di accesso ADFS quando si connettono a un server Exchange.

Effetto su altri client quando è abilitata l'autenticazione moderna

Gli utenti abilitati per l'autenticazione moderna che usano più client ( Outlook on Windows ad esempio e Outlook Mobile) sperimentano comportamenti diversi in ogni client. Nel riepilogo seguente vengono descritti i comportamenti client quando l'autenticazione moderna è abilitata, presupponendo che Block Modern Auth venga applicata come DefaultAuthenticationPolicy a livello di organizzazione.

Client	Comportamento
Outlook per Windows (versione classica)	Usa l'autenticazione moderna per impostazione predefinita.
Outlook per Windows (nuovo)	Tenta di usare l'autenticazione moderna ma non riesce.
Outlook per Mac	Usa l'autenticazione moderna se abilitata nel client.
Outlook iOS	Torna all'autenticazione di base.
Outlook Android	Torna all'autenticazione di base.
App di posta elettronica iOS	Usa l'autenticazione moderna.
App macOS Mail	Usa l'autenticazione moderna.
App Gmail	Torna all'autenticazione di base.
OWA/ECP	Non usa i criteri di autenticazione. A seconda della modalità di configurazione, usa l'autenticazione moderna o l'autenticazione di base.
App Windows Mail	Non rientra nell'autenticazione di base.
Client Thunderbird	Non rientra nell'autenticazione di base.
PowerShell	Usa l'autenticazione di base.

Effetto su OWA/ECP quando l'autenticazione moderna è abilitata per altri client

È possibile o meno usare l'autenticazione basata sulle attestazioni ADFS per Outlook sul web. I passaggi indicati sono necessari per abilitare OAuth per altri client e non influiscono sulla configurazione di OWA/ECP.

Uso dell'autenticazione basata sulle attestazioni AD FS con Outlook sul web

Tempo di attesa dopo la modifica dei criteri di autenticazione

Dopo aver modificato i criteri di autenticazione per consentire l'autenticazione moderna o bloccare l'autenticazione legacy:

Attendere 30 minuti per la lettura dei nuovi criteri da parte dei server front-end

or
Eseguire una reimpostazione IIS in tutti i server front-end.

Migrazione all'autenticazione moderna ibrida dopo l'abilitazione dell'autenticazione moderna per Exchange Server

Se si usa l'autenticazione moderna con ADFS e successivamente si decide di configurare Exchange Hybrid, è consigliabile passare all'autenticazione moderna ibrida. I passaggi di migrazione dettagliati verranno inclusi in una versione futura di questo documento.

Rinnovo dei certificati

Valutare la configurazione del certificato corrente

Quando si tratta di connessioni client a Exchange Server, il certificato che deve essere valutato è quello associato al sito IIS front-end. Per un server ADFS, è ideale assicurarsi che tutti i certificati restituiti in Get-AdfsCertificate siano correnti.

Per identificare il certificato pertinente in un Exchange Server, eseguire le operazioni seguenti in Exchange Management Shell:

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}

Per esaminare i certificati attivi in un server ADFS, eseguire le operazioni seguenti in PowerShell:
```
Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap
```

Aggiornare i certificati in Exchange Server

Se è stato rilevato che il certificato di Exchange deve essere aggiornato per la connettività client, è necessario emettere e importare un nuovo certificato nei server Exchange. Successivamente, il certificato deve essere abilitato almeno per IIS. Valutare se è necessario abilitare altri servizi per il nuovo certificato in base alla configurazione.

Esempio per la creazione, il completamento, l'abilitazione e l'importazione di un nuovo certificato in tutti i server in base al certificato esistente all'interno di Exchange Management Shell:

Generare una nuova richiesta di certificato all'interno di Exchange Management Shell in base al certificato esistente:

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

Creare una variabile contenente il percorso di output desiderato della nuova richiesta di certificato:
```
$requestFile = "C:\temp\CertRequest.req"
```
Creare il file della richiesta di certificato:
```
[System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))
```
Nota

Il percorso della cartella per la richiesta di certificato deve già esistere.
Condividere il file di richiesta con l'autorità di certificazione (CA). I passaggi necessari per ottenere un certificato completato variano in base alla CA.

Nota

.p7b è il formato preferito per la richiesta completata.
Creare una variabile contenente il percorso completo della richiesta completata:
```
$certFile = "C:\temp\ExchangeCert.p7b"
```

Importare la richiesta nel server che ha generato la richiesta in origine:

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

Variabile di fase per la password per proteggere il certificato completato:
```
$pw = Read-Host "Enter password" -AsSecureString
```

Esportare il file binario del certificato in una variabile:

$binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

Variabile di fase per il percorso di output desiderato del certificato completato:
```
$certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"
```

Esportare la richiesta completata da importare in altri server:

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

Abilitare i servizi che devono essere associati al certificato:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS
```
Nota

Potrebbe essere necessario aggiungere altri servizi all'esempio precedente in base alla configurazione dei certificati precedente.
Verificare che il certificato funzioni come previsto indirizzando un client al server per tutti gli spazi dei nomi client con un file host.
Importare il certificato di Exchange in tutti gli altri server Exchange:
```
Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>
```
Nota

L'inclusione del -PrivateKeyExportable parametro è facoltativa durante l'importazione in altri server Exchange.
Abilitare il certificato di Exchange per i servizi Exchange necessari in tutti gli altri server Exchange:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>
```
Nota

Potrebbe essere necessario aggiungere altri servizi all'esempio precedente in base alla configurazione dei certificati precedente.

Aggiornare il certificato in ADFS

A seconda del tipo di certificato che richiede l'aggiornamento in ADFS, determina se è necessario seguire la procedura descritta di seguito.

certificato Service-Communications

Questo esempio fornisce PowerShell necessario per importare un certificato in .pfx formato, ad esempio quello generato seguendo i passaggi del certificato Exchange Server. Assicurarsi di aver eseguito l'accesso al server ADFS primario.

Creare una variabile contenente la password per il certificato:
```
$pw = Read-Host "Enter password" -AsSecureString
```
Creare una variabile contenente il percorso completo per il certificato:
```
$certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"
```

Importare il certificato nell'archivio personale di LocalMachine:

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

Aggiornare il certificato Service-Communications:

Set-AdfsSslCertificate -Thumbprint <Thumbprint>

certificati Token-Signing e Token-Decryption

Seguire i passaggi descritti nella documentazione Ottenere e configurare certificati TS e TD per AD FS .

Nota

L'uso del certificato autofirmato predefinito per Token-Signing nell'autenticazione basata sulle attestazioni ADFS per Outlook sul web richiede l'installazione del certificato nei server Exchange.

Condividi tramite