Configurare La protezione estesa di Windows in Exchange Server
Panoramica
Windows Extended Protection migliora l'autenticazione esistente in Windows Server e riduce gli attacchi di inoltro di autenticazione o man-in-the-middle (MitM). Questa mitigazione viene eseguita usando le informazioni di sicurezza implementate tramite le informazioni di associazione di canale specificate tramite un Channel Binding Token (CBT) oggetto usato principalmente per le connessioni TLS.
La protezione estesa è abilitata per impostazione predefinita quando si installa Exchange Server 2019 CU14 (o versione successiva). Per altre informazioni, vedere Rilasciato: Aggiornamento cumulativo 2024 H1 per Exchange Server.
Nelle versioni precedenti di Exchange Server (ad esempio, Exchange Server 2016), la protezione estesa può essere abilitata tramite lo script diExchangeExtendedProtectionManagement.ps1 in alcuni o tutti i server Exchange.
Terminologia usata in questa documentazione
Directory virtuale o vDir
Viene usato da Exchange Server per consentire l'accesso ad applicazioni Web quali Exchange ActiveSync, Outlook on the Webe il AutoDiscover servizio . Un amministratore può configurare diverse impostazioni della directory virtuale, incluse le impostazioni di autenticazione, sicurezza e creazione di report. La protezione estesa è una di queste impostazioni di autenticazione.
Impostazione protezione estesa
Controlla il comportamento per il controllo di Channel Binding Tokens o CBT. I valori possibili per questa impostazione sono elencati nella tabella seguente:
| Valore | Descrizione |
|---|---|
| Nessuno | Specifica che IIS non esegue il controllo CBT. |
| Consenti | Specifica che il controllo CBT è abilitato, ma non obbligatorio. Questa impostazione consente la comunicazione sicura con i client che supportano la protezione estesa e supporta comunque i client che non sono in grado di usare la protezione estesa. |
| Richiedere | Questo valore specifica che è necessario il controllo CBT. Questa impostazione blocca i client che non supportano la protezione estesa. |
Flag SSL
La configurazione delle impostazioni SSL è necessaria per garantire che i client si connettono alle directory virtuali IIS in modo specifico con i certificati client. Per abilitare la protezione estesa, i flag SSL necessari sono SSL e SSL128.
Offload SSL
Termina la connessione in un dispositivo tra il client e il Exchange Server e quindi usa una connessione non crittografata per connettersi al Exchange Server.
Bridging SSL
Descrive un processo in cui un dispositivo, situato sul bordo di una rete, decrittografa il traffico SSL e quindi lo crittografa nuovamente prima di inviarlo al server Web.
Agente ibrido moderno o ibrido
Questo è il nome di un metodo di configurazione di Exchange ibrido che rimuove alcuni dei requisiti di configurazione per l'ambiente ibrido classico (ad esempio, le connessioni di rete in ingresso attraverso il firewall) per abilitare le funzionalità ibride di Exchange. Altre informazioni su questa funzionalità sono disponibili qui.
Cartelle pubbliche
Sono progettati per l'accesso condiviso e per semplificare l'esplorazione del contenuto in una gerarchia approfondita. Altre informazioni sulle cartelle pubbliche sono disponibili qui.
Prerequisiti per l'abilitazione della protezione estesa in Exchange Server
Consiglio
È consigliabile eseguire lo script di Controllo integrità Exchange Server per verificare se tutti i prerequisiti sono soddisfatti nel server Exchange in cui deve essere attivata la protezione estesa.
Versioni di Exchange Server che supportano la protezione estesa
La protezione estesa è supportata in Exchange Server 2013, 2016 e 2019 a partire dalle versioni di agosto 2022 Exchange Server Security Update (SU).
Se l'organizzazione ha installato Exchange Server 2016 o Exchange Server 2019, deve eseguire il Aggiornamenti cumulativo di exchange trimestrale di settembre 2021 o l'aggiornamento cumulativo H1 del 2022. È necessario avere installato almeno l'aggiornamento della sicurezza di agosto 2022 o versione successiva prima di continuare con la configurazione di Protezione estesa.
Se l'organizzazione ha installato Exchange Server 2013, Exchange Server deve trovarsi in CU23 con l'aggiornamento della sicurezza di agosto 2022 o versione successiva installato.
Avviso
Exchange Server 2013 ha raggiunto la fine del supporto l'11 aprile 2023.
Requisiti di configurazione di Outlook Via Internet
L'offload SSL per è abilitato per Outlook Anywhere impostazione predefinita e deve essere disabilitato prima che sia abilitata la protezione estesa. Seguire i passaggi descritti nell'esempio 3.
Importante
Exchange Server programma di installazione CU14 (o versione successiva) 2019 disabilita automaticamente l'offload Outlook Anywhere SSL. Fa parte della protezione estesa abilitata per impostazione predefinita.
Requisiti della versione NTLM
NTLMv1 è debole e non fornisce protezione dagli attacchi man-in-the-middle (MitM). Deve essere considerato vulnerabile e non più usato.
NTLMv1 non può essere usato insieme alla protezione estesa. Se si impone l'uso NTLMv1 di un client al posto di NTLMv2 e la protezione estesa è abilitata nei server Exchange, questa configurazione comporta la richiesta di password sul lato client senza un modo per eseguire correttamente l'autenticazione sul server Exchange.
Nota
Per aumentare la sicurezza, è consigliabile esaminare e configurare questa impostazione indipendentemente dal fatto che si verifichino problemi o meno.
Se si verificano richieste di password nei client una volta abilitata la protezione estesa, è necessario controllare la chiave e il valore del Registro di sistema seguenti nel client e sul lato Exchange Server:
Chiave del Registro di sistema: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Valore del Registro di sistema: LmCompatibilityLevel
È consigliabile impostarlo su un valore di 5, che è Send NTLMv2 response only. Refuse LM & NTLM. Deve essere impostato almeno su un valore di 3 che è Send NTLMv2 response only.
Se si elimina il valore, il sistema operativo applica l'impostazione predefinita del sistema. In Windows Server 2008 R2 e versioni successive, viene considerato come se fosse impostato su 3.
Per gestire l'impostazione in modo centralizzato, è possibile eseguire questa operazione usando Criteri di gruppo:
Percorso dei criteri: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Altre informazioni: Sicurezza di rete: livello di autenticazione LAN Manager
Requisiti di TLS
Prima di abilitare la protezione estesa, è necessario assicurarsi che tutte le configurazioni TLS siano coerenti in tutti i server Exchange. Ad esempio, se uno dei server usa TLS 1.2, è necessario assicurarsi che tutti i server dell'organizzazione siano configurati usando TLS 1.2. Qualsiasi variazione nell'uso della versione TLS tra server può causare l'esito negativo delle connessioni tra client o server.
Oltre a questo requisito, il valore del valore del Registro di SchUseStrongCrypto sistema deve essere impostato su un valore di 1 in tutti i server Exchange all'interno dell'organizzazione.
Se questo valore non è impostato in modo esplicito su 1, il valore predefinito di questa chiave può essere interpretato come 0 o 1 a seconda della versione di .NET in uso dai file binari Exchange Server ed è possibile che si verifichino problemi di connessione nelle comunicazioni da server a server. Ciò può verificarsi, soprattutto se sono in uso versioni diverse di Exchange Server (ad esempio, Exchange Server 2016 e Exchange Server 2019).
Lo stesso vale per il valore del SystemDefaultTlsVersions Registro di sistema, che deve anche essere impostato in modo esplicito su un valore di 1.
Se questi valori del Registro di sistema non sono configurati come previsto, questa configurazione errata può causare una mancata corrispondenza tra TLS nel server o nella comunicazione tra server o client e, di conseguenza, potrebbe causare problemi di connettività.
Fare riferimento a questo Exchange Server guida alle procedure consigliate per la configurazione di TLS per configurare le impostazioni TLS necessarie nei server Exchange.
Compatibilità software di terze parti
Prima di abilitare la protezione estesa, è essenziale eseguire test su tutti i prodotti di terze parti all'interno dell'ambiente Exchange Server per garantire che funzionino correttamente. Se non si è certi che la protezione estesa sia supportata, contattare il fornitore per la conferma.
Sono state illustrate, ad esempio, soluzioni antivirus, che inviavano connessioni tramite un server proxy locale per proteggere il computer client. Questo scenario impedirebbe la comunicazione con il server Exchange e dovrebbe essere disabilitato perché è considerato una connessione man-in-the-middle (MitM), che verrà bloccata da Protezione estesa.
Scenari che potrebbero influire sulla connettività client quando è stata abilitata la protezione estesa
Scenari di offload SSL
La protezione estesa non è supportata negli ambienti che usano l'offload SSL. La terminazione SSL durante l'offload SSL causa l'esito negativo della protezione estesa. Per abilitare la protezione estesa nell'ambiente Exchange, non è necessario usare l'offload SSL con i servizi di bilanciamento del carico.
Scenari di bridging SSL
La protezione estesa è supportata negli ambienti che usano il bridging SSL in determinate condizioni. Per abilitare la protezione estesa nell'ambiente Exchange usando il bridging SSL, è necessario usare lo stesso certificato SSL in Exchange e nei servizi di bilanciamento del carico. L'uso di certificati diversi causa l'esito negativo del controllo del token di associazione del canale di protezione estesa e, di conseguenza, impedisce ai client di connettersi al server Exchange.
Scenari di protezione estesa e cartelle pubbliche
La sezione seguente illustra gli scenari di cartelle pubbliche, che potrebbero causare errori quando è abilitata la protezione estesa.
La protezione estesa non può essere abilitata nei server Exchange Server 2013 con cartelle pubbliche in un ambiente di coesistenza
Per abilitare La protezione estesa in Exchange Server 2013, assicurarsi di non avere cartelle pubbliche ospitate in Exchange Server 2013. Se si ha la coesistenza di Exchange Server 2013 con Exchange Server 2016 o Exchange Server 2019, è necessario eseguire la migrazione delle cartelle pubbliche a Exchange Server 2016 o Exchange Server 2019 prima di abilitare La protezione estesa. Dopo aver abilitato La protezione estesa e sono presenti cartelle pubbliche in Exchange Server 2013, non verranno più visualizzate agli utenti finali.
Avviso
Exchange Server 2013 ha raggiunto la fine del supporto l'11 aprile 2023.
La protezione estesa non può essere abilitata in Exchange Server 2016 CU22 o Exchange Server 2019 CU11 o versione precedente che ospita una gerarchia di cartelle pubbliche
Se si dispone di un ambiente contenente Exchange Server 2016 CU22 o Exchange Server 2019 CU11 o versioni precedenti e si usano cartelle pubbliche, è necessario confermare la versione del server che ospita la gerarchia delle cartelle pubbliche prima di abilitare la protezione estesa.
Assicurarsi che il server, che ospita la gerarchia di cartelle pubbliche, venga aggiornato a Exchange Server 2016 CU23 o Exchange Server 2019 CU12 (o versione successiva) con la Aggiornamenti di sicurezza più recente installata. Spostare la gerarchia di cartelle pubbliche in un Exchange Server che esegue una versione necessaria se non è possibile aggiornare il server Exchange a una versione supportata.
La tabella seguente può essere usata per chiarire:
| Versione di Exchange | CU installato | SU installato | Ospita le cassette postali PF | Ep supportato? |
|---|---|---|---|---|
| Exchange 2013 | CU23 | Agosto 2022 (o versione successiva) | No | Sì |
| Exchange 2016 | CU22 | Agosto 2022 (o versione successiva) | Nessuna cassetta postale della gerarchia | Sì |
| Exchange 2016 | CU23 (2022 H1) o versione successiva | Agosto 2022 (o versione successiva) | Qualsiasi | Sì |
| Exchange 2019 | CU11 | Agosto 2022 (o versione successiva) | Nessuna cassetta postale della gerarchia | Sì |
| Exchange 2019 | CU12 (2022 H1) o versione successiva | Agosto 2022 (o versione successiva) | Qualsiasi | Sì |
| Qualsiasi altra versione | Qualsiasi altra CU | Qualsiasi altro SU | Qualsiasi | No |
Protezione estesa e configurazione ibrida moderna
La sezione seguente illustra Exchange Server scenari ibridi moderni, che potrebbero causare errori quando è abilitata la protezione estesa.
La protezione estesa non può essere completamente configurata nei server Exchange pubblicati con l'agente ibrido
In una configurazione ibrida moderna, i server Exchange vengono pubblicati tramite un agente ibrido, che esegue il proxy delle chiamate Exchange Online al server Exchange.
L'abilitazione della protezione estesa nei server Exchange pubblicati tramite l'agente ibrido può causare interruzioni delle funzionalità ibride, ad esempio lo spostamento delle cassette postali e le chiamate alla disponibilità, se non vengono eseguite correttamente. È quindi importante identificare tutti i server Exchange, pubblicati con l'aiuto di un agente ibrido e non abilitare la protezione estesa nella directory virtuale EWS Front-End.
Identificazione dei server Exchange pubblicati tramite l'agente ibrido
Se non si dispone di un elenco di server, pubblicati tramite l'agente ibrido, è possibile usare la procedura seguente per identificarli. Questi passaggi non sono necessari se si esegue una distribuzione ibrida Exchange Server classica.
- Accedere a un computer in cui è installato l'agente ibrido e aprire il modulo PowerShell dell'agente ibrido. Eseguire
Get-HybridApplicationper identificare l'oggettoTargetUriusato dall'agente ibrido. - Il
TargetUriparametro fornisce il nome di dominio completo del server Exchange, configurato per l'uso da parte dell'agente ibrido.- Dedurre l'identità del server Exchange usando il nome di dominio completo e prendere nota del nome del server Exchange.
- Se si usa un URL di Load Balancer in
TargetUri, è necessario identificare tutti i server Exchange, in cui è installato ilClient Accessruolo e che possono essere raggiunti dietro l'URL di Load Balancer.
Importante
La protezione estesa non deve essere abilitata nella directory virtuale EWS Front-End nei server Exchange pubblicati tramite un agente ibrido.
È consigliabile seguire questa procedura per proteggere i server Exchange, pubblicati tramite l'agente ibrido:
Nota
Nello scenario seguente, l'agente ibrido viene installato in un server che NON esegue Exchange Server. Inoltre, questo server si trova in un segmento di rete diverso dai server Exchange di produzione.
- Per i server Exchange pubblicati tramite l'agente ibrido, le connessioni in ingresso devono essere limitate da un firewall per consentire le connessioni solo dal computer in cui è installato l'agente ibrido. Ciò non influisce sulle comunicazioni in uscita dai server Exchange ai Exchange Online.
- Nei server Exchange non devono essere ospitate cassette postali, che sono state pubblicate tramite l'agente ibrido. È necessario eseguire la migrazione delle cassette postali esistenti ad altri server cassette postali.
Abilitazione della protezione estesa
La protezione estesa viene abilitata automaticamente durante Exchange Server configurazione di CU14 (o versione successiva) 2019. Nelle versioni precedenti di Exchange Server, che supportano la protezione estesa, può essere abilitato tramite uno script fornito da Microsoft (consigliato) o manualmente tramite Gestione IIS.
Per configurare correttamente la protezione estesa, ogni directory virtuale in tutti i server Exchange dell'organizzazione (esclusi i server Trasporto Edge) deve essere impostata sul valore specificato di Extended Protection e sslFlags.
La tabella seguente riepiloga le impostazioni necessarie per ogni directory virtuale nelle versioni supportate di Exchange Server.
| Sito Web IIS | Directory virtuale | Valore consigliato | SslFlags consigliati |
|---|---|---|---|
Default Website |
API |
Required |
Ssl,Ssl128 |
Default Website |
AutoDiscover |
Off |
Ssl,Ssl128 |
Default Website |
ECP |
Required |
Ssl,Ssl128 |
Default Website |
EWS |
Accept (UI) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
MAPI |
Required |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync |
Accept (UI) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync/Proxy |
Accept (UI) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
OAB |
Accept (UI) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
OWA |
Required |
Ssl,Ssl128 |
Default Website |
PowerShell |
Off |
SslNegotiateCert |
Default Website |
RPC |
Required |
Ssl,Ssl128 |
Exchange Backend |
API |
Required |
Ssl,Ssl128 |
Exchange Backend |
AutoDiscover |
Off |
Ssl,Ssl128 |
Exchange Backend |
ECP |
Required |
Ssl,Ssl128 |
Exchange Backend |
EWS |
Required |
Ssl,Ssl128 |
Exchange Backend |
Microsoft-Server-ActiveSync |
Required |
Ssl,Ssl128 |
Exchange Backend |
Microsoft-Server-ActiveSync/Proxy |
Required |
Ssl,Ssl128 |
Exchange Backend |
OAB |
Required |
Ssl,Ssl128 |
Exchange Backend |
OWA |
Required |
Ssl,Ssl128 |
Exchange Backend |
PowerShell |
Required |
Ssl,SslNegotiateCert,Ssl128 |
Exchange Backend |
RPC |
Required |
Ssl,Ssl128 |
Exchange Backend |
PushNotifications |
Required |
Ssl,Ssl128 |
Exchange Backend |
RPCWithCert |
Required |
Ssl,Ssl128 |
Exchange Backend |
MAPI/emsmdb |
Required |
Ssl,Ssl128 |
Exchange Backend |
MAPI/nspi |
Required |
Ssl,Ssl128 |
Nota
Dopo la versione iniziale, è stato aggiornato Default Website/OAB in modo che sia Accept/Allow anziché Required e Default Website/PowerShellOff anziché Required. La modifica a è dovuta al Default Website/OAB fatto che i client Outlook per Mac non sono più in grado di scaricare la rubrica offline con l'impostazione Required . La modifica a Default Website/PowerShell è dovuta al fatto che la configurazione predefinita Exchange Server non consente le connessioni tramite l'autenticazione NTLM a PowerShell Front-End directory virtuale e pertanto la protezione estesa non è applicabile.
Le modifiche apportate alla directory virtuale non sono supportate a meno che non siano esplicitamente consigliate dal servizio clienti Microsoft e dal supporto tecnico .CSS.Making modifications to the Default Website/PowerShell virtual directory is not supported unless explicitly adviced by Microsoft Customer Service and Support (CSS).
Abilitazione della protezione estesa tramite Exchange Server programma di installazione CU14 (o versione successiva) 2019
Con Exchange Server 2019 CU14 e versioni successive, il programma di installazione dell'aggiornamento cumulativo (CU) di Exchange Server 2019 abilita automaticamente la protezione estesa nel server Cassette postali in cui viene eseguita l'installazione. Ciò si verifica per qualsiasi nuova installazione o quando si aggiorna un'installazione Exchange Server esistente alla versione più recente.
Esistono due nuovi parametri che possono essere usati in modalità di installazione automatica per controllare la protezione estesa abilitata per il comportamento predefinito.
I parametri possono essere usati per ignorare l'attivazione automatica della protezione estesa (/DoNotEnableEP) o per la protezione estesa non abilitata nella directory virtuale EWS Front-End (/DoNotEnableEP_FEEWS).
Avviso
La disabilitazione della protezione estesa rende il server vulnerabile a vulnerabilità note Exchange Server e indeboli la protezione da minacce sconosciute. È consigliabile lasciare abilitata questa funzionalità.
Scenari di configurazione del programma di installazione cu protezione estesa
In questa sezione vengono forniti gli scenari più comuni per la configurazione della protezione estesa in Exchange Server con l'aiuto del programma di installazione dell'aggiornamento cumulativo (CU) di Exchange Server 2019 CU14 (o versione successiva).
Assicurarsi che il server Exchange sia configurato correttamente e soddisfi i requisiti descritti nella sezione Prerequisiti per l'abilitazione della protezione estesa in Exchange Server sezione.
Scenario 1: Abilitare la protezione estesa in un Exchange Server 2019
Eseguire l'installazione di Exchange Server 2019 CU14 (o versione successiva) in modalità assistita o automatica. Il programma di installazione configurerà La protezione estesa come parte dell'installazione del server in cui è stato eseguito.
Scenario 2: Abilitare la protezione estesa in un Exchange Server 2019 pubblicato tramite l'agente ibrido
Seguire i passaggi descritti nella sezione Identificazione dei server Exchange pubblicati tramite l'agente ibrido per identificare i server Exchange pubblicati tramite l'agente ibrido.
Eseguire il programma di installazione di Exchange Server 2019 CU14 (o versione successiva) in modalità automatica usando il /DoNotEnableEP_FEEWS parametro . Ignora l'abilitazione della protezione estesa nella directory virtuale EWS Front-End:
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
Scenario 3: Ignorare l'abilitazione della protezione estesa entro Exchange Server configurazione di CU14 (o versione successiva) 2019
Eseguire il programma di installazione di Exchange Server 2019 CU14 (o versione successiva) in modalità automatica usando il /DoNotEnableEP parametro . Ignora l'abilitazione della protezione estesa:
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP
Avviso
Se non si abilita la protezione estesa, il server è vulnerabile alle vulnerabilità di Exchange note e viene indebolita la protezione da minacce sconosciute. È consigliabile attivare questa funzionalità.
Abilitazione della protezione estesa tramite lo script di PowerShell
È possibile usare lo script ExchangeExtendedProtectionManagement.ps1 per abilitare la protezione estesa in alcuni o tutti i server Exchange contemporaneamente.
Importante
L'abilitazione della protezione estesa all'interno dell'ambiente Exchange Server comporta l'applicazione di molte modifiche in tutti i server Exchange. È consigliabile usare lo script fornito da Microsoft invece di apportare queste modifiche manualmente tramite Gestione IIS.
Assicurarsi di scaricare la versione più recente dello script prima di eseguirlo per configurare la protezione estesa.
È possibile eseguire lo script in qualsiasi Exchange Server specifico nell'ambiente in cui è installato Exchange Management Shell (EMS).
Autorizzazioni per configurare la protezione estesa tramite lo script di PowerShell
L'utente che esegue lo script deve essere membro del Organization Management gruppo di ruoli. Lo script deve essere eseguito da Exchange Management Shell (EMS) con privilegi elevati.
Scenari di configurazione dello script di protezione estesa
In questa sezione vengono forniti gli scenari più comuni per la configurazione della protezione estesa in Exchange Server con l'aiuto dello script di PowerShell ExchangeExtendedProtectionManagement.ps1.
Leggere la documentazione dello script per altri esempi e una descrizione dei parametri dello script.
Scenario 1: Abilitare la protezione estesa in tutti i Exchange Server
Eseguire lo script come indicato di seguito per abilitare la protezione estesa in tutti i server Exchange all'interno dell'organizzazione:
.\ExchangeExtendedProtectionManagement.ps1
Lo script esegue diversi controlli per assicurarsi che tutti i server Exchange siano nella versione minima richiesta di CU e SU per abilitare la protezione estesa. Verifica anche se tutti i server Exchange usano la stessa configurazione TLS.
Dopo aver superato i controlli dei prerequisiti, lo script abiliterà la protezione estesa e aggiungerà i flag SSL necessari in tutte le directory virtuali di tutti i server Exchange nell'ambito. Si arresta nel caso in cui un server Exchange non completi i requisiti, ad esempio se è stata rilevata una configurazione TLS incoerente.
Scenario 2: Configurare la protezione estesa quando si esegue una configurazione ibrida moderna
Se si dispone di una configurazione ibrida moderna, è necessario ignorare l'abilitazione della protezione estesa nella directory virtuale Front-End EWS in Exchange Server, che sono stati pubblicati usando l'agente ibrido moderno.
Questa configurazione può essere eseguita usando il ExcludeVirtualDirectories parametro :
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"
Abilitare la protezione estesa tramite Gestione IIS
Se si vuole abilitare la protezione estesa nell'ambiente manualmente senza usare lo script, è possibile seguire questa procedura.
Nota
Quando si abilita manualmente la protezione estesa, assicurarsi che tutte le directory virtuali nei server Exchange abbiano Extended Protected configurato in base a quanto descritto nella tabella precedente.
Impostare Protezione estesa su obbligatorio o accetta per in una directory virtuale
- Avviare nel
IIS Manager (INetMgr.exe)server Exchange in cui si vuole configurare la protezione estesa - Passare a
Sitese selezionare oDefault Web SiteExchange Back End - Selezionare la directory virtuale da configurare
- Selezionare
Authentication - Se
Windows Authenticationè abilitato, selezionareWindows Authentication
- Selezionare
Advanced Settings(sul lato destro) e nella finestra di apertura selezionare il valore appropriato nell'elenco a discesa Protezione estesa
Impostare l'impostazione SSL obbligatoria per una directory virtuale
- Fare clic sulla directory virtuale per aprire la home page
- Selezionare
SSL Settings - Controllare le
Require SSLimpostazioni per assicurarsi cheRequire SSLsia abilitato per la directory virtuale
- Fare clic
Applyper confermare la nuova impostazione
Disabilitazione della protezione estesa
È possibile usare lo script di PowerShellExchangeExtendedProtectionManagement.ps1 per disabilitare la protezione estesa.
Avviso
La disabilitazione della protezione estesa rende il server vulnerabile a vulnerabilità di Exchange note e la protezione da minacce sconosciute. È consigliabile lasciare abilitata questa funzionalità.
Il comando seguente disabiliterà la configurazione di Protezione estesa per tutti i server Exchange online impostando il valore in tutte le posizioni di configurazione correnti su None:
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection
È anche possibile specificare un subset di server in cui la protezione estesa deve essere disabilitata:
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2
Risoluzione dei problemi
Questa sezione contiene i problemi noti che esistono con la protezione estesa ed elenca alcuni suggerimenti per la risoluzione dei problemi relativi a scenari di errore noti.
Problemi noti relativi alla protezione estesa
Tutti i problemi segnalati in precedenza con Protezione estesa in Exchange Server sono stati risolti. È consigliabile installare l'aggiornamento Exchange Server più recente per la versione di Exchange eseguita nell'organizzazione per trarre vantaggio dalle correzioni e dai miglioramenti più recenti.
Problema: quando si esegue /PrepareSchema, /PrepareDomain o /PrepareAllDomains in Exchange Server 2019 CU14 installazione automatica mostra che la protezione estesa è stata attivata
Si tratta di un problema noto con Exchange Server 2019 CU14 che può essere ignorato in modo sicuro. La protezione estesa non è abilitata durante l'esecuzione /PrepareSchema/PrepareDomain di o /PrepareAllDomains per preparare l'ambiente come descritto nella documentazione Preparare Active Directory e i domini per Exchange Server.
Problema: la modifica delle autorizzazioni per le cartelle pubbliche tramite un client di Outlook non riesce con l'errore seguente: "Le autorizzazioni modificate non possono essere modificate"
Questo problema si verifica se la cartella pubblica per cui si tenta di modificare le autorizzazioni è ospitata in una cassetta postale secondaria della cartella pubblica mentre la cassetta postale della cartella pubblica primaria si trova in un server diverso.
Il problema è stato risolto con l'aggiornamento Exchange Server più recente. Seguire le istruzioni descritte in questa knowledge base per abilitare la correzione.
Problema: la creazione di cartelle pubbliche tramite un client Outlook ha esito negativo con l'errore seguente: 'Impossibile creare la cartella pubblica. Non si dispone di autorizzazioni sufficienti per eseguire questa operazione su questo oggetto. Vedere il contatto della cartella o l'amministratore di sistema."
Questo problema si verifica se la cartella pubblica per cui si tenta di modificare le autorizzazioni è ospitata in una cassetta postale secondaria della cartella pubblica mentre la cassetta postale della cartella pubblica primaria si trova in un server diverso.
Il problema è stato risolto con l'aggiornamento Exchange Server più recente. Seguire le istruzioni descritte in questa knowledge base per abilitare la correzione. Si noti che questa correzione non funziona se è stata implementata una sostituzione globale da impostare su PublicFolderHierarchyHandlerEnabler disabilitato per risolvere il problema descritto in questa knowledge base.
Avvisi ed errori durante l'esecuzione dello script di configurazione di Protezione estesa
Lo script mostra un avviso di problemi noti e chiede conferma:
Per evitare che gli amministratori eseguano scenari in cui le funzioni di Exchange Server esistenti vengono interrotte a causa dell'abilitazione della protezione estesa, lo script fornisce un elenco di scenari con problemi noti. Leggere e valutare attentamente questo elenco prima di abilitare La protezione estesa. È possibile procedere all'attivazione della protezione estesa premendo
Y.
Lo script non abilita la protezione estesa perché il controllo dei prerequisiti non è riuscito:
Nessun server Exchange esegue una compilazione che supporta la protezione estesa:
Se nessun server Exchange nell'organizzazione esegue una compilazione che supporta la protezione estesa, lo script non abilita la protezione estesa nei server non supportati per assicurarsi che la comunicazione da server a server non abbia esito negativo.
Per risolvere questo caso, aggiornare tutti i server Exchange alla versione più recente di CU e SU ed eseguire di nuovo lo script per abilitare la protezione estesa.
È stata rilevata una mancata corrispondenza TLS:
È necessaria una configurazione TLS valida e coerente in tutti i server Exchange nell'ambito. Se le impostazioni TLS in tutti i server nell'ambito non sono uguali, l'abilitazione di Protezione estesa interrompe le connessioni client ai server cassette postali.
Per altre informazioni, vedere le procedure consigliate per la configurazione Exchange Server TLS.
Alcuni server Exchange non sono disponibili/raggiungibili:
Lo script esegue più test su tutti i server Exchange, inclusi nell'ambito. Se uno o più di questi server non sono raggiungibili, lo script li esclude perché non può eseguire l'azione di configurazione necessaria in questi computer.
Se il server è offline, è necessario configurare La protezione estesa non appena è di nuovo online. Se il server non è raggiungibile per altri motivi, è necessario eseguire lo script nel server stesso per abilitare la protezione estesa.
Gli utenti non possono accedere alla cassetta postale tramite uno o più client
Potrebbero esserci diversi motivi per cui alcuni o tutti i client possono iniziare a fornire errori di autenticazione agli utenti dopo l'abilitazione della protezione estesa.
Gli utenti non possono accedere alla cassetta postale in modo permanente o sporadico usando Outlook per Windows, Outlook per Mac, Outlook Mobile o il client di posta elettronica iOS nativo:
Se la configurazione TLS nell'organizzazione di Exchange non è la stessa(ad esempio, la configurazione TLS è stata modificata in uno dei server Exchange dopo l'abilitazione della protezione estesa), questa configurazione errata può causare l'esito negativo delle connessioni client. Per risolvere questo problema, controllare le istruzioni per configurare correttamente TLS in tutti i server Exchange e quindi usare lo script per configurare nuovamente la protezione estesa.
Verificare se viene usato l'offload SSL . Qualsiasi terminazione SSL causa l'esito negativo del controllo del token di associazione del canale di protezione estesa perché l'offload SSL viene considerato un man-in-the-middle, che viene impedito dalla protezione estesa. Per risolvere questo problema, disabilitare l'offload SSL e usare lo script per abilitare nuovamente la protezione estesa.
Gli utenti possono accedere ai messaggi di posta elettronica usando Outlook per Windows e OWA, ma non tramite client non Windows come Outlook per Mac, Outlook Mobile o il client di posta elettronica nativo di iOS. Ciò può verificarsi se l'impostazione Protezione estesa per EWS e/o Exchange ActiveSync è impostata su
Requiredin uno o tutti i server Front-End:Per risolvere questo problema, eseguire lo
ExchangeExtendedProtectionManagement.ps1script con ilExchangeServerNamesparametro e passare il nome del server Exchange, con un'impostazione di protezione estesa non configurata correttamente. È anche possibile eseguire lo script senza parametri per controllare e configurare nuovamente la protezione estesa per tutti i serverIn alternativa, è anche possibile usare
IIS Manager (INetMgr.exe)e modificare l'impostazione Protezione estesa per tali directory virtuali sul valore appropriato, come descritto nella tabella. È consigliabile usare lo script perché controlla i valori corretti ed esegue automaticamente la riconfigurazione se i valori non sono impostati come previsto.
Gli utenti non sono in grado di accedere a OWA o ECP usando il browser Apple Safari in macOS o iOS quando viene usato l'accesso SSO NTLM ed è stata abilitata la protezione estesa:
Per gli utenti sulla piattaforma macOS, è consigliabile usare un Web browser con supporto per la protezione estesa. Il nostro consiglio è Microsoft Edge (Chromium).Our recommendation is Microsoft Edge (Chromium).
Per gli utenti sulla piattaforma iOS, non è disponibile alcun Web browser con supporto per la protezione estesa.
Una soluzione che funziona in entrambe le piattaforme consiste nel configurare l'autenticazione moderna ibrida per OWA ed ECP o usare l'autenticazione basata sulle attestazioni di AD FS con Outlook sul web.
Se dopo aver seguito i passaggi precedenti, alcuni client non funzionano ancora come previsto, è possibile ripristinare temporaneamente la protezione estesa e segnalare il problema a Microsoft aprendo un caso di supporto. Seguire i passaggi descritti nella sezione Disabilitazione della protezione estesa .
La migrazione ibrida della disponibilità o della cassetta postale non funziona
Se si usa Modern Hybrid, l'abilitazione della protezione estesa può causare l'arresto delle funzionalità ibride, ad esempio la disponibilità e la migrazione delle cassette postali, se la configurazione non è stata eseguita come descritto in questo articolo. Per risolvere questo problema, identificare i server ibridi pubblicati usando l'agente ibrido e disabilitare la protezione estesa nella directory virtuale EWS Front-End in questi server.
Le cartelle pubbliche non sono più visibili/accessibili
Esistono due problemi che potrebbero influire sulla connettività di Cartelle pubbliche quando è abilitata la protezione estesa. Assicurarsi di seguire le istruzioni descritte nella sezione Protezione estesa e cartelle pubbliche di questo articolo.
Domande frequenti
Domanda: È necessario installare l'aggiornamento della sicurezza (SU) di agosto 2022 se è già stato installato nell'aggiornamento cumulativo precedente?
Risposta: Sì, è necessario installare di nuovo l'AGGIORNAMENTO di agosto 2022 se si esegue l'aggiornamento a una build CU più recente, ad esempio Exchange Server CU11 2019 a Exchange Server CU12 2019.
Ricordare: Se si prevede di eseguire immediatamente l'aggiornamento (significa installazione di CU + SU), la protezione estesa non deve essere disattivata. Se si prevede di rimanere nella versione cu senza installare immediatamente l'unità disco eseguita, è necessario disabilitare la protezione estesa perché la build cu (senza l'unità di sicurezza installata), non supporta la protezione estesa e pertanto potrebbero verificarsi problemi di connettività client.
Domanda: È sicuro abilitare la protezione estesa in un ambiente che usa Active Directory Federation Services (AD FS) per Outlook sul web (OWA)?
Risposta: Sì, la protezione estesa non ha alcun impatto sull'autenticazione basata sulle attestazioni di AD FS con OWA.
Domanda: È sicuro abilitare La protezione estesa di Windows in un ambiente che usa l'autenticazione moderna ibrida (HMA)?
Risposta: Sì, HMA non sarà interessato da questa modifica. Anche se la protezione estesa non migliora ulteriormente HMA, autenticazione di Windows può comunque essere usato per le applicazioni che non supportano l'autenticazione moderna ibrida. Considerando questo aspetto, l'abilitazione della protezione estesa è consigliata in qualsiasi ambiente idoneo che disponga ancora di servizi exchange locali.
Domanda: La protezione estesa influisce sull'autenticazione moderna ibrida o sull'integrazione di Microsoft Teams?
Risposta: La protezione estesa non influisce sull'integrazione di Microsoft Teams o sull'autenticazione moderna ibrida.
Domanda: Non sono in grado di accedere a OWA/ECP dopo aver abilitato la protezione estesa con un codice di stato HTTP 400, il mio OWA/ECP viene pubblicato tramite il Application Proxy Entra, cosa posso fare per risolvere questo problema?
Risposta: La pubblicazione di Exchange OWA/ECP tramite il Application Proxy Entra non è supportata, è necessario pubblicare OWA/ECP tramite una topologia di rete supportata dagli standard di protezione estesa.
Domanda: Anche se sappiamo che prevenire gli attacchi MitM è importante, è possibile avere i propri dispositivi al centro con i propri certificati?
Risposta: Se il dispositivo usa lo stesso certificato del server Exchange, può essere usato.