Habilitación de la autenticación moderna en Exchange local

2025-05-09

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

Información general

A partir de Exchange Server 2019 CU13, Exchange Server admite OAuth 2.0 (también conocido como Modern Authentication) para entornos locales puros que usan ADFS como servicio de token de seguridad (STS). En este documento se proporcionan los requisitos previos y los pasos necesarios para habilitar esta característica.

La autenticación moderna de Exchange Server 2019 no debe confundirse con la autenticación moderna híbrida (HMA), que usa Microsoft Entra ID para la autenticación moderna. De hecho, HMA sigue siendo el método recomendado para habilitar la autenticación moderna para todos los usuarios locales y en la nube en una configuración híbrida de Exchange. Esta nueva característica permite el uso de autenticación moderna para las organizaciones que no tienen Microsoft Entra ID o no están en una configuración híbrida de Exchange.

¿Cómo funcionará la autenticación moderna y es esta característica aplicable a mí?

Con la autenticación moderna, los usuarios pueden autenticarse en Exchange mediante ADFS. Cuando la autenticación moderna está habilitada para un usuario, su cliente de Outlook se redirige a ADFS. A continuación, los usuarios pueden autenticarse proporcionando credenciales o realizando la autenticación multifactor. Una vez que ADFS autentica a un usuario, genera tokens de acceso. Exchange Server valida estos tokens de acceso para proporcionar acceso de cliente al buzón del usuario.

En el diagrama siguiente se muestra la coordinación entre Exchange Server, ADFS y Outlook para autenticar a un usuario mediante autenticación moderna.

En el gráfico anterior, los pasos 3a, 5a4ay 6a tienen lugar cuando la autenticación moderna está habilitada para el usuario final. Los pasos 3b, 4b se producen cuando la autenticación moderna está deshabilitada para un usuario.

Consulte la tabla siguiente para evaluar si esta característica es aplicable.

Configuración de Exchange	¿Esta característica es aplicable?	Comentarios
Organización de Exchange local con solo Exchange Server 2019	Sí	N/D
Organización de Exchange local con combinación de Exchange Server 2019, Exchange Server 2016 y Exchange Server 2013	No	Exchange Server 2013 no es compatible.
Organización de Exchange local con combinación de Exchange Server 2019 y Exchange Server 2016	Yes	Solo los servidores de Exchange 2019 se pueden usar como servidores de Front-End (acceso de cliente).
Organización híbrida de Exchange mediante HMA	No	HMA con Microsoft Entra ID es la solución preferida. Consulte las instrucciones sobre el uso de nuevas directivas de autenticación.
Organización híbrida de Exchange sin HMA	No	Use HMA con Microsoft Entra ID.

Requisitos previos para habilitar la autenticación moderna en Exchange

Exchange Server 2019 CU13 o posterior

Para usar la autenticación moderna, todos los servidores usados para las conexiones de cliente deben tener instalado Exchange Server 2019 CU13.

ADFS 2019 o posterior

Para habilitar la autenticación moderna en un entorno de Exchange local, se requiere Servicios de federación de Active Directory (AD FS) (ADFS) en Windows Server 2019 o posterior. No se puede instalar y configurar el rol ADFS en un Exchange Server. Para obtener más información, vea Planear la topología de implementación de AD FS.

También puede necesitar Web Application Proxy Server (en Windows Server 2019 o posterior) para habilitar el acceso de cliente desde fuera de la red corporativa. Lea la sección (Opcional) Configurar web Application Proxy se puede configurar para Acceso a extranet para obtener más información.

Requisitos previos del cliente

Para usar la autenticación moderna, los usuarios requieren aplicaciones cliente, como Outlook u otros clientes de sistema operativo nativo, que son compatibles con la autenticación moderna a través de ADFS.

Outlook en Windows

La compatibilidad con la autenticación moderna a través de ADFS está disponible en las siguientes versiones de Microsoft Outlook for Windows. El cliente de Windows de Microsoft Outlook, a partir del número 16.0.17628.10000de compilación, usa la versión más reciente MSAL library para la autenticación. Para asegurarse de que usa la pila de autenticación más actualizada, se recomienda instalar la versión más reciente:

Outlook en Aplicaciones Microsoft 365:

Canal	Compatible	Versión	Compilación (o posterior)
Canal insider	Yes	2304	16327.20200
Canal actual	Yes	2304	16327.20214
Canal mensual para empresas	Yes	2304	16327.20324
Canal semestral para empresas (versión preliminar)	Yes	2402	17328.20184
Canal empresarial semestral	Yes	2402	17328.20452

Outlook para Windows (licencia por volumen & minorista):

Versión	Compatible	Versión	Compilación (o posterior)
Outlook 2016 (cualquier versión)	No	N/D	N/D
Outlook 2019 (cualquier versión)	No	N/D	N/D
Outlook 2021 (minorista)	Yes	2304	16327.20214
Outlook 2021 (volumen)	No	N/D	N/D
Outlook 2024 (minorista)	Yes	2410	18129.20158
Outlook 2024 (volumen)	Yes	2408	17932.20162

Puede comprobar el número de compilación de Office siguiendo los pasos que se mencionan aquí.

Outlook en Mac

La compatibilidad con la autenticación moderna a través de ADFS está disponible en Outlook for Mac (Microsoft 365) a través de Microsoft 365 a partir del número 16.95.4 (25040241)de compilación . Tenga en cuenta que la autenticación moderna a través de ADFS no se admite actualmente en las versiones independientes, como Outlook 2024 for Mac.

Sistema operativo Windows

El cliente de Windows debe ser Windows 11 22H2 or later y debe tener instalada la actualización del 14 de marzo de 2023 .

Puede revisar Windows Update historial para comprobar que KB5023706 está instalado.

Plataformas de Apple

La compatibilidad con la autenticación moderna a través de ADFS está disponible en la Apple Mail aplicación a partir macOS Sequoia de y iOS 17.6.1, y Outlook for Mac (Microsoft 365) a partir de macOS Sequoia.

Protocolos que funcionan con autenticación moderna de ADFS

En la tabla siguiente se describen los protocolos a los que se puede acceder mediante el uso de tokens de autenticación moderna de ADFS. Estamos trabajando continuamente para agregar compatibilidad con ADFS Modern Auth a más protocolos Exchange Server.

Protocolo	Se admite la autenticación moderna de ADFS
MAPI a través de HTTP (MAPI/HTTP)	Yes
Outlook en cualquier lugar (RPC/HTTP)	No
Exchange Active Sync (EAS)	Yes
Servicios Web Exchange (EWS)	Yes
Outlook en la Web (OWA)	Sí (autenticación basada en notificaciones)
Centro de Administración de Exchange (ECP)	Sí (autenticación basada en notificaciones)
Libreta de direcciones sin conexión (OAB)	Yes
IMAP	No
POP	No

Pasos para configurar la autenticación moderna en Exchange Server mediante ADFS como STS

En esta sección se proporcionan detalles sobre cómo implementar la autenticación moderna en Exchange Server 2019 CU13.

Instalar Exchange 2019 CU13 en todos los servidores FE (al menos)

Todos los servidores usados para las conexiones de cliente deben actualizarse a Exchange 2019 CU13. Este enfoque garantiza que las conexiones de cliente iniciales a Exchange 2019 usen OAuth y las conexiones proxy a Exchange Server 2016 usen Kerberos.

Exchange 2019 CU13 agrega compatibilidad con nuevas directivas de autenticación para permitir o bloquear la autenticación moderna en el nivel de usuario. El bloqueo de la autenticación moderna se usa para garantizar que los clientes que no admiten la autenticación moderna todavía puedan conectarse.

La ejecución /PrepareAD con el programa de instalación es necesaria para agregar varios parámetros de directiva de autenticación nuevos a Exchange Server.

BlockModernAuthActiveSync
BlockModernAuthAutodiscover
BlockModernAuthImap
BlockModernAuthMapi
BlockModernAuthOfflineAddressBook
BlockModernAuthPop
BlockModernAuthRpc
BlockModernAuthWebServices

Después de instalar CU13 o posterior, cualquier directiva de autenticación preexistente (incluida la directiva de autenticación predeterminada) tiene los parámetros deshabilitados. Esto significa que, si ya usa HMA, no es necesario cambiar las directivas de autenticación preexistemas.

No se requiere ninguna nueva directiva de autenticación para Exchange Hybrid

Las configuraciones híbridas existentes de Exchange deben usar la autenticación moderna híbrida (HMA). Las instalaciones híbridas que usan HMA pueden dejar los valores de los BlockModernAuth* parámetros en 0 para continuar usando HMA. Los pasos descritos para configurar la autenticación moderna con ADFS solo son pertinentes para las organizaciones que no usan Exchange Hybrid y son puramente locales.

Configuración de Servicios de federación de Active Directory (AD FS) (ADFS)

Debe instalar y configurar ADFS en el entorno para permitir que los clientes de Exchange usen la autenticación de Forms (OAuth) para conectarse a Exchange Server. Consulte lista de comprobación: Configuración de un servidor de federación para ayudar con la configuración de ADFS.

La característica ADFS se puede instalar ejecutando el siguiente comando desde una ventana de PowerShell con privilegios elevados en el nuevo servidor que se convierte en el servidor de ADFS:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Requisitos de certificado para la configuración de ADFS en Exchange Server organización

ADFS requiere dos tipos básicos de certificados (consulte este artículo para obtener información detallada):

Certificado SSL (Capa de sockets seguros) de comunicación de servicio para el tráfico de servicios web cifrados entre el servidor ADFS, los clientes, los servidores exchange y el servidor web Application Proxy opcional. Se recomienda usar un certificado emitido por una entidad de certificación (CA) interna o comercial, ya que todos los clientes deben confiar en este certificado.
Certificado de firma de tokens para la comunicación cifrada y la autenticación entre el servidor ADFS, los controladores de dominio de Active Directory y los servidores de Exchange. Para obtener un certificado de firma de token, solicite uno de una entidad de certificación o cree un certificado autofirmado.

Para obtener más información sobre cómo crear e importar certificados SSL en Windows, consulte Certificados de servidor.

Este es un resumen de los certificados que usamos en este escenario:

Nombre común (CN) en el certificado (en el firmante, nombre alternativo del firmante o coincidencia de certificado comodín)	Tipo	Obligatorio en los servidores	Comentarios
adfs.contoso.com enterpriseregistration.contoso.com	Emitido por una entidad de certificación	Servidor ADFS, Servidor de Application Proxy web (opcional)	Los servidores de federación usan un certificado SSL para proteger el tráfico de servicios web para la comunicación SSL con clientes y con servidores proxy de servidor de federación. Como el certificado SSL debe ser de confianza para los equipos cliente, le recomendamos que use un certificado firmado por una entidad de certificación de confianza. Todos los certificados que seleccione deben tener su clave privada correspondiente.
Firma de token de ADFS: adfs.contoso.com	Autofirmado o problema por una ENTIDAD de certificación	Servidor ADFS, Servidor de Application Proxy web (opcional)	Un certificado de firma de token es un certificado X509. Los servidores de federación usan pares de claves públicas y privadas asociadas para firmar digitalmente todos los tokens de seguridad que generan. Este proceso incluye la firma de metadatos de federación publicados y solicitudes de resolución de artefactos. Puede tener varios certificados de firma de tokens configurados en el complemento Administración de ADFS para permitir la sustitución de certificados cuando un certificado está a punto de expirar. De forma predeterminada, todos los certificados de la lista se publican, pero ADFS solo usa el certificado de firma de tokens principal para firmar tokens realmente. Todos los certificados que seleccione deben tener su clave privada correspondiente. Para obtener un certificado de firma de token, solicite uno de una entidad de certificación empresarial o una entidad de certificación pública o cree un certificado autofirmado.
mail.contoso.com autodiscover.contoso.com	Emitido por una entidad de certificación	Servidores de Exchange, Servidor de Application Proxy web (opcional)	Este certificado es el certificado típico que se usa para cifrar las conexiones de cliente externas a Outlook en la Web (y otros servicios de Exchange). Para obtener más información, vea Requisitos de certificados para los servicios de Exchange.

Implementación y configuración del servidor ADFS

Use Windows Server 2019 o posterior para implementar un servidor ADFS. Siga los pasos descritos en Implementación de un servidor ADFS y Configuración y prueba de la documentación del servidor ADFS . Asegúrese de que se puede acceder a la dirección URL de metadatos de federación en un explorador web desde el servidor Exchange y al menos un equipo cliente.

La dirección URL usa esta sintaxis: https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

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

Configuración del método de autenticación en ADFS

Para usar la autenticación moderna en Outlook en Windows, debe configurar .Primary Authentication Methods Se recomienda elegir Forms Authentication tanto para como ExtranetIntranetpara . Esta configuración se puede realizar mediante la ejecución de los siguientes comandos desde una ventana de PowerShell en el servidor ADFS:

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

Elección de la duración del inicio de sesión único adecuada

Elija una duración de single Sign-On (SSO) adecuada para que los usuarios finales no necesiten volver a autenticarse con frecuencia. Para validar la configuración actual de duración del inicio de sesión único, abra una nueva ventana de PowerShell en el servidor de ADFS y ejecute el siguiente comando:

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

Use el cmdlet Set-AdfsProperties para configurar los valores adecuados para SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMinsy DeviceUsageWindowInDays. Esta configuración debe ajustarse para habilitar el inicio de sesión único y definir su expiración. En función del modo sso, como Keep Me Signed In (KMSI) o Device registration, también es posible que tenga que habilitar KsmiEnabled y PersistentSsoEnabled. Puede encontrar más detalles sobre el inicio de sesión único de ADFS en la documentación de configuración de Inicio de sesión único de AD FS 2016.

Configuración del registro de dispositivos en ADFS

Se recomienda habilitar la Device Registration característica en ADFS para beneficiarse de una experiencia de INICIO de sesión único mejorada. Para habilitar Device Registration, siga los pasos descritos en la documentación Configurar un servidor de federación con el servicio de registro de dispositivos .

A continuación, complete todos los pasos para configurar Device Registration Service Discovery y , Device Registration Discovery Server SSL certificatecomo se describe en la documentación configuración del registro de dispositivos .

Para usar el registro de dispositivos, los usuarios finales deben unir su dispositivo a un área de trabajo. Puede encontrar más detalles en las siguientes documentación:

Compruebe que el registro de dispositivos está configurado y que la autenticación de dispositivos está habilitada comprobando .Device Registration Overview Este paso se recomienda para reducir el número de solicitudes de autenticación para los usuarios y puede ayudar a aplicar directivas de Access Control en ADFS.

Configuración de KSMI en ADFS

Si prefiere no usar Device Registration o no puede hacerlo, puede habilitar la Keep Me Signed In característica en su lugar. ADFS crea una cookie persistente inmediatamente después de la autenticación del usuario, lo que elimina la necesidad de volver a autenticarse en sesiones posteriores, siempre que la cookie siga siendo válida.

El tiempo de expiración del token de actualización es igual a la duración de la cookie de SSO persistente para Keep me signed in. La duración de la cookie de SSO persistente es de un día de forma predeterminada, con un máximo de siete días. De lo contrario, la duración del token de actualización es igual a la duración de la cookie de SSO de sesión (8 horas de forma predeterminada). Puede encontrar más información sobre KSMI en la documentación de configuración de inicio de sesión único de AD FS .

KMSI está deshabilitado de forma predeterminada y se puede habilitar estableciendo la propiedad KmsiEnabled ADFS en True. Asegúrese de ejecutar los pasos siguientes desde una ventana de PowerShell en el servidor de ADFS:

Set-AdfsProperties -EnableKmsi $true

Con KMSI deshabilitado, el período de inicio de sesión único predeterminado es 8 hours. El período de inicio de sesión único se puede configurar mediante la propiedad SsoLifetime. La propiedad se mide en minutos, por lo que su valor predeterminado es 480:

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

Con KMSI habilitado, el período de inicio de sesión único predeterminado es 24 hours. El período de inicio de sesión único con KMSI habilitado se puede configurar mediante la propiedad KmsiLifetimeMins. La propiedad se mide en minutos, por lo que su valor predeterminado es 1440:

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

Creación del grupo de aplicaciones de Outlook de ADFS

Si es la primera vez que configura la autenticación moderna de ADFS en Exchange local, siga los pasos de esta sección de la guía. Si tiene una configuración de autenticación moderna de ADFS existente que se configuró antes de la compatibilidad con clientes distintos Microsoft Outlook for Windowsde , consulte los pasos descritos en la sección Actualizar el grupo de aplicaciones de Outlook de ADFS existente de esta documentación. Los siguientes comandos de PowerShell deben ejecutarse desde una ventana de PowerShell en el servidor de ADFS. Si no tiene previsto usar aplicaciones de iOS y macOS, como la aplicación nativa de Apple Mail, puede omitir la creación de la aplicación cliente nativa de ADFS para iOS y macOS. Sin embargo, se recomienda crearlos en aras de la integridad.

En primer lugar, vamos a crear :ADFS Application Group

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

A continuación, creamos tres más Scopes - EAS.AccessAsUser.Ally : EWS.AccessAsUser.Alloffline_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"

Ahora, vamos a crear dos Native Client Applications - Outlook - Native application y :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 paso siguiente, creamos Web Api Applications. Creamos una aplicación por URI que se usa en el entorno de Exchange Server. Si usa, por ejemplo, autodiscover.contoso.com y mail.contoso.com, debe crear dos Web Api Applications. Asegúrese de reemplazar los URI del ejemplo siguiente por los URI que se usan en la configuración. Es importante asegurarse de que todos los URI orientados al cliente estén cubiertos. Incluya el final / y asegúrese de que los URI empiecen por 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 paso, agregamos los permisos de Native Client Applications cliente para todos en el elemento Web Api Applicationsexistente:

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

Actualizar el grupo de aplicaciones de Outlook de ADFS existente

Importante

Omita los pasos de esta sección si no tiene un grupo de aplicaciones de Outlook de ADFS existente, que se configuró antes de la compatibilidad con clientes distintos de Microsoft Outlook for Windows los que se introdujeron.

Si tiene una configuración de grupo de aplicaciones de Outlook de ADFS existente, que se configuró antes de que se introdujera la compatibilidad con clientes distintos Microsoft Outlook for Windows de los que se introdujeron, siga estos pasos para habilitar la compatibilidad con otras plataformas. Los siguientes comandos de PowerShell deben ejecutarse desde una ventana de PowerShell en el servidor de ADFS.

En primer lugar, vamos a crear tres adicionales Scopes - EAS.AccessAsUser.Ally : EWS.AccessAsUser.Alloffline_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"

Ahora, vamos a crear un nuevo 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/")

Actualizamos el existente Native Client Application - Outlook - Native application. Asegúrese de reemplazar por TargetName el nombre de destino que usa en la configuración 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 paso siguiente, debemos crear uno Web Api Application para cada Identifier (URI) que se usa en el entorno de Exchange Server y existe en la configuración de autenticación moderna de ADFS actual:

$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 paso, agregamos los permisos de Native Client Applications cliente para todos en el elemento Web Api Applicationsexistente:

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

Eliminación del grupo de aplicaciones de Outlook de ADFS existente

Precaución

Siguiendo los pasos de esta sección se quita la configuración existente del grupo de aplicaciones de Outlook de ADFS.

Si tiene una configuración de grupo de aplicaciones de Outlook de ADFS existente y desea quitarla, siga estos pasos para eliminar la configuración existente. Todos los siguientes comandos de PowerShell deben ejecutarse desde una ventana de PowerShell en el servidor de ADFS.

En primer lugar, vamos a eliminar :ADFS Application Group

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

Como último paso, eliminamos la personalizada Scopes que se agregó:

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

(Opcional) La configuración de Application Proxy web se puede configurar para El acceso a extranet

La Application Proxy web forma parte del rol de servidor de acceso remoto en Windows Server. Proporciona funcionalidad de proxy inverso para permitir que los usuarios accedan a las aplicaciones web desde fuera de la red corporativa. La Application Proxy web autentica previamente el acceso a las aplicaciones web mediante ADFS y funciona como un proxy de ADFS.

Si tiene previsto usar el proxy de aplicación web, siga los pasos que se mencionan en Instalación y configuración del servidor de Application Proxy web para configurarlo. Una vez configurado, puede publicar reglas para Autodiscover.contoso.com o mediante mail.contoso.com los pasos mencionados en Publicar una aplicación que usa OAuth2.

(Opcional) Configuración de MFA para el acceso de cliente

Consulte los vínculos siguientes para configurar ADFS con un proveedor de MFA que prefiera.
- Configuración de proveedores de autenticación de terceros como autenticación principal en AD FS 2019
- Configuración de Azure MFA como proveedor de autenticación con AD FS
Configurar Access Control directiva que requiere MFA.
- Directivas de Access Control en Windows Server 2016 AD FS

Crear directivas de autenticación para usuarios finales

Es posible que no todos los usuarios de su organización tengan clientes de correo electrónico que admitan autenticación moderna a través de ADFS. En este escenario, se recomienda habilitar la autenticación moderna para los usuarios con clientes compatibles y bloquearla para esos usuarios sin.

Para habilitar la autenticación moderna para un conjunto específico de usuarios y bloquearla para el resto de usuarios, debe crear al menos dos directivas de autenticación.

Importante

Las nuevas directivas de autenticación estarán disponibles en cuanto Active Directory esté preparado mediante los medios de Exchange 2019 CU13 o posteriores.

Una directiva de toda la organización para bloquear la autenticación moderna de forma predeterminada
Una directiva secundaria para permitir selectivamente la autenticación moderna para usuarios específicos

Los siguientes comandos de PowerShell se deben ejecutar desde una ventana del Shell de administración de Exchange (EMS) en el servidor exchange.

Creación de una directiva de nivel de organización para bloquear la autenticación moderna de forma predeterminada

Una vez habilitada la autenticación moderna, todos los clientes de Outlook intentan usar tokens de OAuth. Sin embargo, algunos clientes que no son compatibles con la autenticación moderna de ADFS solo pueden recuperar tokens de OAuth de Microsoft Entra ID. Por lo tanto, estos clientes no pueden conectarse si la autenticación moderna está habilitada.

Para evitar este escenario, puede implementar una directiva de toda la organización para deshabilitar la autenticación moderna. En el ejemplo, creamos una nueva directiva de autenticación denominada Block Modern Auth.

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

Esta directiva se puede establecer en el nivel de organización mediante el siguiente comando.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

Creación de una directiva de autenticación de nivel de usuario para habilitar la autenticación moderna

A continuación, cree una segunda directiva de autenticación que habilite la autenticación moderna. Asigne esta directiva a todos los usuarios con clientes de Outlook compatibles para permitir que sus clientes usen la autenticación moderna.

En el ejemplo, se crea una nueva autenticación denominada Allow Modern Auth mediante el siguiente comando:

New-AuthenticationPolicy "Allow Modern Auth"

Configuración de Exchange Server para usar tokens de OAuth de ADFS

Compruebe si OAuth está habilitado en los siguientes directorios virtuales. Si no está habilitado, habilítelo OAuth para todos estos directorios virtuales:
```
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*
```
La salida aparece como sigue. El detalle principal en el que se debe centrarse es OAuth, como se mencionó anteriormente:
```
Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
```
Si OAuth falta en cualquier servidor o en cualquiera de los cinco directorios virtuales, debe agregarlo mediante los comandos pertinentes antes de continuar: Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OabVirtualDirectory, Set-AutodiscoverVirtualDirectory y Set-ActiveSyncVirtualDirectory.
Ejecute el siguiente comando:
```
New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml
```
Este comando es necesario para crear un nuevo objeto de servidor de autenticación en Exchange Server para ADFS. Los objetos de servidor de autenticación son una lista de emisores de confianza. Solo se aceptan los tokens de OAuth de estos emisores.
Ejecute el siguiente comando:
```
Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true
```
Establezca el servidor de autenticación que acabamos de agregar como DefaultAuthorizationEndpoint. Al anunciar el encabezado De autenticación moderna, Exchange Server anuncia la dirección URL de autenticación de DefaultAuthorizationEndpoint. Así es como los clientes saben qué punto de conexión usar para la autenticación.
Es necesario ejecutar este comando para habilitar la autenticación moderna en el nivel de organización:
```
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
```
Habilite la autenticación moderna para los usuarios con clientes admitidos mediante la asignación de la Allow Modern Auth directiva de autenticación:
```
Set-User -Identity User -AuthenticationPolicy "Allow Modern Auth"
```

Client-Side configuración de autenticación moderna

Se recomienda probar la autenticación moderna con pocos usuarios antes de implementarla en todos los usuarios. Una vez que un grupo piloto de usuarios puede usar la autenticación moderna, se pueden implementar más usuarios. Valide que el cliente admite la autenticación moderna de ADFS. Puede encontrar más detalles sobre los clientes admitidos en la sección Requisitos previos del cliente .

Microsoft Windows

Habilite autenticación moderna y agregue el dominio de ADFS como dominio de confianza en Outlook:

Cree las siguientes claves del Registro para convertir el dominio de ADFS en un dominio de confianza. Asegúrese de agregar ambas claves con y sin / al final del dominio de 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
Puede usar PowerShell para crear las claves del Registro o implementarlas con la ayuda de un directiva de grupo. Ejecute los siguientes comandos desde una ventana de PowerShell en cada equipo cliente. Reemplace por your-ADFS-domain el dominio de 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 habilitar la autenticación moderna de ADFS en, agregue el EnableExchangeOnPremModernAuthvalor en Microsoft Outlook for WindowsHKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\.REG_DWORD

Puede usar PowerShell para crear el valor del Registro o implementarlo a través de un directiva de grupo. Ejecute el siguiente comando desde una ventana de PowerShell en cada equipo cliente.
```
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord
```

Apple macOS

Para habilitar la autenticación moderna para Microsoft Outlook en las versiones compatibles de MacOS de Apple, debe modificar las preferencias de la aplicación Microsoft Outlook.

Abra una ventana terminal y ejecute el siguiente comando, reemplazando host1 por el FQDN del servidor de ADFS. Asegúrese de no incluir el protocolo ni de agregar barras diagonales al final del FQDN. Por ejemplo, si el servidor de ADFS es accesible a través de https://fs.contoso.com/, use fs.contoso.com. Si tiene varios espacios de nombres de ADFS, agréguelos separados por un espacio.

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

En el caso de los dispositivos administrados, los administradores pueden usar una solución de mobile Administración de dispositivos (MDM) para administrar e insertar de forma centralizada una lista de FQDN de ADFS en los dispositivos cliente. En la tabla siguiente se describen los valores de configuración necesarios para controlar esta característica a través de MDM:

Configuraciones	Valores
Aplicación de destino	`Outlook Mac`
Clave de configuración	`trustedauthorities`
Tipo de valor	`String`
Valor de configuración	`<ADFS FQDNs>`

Comprobación del flujo de autenticación moderna

Una vez configurado correctamente, los usuarios experimentan el símbolo del sistema de inicio de sesión de ADFS cuando se conectan a un servidor exchange.

Efecto en otros clientes cuando la autenticación moderna está habilitada

Los usuarios habilitados para la autenticación moderna que usan varios clientes (por ejemplo, Outlook on Windows y Outlook Mobile) experimentan comportamientos diferentes en cada cliente. En el siguiente resumen se describen los comportamientos del cliente cuando está habilitada la autenticación moderna, suponiendo que Block Modern Auth se aplica como DefaultAuthenticationPolicy en el nivel de organización.

Cliente	Comportamiento
Outlook para Windows (clásico)	Usa autenticación moderna de forma predeterminada.
Outlook para Windows (nuevo)	Intenta usar la autenticación moderna, pero produce un error.
Outlook para Mac	Usa autenticación moderna si está habilitada en el cliente.
Outlook iOS	Vuelve a la autenticación básica.
Outlook Android	Vuelve a la autenticación básica.
Aplicación de correo de iOS	Usa la autenticación moderna.
aplicación de correo de macOS	Usa la autenticación moderna.
Aplicación gmail	Vuelve a la autenticación básica.
OWA/ECP	No usa la directiva de autenticación. En función de cómo se configure, usa autenticación moderna o autenticación básica.
Aplicación de Correo de Windows	No vuelve a la autenticación básica.
Cliente de Thunderbird	No vuelve a la autenticación básica.
PowerShell	Usa la autenticación básica.

Efecto en OWA/ECP cuando la autenticación moderna está habilitada para otros clientes

Puede usar o no la autenticación basada en notificaciones de ADFS para Outlook en la Web. Los pasos mencionados son necesarios para habilitar OAuth para otros clientes y no afectan a cómo se configura OWA/ECP.

Uso de la autenticación basada en notificaciones de AD FS con Outlook en la Web

Tiempo de espera después de cambiar la directiva de autenticación

Después de cambiar la directiva de autenticación para permitir la autenticación moderna o bloquear la autenticación heredada:

Espere 30 minutos para que los servidores front-end lean las nuevas directivas.

o
Realice un restablecimiento de IIS en todos los servidores front-end.

Migración a la autenticación moderna híbrida después de habilitar la autenticación moderna para Exchange Server

Si usa autenticación moderna con ADFS y, posteriormente, decide configurar Exchange Hybrid, debe realizar la transición a Autenticación moderna híbrida. Los pasos de migración detallados se incluirán en una versión futura de este documento.

Renovación de certificados

Evaluación de la configuración actual del certificado

En lo que respecta a las conexiones de cliente a Exchange Server, el certificado que se debe evaluar es el enlazado al sitio de IIS de front-end. Para un servidor ADFS, es ideal asegurarse de que todos los certificados devueltos en Get-AdfsCertificate son actuales.

Para identificar el certificado pertinente en un Exchange Server, realice lo siguiente en el Shell de administración de 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 revisar los certificados activos en un servidor ADFS, realice lo siguiente en PowerShell:
```
Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap
```

Actualización de certificados en Exchange Server

Si se ha detectado que el certificado de Exchange debe actualizarse para la conectividad de cliente, se debe emitir e importar un nuevo certificado en los servidores de Exchange. Después, el certificado debe habilitarse para IIS como mínimo. Evalúe si se deben habilitar otros servicios para el nuevo certificado en función de la configuración.

Ejemplo de creación, finalización, habilitación e importación de un nuevo certificado en todos los servidores en función del certificado existente en el Shell de administración de Exchange:

Genere una nueva solicitud de certificado en el Shell de administración de Exchange en función del certificado existente:

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

Stage a variable que contiene la ruta de acceso de salida deseada de la nueva solicitud de certificado:
```
$requestFile = "C:\temp\CertRequest.req"
```
Cree el archivo de solicitud de certificado:
```
[System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))
```
Nota:

La ruta de acceso de la carpeta para la solicitud de certificado ya debe existir.
Comparta el archivo de solicitud con la entidad de certificación (CA). Los pasos necesarios para obtener un certificado completado varían en función de la entidad de certificación.

Nota:

.p7b es el formato preferido para la solicitud completada.
Stage a variable que contiene la ruta de acceso completa de la solicitud completada:
```
$certFile = "C:\temp\ExchangeCert.p7b"
```

Importe la solicitud en el servidor que generó originalmente la solicitud:

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

Variable de fase de la contraseña para proteger el certificado completado:
```
$pw = Read-Host "Enter password" -AsSecureString
```

Exporte el archivo binario del certificado en una variable:

$binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

Variable de fase para la ruta de acceso de salida deseada del certificado completado:
```
$certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"
```
Exporte la solicitud completada que se va a importar en otros servidores:
```
[System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)
```
Habilite los servicios que deben enlazarse al certificado:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS
```
Nota:

Es posible que tenga que agregar más servicios al ejemplo anterior en función de la configuración de los certificados anteriores.
Para validar que el certificado funciona según lo previsto, dirija un cliente al servidor para todos los espacios de nombres de cliente con un archivo host.
Importe el certificado de Exchange en todos los demás servidores de Exchange:
```
Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>
```
Nota:

Incluir el -PrivateKeyExportable parámetro es opcional al importar a otros servidores de Exchange.
Habilite el certificado de Exchange para los servicios de Exchange necesarios en todos los demás servidores de Exchange:
```
Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>
```
Nota:

Es posible que tenga que agregar más servicios al ejemplo anterior en función de la configuración de los certificados anteriores.

Actualización del certificado en ADFS

Dependiendo del tipo de certificado que requiere actualización en ADFS, determina si necesita seguir los pasos que se describen a continuación.

certificado de Service-Communications

En este ejemplo se proporciona el powershell necesario para importar un certificado en .pfx formato, como el generado siguiendo los pasos del certificado de Exchange Server. Asegúrese de que ha iniciado sesión en el servidor ADFS principal.

Stage a variable que contiene la contraseña del certificado:
```
$pw = Read-Host "Enter password" -AsSecureString
```
Stage a variable que contiene la ruta de acceso completa para el certificado:
```
$certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"
```

Importe el certificado en el almacén personal de LocalMachine:

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

Actualice el certificado de Service-Communications:
```
Set-AdfsSslCertificate -Thumbprint <Thumbprint>
```

certificados de Token-Signing y Token-Decryption

Siga los pasos descritos en la documentación Obtención y configuración de certificados TS y TD para AD FS .

Nota:

El uso del certificado autofirmado predeterminado para Token-Signing en la autenticación basada en notificaciones de ADFS para Outlook en la Web requiere que el certificado se instale en los servidores de Exchange.

Compartir a través de