Configurar a Proteção Expandida do Windows no Exchange Server
Visão Geral
A Proteção Alargada do Windows melhora a autenticação existente no Windows Server e mitiga o reencaminhamento de autenticação ou ataques man-in-the-middle (MitM). Esta mitigação é efetuada através da utilização de informações de segurança que são implementadas através de informações de enlace de canal especificadas através de uma Channel Binding Token (CBT) que é utilizada principalmente para ligações TLS.
A Proteção Alargada está ativada por predefinição ao instalar o Exchange Server 2019 CU14 (ou posterior). Para obter mais informações, veja Lançamento: Atualização Cumulativa de 2024 H1 para Exchange Server.
Em versões mais antigas do Exchange Server (por exemplo, Exchange Server 2016), a Proteção Expandida pode ser ativada com a ajuda do script ExchangeExtendedProtectionManagement.ps1 em alguns ou em todos os servidores exchange.
Terminologia utilizada nesta documentação
Diretório Virtual ou vDir
É utilizado por Exchange Server para permitir o acesso a aplicações Web como Exchange ActiveSync, Outlook on the Webe o AutoDiscover serviço. Várias definições de diretório virtual podem ser configuradas por um administrador, incluindo definições de autenticação, segurança e relatórios. A Proteção Expandida é uma dessas definições de autenticação.
Definição proteção expandida
Controla o comportamento da verificação de Channel Binding Tokens ou CBT. Os valores possíveis para esta definição estão listados na seguinte tabela:
| Valor | Descrição |
|---|---|
| Nenhum | Especifica que o IIS não efetua a verificação CBT. |
| Permitir | Especifica que a verificação CBT está ativada, mas não é necessária. Esta definição permite uma comunicação segura com clientes que suportam a Proteção Alargada e ainda suporta clientes que não são capazes de utilizar a Proteção Expandida. |
| Exigir | Este valor especifica que a verificação CBT é necessária. Esta definição bloqueia os clientes que não suportam a Proteção Expandida. |
Sinalizadores SSL
A configuração das definições de SSL é necessária para garantir que os clientes se ligam aos diretórios virtuais do IIS de uma forma específica com certificados de cliente. Para ativar a Proteção Alargada, os sinalizadores SSL necessários são SSL e SSL128.
Descarga de SSL
Termina a ligação num dispositivo entre o cliente e o Exchange Server e, em seguida, utiliza uma ligação não encriptada para ligar ao Exchange Server.
Ponte SSL
Descreve um processo em que um dispositivo, localizado na extremidade de uma rede, desencripta o tráfego SSL e, em seguida, encripta novamente o mesmo antes de o enviar para o servidor Web.
Agente Híbrido ou Híbrido Moderno
Este é o nome de um método de configuração híbrida do Exchange que remove alguns dos requisitos de configuração para o híbrido clássico (por exemplo, ligações de rede de entrada através da firewall) para ativar as funcionalidades híbridas do Exchange. Pode saber mais sobre esta funcionalidade aqui.
Pastas Públicas
Foram concebidos para acesso partilhado e para ajudar a tornar o conteúdo numa hierarquia profunda mais fácil de navegar. Pode saber mais sobre as Pastas Públicas aqui.
Pré-requisitos para ativar a Proteção Alargada no Exchange Server
Dica
Recomendamos que execute o script do Verificador de Estado de Funcionamento do Exchange Server para marcar se todos os pré-requisitos são cumpridos no servidor Exchange no qual a Proteção Expandida deve ser ativada.
Versões do exchange server que suportam a Proteção Expandida
A Proteção Alargada é suportada em Exchange Server 2013, 2016 e 2019 a partir das versões de agosto de 2022 Exchange Server Atualização de Segurança (SU).
Se a sua organização tiver Exchange Server 2016 ou Exchange Server 2019 instalado, tem de executar a Atualizações Cumulativa trimestral do Exchange trimestral de setembro de 2021 ou a Atualização Cumulativa de H1 de setembro de 2021. Tem de ter, pelo menos, a Atualização de Segurança de agosto de 2022 ou posterior instalada antes de continuar com a configuração da Proteção Alargada.
Se a sua organização tiver Exchange Server 2013 instalada, Exchange Server tem de estar na CU23 com a Atualização de Segurança de agosto de 2022 ou posterior instalada.
Aviso
Exchange Server 2013 chegou ao fim do suporte a 11 de abril de 2023.
Requisitos de configuração do Outlook Anywhere
A descarga de SSL para Outlook Anywhere está ativada por predefinição e tem de ser desativada antes de a Proteção Expandida ser ativada. Siga os passos descritos no Exemplo 3.
Importante
Exchange Server instalador CU14 (ou posterior) de 2019 desativa a descarga de SSL automaticamenteOutlook Anywhere. Isto faz parte da Proteção Expandida ativada por predefinição.
Requisitos de versão do NTLM
NTLMv1 é fraco e não fornece proteção contra ataques man-in-the-middle (MitM). Deve ser considerado vulnerável e já não ser utilizado.
NTLMv1 não pode ser utilizado em conjunto com a Proteção Expandida. Se impor a utilização NTLMv1 de um cliente em vez de NTLMv2 e tiver a Proteção Expandida ativada nos seus servidores exchange, esta configuração leva a pedidos de palavra-passe no lado do cliente sem uma forma de autenticar com êxito no servidor Exchange.
Observação
Para aumentar a segurança, recomendamos que reveja e configure esta definição, independentemente de se deparar ou não com problemas.
Se ocorrer pedidos de palavra-passe nos seus clientes assim que a Proteção Expandida estiver ativada, deve marcar a seguinte chave de registo e valor no cliente e no lado Exchange Server:
Chave do registo: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Valor do registo: LmCompatibilityLevel
Recomenda-se que o defina como um valor de 5, que é Send NTLMv2 response only. Refuse LM & NTLM. Tem de ser definido, pelo menos, para um valor do 3 qual seja Send NTLMv2 response only.
Se eliminar o valor, o sistema operativo impõe a predefinição do sistema. No Windows Server 2008 R2 e posterior, tratamo-lo como se estivesse definido 3como .
Se quiser gerir a definição centralmente, pode fazê-lo com Política de Grupo:
Localização da política: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Mais informações: Segurança de rede: nível de autenticação do Lan Manager
Requisitos do TLS
Antes de ativar a Proteção Expandida, tem de garantir que todas as configurações TLS são consistentes em todos os servidores do Exchange. Por exemplo, se um dos servidores utilizar TLS 1.2, tem de garantir que todos os servidores na organização estão configurados com TLS 1.2. Qualquer variação na utilização da versão TLS entre servidores pode fazer com que as ligações cliente ou servidor ao servidor falhem.
Para além deste requisito, o valor do valor do registo tem de SchUseStrongCrypto ser definido para um valor de 1 entre todos os servidores do Exchange na organização.
Se este valor não estiver explicitamente definido como 1, o valor predefinido desta chave pode ser interpretado como 0 ou 1 consoante a versão do .NET em utilização pelos binários Exchange Server e existe a possibilidade de ocorrer problemas de ligação no servidor para a comunicação do servidor. Isto pode acontecer, especialmente se estiverem a ser utilizadas diferentes versões do Exchange Server (por exemplo, Exchange Server 2016 e Exchange Server 2019).
O mesmo se aplica ao valor do SystemDefaultTlsVersions registo, que também tem de ser explicitamente definido como um valor de 1.
Se estes valores de registo não estiverem configurados conforme esperado, esta configuração incorreta pode causar um erro de correspondência do TLS no servidor para o servidor ou cliente para a comunicação do servidor e, como resultado, pode levar a problemas de conectividade.
Veja este Exchange Server guia de melhores práticas de configuração do TLS para configurar as definições de TLS necessárias nos seus servidores Exchange.
Compatibilidade de software de terceiros
Antes de ativar a Proteção Expandida, é essencial realizar testes em todos os produtos de terceiros no seu ambiente de Exchange Server para garantir que funcionam corretamente. Se não tiver a certeza se a Proteção Expandida é suportada, deve contactar o fornecedor para confirmação.
Vimos, por exemplo, soluções antivírus, que estavam a enviar ligações através de um servidor proxy local para proteger o computador cliente. Tal cenário impediria a comunicação com o servidor Exchange e teria de ser desativado, uma vez que é considerado uma ligação man-in-the-middle (MitM), que será bloqueada pela Proteção Expandida.
Cenários que podem afetar a conectividade do cliente quando a Proteção Expandida foi ativada
Cenários de Descarga de SSL
A Proteção Expandida não é suportada em ambientes que utilizam a Descarga de SSL. A terminação SSL durante a Descarga de SSL faz com que a Proteção Expandida falhe. Para ativar a Proteção Expandida no seu ambiente do Exchange, não pode estar a utilizar a descarga de SSL com os Balanceadores de Carga.
Cenários de Bridging SSL
A Proteção Alargada é suportada em ambientes que utilizam O Bridging SSL em determinadas condições. Para ativar a Proteção Alargada no seu ambiente do Exchange com o SSL Bridging, tem de utilizar o mesmo certificado SSL no Exchange e nos Seus Balanceadores de Carga. A utilização de certificados diferentes faz com que o Token de Enlace do Canal de Proteção Alargada marcar falhe e, como resultado, impeça que os clientes se liguem ao servidor Exchange.
Cenários de Proteção Alargada e Pasta Pública
A secção seguinte abrange cenários de Pasta Pública, o que pode levar a falhas quando a Proteção Expandida está ativada.
A Proteção Alargada não pode ser ativada em servidores Exchange Server 2013 com Pastas Públicas num ambiente de coexistência
Para ativar a Proteção Alargada no Exchange Server 2013, certifique-se de que não tem pastas públicas alojadas no Exchange Server 2013. Se tiver coexistência do Exchange Server 2013 com o Exchange Server 2016 ou Exchange Server 2019, tem de migrar as suas Pastas Públicas para o Exchange Server 2016 ou Exchange Server 2019 antes de ativar a Proteção Alargada. Depois de a Proteção Expandida ter sido ativada e existirem Pastas Públicas no Exchange Server 2013, deixarão de aparecer aos utilizadores finais!
Aviso
Exchange Server 2013 chegou ao fim do suporte a 11 de abril de 2023.
A Proteção Alargada não pode ser ativada no Exchange Server CU22 ou Exchange Server CU11 de 2019 ou anterior que aloje uma hierarquia de Pastas Públicas
Se tiver um ambiente que contenha Exchange Server CU22 ou Exchange Server 2019 CU11 ou anterior e estiver a utilizar Pastas Públicas, tem de confirmar a versão do servidor que aloja a hierarquia de Pastas Públicas antes de ativar a Proteção Expandida!
Certifique-se de que o servidor, que aloja a hierarquia de Pastas Públicas, é atualizado para Exchange Server CU23 ou Exchange Server 2019 CU12 (ou posterior) com a Atualizações de Segurança mais recente instalada. Mova a hierarquia de Pastas Públicas para um Exchange Server que execute uma versão necessária se não conseguir atualizar o servidor Exchange para uma versão suportada.
A tabela seguinte pode ser utilizada para esclarecer:
| Versão do Exchange | instalada | SU instalada | Caixas de correio PF de anfitriões | O EP é suportado? |
|---|---|---|---|---|
| Exchange 2013 | CU23 | Agosto de 2022 (ou superior) | Não | Sim |
| Exchange 2016 | CU22 | Agosto de 2022 (ou superior) | Sem caixas de correio de hierarquia | Sim |
| Exchange 2016 | CU23 (2022 H1) ou posterior | Agosto de 2022 (ou superior) | Qualquer | Sim |
| Exchange 2019 | CU11 | Agosto de 2022 (ou superior) | Sem caixas de correio de hierarquia | Sim |
| Exchange 2019 | CU12 (2022 H1) ou posterior | Agosto de 2022 (ou superior) | Qualquer | Sim |
| Qualquer outra versão | Qualquer outra | Qualquer outra SU | Qualquer | Não |
Proteção Alargada e Configuração Híbrida Moderna
A secção seguinte abrange Exchange Server cenários Híbridos Modernos, o que pode levar a falhas quando a Proteção Expandida está ativada.
A Proteção Expandida não pode ser totalmente configurada em Servidores Exchange que são publicados com o Agente Híbrido
Numa configuração Híbrida Moderna, os servidores Exchange são publicados através de um Agente Híbrido, que proxies do Exchange Online chama para o servidor Exchange.
Ativar a Proteção Expandida em Servidores Exchange que são publicados através do Agente Híbrido pode levar a uma interrupção das funcionalidades híbridas, como movimentações de caixa de correio e chamadas de disponibilidade, se não forem feitas corretamente. Por conseguinte, é importante identificar todos os servidores exchange, que são publicados com a ajuda de um Agente Híbrido e não ativar a Proteção Expandida no Front-End diretório virtual do EWS nos mesmos.
Identificar servidores exchange que são publicados com o Agente Híbrido
Caso não tenha uma lista de servidores, que foram publicados através do Agente Híbrido, pode utilizar os seguintes passos para os identificar. Estes passos não são necessários se estiver a executar uma implementação clássica Exchange Server Híbrida.
- Inicie sessão num computador onde o Agente Híbrido está instalado e abra o módulo do PowerShell do Agente Híbrido. Execute
Get-HybridApplicationpara identificar oTargetUriutilizado pelo Agente Híbrido. - O
TargetUriparâmetro dá-lhe o Fqdn do servidor Exchange, que está configurado para ser utilizado pelo Agente Híbrido.- Deduzir a identidade do servidor Exchange com o Fqdn e tomar nota do nome do servidor Exchange.
- Se estiver a utilizar um URL de Load Balancer no
TargetUri, tem de identificar todos os servidores exchange, que têm aClient Accessfunção instalada e que podem ser acedidos por trás do URL do Load Balancer.
Importante
A Proteção Expandida não pode ser ativada no Front-End diretório virtual do EWS nos Servidores Exchange que são publicados através de um Agente Híbrido.
Recomendamos os seguintes passos para salvaguardar os servidores exchange, que foram publicados através do Agente Híbrido:
Observação
No cenário seguinte, o Agente Híbrido é instalado num servidor que NÃO é executado Exchange Server. Além disso, este servidor está localizado num segmento de rede diferente dos servidores exchange de produção.
- Para os servidores Exchange publicados através do Agente Híbrido, as ligações de entrada devem ser restringidas por uma firewall para permitir ligações apenas a partir do computador no qual o Agente Híbrido está instalado. Isto não afeta as comunicações de saída dos servidores exchange para Exchange Online.
- Não devem ser alojadas caixas de correio nos servidores exchange, que foram publicados através do Agente Híbrido. As caixas de correio existentes devem ser migradas para outros servidores de caixa de correio.
Ativar a Proteção Expandida
A Proteção Alargada é ativada automaticamente durante Exchange Server configuração cu14 (ou posterior) de 2019. Em versões mais antigas do Exchange Server, que suportam a Proteção Alargada, pode ser ativada através de um script fornecido pela Microsoft (recomendado) ou manualmente através do Gestor do IIS.
Para configurar corretamente a Proteção Expandida, cada diretório virtual em todos os servidores Exchange na organização (excluindo os servidores de Transporte Edge) tem de ser definido para o valor prescrito de Extended Protection e sslFlags.
A tabela seguinte resume as definições necessárias para cada diretório virtual nas versões suportadas do Exchange Server.
| Web site do IIS | Diretório Virtual | Valor Recomendado | SSLFlags recomendado |
|---|---|---|---|
Default Website |
API |
Required |
Ssl,Ssl128 |
Default Website |
AutoDiscover |
Off |
Ssl,Ssl128 |
Default Website |
ECP |
Required |
Ssl,Ssl128 |
Default Website |
EWS |
Accept (IU) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
MAPI |
Required |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync |
Accept (IU) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync/Proxy |
Accept (IU) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
OAB |
Accept (IU) / 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 |
Observação
Após a versão inicial, atualizámos para ser Accept/Allow em vez de Required e Default Website/PowerShell para estar Off em vez de Required.Default Website/OAB A alteração para deve-se Default Website/OAB ao facto de Outlook para Mac clientes já não conseguirem transferir o OAB com a Required definição. A alteração para deve-se ao Default Website/PowerShell facto de a configuração predefinida Exchange Server não permitir ligações através da autenticação NTLM para o PowerShell Front-End diretório virtual e, por conseguinte, a Proteção Alargada não é aplicável.
As modificações ao Default Website/PowerShell diretório virtual não são suportadas, a menos que sejam explicitamente recomendadas pelo Suporte e Suporte ao Cliente da Microsoft (CSS).
Ativar a Proteção Alargada com o instalador cu14 (ou posterior) do Exchange Server 2019
Com Exchange Server 2019 CU14 e posterior, o instalador da Atualização Cumulativa () do Exchange Server 2019 ativa automaticamente a Proteção Expandida no servidor da Caixa de Correio onde a configuração é executada. Isto acontece em qualquer nova instalação ou ao atualizar uma instalação de Exchange Server existente para a versão mais recente.
Existem dois novos parâmetros que podem ser utilizados no modo de configuração automática para controlar a Proteção Expandida ativada por comportamento predefinido.
Os parâmetros podem ser utilizados para ignorar a ativação automática da Proteção Expandida (/DoNotEnableEP) ou para não ativar a Proteção Expandida no Front-End diretório virtual do EWS (/DoNotEnableEP_FEEWS).
Aviso
Desativar a Proteção Expandida torna o servidor vulnerável a vulnerabilidades conhecidas Exchange Server e enfraquece a proteção contra ameaças desconhecidas. Recomendamos que deixe esta funcionalidade ativada.
Cenários de configuração do instalador de Proteção Alargada
Nesta secção, fornecemos os cenários mais comuns para configurar a Proteção Alargada no Exchange Server pela ajuda do instalador de Atualização Cumulativa () do Exchange Server 2019 (ou posterior).
Certifique-se de que o servidor Exchange está corretamente configurado e cumpre os requisitos conforme descrito na secção Pré-requisitos para ativar a Proteção Expandida no Exchange Server.
Cenário 1: Ativar a Proteção Alargada num Exchange Server 2019
Execute a configuração Exchange Server CU14 (ou posterior) de 2019 no modo assistido ou sem supervisão. O instalador irá configurar a Proteção Expandida como parte da instalação do servidor no qual foi executado.
Cenário 2: Ativar a Proteção Alargada num Exchange Server 2019 publicado através do Agente Híbrido
Siga os passos descritos na secção Identificar servidores exchange que são publicados com o Agente Híbrido para identificar os Servidores Exchange que são publicados através do Agente Híbrido.
Execute a configuração Exchange Server CU14 (ou posterior) de 2019 no modo sem supervisão com o /DoNotEnableEP_FEEWS parâmetro . Ignora a ativação da Proteção Expandida no Front-End diretório virtual do EWS:
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
Cenário 3: Ignorar a ativação da Proteção Expandida por Exchange Server 2019 CU14 (ou posterior)
Execute a configuração Exchange Server CU14 (ou posterior) de 2019 no modo sem supervisão com o /DoNotEnableEP parâmetro . Ignora a ativação da Proteção Expandida:
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP
Aviso
Não ativar a Proteção Expandida torna o servidor vulnerável a vulnerabilidades conhecidas do Exchange e enfraquece a proteção contra ameaças desconhecidas. Recomendamos que ative esta funcionalidade.
Ativar a Proteção Expandida com o script do PowerShell
Pode utilizar o script ExchangeExtendedProtectionManagement.ps1 para ativar a Proteção Expandida em alguns ou em todos os seus servidores exchange de uma só vez.
Importante
Ativar a Proteção Alargada no seu ambiente Exchange Server envolve fazer muitas alterações em todos os servidores exchange. Recomendamos que utilize o script fornecido pela Microsoft em vez de efetuar estas alterações manualmente através do Gestor do IIS.
Certifique-se de que transfere a versão mais recente do script antes de o executar para configurar a Proteção Expandida.
Pode executar o script em qualquer Exchange Server específico no seu ambiente, que tenha a Shell de Gestão do Exchange (EMS) instalada.
Permissões para configurar a Proteção Expandida com o script do PowerShell
O utilizador que executa o script tem de ser membro do Organization Management grupo de funções. O script tem de ser executado a partir de uma Shell de Gestão do Exchange (EMS) elevada.
Cenários de configuração do script de Proteção Alargada
Nesta secção, fornecemos os cenários mais comuns para configurar a Proteção Expandida no Exchange Server pela ajuda do script doExchangeExtendedProtectionManagement.ps1 PowerShell.
Leia a documentação do script para obter mais exemplos e uma descrição dos parâmetros do script.
Cenário 1: Ativar a Proteção Alargada em todos os Exchange Server
Execute o script da seguinte forma para ativar a Proteção Expandida em todos os servidores Exchange na sua organização:
.\ExchangeExtendedProtectionManagement.ps1
O script efetua várias verificações para garantir que todos os servidores exchange estão na versão mínima necessária da e da SU para ativar a Proteção Expandida. Também verifica se todos os servidores do Exchange estão a utilizar a mesma configuração TLS.
Depois de as verificações de pré-requisitos terem sido aprovadas, o script ativará a Proteção Expandida e adicionará os sinalizadores SSL necessários em todos os diretórios virtuais de todos os servidores exchange no âmbito. Para caso de um servidor Exchange não preenchimento completo dos requisitos (por exemplo, se tiver sido detetada uma configuração TLS inconsistente).
Cenário 2: Configurar a Proteção Expandida ao executar uma configuração Híbrida Moderna
Caso tenha a configuração Híbrida Moderna, tem de ignorar a ativação da Proteção Expandida no Front-End diretório virtual do EWS em Exchange Servers, que foram publicados com o Agente Híbrido Moderno.
Esta configuração pode ser feita com o ExcludeVirtualDirectories parâmetro :
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"
Ativar a Proteção Expandida com o Gestor de IIS
Se quiser ativar manualmente a Proteção Expandida no seu ambiente sem utilizar o script, pode utilizar os seguintes passos.
Observação
Ao ativar manualmente a Proteção Expandida, certifique-se de que todos os diretórios virtuais nos servidores do Exchange têm a Proteção Expandida configurada de acordo com o descrito na tabela acima.
Defina a Proteção Expandida como necessária ou aceite para num diretório virtual
- Inicie o
IIS Manager (INetMgr.exe)no servidor Exchange no qual pretende configurar a Proteção Expandida - Aceda a
Sitese selecione ouDefault Web SiteExchange Back End - Selecione o diretório virtual que pretende configurar
- Selecionar
Authentication - Se
Windows Authenticationestiver ativado, selecioneWindows Authentication
- Selecione
Advanced Settings(no lado direito) e, na janela de abertura, selecione o valor adequado no menu pendente Proteção Expandida
Definir a definição SSL Necessário para um diretório virtual
- Clique no diretório virtual para abrir a home page
- Selecionar
SSL Settings - Verifique as
Require SSLdefinições para se certificar de queRequire SSLestá ativado para o diretório virtual
- Clique
Applypara confirmar a nova definição
Desativar a Proteção Expandida
Pode utilizar o scriptExchangeExtendedProtectionManagement.ps1 PowerShell para desativar a Proteção Expandida.
Aviso
Desativar a Proteção Expandida torna o servidor vulnerável a vulnerabilidades conhecidas do Exchange e enfraquece a proteção contra ameaças desconhecidas. Recomendamos que deixe esta funcionalidade ativada.
O comando seguinte irá desativar a configuração da Proteção Expandida para todos os Servidores Exchange que estão online ao definir o valor em todas as localizações de configuração atuais como None:
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection
Também pode especificar um subconjunto de servidores no qual a Proteção Expandida deve ser desativada:
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2
Solução de problemas
Esta secção contém problemas conhecidos que existem com a Proteção Expandida e lista algumas sugestões de resolução de problemas para cenários de falha conhecidos.
Problemas conhecidos com a Proteção Expandida
Todos os problemas comunicados anteriormente com a Proteção Alargada no Exchange Server foram corrigidos. Recomendamos vivamente que instale a atualização de Exchange Server mais recente para a versão do Exchange que executa na sua organização para beneficiar das correções e melhorias mais recentes.
Problema: quando executa /PrepareSchema, /PrepareDomain ou /PrepareAllDomains no Exchange Server 2019 CU14, a configuração do modo automática mostra que a Proteção Expandida foi ativada
Este é um problema conhecido com Exchange Server CU14 de 2019 que pode ser ignorado em segurança. A Proteção Expandida não está ativada ao executar /PrepareSchema/PrepareDomain ou /PrepareAllDomains preparar o ambiente, conforme descrito na documentação Preparar o Active Directory e os domínios para Exchange Server.
Problema: a alteração das permissões para Pastas Públicas através de um cliente do Outlook falha com o seguinte erro: "As Permissões modificadas não podem ser alteradas"
Este problema ocorre se a Pasta Pública para a qual tenta alterar as permissões estiver alojada numa caixa de correio secundária da Pasta Pública enquanto a caixa de correio principal pasta pública estiver num servidor diferente.
O problema foi corrigido com a atualização de Exchange Server mais recente. Siga as instruções descritas neste KB para ativar a correção.
Problema: a criação de Pastas Públicas através de um cliente do Outlook falha com o seguinte erro: "Não é possível criar a pasta pública. Não tem permissões suficientes para efetuar esta operação neste objeto. Consulte o contacto da pasta ou o administrador de sistema.
Este problema ocorre se a Pasta Pública para a qual tenta alterar as permissões estiver alojada numa caixa de correio secundária da Pasta Pública enquanto a caixa de correio principal pasta pública estiver num servidor diferente.
O problema foi corrigido com a atualização de Exchange Server mais recente. Siga as instruções descritas neste KB para ativar a correção. Tenha em atenção que esta correção não funciona se tiver sido implementada uma substituição global para definir PublicFolderHierarchyHandlerEnabler como desativada para resolver o problema descrito nesta BDC.
Avisos e erros durante a execução do script de configuração da Proteção Expandida
O script mostra um aviso de problemas conhecidos e pede confirmação:
Para impedir que os administradores se detetam em cenários em que as funções de Exchange Server existentes são interrompidas devido à ativação da Proteção Expandida, o script fornece uma lista de cenários com problemas conhecidos. Leia e avalie cuidadosamente esta lista antes de ativar a Proteção Expandida. Pode continuar a ativar a Proteção Expandida ao premir
Y.
O script não ativa a Proteção Expandida porque um pré-requisito marcar falhou:
Nenhum servidor Exchange executa uma construção que suporte a Proteção Expandida:
Se nenhum servidor Exchange na organização estiver a executar uma compilação que suporte a Proteção Expandida, o script não ativa a Proteção Expandida em servidores não suportados para garantir que a comunicação servidor a servidor não falha.
Para resolve este caso, atualize todos os servidores exchange para a e SU mais recentes e execute novamente o script para ativar a Proteção Expandida.
Foi detetado um erro de correspondência do TLS:
É necessária uma configuração TLS válida e consistente em todos os servidores Exchange no âmbito. Se as definições de TLS em todos os servidores no âmbito não forem as mesmas, ativar a Proteção Expandida interrompe as ligações de cliente aos servidores de caixa de correio.
Leia as Exchange Server melhores práticas de configuração do TLS para obter mais informações.
Alguns servidores exchange não estão disponíveis/acessíveis:
O script efetua vários testes em todos os servidores exchange, que estão no âmbito. Se um ou mais destes servidores não estiverem acessíveis, o script exclui-os, uma vez que não pode executar a ação de configuração necessária nestes computadores.
Se o servidor estiver offline, deve configurar a Proteção Expandida assim que estiver novamente online. Se o servidor estava inacessível por outros motivos, deve executar o script no próprio servidor para ativar a Proteção Expandida.
Os utilizadores não podem aceder à respetiva caixa de correio através de um ou mais clientes
Podem existir vários motivos pelos quais alguns ou todos os clientes podem começar a apresentar erros de autenticação aos utilizadores depois de a Proteção Alargada ter sido ativada.
Os utilizadores não podem aceder à respetiva caixa de correio de forma permanente ou esporadicamente utilizando o Outlook para Windows, Outlook para Mac, o Outlook Mobile ou o cliente de e-mail iOS nativo:
Se a configuração do TLS na organização do Exchange não for a mesma (por exemplo, a configuração do TLS foi alterada num dos servidores exchange após a ativação da Proteção Expandida), esta configuração incorreta pode fazer com que as ligações do cliente falhem. Para resolve este problema, marcar as instruções para configurar corretamente o TLS em todos os servidores exchange e, em seguida, utilize o script para configurar novamente a Proteção Expandida.
Verifique se a Descarga de SSL é utilizada. Qualquer terminação SSL faz com que o Token de Enlace do Canal de Proteção Alargada marcar falhe, uma vez que a Descarga de SSL é considerada um man-in-the-middle, o que é impedido pela Proteção Expandida. Para resolve este problema, desative a Descarga de SSL e utilize o script para ativar novamente a Proteção Expandida.
Os utilizadores podem aceder aos respetivos e-mails utilizando o Outlook para Windows e o OWA, mas não através de clientes não Windows, como o Outlook para Mac, o Outlook Mobile ou o cliente de e-mail nativo do iOS. Isto pode acontecer se a definição Proteção Expandida para EWS e/ou Exchange ActiveSync estiver definida como
Requirednum ou em todos os servidores Front-End:Para resolve este problema, execute o
ExchangeExtendedProtectionManagement.ps1script com oExchangeServerNamesparâmetro e transmita o nome do servidor Exchange, que tem uma definição de Proteção Expandida configurada incorretamente. Também pode executar o script sem qualquer parâmetro para marcar e configurar novamente a Proteção Expandida para todos os servidoresEm alternativa, também pode utilizar
IIS Manager (INetMgr.exe)e alterar a definição Proteção Expandida para esses Diretórios virtuais para o valor adequado , conforme descrito na tabela. Recomendamos vivamente que utilize o script, uma vez que verifica os valores corretos e efetua a reconfiguração automaticamente se os valores não estiverem definidos conforme esperado.
Os utilizadores não conseguem aceder ao OWA ou ao ECP através do browser Apple Safari no macOS ou iOS quando o SSO NTLM é utilizado e a Proteção Expandida foi ativada:
Para os utilizadores na plataforma macOS, sugerimos a utilização de um browser com suporte de Proteção Alargada. A nossa recomendação é o Microsoft Edge (Chromium).
Para os utilizadores na plataforma iOS, não existe nenhum browser com suporte de Proteção Alargada.
Uma solução que funciona em ambas as plataformas é configurar a Autenticação Moderna Híbrida para OWA e ECP ou utilizar a autenticação baseada em afirmações do AD FS com Outlook na Web.
Se, após seguir os passos acima, alguns clientes ainda não estiverem a funcionar conforme esperado, pode reverter temporariamente a Proteção Expandida e comunicar o problema à Microsoft ao abrir um pedido de suporte connosco. Siga os passos descritos na secção Desativar a Proteção Expandida .
A migração híbrida de caixa de correio ou de disponibilidade não está a funcionar
Se estiver a utilizar o Híbrido Moderno, ativar a Proteção Expandida pode fazer com que as funcionalidades híbridas, como a migração de caixa de correio/disponibilidade, deixem de funcionar se a configuração não tiver sido efetuada conforme descrito neste artigo. Para resolve este problema, identifique os servidores híbridos que foram publicados com o Agente Híbrido e desative a Proteção Expandida no Front-End diretório virtual do EWS nestes servidores.
As Pastas Públicas já não estão visíveis/acessíveis
Existem dois problemas que podem afetar a conectividade das Pastas Públicas quando a Proteção Expandida está ativada. Siga as instruções descritas na secção Proteção Alargada e Pastas Públicas deste artigo.
Perguntas Frequentes
Pergunta: É necessário instalar a Atualização de Segurança (SU) de agosto de 2022 se já tiver sido instalada na Atualização Cumulativa () anterior?
Resposta: Sim, é necessário instalar novamente a SU de agosto de 2022 se atualizar para uma compilação mais recente (por exemplo, Exchange Server CU11 de 2019 para Exchange Server 2019 CU12).
Lembre-se: Se planear efetuar a atualização imediatamente (significa instalação + SU), a Proteção Expandida não precisa de ser desativada. Se planear permanecer na sem instalar a SU imediatamente, tem de desativar a Proteção Expandida, uma vez que a compilação da (sem a SU estar instalada), não suporta a Proteção Alargada e, por conseguinte, poderá deparar-se com problemas de conectividade do cliente.
Pergunta: É seguro ativar a Proteção Expandida num ambiente que utiliza Serviços de Federação do Active Directory (AD FS) (AD FS) para Outlook na Web (OWA)?
Resposta: Sim, a Proteção Expandida não tem impacto na autenticação baseada em afirmações do AD FS com o OWA.
Pergunta: É seguro ativar a Proteção Expandida do Windows num ambiente que utiliza a Autenticação Moderna Híbrida (HMA)?
Resposta: Sim, o HMA não será afetado por esta alteração. Embora a Proteção Expandida não melhore ainda mais o HMA, autenticação do Windows ainda podem ser utilizadas para aplicações que não suportam a Autenticação Moderna Híbrida. Tendo em conta isto, a ativação da Proteção Alargada seria recomendada em qualquer ambiente elegível que ainda tenha serviços do Exchange no local.
Pergunta: A Proteção Alargada afeta a integração da Autenticação Moderna Híbrida ou do Microsoft Teams?
Resposta: A Proteção Alargada não afeta a integração do Microsoft Teams ou a Autenticação Moderna Híbrida.
Pergunta: Não consigo aceder ao OWA/ECP depois de ativar a Proteção Expandida com um código de status HTTP 400, o meu OWA/ECP é publicado através do Proxy de Aplicativo Entra, o que posso fazer para resolve isto?
Resposta: A publicação do Exchange OWA/ECP através do Entra Proxy de Aplicativo não é suportada. Terá de publicar o OWA/ECP através de uma topologia de rede suportada pela Extended Protection Standards.
Pergunta: Embora compreendamos que a prevenção de ataques MitM é importante, podemos ter os nossos próprios dispositivos no meio com os nossos próprios certificados?
Resposta: Se o dispositivo utilizar o mesmo certificado que o servidor Exchange, pode ser utilizado.