Ativar a Autenticação Moderna no Exchange no local

2025-05-09

APLICA-SE A: no-img-16 2016 yes-img-19 2019 yes-img-se Subscription Edition

Visão Geral

A partir do Exchange Server CU13 de 2019, o Exchange Server suporta OAuth 2.0 (também conhecido como Modern Authentication) para ambientes no local puros com o ADFS como um Serviço de Tokens de Segurança (STS). Este documento fornece os pré-requisitos e os passos para ativar esta funcionalidade.

A Autenticação Moderna no Exchange Server 2019 não deve ser confundida com a Autenticação Moderna Híbrida (HMA), que utiliza Microsoft Entra ID para Autenticação Moderna. Na verdade, o HMA continua a ser o método recomendado para ativar a Autenticação Moderna para todos os utilizadores no local e na cloud numa configuração híbrida do Exchange. Esta nova funcionalidade permite a utilização da Autenticação Moderna para organizações que não têm Microsoft Entra ID ou que não estão numa configuração híbrida do Exchange.

Como funciona a Autenticação Moderna e esta funcionalidade é aplicável a mim?

Com a Autenticação Moderna, os utilizadores podem autenticar-se no Exchange com o ADFS. Quando a Autenticação Moderna está ativada para um utilizador, o cliente do Outlook é redirecionado para o ADFS. Em seguida, os utilizadores podem autenticar-se ao fornecer credenciais ou efetuar a autenticação multifator. Depois de o ADFS autenticar um utilizador, gera tokens de acesso. Exchange Server valida estes tokens de acesso para fornecer acesso de cliente à caixa de correio do utilizador.

O diagrama seguinte ilustra a coordenação entre o Exchange Server, o ADFS e o Outlook para autenticar um utilizador com a Autenticação Moderna.

No gráfico anterior, os passos 3a, 4ae 6a5a ocorrem quando a Autenticação Moderna está ativada para o utilizador final. Os passos 3b, 4b ocorrem quando a Autenticação Moderna está desativada para um utilizador.

Veja a tabela seguinte para avaliar se esta funcionalidade é aplicável para si.

Configuração do Exchange	Esta funcionalidade é aplicável?	Comentários
Organização do Exchange no Local com apenas Exchange Server 2019	Sim	N/D
Organização do Exchange no Local com combinação de Exchange Server 2019, Exchange Server 2016 e Exchange Server 2013	Não	Exchange Server 2013 está sem suporte.
Organização do Exchange no Local com combinação de Exchange Server 2019 e Exchange Server 2016	Sim	Apenas os servidores do Exchange 2019 podem ser utilizados como Servidores de Front-End (Acesso de Cliente).
Organização híbrida do Exchange com HMA	Não	O HMA que utiliza Microsoft Entra ID é a solução preferencial. Veja a documentação de orientação sobre a utilização de novas políticas de autenticação.
Organização híbrida do Exchange sem HMA	Não	Utilize o HMA com Microsoft Entra ID.

Pré-requisitos para ativar a Autenticação Moderna no Exchange

Exchange Server 2019 CU13 ou posterior

Para utilizar a Autenticação Moderna, todos os servidores utilizados para ligações de cliente têm de ter Exchange Server 2019 CU13 instalado.

ADFS 2019 ou posterior

Para ativar a Autenticação Moderna num ambiente do Exchange no local, é necessário Serviços de Federação do Active Directory (AD FS) (ADFS) no Windows Server 2019 ou posterior. Não é suportado instalar e configurar a função do ADFS num Exchange Server. Para obter mais informações, veja Planear a Topologia de Implementação do AD FS.

Também poderá precisar do Servidor de Proxy de Aplicativo Web (no Windows Server 2019 ou posterior) para ativar o acesso do cliente a partir de uma rede empresarial externa. Leia a secção (Opcional) Configure Web Proxy de Aplicativo pode ser configurada para Acesso à Extranet para obter mais detalhes.

Pré-requisitos do cliente

Para utilizar a Autenticação Moderna, os utilizadores precisam de aplicações cliente, como o Outlook ou outros clientes do sistema operativo nativo, que são compatíveis com a Autenticação Moderna através do ADFS.

Outlook no Windows

O suporte para a Autenticação Moderna através do ADFS está disponível nas seguintes versões do Microsoft Outlook for Windows. O cliente Do Microsoft Outlook para Windows, a partir do número 16.0.17628.10000de compilação , utiliza o mais recente MSAL library para autenticação. Para garantir que está a utilizar a pilha de autenticação mais atualizada, recomenda-se que instale a versão mais recente:

Outlook no Microsoft 365 Apps:

Canal	Com suporte	Versão	Compilar (ou posterior)
Canal insider	Sim	2304	16327.20200
Canal Atual	Sim	2304	16327.20214
Canal Empresarial Mensal	Sim	2304	16327.20324
Canal Empresarial Semestral (Visualização)	Sim	2402	17328.20184
Canal Empresarial Semestral	Sim	2402	17328.20452

Outlook para Windows (licenciamento em volume & revenda):

Versão	Com suporte	Versão	Compilar (ou posterior)
Outlook 2016 (Qualquer versão)	Não	N/D	N/D
Outlook 2019 (Qualquer versão)	Não	N/D	N/D
Outlook 2021 (Retalho)	Sim	2304	16327.20214
Outlook 2021 (Volume)	Não	N/D	N/D
Outlook 2024 (Retalho)	Sim	2410	18129.20158
Outlook 2024 (Volume)	Sim	2408	17932.20162

Pode marcar o número de compilação do seu Office ao seguir os passos mencionados aqui.

Outlook no Mac

O suporte para a Autenticação Moderna através do ADFS está disponível no Outlook for Mac (Microsoft 365) através do Microsoft 365 a partir do número de compilação 16.95.4 (25040241). Tenha em atenção que a Autenticação Moderna através do ADFS não é atualmente suportada nas versões autónomas, como Outlook 2024 for Mac.

SO Windows

O cliente Windows tem de estar Windows 11 22H2 or later e tem de ter a atualização de 14 de março de 2023 instalada.

Pode rever Windows Update histórico para verificar se KB5023706 está instalado.

Plataformas da Apple

O suporte para a Autenticação Moderna através do ADFS está disponível na aplicação Apple Mail que começa com macOS Sequoia e iOS 17.6.1, e no Outlook for Mac (Microsoft 365) início do macOS Sequoia.

Protocolos que funcionam com a Autenticação Moderna do ADFS

A tabela seguinte descreve os protocolos que podem ser acedidos através da utilização de tokens de Autenticação Moderna do ADFS. Estamos continuamente a trabalhar para adicionar suporte de Autenticação Moderna do ADFS a mais protocolos Exchange Server.

Protocolo	Autenticação Moderna do ADFS Suportada
MAPI através de HTTP (MAPI/HTTP)	Sim
Outlook Anywhere (RPC/HTTP)	Não
Exchange Active Sync (EAS)	Sim
Serviços Web do Exchange (EWS)	Sim
Outlook na Web (OWA)	Sim (autenticação baseada em afirmações)
Exchange Administração Center (ECP)	Sim (autenticação baseada em afirmações)
Livro de Endereços Offline (OAB)	Sim
IMAP	Não
POP	Não

Passos para configurar a Autenticação Moderna no Exchange Server com o ADFS como STS

Esta secção fornece detalhes sobre como implementar a Autenticação Moderna no Exchange Server 2019 CU13.

Instalar o Exchange 2019 CU13 em todos os Servidores FE (pelo menos)

Todos os servidores utilizados para ligações de cliente têm de ser atualizados para o Exchange 2019 CU13. Esta abordagem garante que as ligações de cliente iniciais ao Exchange 2019 utilizam o OAuth e as ligações proxiadas para Exchange Server 2016 utilizam Kerberos.

O Exchange 2019 CU13 adiciona suporte para novas políticas de autenticação para permitir ou bloquear a Autenticação Moderna ao nível do utilizador. O bloqueio da Autenticação Moderna é utilizado para garantir que os clientes que não suportam a Autenticação Moderna continuam a poder ligar-se.

A execução /PrepareAD com a Configuração é necessária para adicionar vários novos parâmetros de política de autenticação ao Exchange Server.

BlockModernAuthActiveSync
BlockModernAuthAutodiscover
BlockModernAuthImap
BlockModernAuthMapi
BlockModernAuthOfflineAddressBook
BlockModernAuthPop
BlockModernAuthRpc
BlockModernAuthWebServices

Depois de instalar a CU13 ou posterior, quaisquer políticas de autenticação pré-existentes (incluindo a política de autenticação predefinida) têm os parâmetros desativados. Isto significa que, se já estiver a utilizar o HMA, não precisa de alterar as políticas de autenticação pré-existentes.

Não é necessária nenhuma nova política de autenticação para o Exchange Híbrido

As configurações híbridas existentes do Exchange devem utilizar a Autenticação Moderna Híbrida (HMA). As instalações híbridas com HMA podem deixar os valores dos BlockModernAuth* parâmetros em 0 para continuar a utilizar o HMA. Os passos descritos para configurar a Autenticação Moderna com o ADFS só são relevantes para as organizações que não estão a utilizar o Exchange Híbrido e são puramente no local.

Configurar Serviços de Federação do Active Directory (AD FS) (ADFS)

Tem de instalar e configurar o ADFS no ambiente para permitir que os clientes do Exchange utilizem Forms autenticação (OAuth) para se ligarem a Exchange Server. Veja a Lista de Verificação: Configurar um Servidor de Federação para ajudar na configuração do ADFS.

A funcionalidade ADFS pode ser instalada ao executar o seguinte comando a partir de uma janela elevada do PowerShell no novo servidor que se torna o servidor do ADFS:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Requisitos de certificado para a configuração do ADFS na Organização do Exchange Server

O ADFS requer dois tipos básicos de certificados (veja este artigo para obter informações detalhadas):

Um certificado SSL (Secure Sockets Layer) de comunicação de serviço para o tráfego de serviços Web encriptados entre o servidor ADFS, clientes, servidores Exchange e o servidor de Proxy de Aplicativo Web opcional. Recomendamos que utilize um certificado emitido por uma autoridade de certificação (AC) interna ou comercial, porque todos os clientes precisam de confiar neste certificado.
Um certificado de assinatura de tokens para comunicação encriptada e autenticação entre o servidor ADFS, os controladores de domínio do Active Directory e os servidores exchange. Pode obter um certificado de assinatura de tokens ao pedir um a partir de uma AC ou ao criar um certificado autoassinado.

Para obter mais informações sobre como criar e importar certificados SSL no Windows, veja Certificados de Servidor.

Eis um resumo dos certificados que estamos a utilizar neste cenário:

Nome comum (CN) no certificado (no Assunto, Nome Alternativo do Requerente ou uma correspondência de certificado de caráter universal)	Tipo	Necessário nos servidores	Comments
adfs.contoso.com enterpriseregistration.contoso.com	Emitido por uma AC	Servidor ADFS, Servidor de Proxy de Aplicativo Web (opcional)	Os servidores de federação utilizam um certificado SSL para proteger o tráfego dos serviços Web para comunicação SSL com clientes e com proxies de servidor de federação. Como o certificado SSL deve ser confiável para os computadores clientes, recomendamos usar um certificado assinado por uma autoridade de certificação de confiança. Todos os certificados selecionados devem ter uma chave privada correspondente.
Assinatura de Tokens do ADFS - adfs.contoso.com	Autoassinado ou problema por uma AC	Servidor ADFS, Servidor de Proxy de Aplicativo Web (opcional)	Um certificado de assinatura de tokens é um certificado X509. Os servidores de federação utilizam pares de chaves públicas/privadas associados para assinar digitalmente todos os tokens de segurança que produzem. Este processo inclui a assinatura de metadados de federação publicados e pedidos de resolução de artefactos. Pode ter vários certificados de assinatura de tokens configurados no snap-in Gestão do ADFS para permitir o rollover de certificados quando um certificado está perto de expirar. Por predefinição, todos os certificados na lista são publicados, mas apenas o certificado de assinatura de tokens principal é utilizado pelo ADFS para assinar tokens. Todos os certificados selecionados devem ter uma chave privada correspondente. Pode obter um certificado de assinatura de tokens ao pedir um a uma AC empresarial ou a uma AC pública ou ao criar um certificado autoassinado.
mail.contoso.com autodiscover.contoso.com	Emitido por uma AC	Servidores exchange, Servidor de Proxy de Aplicativo Web (opcional)	Este certificado é o certificado típico que é utilizado para encriptar ligações de cliente externo para Outlook na Web (e outros serviços do Exchange). Para saber mais, confira Requisitos de certificado para serviços Exchange.

Implementar e Configurar o Servidor ADFS

Utilize Windows Server 2019 ou posterior para implementar um servidor ADFS. Siga os passos em Implementar um servidor ADFS e Configurar e testar a documentação do servidor ADFS . Certifique-se de que o URL de metadados de federação pode ser acedido num browser a partir do servidor Exchange e, pelo menos, de um computador cliente.

O URL utiliza esta sintaxe: https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

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

Configurar o Método de Autenticação no ADFS

Para utilizar a Autenticação Moderna no Outlook no Windows, tem de configurar o Primary Authentication Methods. Recomendamos que Forms Authentication escolha para e ExtranetIntranet. Esta configuração pode ser feita ao executar os seguintes comandos a partir de uma janela do PowerShell no servidor do ADFS:

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

Escolher a Duração de SSO adequada

Escolha uma duração de Sign-On Único (SSO) adequada para que os utilizadores finais não sejam obrigados a reautenenciar frequentemente. Para validar a configuração de duração do SSO atual, abra uma nova janela do PowerShell no servidor do ADFS e execute o seguinte comando:

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

Utilize o cmdlet Set-AdfsProperties para configurar os valores adequados para SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMinse DeviceUsageWindowInDays. Estas definições devem ser ajustadas para ativar o SSO e definir a respetiva expiração. Consoante o modo SSO, como Keep Me Signed In (KMSI) ou Device registration, também poderá ter de ativar KsmiEnabled e PersistentSsoEnabled. Pode encontrar mais detalhes sobre o SSO do ADFS na documentação definições de Logon único do AD FS 2016.

Configurar o registo de dispositivos no ADFS

Recomenda-se que Device Registration a funcionalidade no ADFS beneficie de uma experiência de SSO melhorada. Para ativar Device Registrationo , siga os passos descritos na documentação Configurar um servidor de federação com o Serviço de Registo de Dispositivos .

Em seguida, conclua todos os passos para configurar Device Registration Service Discovery e o Device Registration Discovery Server SSL certificate, conforme descrito na documentação Configurar o Registo de Dispositivos .

Para utilizar o registo de dispositivos, os utilizadores finais têm de associar o respetivo dispositivo a uma Área de Trabalho. Pode encontrar mais detalhes nas seguintes documentação:

Verifique se o registo do dispositivo está configurado e se a autenticação do dispositivo está ativada ao verificar o Device Registration Overview. Este passo é recomendado para reduzir o número de pedidos de autenticação para os utilizadores e pode ajudar a impor políticas de Controle de Acesso no ADFS.

Configurar o KSMI no ADFS

Se preferir não utilizar Device Registration ou não conseguir fazê-lo, pode ativar a Keep Me Signed In funcionalidade. Em seguida, o ADFS cria um cookie persistente imediatamente após a autenticação do utilizador, eliminando a necessidade de reautenticação nas sessões subsequentes, desde que o cookie permaneça válido.

O tempo de expiração do token de atualização é igual à duração do cookie SSO persistente para Keep me signed in. A duração persistente do cookie SSO é um dia, por predefinição, com um máximo de sete dias. Caso contrário, a duração do token de atualização é igual à duração do cookie SSO da sessão (8 horas por predefinição). Pode encontrar mais informações sobre a KSMI na documentação de definições de início de sessão único do AD FS .

O KMSI está desativado por predefinição e pode ser ativado ao definir a propriedade KmsiEnabled ADFS como True. Certifique-se de que executa os seguintes passos a partir de uma janela do PowerShell no servidor do ADFS:

Set-AdfsProperties -EnableKmsi $true

Com KMSI desativado, o período de início de sessão único predefinido é 8 hours. O período de início de sessão único pode ser configurado com a propriedade SsoLifetime. A propriedade é medida em minutos, pelo que o valor predefinido é 480:

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

Com KMSI ativado, o período de início de sessão único predefinido é 24 hours. O período de início de sessão único com KMSI ativado pode ser configurado com a propriedade KmsiLifetimeMins. A propriedade é medida em minutos, pelo que o valor predefinido é 1440:

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

Criar o Grupo de Aplicações do Outlook do ADFS

Se esta for a primeira vez que configura a Autenticação Moderna do ADFS no Exchange no local, siga os passos nesta secção do guia. Se tiver uma configuração de Autenticação Moderna do ADFS existente configurada antes do suporte para clientes que não Microsoft Outlook for Windowso , veja os passos na secção Atualizar o Grupo de Aplicações do Outlook do ADFS existente desta documentação. Os seguintes comandos do PowerShell têm de ser executados a partir de uma janela do PowerShell no servidor do ADFS. Se não planear utilizar aplicações iOS e macOS, como a aplicação Nativa do Apple Mail, pode ignorar a criação da aplicação cliente nativa do ADFS para iOS e macOS. No entanto, recomendamos que as crie por uma questão de completa.

Primeiro, vamos criar o ADFS Application Group:

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

Em seguida, vamos criar mais Scopes - EAS.AccessAsUser.Alltrês , EWS.AccessAsUser.All e :offline_access

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

Agora, estamos a criar dois Native Client Applications - Outlook - Native application e :iOS and macOS - Native mail application

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

Como próximo passo, criamos Web Api Applications. Criamos uma aplicação por URI que é utilizada no seu ambiente de Exchange Server. Se utilizar, por exemplo, autodiscover.contoso.com e mail.contoso.com, tem de criar dois Web Api Applications. Certifique-se de que substitui os URIs no exemplo seguinte pelos URIs, que utiliza na configuração. É importante garantir que todos os URIs destinados ao cliente estão abrangidos. Inclua o seguinte / e certifique-se de que os URIs começam com https://:

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

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

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

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

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

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

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

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

Como último passo, adicionamos as permissões de cliente para todos os Native Client Applications existentes:Web Api Applications

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

Atualizar o Grupo de Aplicações do Outlook do ADFS existente

Importante

Ignore os passos nesta secção se não tiver um Grupo de Aplicações do Outlook do ADFS existente, que foi configurado antes de o suporte para clientes que Microsoft Outlook for Windows não foram introduzidos.

Se tiver uma configuração existente do Grupo de Aplicações do Outlook do ADFS, que foi configurada antes do suporte para clientes que não Microsoft Outlook for Windows foram introduzidos, siga os passos aqui para ativar o suporte para outras plataformas. Os seguintes comandos do PowerShell têm de ser executados a partir de uma janela do PowerShell no servidor do ADFS.

Primeiro, estamos a criar três extras ScopesEWS.AccessAsUser.All - EAS.AccessAsUser.Alle :offline_access

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

Agora, estamos a criar um novo Native Client Applications - iOS and macOS - Native mail application:

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

Atualizamos o existente Native Client Application - Outlook - Native application. Certifique-se de que substitui o TargetName pelo nome de destino que está a utilizar na configuração existente:

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

Como próximo passo, temos de criar um Web Api Application para cada Identifier (URI) que é utilizado no seu ambiente de Exchange Server e existe na configuração atual da Autenticação Moderna do ADFS:

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

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

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

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

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

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

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

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

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

Como último passo, adicionamos as permissões de cliente para todos os Native Client Applications existentes:Web Api Applications

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

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

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

Remover o Grupo de Aplicações do Outlook do ADFS existente

Cuidado

Ao seguir os passos nesta secção, remove a configuração existente do Grupo de Aplicações do Outlook do ADFS.

Se tiver uma configuração existente do Grupo de Aplicações do Outlook do ADFS e quiser removê-la, siga os passos aqui para eliminar a configuração existente. Todos os seguintes comandos do PowerShell têm de ser executados a partir de uma janela do PowerShell no servidor do ADFS.

Primeiro, vamos eliminar o ADFS Application Group:

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

Como último passo, eliminamos o personalizado Scopes que foi adicionado:

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

(Opcional) Configurar Proxy de Aplicativo Web pode ser configurado para o Acesso à Extranet

A Proxy de Aplicativo Web faz parte da função de servidor de Acesso Remoto no Windows Server. Fornece funcionalidades de proxy inverso para permitir que os utilizadores acedam às suas aplicações Web a partir de fora da rede empresarial. A web Proxy de Aplicativo pré-autentica o acesso a aplicações Web através do ADFS e funciona como um proxy do ADFS.

Se planear utilizar o proxy de Aplicações Web, utilize os passos mencionados em Instalar e Configurar o Servidor de Proxy de Aplicativo Web para o configurar. Depois de configurado, pode publicar regras para Autodiscover.contoso.com ou/e mail.contoso.com com os passos mencionados em Publicar uma Aplicação que utiliza OAuth2.

(Opcional) Configurar a MFA para acesso de cliente

Veja as seguintes ligações para configurar o ADFS com um fornecedor de MFA à sua escolha.
- Configurar fornecedores de autenticação de terceiros como autenticação primária no AD FS 2019
- Configurar a MFA do Azure como fornecedor de autenticação com o AD FS
Configure a Política de Controle de Acesso que requer mFA.
- Políticas de Controle de Acesso no AD FS do Windows Server 2016

Criar Políticas de Autenticação para Utilizadores Finais

É possível que nem todos os utilizadores na sua organização tenham clientes de e-mail que suportem a Autenticação Moderna através do ADFS. Neste cenário, recomendamos ativar a Autenticação Moderna para utilizadores com clientes suportados e bloqueá-la para esses utilizadores sem.

Para ativar a Autenticação Moderna para um conjunto específico de utilizadores e bloqueá-la para os restantes utilizadores, tem de criar, pelo menos, duas políticas de autenticação.

Importante

As novas políticas de autenticação ficam disponíveis assim que o Active Directory é preparado com o suporte de dados do Exchange 2019 CU13 ou posterior.

Uma política para toda a organização para bloquear a Autenticação Moderna por predefinição
Uma política secundária para permitir seletivamente a Autenticação Moderna para utilizadores específicos

Os seguintes comandos do PowerShell têm de ser executados a partir de uma janela do Exchange Management Shell (EMS) no seu servidor Exchange.

Criar uma política ao nível da organização para bloquear a Autenticação Moderna por predefinição

Assim que a Autenticação Moderna estiver ativada, todos os clientes do Outlook tentam utilizar tokens OAuth. No entanto, alguns clientes que não são compatíveis com a Autenticação Moderna do ADFS só podem obter tokens OAuth de Microsoft Entra ID. Por isso, estes clientes não conseguem ligar-se se a Autenticação Moderna estiver ativada.

Para impedir este cenário, pode implementar uma política em toda a organização para desativar a Autenticação Moderna. No exemplo, criamos uma nova política de autenticação com o nome Block Modern Auth.

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

Esta política pode ser definida ao nível da Organização com o seguinte comando.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

Criar uma política de autenticação ao nível do utilizador para ativar a Autenticação Moderna

Em seguida, crie uma segunda política de autenticação que ative a Autenticação Moderna. Atribua esta política a todos os utilizadores com clientes do Outlook suportados para permitir que os clientes utilizem a Autenticação Moderna.

No exemplo, criamos uma nova autenticação denominada Allow Modern Auth com o seguinte comando:

New-AuthenticationPolicy "Allow Modern Auth"

Configurar Exchange Server para utilizar tokens OAuth do ADFS

Verifique se OAuth está ativado nos seguintes diretórios virtuais. Se não estiver ativado, ative-o OAuth para todos estes diretórios virtuais:
```
Get-MapiVirtualDirectory | Format-List Server, *auth*
Get-WebServicesVirtualDirectory | Format-List Server, *auth*
Get-OabVirtualDirectory | Format-List Server, *auth*
Get-AutodiscoverVirtualDirectory | Format-List Server, *auth*
Get-ActiveSyncVirtualDirectory | Format-List Server, *auth*
```
O resultado é apresentado da seguinte forma. O principal detalhe em que se deve focar é OAuth, conforme mencionado anteriormente:
```
Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
```
Se OAuth estiver em falta em qualquer servidor ou em qualquer um dos cinco diretórios virtuais, tem de adicioná-lo com os comandos relevantes antes de continuar: Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OabVirtualDirectory, Set-AutodiscoverVirtualDirectory e Set-ActiveSyncVirtualDirectory.
Execute o seguinte comando:
```
New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml
```
Este comando é necessário para criar um novo objeto de servidor de autenticação no Exchange Server para o ADFS. Os objetos do servidor de autenticação são uma lista de emissores fidedignos. Apenas os tokens OAuth destes emissores são aceites.
Execute o seguinte comando:
```
Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true
```
Defina o servidor de Autenticação que acabámos de adicionar como o DefaultAuthorizationEndpoint. Ao anunciar o cabeçalho Autenticação Moderna, Exchange Server anuncia o URL de autenticação do DefaultAuthorizationEndpoint. É assim que os clientes sabem que ponto final utilizar para autenticação.
Temos de executar este comando para ativar a Autenticação Moderna ao nível da organização:
```
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
```
Ative a Autenticação Moderna para utilizadores com clientes suportados ao atribuir a Allow Modern Auth política de autenticação:
```
Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"
```

Client-Side configuração da Autenticação Moderna

Recomendamos que teste a Autenticação Moderna com poucos utilizadores antes de implementar para todos os utilizadores. Assim que um grupo piloto de utilizadores puder utilizar a Autenticação Moderna, podem ser implementados mais utilizadores. Confirme que o cliente suporta a Autenticação Moderna do ADFS. Pode encontrar mais detalhes sobre os clientes suportados na secção Pré-requisitos do cliente .

Microsoft Windows

Ative a Autenticação Moderna e adicione o seu domínio do ADFS como domínio fidedigno no Outlook:

Crie as seguintes chaves de registo para tornar o seu domínio do ADFS num domínio fidedigno. Certifique-se de que adiciona ambas as chaves com e sem o / no final do domínio do ADFS:
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain/
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain
Pode utilizar o PowerShell para criar as chaves de registo ou implementá-las com a ajuda de um Política de Grupo. Execute os seguintes comandos a partir de uma janela do PowerShell em cada computador cliente. Substitua pelo your-ADFS-domain seu domínio do ADFS.
```
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains" -Force
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain/")
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain")
```
Para ativar a Autenticação Moderna do ADFS, adicione o EnableExchangeOnPremModernAuthREG_DWORD valor HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\em Microsoft Outlook for Windows .

Pode utilizar o PowerShell para criar o valor do registo ou implementá-lo através de um Política de Grupo. Execute o seguinte comando a partir de uma janela do PowerShell em cada computador cliente.
```
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord
```

Apple macOS

Para ativar a Autenticação Moderna para o Microsoft Outlook em versões suportadas do macOS da Apple, tem de modificar as preferências da aplicação Microsoft Outlook.

Abra uma janela terminal e execute o seguinte comando, substituindo host1 pelo FQDN do servidor do ADFS. Certifique-se de que não inclui o protocolo nem adiciona quaisquer barras no final do FQDN. Por exemplo, se o servidor do ADFS estiver acessível através de https://fs.contoso.com/, utilize fs.contoso.com. Se tiver vários espaços de nomes do ADFS, adicione-os separados por um espaço.

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

Para dispositivos geridos, os administradores podem utilizar uma solução de Gerenciamento de Dispositivos Móvel (MDM) para gerir e enviar centralmente uma lista de FQDNs do ADFS para dispositivos cliente. A tabela seguinte descreve as definições de configuração necessárias para controlar esta funcionalidade através da MDM:

Configurações	Values
Aplicação de destino	`Outlook Mac`
Chave de configuração	`trustedauthorities`
Tipo do valor	`String`
Valor de configuração	`<ADFS FQDNs>`

Verificar o fluxo de Autenticação Moderna

Depois de configurados corretamente, os utilizadores experimentam o pedido de início de sessão do ADFS quando se ligam a um servidor Exchange.

Efeito noutros clientes quando a Autenticação Moderna está ativada

Os utilizadores ativados para a Autenticação Moderna que utilizam vários clientes (por exemplo, Outlook on Windows e Outlook Mobile) têm comportamentos diferentes em cada cliente. No resumo seguinte, descrevemos os comportamentos do cliente quando a Autenticação Moderna está ativada, assumindo Block Modern Auth que é aplicada ao nível da DefaultAuthenticationPolicy organização.

Cliente	Comportamento
Outlook para Windows (Clássico)	Utiliza a Autenticação Moderna por predefinição.
Outlook para Windows (Novo)	Tenta utilizar a Autenticação Moderna, mas falha.
Outlook para Mac	Utiliza a Autenticação Moderna se estiver ativada no cliente.
Outlook para iOS	Volta à autenticação Básica.
Outlook Android	Volta à autenticação Básica.
Aplicação Correio do iOS	Utiliza Autenticação Moderna.
aplicação Correio do macOS	Utiliza Autenticação Moderna.
Aplicação Gmail	Volta à autenticação Básica.
OWA/ECP	Não utiliza a política de autenticação. Consoante a forma como está configurada, utiliza a Autenticação Moderna ou a Autenticação Básica.
Aplicação Correio do Windows	Não reverte para autenticação Básica.
Cliente Thunderbird	Não reverte para autenticação Básica.
PowerShell	Utiliza autenticação básica.

Efeito no OWA/ECP quando a Autenticação Moderna está ativada para outros clientes

Pode ou não estar a utilizar a autenticação baseada em afirmações do ADFS para Outlook na Web. Os passos mencionados são necessários para ativar o OAuth para outros clientes e não afetam a forma como o OWA/ECP está configurado.

Utilizar a autenticação baseada em afirmações do AD FS com Outlook na Web

Tempo de espera após alterar a política de autenticação

Depois de alterar a política de autenticação para permitir a Autenticação Moderna ou bloquear a autenticação legada:

Aguarde 30 minutos para que as novas políticas sejam lidas pelos servidores front-end

or
Efetue uma reposição do IIS em todos os servidores front-end.

Migrar para a Autenticação Moderna Híbrida depois de utilizar a ativação da Autenticação Moderna para Exchange Server

Se estiver a utilizar a Autenticação Moderna com o ADFS e, mais tarde, decidir configurar o Exchange Híbrido, deve transitar para a Autenticação Moderna Híbrida. Os passos de migração detalhados serão incluídos numa versão futura deste documento.

Renovar certificados

Avaliar a configuração do certificado atual

Quando se trata de ligações de cliente a Exchange Server, o certificado que deve ser avaliado é o vinculado ao Site IIS de Front-end. Para um servidor ADFS, garantir que todos os certificados devolvidos são Get-AdfsCertificate atuais é ideal.

Para identificar o certificado relevante num Exchange Server, execute o seguinte no Shell de Gestão do Exchange:

Import-Module WebAdministration
(Get-ChildItem IIS:SSLBindings | Where-Object {($_.Sites -ne $null) -and ($_.Port -eq "443")}).Thumbprint | ForEach-Object {Get-ExchangeCertificate $_ | Where-Object {$_.Services -Match "IIS"} | Format-Table Thumbprint, Services, RootCAType, Status, NotAfter, Issuer -AutoSize -Wrap}

Para rever certificados ativos num Servidor ADFS, execute o seguinte no PowerShell:

Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap

Atualizar certificados no Exchange Server

Se se verificar que o certificado do Exchange tem de ser atualizado para a conectividade do cliente, tem de ser emitido e importado um novo certificado para os Servidores exchange. Posteriormente, o certificado deve ser ativado para o IIS no mínimo. Avalie se outros serviços devem estar ativados para o novo certificado com base na configuração.

Exemplo de criação, conclusão, ativação e importação de um novo certificado em todos os servidores com base no certificado existente na Shell de Gestão do Exchange:

Gere um novo pedido de certificado no Shell de Gestão do Exchange com base no certificado existente:

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

Teste uma variável que contém o caminho de saída pretendido do novo pedido de certificado:
```
$requestFile = "C:\temp\CertRequest.req"
```
Crie o ficheiro de pedido de certificado:
```
[System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))
```
Observação

O caminho da pasta para o pedido de certificado já tem de existir.
Partilhe o ficheiro de pedido com a Autoridade de Certificação (AC). Os passos necessários para obter um certificado concluído variam consoante a sua AC.

Observação

.p7b é o formato preferencial para o pedido concluído.
Teste uma variável que contém o caminho completo do pedido concluído:
```
$certFile = "C:\temp\ExchangeCert.p7b"
```

Importe o pedido para o servidor que gerou originalmente o pedido:

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

Variável de fase para a palavra-passe para proteger o certificado concluído:
```
$pw = Read-Host "Enter password" -AsSecureString
```

Exporte o binário do certificado para uma variável:

$binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

Variável de fase para o caminho de saída pretendido do certificado concluído:
```
$certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"
```

Exporte o pedido concluído para ser importado noutros servidores:

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

Ative os serviços que devem estar vinculados ao certificado:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS
```
Observação

Poderá ter de adicionar mais serviços ao exemplo anterior com base na configuração dos certificados anteriores.
Valide se o certificado está a funcionar conforme pretendido ao direcionar um cliente para o servidor para todos os espaços de nomes de cliente com um ficheiro de anfitrião.
Importe o certificado do Exchange em todos os outros servidores exchange:
```
Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>
```
Observação

A inclusão do -PrivateKeyExportable parâmetro é opcional ao importar para outros servidores do Exchange.
Ative o certificado do Exchange para os serviços do Exchange necessários em todos os outros servidores Exchange:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>
```
Observação

Poderá ter de adicionar mais serviços ao exemplo anterior com base na configuração dos certificados anteriores.

Atualizar certificado no ADFS

Consoante o tipo de certificado que requer atualização no ADFS, determina se precisa de seguir os passos descritos abaixo.

certificado de Service-Communications

Este exemplo fornece o PowerShell necessário para importar um certificado no .pfx formato, como o gerado ao seguir os passos Exchange Server certificado. Certifique-se de que tem sessão iniciada no servidor ADFS principal.

Teste uma variável que contém a palavra-passe do certificado:
```
$pw = Read-Host "Enter password" -AsSecureString
```
Teste uma variável que contém o caminho completo para o certificado:
```
$certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"
```

Importe o certificado para o arquivo pessoal da LocalMachine:

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

Atualize o certificado de Service-Communications:

Set-AdfsSslCertificate -Thumbprint <Thumbprint>

certificados de Token-Signing e Token-Decryption

Siga os passos descritos na documentação Obter e Configurar Certificados TS e TD para o AD FS .

Observação

A utilização do certificado autoassinado predefinido para Token-Signing na autenticação baseada em afirmações do ADFS para Outlook na Web requer que o certificado seja instalado nos Servidores Exchange.

Compartilhar via