Preguntas más frecuentes (P+F) sobre AD FS

Puede actualizar o migrar AD FS siguiendo los pasos descritos en uno de los siguientes artículos vinculados:

• De AD FS en Windows Server 2012 R2 a AD FS en Windows Server 2016 o posterior. (El proceso es el mismo si va a actualizar desde AD FS en Windows Server 2016 a AD FS en Windows Server 2019).
  • Actualización a AD FS en Windows Server 2016 mediante una base de datos WID
  • Actualización a AD FS en Windows Server 2016 mediante una base de datos SQL
• De AD FS en Windows Server 2012 a AD FS en Windows Server 2012 R2:
  • Migración a AD FS en Windows Server 2012 R2
• De AD FS 2.0 a AD FS en Windows Server 2012:
  • Migración a AD FS en Windows Server 2012
• De AD FS 1.x a AD FS 2.0:
  • Actualización de AD FS 1.x a AD FS 2.0

Si necesita realizar una actualización de AD FS 2.0 o 2.1 (Windows Server 2008 R2 o Windows Server 2012), debe usar los scripts integrados que se encuentran en C:\Windows\ADFS.

La compatibilidad con HTTP/2 se agregó en Windows Server 2016, pero HTTP/2 no se puede usar para la autenticación de certificado de cliente. Muchos escenarios de AD FS usan la autenticación de certificados de cliente. Asimismo, muchos clientes no admiten el reintento de solicitudes mediante HTTP/1.1. Por lo tanto, la configuración de granja de AD FS vuelve a configurar los parámetros HTTP del servidor local en HTTP/1.1. Esta reconfiguración requiere que se reinicie el servidor.

Esta configuración se admite; sin embargo, no se admitirían nuevas características de AD FS 2016. Esta configuración está pensada para ser temporal durante la fase de migración de AD FS 2012 R2 a AD FS 2016. Por lo tanto, no debe implementarse durante largos períodos de tiempo.

Sí, pero se encontrará con los siguientes inconvenientes:

• Tendrá que administrar manualmente la actualización de los certificados de firma de tokens, ya que Azure AD no podrá acceder a los metadatos de federación. Para obtener más información sobre cómo actualizar manualmente el certificado de firma de tokens, consulte Renovación de los certificados de federación para Office 365 y Azure Active Directory.
• No podrá usar flujos de autenticación heredados (por ejemplo, el flujo de autenticación del proxy exO).

AD FS es un sistema sin estado, por lo que el equilibrio de carga es bastante sencillo para los inicios de sesión. Estas son algunas recomendaciones clave para los sistemas de equilibrio de carga:

• Los equilibradores de carga no deben configurarse con afinidad de IP. La afinidad de IP puede suponer una carga innecesaria en un subconjunto de los servidores en ciertos escenarios de Exchange Online.
• Asimismo, los equilibradores de carga no deben terminar las conexiones HTTPS y volver a iniciar una nueva conexión con el servidor de AD FS.
• En su lugar, los equilibradores de carga deben garantizar que la dirección IP de conexión se traduzca como la IP de origen en el paquete HTTP cuando se envía a AD FS. Si un equilibrador de carga no puede enviar la IP de origen en el paquete HTTP, este debe agregar la dirección IP al encabezado denominado X-Forwarded-For. Este paso es necesario para controlar correctamente determinadas características relacionadas con la IP (como IP prohibidas y el bloqueo inteligente de la extranet). Si esta configuración no se implementa correctamente, se podría reducir la seguridad.
• Los equilibradores de carga deben admitir SNI. Si no lo hacen, asegúrese de que AD FS está configurado para crear enlaces HTTPS para controlar los clientes que no admiten SNI.
• Los equilibradores de carga deben usar el punto de conexión de sondeo de estado HTTP de AD FS para detectar si los servidores de AD FS o del Proxy de aplicación web están en ejecución. Debe excluirlos si no se devuelven 200 estados correctos.

AD FS admite distintas configuraciones de varios bosques. Asimismo, se basa en la red de confianza de AD DS subyacente para autenticar a los usuarios en varios dominios de confianza. Se recomienda encarecidamente que use las confianzas de bosques bidireccionales porque son más fáciles de configurar, lo que le permitirá garantizar que el sistema de confianza funciona correctamente.

Además:

• Si tiene una confianza de bosque unidireccional, como un bosque de red perimetral (también conocido como DMZ) que contiene identidades de asociados, le recomendamos que implemente AD FS en el bosque de empresa. Trate el bosque de la red perimetral como otro proveedor de notificaciones local de confianza conectado a través de LDAP. En este caso, la autenticación integrada de Windows no funcionará para los usuarios del bosque de la red perimetral. En su lugar deberán utilizar la autenticación de contraseña porque es el único mecanismo compatible con LDAP.

  Si no puede usar esta opción, debe configurar otro servidor de AD FS en el bosque de red perimetral. Agréguelo como una confianza de proveedor de notificaciones en el servidor de AD FS del bosque de empresa. Los usuarios deberán realizar la detección del dominio de inicio, pero tanto la autenticación integrada de Windows como la autenticación de contraseña funcionarán. Realice los cambios adecuados en las reglas de emisión de AD FS en el bosque de la red perimetral, ya que AD FS en el bosque de empresa no podrá obtener más información sobre los usuarios del bosque de la red perimetral.

• Se admiten las confianzas de nivel de dominio, ya que pueden funcionar. Aún así, le recomendamos encarecidamente que cambie a un modelo de confianza a nivel de bosque. También deberá asegurarse de que el enrutamiento UPN y la resolución de nombres NetBIOS funcionen correctamente.

Sí, se aceptan direcciones IPv6 de ubicaciones conocidas o desconocidas.

AD FS proporciona un mecanismo extensible para que los proveedores de autenticación multifactor de terceros se integren. No hay ningún programa de certificación establecido para ello. Se supone que el proveedor ha realizado las validaciones necesarias antes del lanzamiento.

La lista de proveedores que han notificado a Microsoft está disponible aquí: Proveedores de autenticación multifactor para AD FS. Aún así, puede haber proveedores disponibles que no conozcamos. Actualizaremos la lista a medida que detectemos otras nuevas.

Sí, los proxies de terceros se pueden colocar delante de AD FS, pero cualquier proxy de terceros debe admitir el uso del protocolo MS-ADFSPIP en lugar del Proxy de aplicación web.

Actualmente, conocemos los siguientes proveedores de terceros. Aún así, puede haber proveedores disponibles que no conozcamos. Actualizaremos esta lista a medida que detectemos otros nuevos.

• Administrador de directivas de acceso de F5
• Controlador de entrega de aplicaciones (ADC) de Citrix

Puede descargar la versión de AD FS 2016 de la hoja de cálculo. También puede usar esta hoja de cálculo para AD FS en Windows Server 2012 R2.

Apple ha publicado un conjunto de requisitos denominado Seguridad de transporte de aplicaciones (ATS) que pueden afectar a las llamadas de las aplicaciones de iOS que se autentican en AD FS. Para asegurarse de que los servidores de Proxy de aplicación web y AD FS son válidos, compruebe que admitan los requisitos para la conexión mediante ATS. En concreto, debe comprobar que:

• Los servidores de AD FS y el Proxy de aplicación web admiten TLS 1.2.
• El conjunto de cifrado negociado de la conexión TLS admitirá la confidencialidad directa perfecta.

Para obtener información sobre cómo habilitar y deshabilitar SSL 2.0 y 3.0 y TLS 1.0, 1.1 y 1.2, consulte Administrar protocolos SSL en AD FS.

Para asegurarse de que los servidores de Proxy de aplicación web y AD FS negocian solo los conjuntos de cifrado TLS que admiten ATP, puede deshabilitar todos los conjuntos de cifrado que no estén en la lista de conjuntos de cifrado compatibles con ATP. Para ello, use los cmdlets de PowerShell de TLS de Windows.

El valor de la notificación "sub" es el hash del id. de cliente y el valor de la notificación de delimitador.

La duración del token de actualización será la del token que AD FS recibió de la relación de confianza del proveedor de notificaciones remotas. A su vez, la duración del token de acceso será la del token del usuario de confianza para el que se emite el token de acceso.

Puede usar el elemento id_token personalizado para agregar información pertinente en el propio elemento id_token. Para obtener más información, consulte el artículo Personalización de notificaciones para que se emitan en id_token.

Se agregó un valor ValueType especial (http://www.w3.org/2001/XMLSchema#json) y un carácter de escape (\x22) para este escenario en AD FS 2016. Utilice los siguientes ejemplos para ver la regla de emisión y el resultado final del token de acceso.

Ejemplo de regla de emisión:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

Notificaciones emitidas en el token de acceso:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Con AD FS en Windows Server 2019, ahora puede pasar el valor del recurso insertado en el parámetro de ámbito. El parámetro de ámbito se puede organizar como una lista separada por espacios en la que cada entrada está estructurada como recurso/ámbito.

AD FS en Windows Server 2019 admite la clave de prueba para el intercambio de código (PKCE) para el flujo de concesión de código de autorización de OAuth.

Compatible:

• aza. Si se usan las extensiones de protocolo de OAuth 2.0 para los clientes de agente y el parámetro de ámbito contiene el ámbito "aza", el servidor emite un nuevo token de actualización principal y lo establece en el campo refresh_token de la respuesta. Además, establece el campo refresh_token_expires_in en la duración del nuevo token de actualización principal, si se aplica uno.
• openid. Permite que la aplicación solicite el uso del protocolo de autorización OpenID Connect.
• logon_cert. Permite a una aplicación solicitar certificados de inicio de sesión, que se pueden usar para iniciar sesión de forma interactiva de usuarios autenticados. El servidor de AD FS omite el parámetro access_token de la respuesta y, en su lugar, proporciona una cadena de certificados CMS codificada en Base 64 o una respuesta de PKI completa de CMC. Para obtener más información, consulte Instrucciones de procesamiento.
• user_impersonation. Es obligatorio si quiere solicitar un token de acceso en nombre del usuario de AD FS. Para obtener más información sobre cómo usar este ámbito, consulte Compilación de una aplicación de varios niveles usando "en nombre de" (OBO) mediante OAuth con AD FS 2016.

No compatible:

• vpn_cert. Permite a una aplicación solicitar certificados VPN, que se pueden usar para establecer conexiones VPN mediante la autenticación EAP-TLS. Este ámbito ya no se admite.
• email. Permite que la aplicación solicite una notificación por correo electrónico para el usuario que ha iniciado sesión. Este ámbito ya no se admite.
• profile. Permite que la aplicación solicite una notificación relacionada con el perfil del usuario que ha iniciado sesión. Este ámbito ya no se admite.

El certificado SSL de AD FS no es el mismo que el certificado de comunicaciones del servicio AD FS que se encuentra en el complemento Administración de AD FS. Para cambiar el certificado SSL de AD FS, debe usar PowerShell. Siga los detalles que encontrará en Administración de certificados SSL en AD FS y WAP 2016.

Para obtener información sobre cómo deshabilitar y habilitar protocolos SSL y conjuntos de cifrado, consulte Administración de protocolos SSL en AD FS.

• Si el proxy se usa para redirigir mediante proxy las solicitudes de AD FS que usan la autenticación integrada de Windows, el certificado SSL del proxy debe usar la misma clave que el certificado SSL del servidor de federación.
• Si la propiedad ExtendedProtectionTokenCheck de AD FS está habilitada (la configuración predeterminada en AD FS), el certificado SSL del proxy debe usar la misma clave que el certificado SSL del servidor de federación.
• De lo contrario, el certificado SSL de proxy puede tener una clave diferente de la del certificado SSL de AD FS. En cambio, debe cumplir los mismos requisitos.

AD FS solo muestra un método de autenticación en la pantalla de inicio de sesión cuando la aplicación requiere explícitamente un URI de autenticación específico que se asigna a un método de autenticación configurado y habilitado. El método se transmite en el parámetro wauth en las solicitudes de WS-Federation. Se transmite en el parámetro RequestedAuthnCtxRef en las solicitudes del protocolo SAML. Solo se muestra el método de autenticación solicitado. (Por ejemplo, inicio de sesión con contraseña).

Cuando AD FS se utiliza con Azure AD, es habitual que las aplicaciones envíen el parámetro prompt=login a Azure AD. Por este motivo, Azure AD traduce de forma predeterminada este parámetro para que solicite un inicio de sesión nuevo basado en contraseña en AD FS. Este escenario es la razón más común por la que puede ver un inicio de sesión con contraseña en AD FS en su red o no ver una opción para iniciar sesión con su certificado. Puede resolver fácilmente este problema realizando un cambio en la configuración del dominio federado en Azure AD.

Para obtener más información, consulte Compatibilidad con el parámetro prompt=login de Servicios de federación de Active Directory.

Para cambiar la cuenta de servicio de AD FS, consulte el cuadro de herramientas de AD FS del Módulo de PowerShell de la cuenta de servicio. Para obtener instrucciones, consulte Cambiar la cuenta del servicio AD FS.

Consulte Configuración de los exploradores para usar la Autenticación integrada de Windows (WIA) con AD FS.

Si no tiene directivas de control de acceso basadas en el dispositivo en AD FS o en la inscripción de certificado de Windows Hello para empresas mediante AD FS; puede desactivar el valor BrowserSsoEnabled. El valor BrowserSsoEnabled permite que AD FS recopile un token de actualización principal (PRT) del cliente que contiene información del dispositivo. Sin ese token, la autenticación del dispositivo de AD FS no funcionará en dispositivos Windows 10.

A menudo, los administradores se preguntan durante cuánto tiempo pueden usar los usuarios el inicio de sesión único (SSO) sin tener que escribir nuevas credenciales y cómo pueden hacer que los administradores controlen ese comportamiento. Este comportamiento y los valores de configuración que lo controlan se describen en el artículo Configuración de inicio de sesión único de AD FS.

A continuación, se enumeran las duraciones predeterminadas de las distintas cookies y los tokens (así como los parámetros que rigen las duraciones):

Dispositivos registrados

• Cookies de SSO y PRT: 90 días como máximo, regidas por PSSOLifeTimeMins. (Si el dispositivo se usa al menos cada 14 días. Esta ventana de tiempo se controla mediante DeviceUsageWindow).

• Token de actualización: se calcula en función de los parámetros anteriores para proporcionar un comportamiento coherente.

• access_token: una hora de forma predeterminada, según el usuario de confianza.

• id_token: igual que el token de acceso (access_token).

Dispositivos no registrados

• Cookies de SSO: ocho horas de forma predeterminada, regidas por SSOLifetimeMins. Cuando la opción "Mantener la sesión (KMSI)" está habilitada, el valor predeterminado es 24 horas. Este valor predeterminado se puede configurar mediante KMSILifetimeMins.

• Token de actualización: ocho horas de forma predeterminada. 24 horas si la opción KMSI está habilitada.

• access_token: una hora de forma predeterminada, según el usuario de confianza.

• id_token: igual que el token de acceso (access_token).

AD FS no admite flujos implícitos para el cliente confidencial. La autenticación de cliente solo está habilitada para el punto de conexión de token y AD FS no emitirá un token de acceso sin la autenticación de cliente. Si el cliente confidencial necesita un token de acceso y también requiere la autenticación de usuario, deberá usar el flujo del código de autorización.

HSTS es un mecanismo de directiva de seguridad web. Esta ayuda a mitigar los ataques de degradación del protocolo y el secuestro de cookies de los servicios que tienen puntos de conexión HTTP y HTTPS. Permite que los servidores web declaren que los exploradores web (u otros agentes de usuario que cumplen los requisitos) solo deben interactuar con ellos mediante HTTPS y nunca a través del protocolo HTTP.

Todos los puntos de conexión de AD FS para el tráfico de autenticación web se abren exclusivamente a través de HTTPS. Por ello, AD FS mitiga las amenazas que crea el mecanismo de directiva de HSTS. (De forma predeterminada, no hay ningún cambio a alguna versión anterior de HTTP porque no hay agentes de escucha en HTTP). AD FS también impide que las cookies se envíen a otro servidor que tenga puntos de conexión de protocolo HTTP; para ello, marca todas las cookies con una marca segura.

Así pues, no necesita HSTS en un servidor AD FS porque HSTS no se puede degradar. Los servidores de AD FS cumplen estos requisitos porque nunca pueden usar HTTP y todas las cookies se marcan como seguras.

Además, AD FS 2016 (con las revisiones más recientes) y AD FS 2019 admiten la emisión del encabezado HSTS. Para configurar este comportamiento, consulte Personalización de encabezados de respuesta de seguridad HTTP con AD FS.

No se recomienda realizar la terminación SSL antes del servidor del Proxy de aplicación web. Si se hace frente al servidor del Proxy de aplicación web, X-MS-Forwarded-Client-IP contendrá la dirección IP del dispositivo de red frente al servidor del Proxy de aplicación web. A continuación, se incluye una breve descripción de las distintas notificaciones relacionadas con IP que admite AD FS:

• X-MS-Client-IP. IP de red del dispositivo que se conectó a STS. Para las solicitudes de extranet, esta notificación siempre contiene la dirección IP del servidor del Proxy de aplicación web.
• X-MS-Forwarded-Client-IP. Notificación de varios valores que contiene los valores reenviados a AD FS mediante Exchange Online. También contiene la dirección IP del dispositivo conectado al servidor del Proxy de aplicación web.
• Userip. Para las solicitudes de extranet, esta notificación contendrá el valor X-MS-Forwarded-Client-IP. En el caso de las solicitudes de intranet, esta notificación contendrá el mismo valor que X-MS-Client-IP.

Además, en AD FS 2016 (con las revisiones más recientes) y las versiones posteriores, también se admite la captura del encabezado X-Forwarded-For. Cualquier equilibrador de carga o dispositivo de red que no se reenvíe en el nivel 3 (la IP se conserva) debe agregar la dirección IP de cliente entrante al encabezado X-Forwarded-For estándar del sector.

El punto de conexión de información del usuario de AD FS siempre devuelve la notificación del firmante tal y como se especifica en los estándares de OpenID. AD FS no proporciona notificaciones adicionales solicitadas a través del punto de conexión de información del usuario. Si necesita notificaciones adicionales en el token de identificador, consulte Tokens de id. personalizados en AD FS.

Este grupo solo se crea cuando existe un controlador de dominio de Windows Server 2016 con el rol PDC de FSMO en el dominio. Para resolver el error, puede crear el grupo manualmente. Siga estos pasos para agregar los permisos necesarios después de agregar la cuenta de servicio como miembro del grupo:

1. Abra Usuarios y equipos de Active Directory.
2. Haga clic con el botón derecho en el nombre de dominio en el panel izquierdo y seleccione Propiedades.
3. Seleccione Seguridad. (Si falta la pestaña Seguridad, active Características avanzadas en el menú Ver).
4. Seleccione Avanzado, Agregar y luego Seleccione una entidad de seguridad.
5. Se abrirá el cuadro de diálogo Select User, Computer, Service Account, or Group (Seleccionar usuarios, equipos, cuentas de servicio o grupos). En el cuadro de texto Enter the object name to select (Escriba el nombre del objeto que quiera seleccionar), escriba Grupo de administradores de claves. Seleccione Aceptar.
6. En el cuadro de lista Se aplica a, seleccione Descendant User objects (Objetos de usuario descendientes).
7. Desplácese hasta la parte inferior de la página y seleccione Borrar todo.
8. En la sección Propiedades, selecciona Read msDS-KeyCredentialLink (Leer msDS-KeyCredentialLink) y Write msDS-KeyCredentialLink (Escribir msDS-KeyCredentialLink).

Los usuarios federados pueden experimentar un error en la autenticación en Azure AD para las aplicaciones que usan la biblioteca ADAL de Android. La aplicación obtendrá el valor AuthenticationException cuando intente mostrar la página de inicio de sesión. En el explorador Chrome, es posible que la página de inicio de sesión de AD FS se describa como no segura.

En todas las versiones y todos los dispositivos, Android no admite la descarga de certificados adicionales del campo authorityInformationAccess del certificado. Esta limitación también se aplica al explorador Chrome. Cualquier certificado de autenticación de servidor que no tenga certificados intermedios producirá este error si la cadena de certificados completa no se pasa desde AD FS.

Para resolver este problema, configure los servidores de AD FS y el Proxy de aplicación web para enviar los certificados intermedios necesarios junto con el certificado SSL.

Cuando exporte el certificado SSL desde un equipo para importarlo al almacén personal del equipo de los servidores AD FS y el Proxy de aplicación web, asegúrese de exportar la clave privada y seleccione Intercambio de información personal - PKCS #12.

Asimismo, asegúrese de seleccionar la opción Include all certificates in the certificate path if possible (Incluir todos los certificados en la ruta de acceso del certificado si es posible) y Exportar todas las propiedades extendidas.

Ejecute certlm.msc en los servidores de Windows e importe el archivo *.pfx en el almacén de certificados personal del equipo. De este modo, el servidor pasará toda la cadena de certificados a la biblioteca ADAL.

AD FS no admite las solicitudes HEAD. Las aplicaciones no deben usar solicitudes HEAD en puntos de conexión de AD FS. El uso de estas solicitudes puede provocar respuestas de error HTTP inesperadas o con retrasos. Asimismo, es posible que vea eventos de error inesperados en el registro de eventos de AD FS.

No se emite ningún token de actualización si el token que emite el IdP tiene una validez de menos de una hora. Para asegurarse de que se emite un token de actualización, aumente la validez del token que emite el IdP a más de una hora.

El cifrado del token de RP se establece en AES256. No se puede cambiar a ningún otro valor.

Las granjas de AD FS modo mixto están pensadas para ser temporales. Le recomendamos que, durante la planificación, sustituya el certificado SSL antes del proceso de actualización o que complete el proceso y aumente el nivel de comportamiento de la granja antes de actualizar el certificado SSL. Si no se ha seguido esa recomendación, siga estas instrucciones para actualizar el certificado SSL.

En los servidores proxy de aplicaciones web, aún puede utilizar Set-WebApplicationProxySslCertificate. En los servidores AD FS, debe usar netsh. Siga estos pasos:

1. Seleccione un subconjunto de servidores de AD FS 2016 para su mantenimiento.

2. En los servidores seleccionados en el paso anterior, importe el nuevo certificado a través de MMC.

3. Elimine los certificados existentes:

   a. netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. Agregue los nuevos certificados:

   a. netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. Reinicie el servicio de AD FS en el servidor seleccionado.

6. Quite un subconjunto de servidores del Proxy de aplicación web para su mantenimiento.

7. En los servidores del Proxy de aplicación web seleccionados, importe el nuevo certificado a través de MMC.

8. Establezca el nuevo certificado en el servidor del Proxy de aplicación web mediante este cmdlet:

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. Reinicie el servicio en los servidores del Proxy de aplicación web seleccionados.

10. Vuelva a colocar los servidores del Proxy de aplicación web y de AD FS seleccionados en el entorno de producción.

Actualice el resto de los servidores de AD FS y del Proxy de aplicación web de la misma manera.

Los servidores de aplicaciones web y AD FS admiten cualquier firewall que no realice la terminación SSL en el punto de conexión. Además, los servidores del Proxy de aplicación web y de AD FS tienen mecanismos integrados para:

• Ayudarle a evitar ataques web comunes, como el scripting entre sitios.
• Realizar un proxy de AD FS.
• Cumplir todos los requisitos que se definen en el protocolo MS-ADFSPIP.

En AD FS 2016, el enlace de tokens se habilita automáticamente y provoca varios problemas conocidos con los escenarios de proxy y de federación. Estos problemas provocan este evento. Para resolverlo, ejecute el siguiente comando de PowerShell para quitar la compatibilidad con el enlace de tokens:

Set-AdfsProperties -IgnoreTokenBinding $true

Después de realizar una actualización a Windows Server 2019, la versión de configuración del Proxy de aplicación web se seguirá mostrando como Windows Server 2016. El Proxy de aplicación web no tiene nuevas características específicas de la versión para Windows Server 2019. Si se ha generado el nivel de comportamiento de la granja en AD FS, el Proxy de aplicación web seguirá mostrándose como Windows Server 2016. Este comportamiento es así por diseño.

Con ESL habilitado, AD FS realiza un seguimiento de la actividad de la cuenta y de las ubicaciones conocidas de los usuarios en la base de datos ADFSArtifactStore. Esta base de datos se escala en función del número de usuarios y de las ubicaciones conocidas a las que se realiza un seguimiento. Al planificar la habilitación de ESL, puede calcular el tamaño de la base de datos ADFSArtifactStore para que crezca a una velocidad de hasta 1 GB por 100 000 usuarios.

Si la granja de servidores de AD FS usa Windows Internal Database, la ubicación predeterminada de los archivos de la base de datos será C:\Windows\WID\Data. Para evitar llenar esta unidad, asegúrese de tener al menos 5 GB de almacenamiento libre antes de habilitar ESL. Además del almacenamiento en disco, planifique un aumento de la memoria de proceso total después de habilitar ESL de hasta un 1 GB de RAM adicional para una cantidad de 500 000 usuarios o menos.

Este es el texto del evento:

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

Este evento se produce cuando AD FS intenta enumerar todos los bosques en una cadena de bosques de confianza y se conecta a través de todos los bosques, pero los bosques no son de confianza. Por ejemplo, suponga que el bosque A y el bosque B de AD FS son de confianza y que y el bosque B y el bosque C también son de confianza. AD FS enumerará los tres bosques e intentará encontrar una relación de confianza entre el bosque A y el C. Si AD FS tiene que autenticar a los usuarios del bosque con errores, configure una relación de confianza entre el bosque de AD FS y el bosque con errores. Si AD FS no autentica a los usuarios del bosque con errores, ignore este evento.

Este es el texto del evento:

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

En AD FS 2016, el enlace de tokens se habilita automáticamente y provoca varios problemas conocidos con los escenarios de proxy y de federación. Estos problemas provocan este evento. Para resolverlo, ejecute el siguiente comando de PowerShell para quitar la compatibilidad con el enlace de tokens:

Set-AdfsProperties -IgnoreTokenBinding $true

Este es el texto del evento:

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

Este evento se espera cuando ambas instrucciones tienen el valor "true":

• Tiene una granja de servidores en modo mixto.
• AD FS 2019 proporciona a la granja la información de nivel de comportamiento máximo para el servidor de federación principal, pero no la reconoce la versión 2016 del servidor de federación.

AD FS 2019 sigue intentando compartir en la granja el valor de MaxBehaviorLevel Win2019 hasta que queda obsoleto después de dos meses y se quita automáticamente de la granja. Para evitar este evento, migre el rol de federación principal al servidor de federación con la última versión. Siga las instrucciones de Actualización de la granja de AD FS al nivel de comportamiento de la granja de Windows Server 2019.