Configurar a Proteção Estendida do Windows no Exchange Server
Visão geral
A Proteção Estendida do Windows aprimora a autenticação existente no Windows Server e atenua os ataques de MitM (retransmissão de autenticação ou de homem no meio). Essa mitigação é realizada usando informações de segurança implementadas por meio de informações de associação de canal especificadas por meio de uma Channel Binding Token (CBT) que é usada principalmente para conexões TLS.
A Proteção Estendida é habilitada por padrão ao instalar Exchange Server CU14 2019 (ou posterior). Para obter mais informações, confira Lançamento: Atualização Cumulativa H1 2024 H1 para Exchange Server.
Em versões mais antigas do Exchange Server (por exemplo, Exchange Server 2016), a Proteção Estendida pode ser habilitada pela ajuda do script ExchangeExtendedProtectionManagement.ps1 em alguns ou em todos os servidores do Exchange.
Terminologia usada nesta documentação
Diretório Virtual ou vDir
É usado por Exchange Server para permitir o acesso a aplicativos Web, como Exchange ActiveSync, Outlook on the Webe o AutoDiscover serviço. Várias configurações de diretório virtual podem ser configuradas por um administrador, incluindo autenticação, segurança e configurações de relatório. A Proteção Estendida é uma dessas configurações de autenticação.
Configuração proteção estendida
Controla o comportamento para verificação de Channel Binding Tokens ou CBT. Os valores possíveis para essa configuração estão listados na tabela a seguir:
| Configuração de proteção estendida | Descrição |
|---|---|
| Nenhum | Especifica que o IIS não executa a verificação de TCC. |
| Permitir | Especifica que a verificação de TCC está habilitada, mas não é necessária. Essa configuração permite uma comunicação segura com clientes que dão suporte à Proteção Estendida e ainda dá suporte a clientes que não são capazes de usar a Proteção Estendida. |
| Exigir | Esse valor especifica que a verificação de TCC é necessária. Essa configuração bloqueia clientes que não dão suporte à Proteção Estendida. |
Sinalizadores SSL
A configuração das configurações de SSL é necessária para garantir que os clientes se conectem a diretórios virtuais do IIS de forma específica com certificados de cliente. Para habilitar a Proteção Estendida, os sinalizadores SSL necessários são SSL e SSL128.
Descarregamento de SSL
Encerra a conexão em um dispositivo entre o cliente e o Exchange Server e, em seguida, usa uma conexão não criptografada para se conectar ao Exchange Server.
Ponte SSL
Descreve um processo em que um dispositivo, localizado na borda de uma rede, descriptografa o tráfego SSL e o criptografa novamente antes de enviá-lo para o servidor Web.
Agente Híbrido ou Híbrido Moderno
Esse é o nome de um método de configuração do Híbrido do Exchange que remove alguns dos requisitos de configuração para o híbrido clássico (por exemplo, conexões de rede de entrada por meio do firewall) para habilitar recursos híbridos do Exchange. Você pode saber mais sobre esse recurso aqui.
Pastas Públicas
São projetados para acesso compartilhado e para ajudar a tornar o conteúdo em uma hierarquia profunda mais fácil de navegar. Você pode saber mais sobre pastas públicas aqui.
Pré-requisitos para habilitar a Proteção Estendida em Exchange Server
Importante
Recomendamos executar o script Exchange Server Health Checker para marcar se todos os pré-requisitos são atendidos no servidor exchange no qual a Proteção Estendida deve ser ativada.
Versões do servidor do Exchange que dão suporte à Proteção Estendida
Há suporte para Proteção Estendida em Exchange Server 2013, 2016 e 2019 a partir das versões de su (atualização de segurança) Exchange Server de agosto de 20222.
Se sua organização tiver Exchange Server 2016 ou Exchange Server 2019 instaladas, ela deverá estar executando a Atualizações Cumulativa trimestral do Exchange de setembro de 2021 ou a Atualização Cumulativa H1 de 2022. Você deve 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 Estendida.
Se sua organização tiver Exchange Server 2013 instalada, Exchange Server deverá 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 em 11 de abril de 2023.
Requisitos de configuração do Outlook Anywhere
O descarregamento SSL para Outlook Anywhere é habilitado por padrão e deve ser desabilitado antes que a Proteção Estendida esteja habilitada. Siga as etapas conforme descrito no Exemplo 3.
Importante
Exchange Server instalador CU14 (ou posterior) 2019 desabilita o descarregamento Outlook Anywhere de SSL automaticamente. Isso faz parte da Proteção Estendida habilitada por avaliação padrão.
Requisitos de versão NTLM
NTLMv1 é fraco e não fornece proteção contra ataques do MitM (homem no meio). Ela deve ser considerada vulnerável e não deve mais ser usada.
NTLMv1 não pode ser usado junto com a Proteção Estendida. Se você impor um cliente a usar NTLMv1 em vez de NTLMv2 e tiver a Proteção Estendida habilitada em seus servidores do Exchange, essa configuração levará a prompts de senha no lado do cliente sem uma maneira de se autenticar com êxito no servidor exchange.
Observação
Para aumentar a segurança, recomendamos que você examine e configure essa configuração independentemente de você ter problemas ou não.
Se você tiver solicitações de senha em seus clientes depois que a Proteção Estendida estiver habilitada, você deverá marcar a seguinte chave e valor do registro no cliente e no lado Exchange Server:
Chave do Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Valor do registro: LmCompatibilityLevel
É recomendável defini-lo como um valor de 5, que é Send NTLMv2 response only. Refuse LM & NTLM. Ele deve ser definido pelo menos como um valor do 3 qual é Send NTLMv2 response only.
Se você excluir o valor, o sistema operacional imporá o padrão do sistema. No Windows Server 2008 R2 e posterior, tratamos como se estivesse definido 3como .
Se você quiser gerenciar a configuração centralmente, poderá fazê-lo usando Política de Grupo:
Local 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 TLS
Antes de habilitar a Proteção Estendida, você deve garantir que todas as configurações de TLS sejam consistentes em todos os servidores do Exchange. Por exemplo, se um dos servidores usar TLS 1.2, você deverá garantir que todos os servidores da organização estejam configurados usando TLS 1.2. Qualquer variação na versão TLS usada entre servidores pode fazer com que as conexões cliente ou servidor para servidor falhem.
Além desse requisito, o valor do valor do SchUseStrongCrypto registro deve ser definido como um valor de 1 todos os servidores exchange dentro da organização.
Se esse valor não estiver explicitamente definido como 1, o valor padrão dessa chave poderá ser interpretado como 0 ou 1 dependendo da versão do .NET em uso pelos binários Exchange Server e há uma chance de você ter problemas de conexão no servidor com a comunicação do servidor. Isso pode acontecer, especialmente se diferentes versões de Exchange Server (por exemplo, Exchange Server 2016 e Exchange Server 2019) estiverem em uso.
O mesmo se aplica ao valor do SystemDefaultTlsVersions registro, que também deve ser definido explicitamente como um valor de 1.
Se esses valores de registro não estiverem configurados conforme o esperado, essa configuração incorreta poderá causar incompatibilidade de TLS no servidor para servidor ou cliente para comunicação do servidor e, como resultado, pode levar a problemas de conectividade.
Consulte este guia Exchange Server práticas recomendadas de configuração do TLS para configurar as configurações TLS necessárias em seus servidores do Exchange.
Compatibilidade de software de terceiros
Verifique se todos os produtos de terceiros que estão em execução em seu ambiente Exchange Server para garantir que eles funcionem corretamente se a Proteção Estendida estiver habilitada.
Vimos, por exemplo, soluções antivírus, que enviavam conexões por meio de um servidor proxy local para proteger o computador cliente. Tal cenário impediria a comunicação com o servidor exchange e precisaria ser desabilitado, pois é considerado uma conexão homem-no-meio (MitM), que será bloqueada pela Proteção Estendida.
Cenários que poderiam afetar a conectividade do cliente quando a Proteção Estendida estava habilitada
Cenários de descarregamento de SSL
A Proteção Estendida não tem suporte em ambientes que usam o descarregamento de SSL. O término do SSL durante o descarregamento de SSL faz com que a Proteção Estendida falhe. Para habilitar a Proteção Estendida em seu ambiente do Exchange, você não deve estar usando o descarregamento de SSL com seus Balanceadores de Carga.
Cenários de ponte SSL
A Proteção Estendida tem suporte em ambientes que usam ponte SSL em determinadas condições. Para habilitar a Proteção Estendida em seu ambiente do Exchange usando a Ponte SSL, você deve usar o mesmo certificado SSL no Exchange e seus Balanceadores de Carga. O uso de certificados diferentes faz com que o token de associação de canal de proteção estendida marcar falhe e, como resultado, impeça que os clientes se conectem ao servidor exchange.
Cenários de Proteção Estendida e Pasta Pública
A seção a seguir aborda cenários de Pasta Pública, o que pode levar a falhas quando a Proteção Estendida estiver habilitada.
A Proteção Estendida não pode ser habilitada em servidores Exchange Server 2013 com pastas públicas em um ambiente de coexistência
Para habilitar a Proteção Estendida no Exchange Server 2013, verifique se você não tem nenhuma Pasta Pública hospedada no Exchange Server 2013. Se você tiver coexistência de Exchange Server 2013 com Exchange Server 2016 ou Exchange Server 2019, deverá migrar suas Pastas Públicas para Exchange Server 2016 ou Exchange Server 2019 antes de habilitar a Proteção Estendida. Depois que a Proteção Estendida estiver habilitada e houver Pastas Públicas no Exchange Server 2013, elas não aparecerão mais para usuários finais!
Aviso
Exchange Server 2013 chegou ao fim do suporte em 11 de abril de 2023.
A Proteção Estendida não pode ser habilitada em Exchange Server CU22 2016 ou Exchange Server 2019 CU11 ou mais antigo que hospeda uma hierarquia de Pasta Pública
Se você tiver um ambiente que contenha Exchange Server CU22 ou Exchange Server 2019 CU11 ou mais antigo e estiver utilizando Pastas Públicas, confirme a versão do servidor que hospeda a hierarquia pasta pública antes de habilitar a Proteção Estendida!
Verifique se o servidor, que hospeda a hierarquia pasta pública, é atualizado para Exchange Server CU23 2016 ou Exchange Server CU12 2019 (ou posterior) com o Atualizações de segurança mais recente instalado. Mova a hierarquia pasta pública para um Exchange Server que executa uma versão necessária se você não puder atualizar o servidor exchange para uma versão com suporte.
A tabela a seguir pode ser usada para esclarecer:
| Versão do Exchange | CU instalada | SU instalado | Hospeda caixas de correio PF | Há suporte para EP? |
|---|---|---|---|---|
| Exchange 2013 | CU23 | Ago 2022 (ou superior) | Não | Sim |
| Exchange 2016 | CU22 | Ago 2022 (ou superior) | Sem caixas de correio de hierarquia | Sim |
| Exchange 2016 | CU23 (2022 H1) ou posterior | Ago 2022 (ou superior) | Qualquer | Sim |
| Exchange 2019 | CU11 | Ago 2022 (ou superior) | Sem caixas de correio de hierarquia | Sim |
| Exchange 2019 | CU12 (2022 H1) ou posterior | Ago 2022 (ou superior) | Qualquer | Sim |
| Qualquer outra versão | Qualquer outra CU | Qualquer outro SU | Qualquer | Não |
Proteção Estendida e configuração híbrida moderna
A seção a seguir aborda Exchange Server cenários híbridos modernos, o que pode levar a falhas quando a Proteção Estendida estiver habilitada.
A Proteção Estendida não pode ser totalmente configurada nos Exchange Servers que são publicados usando o Agente Híbrido
Em uma configuração híbrida moderna, os servidores do Exchange são publicados por meio de um Agente Híbrido, que proxie as chamadas Exchange Online para o servidor exchange.
Habilitar a Proteção Estendida no Exchange Servers que são publicados via Agente Híbrido, pode levar à interrupção de recursos híbridos, como movimentações de caixa de correio e chamadas gratuitas/ocupadas, se não for feita corretamente. Portanto, é importante identificar todos os servidores do Exchange, que são publicados pela ajuda de um Agente Híbrido e não habilitar a Proteção Estendida no Front-End diretório virtual do EWS neles.
Identificando servidores do Exchange que são publicados usando o Agente Híbrido
Caso você não tenha uma lista de servidores, que foram publicados por meio do Hybrid Agent, você poderá usar as etapas a seguir para identificá-los. Essas etapas não serão necessárias se você estiver executando uma implantação clássica Exchange Server Hybrid.
- Faça logon em um computador em que o Agente Híbrido está instalado e abra o módulo do PowerShell do Agente Híbrido. Execute
Get-HybridApplicationpara identificar oTargetUriusado pelo Agente Híbrido. - O
TargetUriparâmetro fornece o Fqdn do servidor Exchange, que está configurado para ser usado pelo Agente Híbrido.- Deduza a identidade do servidor do Exchange usando o Fqdn e anote o nome do servidor do Exchange.
- Se você estiver usando uma URL Load Balancer no
TargetUri, precisará identificar todos os servidores do Exchange, que têm aClient Accessfunção instalada e que podem ser acessados por trás da URL Load Balancer.
Importante
A Proteção Estendida não deve ser habilitada no Front-End diretório virtual do EWS em Exchange Servers que são publicados por meio de um Agente Híbrido.
Recomendamos as seguintes etapas para proteger os servidores do Exchange, que foram publicados por meio do Hybrid Agent:
Observação
No cenário a seguir, o Agente Híbrido é instalado em um servidor que NÃO executa Exchange Server. Além disso, esse servidor está localizado em um segmento de rede diferente dos servidores do Exchange de produção.
- Para servidores do Exchange publicados por meio do Agente Híbrido, as conexões de entrada devem ser restritas por um firewall para permitir conexões somente do computador no qual o Agente Híbrido está instalado. Isso não afeta as comunicações de saída dos servidores do Exchange para Exchange Online.
- Nenhuma caixa de correio deve ser hospedada nos servidores do Exchange, que foram publicados por meio do Hybrid Agent. As caixas de correio existentes devem ser migradas para outros servidores de caixa de correio.
Habilitando a Proteção Estendida
A Proteção Estendida é habilitada automaticamente durante Exchange Server configuração cu14 (ou posterior) de 2019. Em versões mais antigas do Exchange Server, que dão suporte à Proteção Estendida, ela pode ser habilitada por meio de um script fornecido pela Microsoft (recomendado) ou manualmente por meio do IIS Manager.
Para configurar corretamente a Proteção Estendida, cada diretório virtual em todos os servidores do Exchange na organização (excluindo servidores do Edge Transport) deve ser definido como valor prescrito de Extended Protection e sslFlags.
A tabela a seguir resume as configurações necessárias para cada diretório virtual nas versões com suporte do Microsoft Exchange.
| Site do IIS | Diretório Virtual | Proteção Estendida Recomendada | SslFlags recomendado |
|---|---|---|---|
Default Website |
API |
Required |
Ssl,Ssl128 |
Default Website |
AutoDiscover |
Off |
Ssl,Ssl128 |
Default Website |
ECP |
Required |
Ssl,Ssl128 |
Default Website |
EWS |
Accept (interface do usuário) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
MAPI |
Required |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync |
Accept (interface do usuário) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
Microsoft-Server-ActiveSync/Proxy |
Accept (interface do usuário) / Allow (Script) |
Ssl,Ssl128 |
Default Website |
OAB |
Accept (interface do usuário) / 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, atualizamos Default Website/OAB para estar Accept/Allow em vez de Required e Default Website/PowerShell para estar Off em vez de Required. A alteração é devido a Default Website/OAB Outlook para Mac clientes não poderem baixar a OAB por mais tempo com a Required configuração. A alteração Default Website/PowerShell ocorre porque o Exchange Server configuração padrão não permite conexões usando a autenticação NTLM para o PowerShell Front-End diretório virtual e, portanto, a Proteção Estendida não é aplicável.
Não há suporte para modificações no Default Website/PowerShell diretório virtual, a menos que seja explicitamente recomendado pelo CSS (Serviço de Cliente e Suporte da Microsoft).
Habilitando a Proteção Estendida usando Exchange Server instalador CU14 (ou posterior) 2019
Com Exchange Server CU14 2019 e posteriores, o instalador cu (atualização cumulativa) Exchange Server 2019 habilita automaticamente a Proteção Estendida no servidor da caixa de correio onde a instalação é executada. Isso acontece para qualquer nova instalação ou ao atualizar uma instalação de Exchange Server existente para a versão mais recente.
Há dois novos parâmetros que podem ser usados no modo de instalação autônomo para controlar a Proteção Estendida habilitada pelo comportamento padrão.
Os parâmetros podem ser usados para ignorar a ativação automática da Proteção Estendida (/DoNotEnableEP) ou para não habilitar a Proteção Estendida no diretório virtual Front-End EWS (/DoNotEnableEP_FEEWS).
Aviso
Desabilitar a Proteção Estendida torna seu servidor vulnerável a vulnerabilidades conhecidas do Exchange e enfraquece a proteção contra ameaças desconhecidas. Recomendamos deixar esse recurso habilitado.
Cenários de configuração do instalador cu de proteção estendida
Nesta seção, fornecemos os cenários mais comuns para configurar a Proteção Estendida em Exchange Server pela ajuda do instalador cu14 (ou posterior) da CU (atualização cumulativa) do Exchange Server 2019.
Verifique se o servidor exchange está configurado corretamente e atende aos requisitos conforme descrito nos pré-requisitos para habilitar a Proteção Estendida na seção Exchange Server.
Cenário 1: Habilitar a Proteção Estendida em um Exchange Server 2019
Execute a configuração cu14 (ou posterior) do Exchange Server 2019 no modo assistido ou autônomo. O instalador configurará a Proteção Estendida como parte da instalação do servidor no qual ele foi executado.
Cenário 2: Habilitar a Proteção Estendida em um Exchange Server 2019 que é publicado por meio do Hybrid Agent
Siga as etapas descritas na seção Identificar servidores do Exchange que são publicados usando o Agente Híbrido para identificar os Exchange Servers publicados por meio do Hybrid Agent.
Execute a configuração cu14 (ou posterior) do Exchange Server 2019 no modo autônomo usando o /DoNotEnableEP_FEEWS parâmetro. Ele ignora a habilitação da Proteção Estendida no diretório virtual Front-End EWS:
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP_FEEWS
Cenário 3: ignorar a habilitação da Proteção Estendida por Exchange Server configuração cu14 (ou posterior) de 2019
Execute a configuração cu14 (ou posterior) do Exchange Server 2019 no modo autônomo usando o /DoNotEnableEP parâmetro. Ele ignora a habilitação da Proteção Estendida:
<Virtual DVD drive letter>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade /DoNotEnableEP
Aviso
Não habilitar a Proteção Estendida torna seu servidor vulnerável a vulnerabilidades conhecidas do Exchange e enfraquece a proteção contra ameaças desconhecidas. Recomendamos ativar esse recurso.
Habilitando a Proteção Estendida usando o script do PowerShell
Você pode usar o scriptExchangeExtendedProtectionManagement.ps1 para habilitar a Proteção Estendida em alguns ou em todos os servidores do Exchange ao mesmo tempo.
Importante
Habilitar a Proteção Estendida em seu ambiente Exchange Server envolve fazer muitas alterações em todos os servidores do Exchange. Recomendamos usar o script fornecido pela Microsoft em vez de fazer essas alterações manualmente por meio do IIS Manager.
Baixe a versão mais recente do script antes de executá-lo para configurar a Proteção Estendida.
Você pode executar o script em qualquer Exchange Server específico em seu ambiente, que tem o EMS (Exchange Management Shell) instalado.
Permissões para configurar a Proteção Estendida usando o script do PowerShell
O usuário que executa o script deve ser um membro do Organization Management grupo de funções. O script deve ser executado a partir de um EMS (Exchange Management Shell) elevado.
Cenários de configuração de script de Proteção Estendida
Nesta seção, fornecemos os cenários mais comuns para configurar a Proteção Estendida em Exchange Server pela ajuda do ExchangeExtendedProtectionManagement.ps1 script do PowerShell.
Leia a documentação do script para obter mais exemplos e uma descrição dos parâmetros de script.
Cenário 1: Habilitar a Proteção Estendida em todos os Exchange Server
Execute o script da seguinte maneira para habilitar a Proteção Estendida em todos os servidores do Exchange em sua organização:
.\ExchangeExtendedProtectionManagement.ps1
O script executa várias verificações para garantir que todos os servidores exchange estejam na versão mínima necessária de CU e SU para habilitar a Proteção Estendida. Ele também verifica se todos os servidores do Exchange estão usando a mesma configuração TLS.
Depois que as verificações de pré-requisitos forem aprovadas, o script habilitará a Proteção Estendida e adicionará os sinalizadores SSL necessários em todos os diretórios virtuais de todos os servidores do Exchange no escopo. Ele será interrompido no caso de um servidor do Exchange não preenchimento completo dos requisitos (por exemplo, se uma configuração TLS inconsistente foi detectada).
Cenário 2: configurar a Proteção Estendida ao executar uma configuração híbrida moderna
Caso tenha configuração híbrida moderna, você deve ignorar a habilitação da Proteção Estendida no Front-End diretório virtual EWS no Exchange Servers, que foi publicado usando o Modern Hybrid Agent.
Essa configuração pode ser feita usando o ExcludeVirtualDirectories parâmetro:
.\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames MHServer1, MHServer2 -ExcludeVirtualDirectories "EWSFrontEnd"
Habilitar a Proteção Estendida usando o Gerenciador do IIS
Se você quiser habilitar a Proteção Estendida em seu ambiente manualmente sem usar o script, poderá usar as etapas a seguir.
Observação
Ao habilitar manualmente a Proteção Estendida, verifique se todos os diretórios virtuais em seus servidores do Exchange têm Proteção Estendida configurada de acordo com descrito na tabela acima.
Defina Proteção Estendida como necessária ou aceita em um diretório virtual
- Inicie o
IIS Manager (INetMgr.exe)no servidor exchange no qual você deseja configurar a Proteção Estendida - Vá para
Sitese selecione oDefault Web SiteouExchange Back End - Selecione o diretório virtual, que você deseja configurar
- Selecione
Authentication - Se
Windows Authenticationestiver habilitado, selecioneWindows Authentication
- Selecione
Advanced Settings(no lado direito) e, na janela de abertura, selecione o valor adequado na lista suspensa Proteção Estendida
Defina a configuração SSL necessária para um diretório virtual
- Clique no diretório virtual para abrir a home page
- Selecione
SSL Settings - Verifique as
Require SSLconfigurações para ter certeza de queRequire SSLestá habilitado para o diretório virtual
- Clique
Applypara confirmar a nova configuração
Desabilitando a proteção estendida
Você pode usar o scriptExchangeExtendedProtectionManagement.ps1 PowerShell para desabilitar a Proteção Estendida.
Aviso
Desabilitar a Proteção Estendida torna seu servidor vulnerável a vulnerabilidades conhecidas do Exchange e enfraquece a proteção contra ameaças desconhecidas. Recomendamos deixar esse recurso habilitado.
O comando a seguir desabilitará a configuração de Proteção Estendida para todos os Exchange Servers que estão online definindo o valor em todos os locais de configuração atuais como None:
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection
Você também pode especificar um subconjunto de servidores no qual a Proteção Estendida deve ser desabilitada:
.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection -ExchangeServerNames ExchServer1, ExchServer2
Solução de problemas
Esta seção contém problemas conhecidos que existem com a Proteção Estendida e lista algumas dicas de solução de problemas para cenários de falha conhecidos.
Problemas conhecidos com Proteção Estendida
Dica
Todos os problemas relatados anteriormente com a Proteção Estendida em Exchange Server foram corrigidos. Recomendamos instalar a atualização de Exchange Server mais recente para a versão do Exchange que você executa em sua organização para se beneficiar das correções e melhorias mais recentes.
Problema: quando você executa /PrepareSchema, /PrepareDomain ou /PrepareAllDomains no Exchange Server configuração do modo autônomo CU14 2019 mostra que a Proteção Estendida foi ativada
Esse é um problema conhecido com Exchange Server CU14 2019 que pode ser ignorado com segurança. A Proteção Estendida não está habilitada ao executar /PrepareSchemaou /PrepareAllDomains/PrepareDomain para preparar o ambiente, conforme descrito no Prepare Active Directory e domínios para Exchange Server documentação.
Problema: A alteração de permissões para pastas públicas usando um cliente do Outlook falha com o seguinte erro: "As permissões modificadas não podem ser alteradas"
Esse problema ocorrerá se a Pasta Pública para a qual você tentar alterar as permissões estiver hospedada em uma caixa de correio secundária da Pasta Pública enquanto a caixa de correio pasta pública primária estiver em um servidor diferente.
O problema foi corrigido com a atualização de Exchange Server mais recente. Siga as instruções conforme descrito neste KB para habilitar a correção.
Avisos e erros durante a execução do script de configuração de Proteção Estendida
O script mostra um aviso de problemas conhecidos e pede confirmação:
Para impedir que os administradores entrem em cenários em que as funções de Exchange Server existentes são interrompidas devido à habilitação da Proteção Estendida, o script fornece uma lista de cenários que têm problemas conhecidos. Leia e avalie esta lista cuidadosamente antes de habilitar a Proteção Estendida. Você pode continuar a ativar a Proteção Estendida pressionando
Y.
O script não habilita a Proteção Estendida porque um marcar de pré-requisito falhou:
Nenhum servidor do Exchange executa um build que dá suporte à Proteção Estendida:
Se nenhum servidor do Exchange na organização estiver executando um build que dê suporte à Proteção Estendida, o script não habilita a Proteção Estendida em servidores sem suporte para garantir que a comunicação servidor a servidor não falhe.
Para resolve esse caso, atualize todos os servidores do Exchange para a CU e SU mais recentes e execute o script novamente para habilitar a Proteção Estendida.
A incompatibilidade do TLS foi detectada:
Uma configuração TLS válida e consistente é necessária em todos os servidores do Exchange no escopo. Se as configurações do TLS em todos os servidores no escopo não forem as mesmas, habilitar a Proteção Estendida interromperá as conexões do cliente com servidores de caixa de correio.
Leia as melhores práticas de configuração do TLS Exchange Server para obter mais informações.
Alguns servidores do Exchange não estão disponíveis/acessíveis:
O script executa vários testes em todos os servidores do Exchange, que estão no escopo. Se um ou mais desses servidores não forem acessíveis, o script os excluirá, pois não poderá executar a ação de configuração necessária nesses computadores.
Se o servidor estiver offline, você deverá configurar a Proteção Estendida assim que ele estiver novamente online. Se o servidor estiver inacessível por outros motivos, você deverá executar o script no próprio servidor para habilitar a Proteção Estendida.
Os usuários não podem acessar sua caixa de correio por meio de um ou mais clientes
Pode haver vários motivos pelos quais alguns ou todos os clientes podem começar a dar erros de autenticação aos usuários depois que a Proteção Estendida foi habilitada por um administrador. Se esse problema acontecer, marcar a seguinte seção:
Se a configuração do TLS em toda a organização do Exchange não for a mesma (por exemplo, a configuração do TLS foi alterada em um dos servidores do Exchange depois que a Proteção Estendida foi habilitada), essa configuração incorreta pode fazer com que as conexões do cliente falhem. Para resolve esse problema, marcar as instruções para configurar corretamente o TLS em todos os servidores do Exchange e, em seguida, usar o script para configurar a Proteção Estendida novamente.
Verifique se o descarregamento de SSL é usado. Qualquer terminação SSL faz com que o token de associação de canal de proteção estendida marcar falhe, pois o descarregamento de SSL é considerado como um homem no meio, o que é impedido pela Proteção Estendida. Para resolve esse problema, desabilite o descarregamento de SSL e use o script para habilitar a Proteção Estendida novamente.
Os usuários podem acessar seus emails usando o Outlook para Windows e Outlook na Web, mas não através de clientes que não são do Windows, como Outlook para Mac, Outlook Mobile ou o cliente de email nativo do iOS. Isso pode acontecer se a configuração proteção estendida para EWS e/ou Exchange ActiveSync estiver definida como
Requiredem um ou todos os servidores Front-End.Para resolve esse problema, execute o
ExchangeExtendedProtectionManagement.ps1script com oExchangeServerNamesparâmetro e passe o nome do servidor Exchange, que tem uma configuração de Proteção Estendida configurada incorretamente. Você também pode executar o script sem nenhum parâmetro para marcar e configurar a Proteção Estendida para todos os servidores novamenteComo alternativa, você também pode usar
IIS Manager (INetMgr.exe)e alterar a configuração proteção estendida para esses Diretórios virtuais para o valor adequado, conforme descrito na tabela. É altamente recomendável usar o script, pois ele verifica os valores corretos e executa a reconfiguração automaticamente se os valores não forem definidos conforme o esperado.Se depois de seguir as etapas acima, alguns clientes ainda não estiverem funcionando conforme o esperado, você poderá reverter a Proteção Estendida temporariamente e relatar o problema à Microsoft abrindo um caso de suporte conosco. Siga as etapas conforme descrito na seção Desabilitar proteção estendida .
A migração híbrida gratuita/ocupada ou de caixa de correio não está funcionando
Se você estiver usando o Híbrido Moderno, habilitar a Proteção Estendida pode fazer com que recursos híbridos, como migração gratuita/ocupada e caixa de correio, parem de funcionar se a configuração não for executada, conforme descrito neste artigo. Para resolve esse problema, identifique os servidores híbridos que foram publicados usando o Agente Híbrido e desabilite a Proteção Estendida no Front-End diretório virtual do EWS nesses servidores.
As pastas públicas não estão mais visíveis/acessíveis
Há dois problemas que podem afetar a conectividade de Pastas Públicas quando a Proteção Estendida estiver habilitada. Siga as instruções conforme descrito na seção Proteção Estendida e Pastas Públicas deste artigo.
Perguntas frequentes
Pergunta: Será necessário instalar o SU (Atualização de Segurança) de agosto de 2022 se ele já estiver instalado na CU (Atualização Cumulativa anterior)?
Resposta: Sim, é necessário instalar o SU de agosto de 2022 novamente se você atualizar para um build de CU mais recente (por exemplo, Exchange Server CU11 2019 para Exchange Server CU12 2019).
Lembrar: Se você planeja fazer a atualização imediatamente (significa cu + instalação de SU), a Proteção Estendida não precisa ser desligada. Se você planeja permanecer na CU sem instalar o SU imediatamente, você deve desabilitar a Proteção Estendida como o build de CU (sem a instalação do SU), não dá suporte à Proteção Estendida e, portanto, você pode ter problemas de conectividade do cliente.
Pergunta: É seguro habilitar a Proteção Estendida em um ambiente que usa Serviços de Federação do Active Directory (AD FS) (AD FS) para Outlook na Web (OWA)?
Resposta: Sim, a Proteção Estendida não tem impacto na autenticação baseada em declarações do AD FS com o OWA.
Pergunta: É seguro habilitar a Proteção Estendida do Windows em um ambiente que usa o HMA (Hybrid Modern Auth)?
Resposta: Sim, o HMA não será afetado por essa alteração. Embora a Proteção Estendida não aprimore ainda mais o HMA, autenticação do Windows ainda pode ser usado para aplicativos que não dão suporte ao Auth Moderno Híbrido. Considerando isso, a habilitação da Proteção Estendida seria recomendada em qualquer ambiente qualificado que ainda tenha serviços locais do Exchange.
Pergunta: A Proteção Estendida afeta a integração do Auth moderno híbrido ou do Microsoft Teams?
Resposta: A Proteção Estendida não afeta a integração do Microsoft Teams ou o Auth Moderno Híbrido.
Pergunta: Não consigo acessar o OWA/ECP depois de habilitar a Proteção Estendida com um código HTTP 400 status, meu OWA/ECP é publicado por meio do Entra Proxy de Aplicativo, o que posso fazer para resolve isso?
Resposta: Não há suporte para a publicação do Exchange OWA/ECP por meio do entra Proxy de Aplicativo, você precisará publicar o OWA/ECP por meio de uma topologia de rede com suporte pelos Padrões de Proteção Estendida.
Pergunta: Embora entendamos que a prevenção de ataques mitm é importante, podemos ter nossos próprios dispositivos no meio com nossos próprios certificados?
Resposta: Se o dispositivo usar o mesmo certificado que o servidor exchange, ele poderá ser usado.