Configuración de AD FS para la autenticación de certificados de usuario

  • Artículo

En este artículo se describe cómo habilitar la autenticación de certificados de usuario en Servicios de federación de Active Directory (AD FS). También se proporciona información de solución de problemas comunes con este tipo de autenticación.

Hay dos casos de uso principales de la autenticación de certificados de usuario:

  • Los usuarios usan tarjetas inteligentes para iniciar sesión en su sistema de AD FS.
  • Los usuarios usan certificados aprovisionados para dispositivos móviles.

Requisitos previos

  • Determine el modo de autenticación de certificados de usuario de AD FS que quiere habilitar mediante uno de los modos descritos en Compatibilidad de AD FS con el enlace de nombre de host alternativo para la autenticación de certificado.
  • Asegúrese de que todos los servidores de AD FS y Web Application Proxy (WAP) instalen y confíen en la cadena de confianza del certificado de usuario, incluidas las entidades de certificación intermedias. Normalmente se hace a través del objeto de directiva de grupo (GPO) en servidores de AD FS y WAP.
  • Asegúrese de que el certificado raíz de la cadena de confianza de los certificados de usuario esté en el almacén NTAuth de Active Directory.
  • Si usa AD FS en modo de autenticación de certificado alternativo, asegúrese de que los servidores de AD FS y WAP tengan certificados de Capa de sockets seguros (SSL) que contengan el nombre de host de AD FS con el prefijo "certauth". Un ejemplo es certauth.fs.contoso.com. Asegúrese también de que se permite el tráfico a este nombre de host mediante el firewall.
  • Si usa la autenticación de certificados de la extranet, asegúrese de que al menos un acceso a la información de la entidad (AIA) y al menos un punto de distribución CRL (CDP) o la ubicación del Protocolo de estado de certificado en línea (OCSP) de la lista especificada en los certificados sean accesibles desde Internet.
  • Si va a configurar AD FS para la autenticación de certificados de Microsoft Entra, asegúrese de que ha configurado los valores de Microsoft Entra y las reglas de notificación de AD FS necesarias para el emisor de certificados y el número de serie.
  • Si va a usar la autenticación de certificados de Microsoft Entra con clientes de Exchange ActiveSync, el certificado de cliente debe tener la dirección de correo electrónico enrutable del usuario en Exchange Online en el valor de Nombre de la entidad de seguridad o Nombre RFC822 del campo Nombre alternativo del firmante. Microsoft Entra ID asigna el valor de RFC822 al atributo de dirección de Proxy del directorio.

Nota:

AD FS no admite sugerencias de nombre de usuario con la autenticación basada en certificado o tarjeta inteligente.

Habilitación de la autenticación de certificados de usuario

Habilite la autenticación de certificados de usuario como método de autenticación de intranet o extranet en AD FS mediante la consola de administración de AD FS o el cmdlet Set-AdfsGlobalAuthenticationPolicy de PowerShell.

Entre las consideraciones opcionales se incluyen:

  • Si quiere usar notificaciones basadas en campos y extensiones de certificado además del tipo de notificación de EKU, https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku, configure más reglas de paso de notificaciones en la confianza del proveedor de notificaciones de Active Directory. Consulte la lista completa de notificaciones de certificado disponibles más adelante en este artículo.

  • Si necesita restringir el acceso en función del tipo de certificado, puede usar las propiedades adicionales del certificado en las reglas de autorización de emisión de AD FS de la aplicación. Los escenarios comunes son permitir solo los certificados aprovisionados por un proveedor de administración de dispositivos móviles (MDM) o permitir solo certificados de tarjeta inteligente.

    Importante

    Los clientes que usan el flujo de código de dispositivo para la autenticación y realizan la autenticación de dispositivos mediante un proveedor de identidades distinto de Microsoft Entra ID (por ejemplo, AD FS) no pueden aplicar el acceso basado en dispositivos a los recursos de Microsoft Entra. Por ejemplo, no pueden permitir solo dispositivos administrados mediante un servicio MDM de terceros.

    Para ayudar a proteger el acceso a los recursos corporativos en Microsoft Entra ID y evitar la pérdida de datos, configure el acceso condicional basado en dispositivos de Microsoft Entra. Por ejemplo, use Requerir que el dispositivo se marque como queja para conceder control en el acceso condicional de Microsoft Entra.

    Configure entidades de certificados de emisión permitidas para los certificados de cliente mediante la guía "Administración de emisores de confianza para la autenticación de cliente" en Introducción técnica a Schannel SSP.

  • Considere la posibilidad de modificar las páginas de inicio de sesión para satisfacer las necesidades de los usuarios cuando realicen la autenticación de certificados. Un caso común es cambiar el inicio de sesión con el certificado X509 por algo más fácil de usar.

Configuración de la autenticación de certificados completa para el explorador Chrome en escritorios de Windows

Cuando una máquina tiene varios certificados de usuario (como certificados Wi-Fi) que satisfacen los propósitos de la autenticación de cliente, el explorador Chrome en los escritorios de Windows pedirá a los usuarios que seleccionen el certificado correcto. Esta petición puede resultar confusa para los usuarios. Para optimizar esta experiencia, puede establecer una directiva para que Chrome seleccione automáticamente el certificado correcto.

Puede establecer esta directiva manualmente realizando un cambio en el Registro, o bien puede configurarla automáticamente mediante GPO (para establecer las claves del Registro). Para ello, es necesario que los certificados de cliente de usuario para la autenticación en AD FS tengan emisores distintos a los de otros casos de uso.

Para más información sobre cómo configurar la autenticación de certificados para Chrome, consulte Lista de directivas de Chrome Enterprise.

Solución de problemas de autenticación de certificados

Use la siguiente información para solucionar problemas comunes cuando haya configurado AD FS para la autenticación de certificados de los usuarios.

Comprobación de que los emisores de confianza de certificados estén configurados correctamente en todos los servidores de AD FS y WAP

Si los emisores de confianza de certificados no están configurados correctamente, un síntoma común es un error HTTP 204: "No hay contenido de https://certauth.adfs.contoso.com.".

AD FS usa el sistema operativo Windows subyacente para demostrar la posesión del certificado de usuario y valida la cadena de confianza del certificado para asegurarse de que coincide con un emisor de confianza. Para ello, es necesario asegurarse de que todas las autoridades raíz e intermedias estén configuradas como emisores de confianza en el almacenamiento local de las entidades de certificación del equipo.

Para validar esto automáticamente, use la herramienta Diagnostics Analyzer de AD FS. La herramienta consulta todos los servidores y garantiza que los certificados adecuados se aprovisionen correctamente.

  1. Descargue y ejecute la herramienta.
  2. Cargue los resultados y revise los posibles errores.

Comprobación de que la autenticación de certificados esté habilitada en la directiva de autenticación de AD FS

AD FS realiza la autenticación de certificados de usuario de forma predeterminada en el puerto 49443 con el mismo nombre de host que AD FS (ejemplo: adfs.contoso.com). También puede configurar AD FS para usar el puerto 443 (el puerto HTTPS predeterminado) mediante el enlace SSL alternativo. Sin embargo, la dirección URL usada en esta configuración es certauth.<adfs-farm-name> (ejemplo: certauth.contoso.com). Para más información, consulte Compatibilidad de AD FS con el enlace de nombre de host alternativo para la autenticación de certificado.

Nota

En AD FS en Windows Server 2016, ahora se admiten dos modos. El primer modo usa el host adfs.contoso.com con los puertos 443 y 49443. El segundo modo usa los hosts adfs.contoso.com y certauth.adfs.contoso.com con el puerto 443. Necesita un certificado SSL para admitir certauth.\<adfs-service-name> como un nombre de firmante alternativo. Puede hacerlo en el momento de la creación de la granja de servidores o después mediante PowerShell.

El caso más común de problemas de conectividad de red es que un firewall se ha configurado incorrectamente y bloquea el tráfico de la autenticación de certificados de usuario. Cuando se produce este problema, normalmente verá una pantalla en blanco o un error de servidor 500. Cómo solucionarlo:

  1. Anote el nombre de host y el puerto que configuró en AD FS.
  2. Asegúrese de que cualquier firewall delante de AD FS o WAP esté configurado para permitir la combinación hostname:port de granja de servidores de AD FS. El ingeniero de red debe realizar este paso.

Comprobación de la conectividad de CRL

Las listas de revocación de certificados (CRL) son puntos de conexión que se codifican en el certificado de usuario para realizar comprobaciones de revocación en tiempo de ejecución. Por ejemplo, si se roba un dispositivo que contiene un certificado, un administrador puede agregar el certificado a la lista de certificados revocados. Cualquier punto de conexión que haya aceptado este certificado anteriormente producirá un error en la autenticación.

Cada servidor AD FS y WAP debe alcanzar el punto de conexión de CLR para validar si el certificado que se presentó sigue siendo válido y no se ha revocado. La validación de CRL puede producirse a través de HTTPS, HTTP, LDAP o OCSP. Si los servidores de AD FS y WAP no pueden llegar al punto de conexión, se producirá un error en la autenticación. Siga estos pasos para solucionarlo:

  1. Consulte con el ingeniero de infraestructura de clave pública (PKI) para determinar qué puntos de conexión de CLR se usan para revocar los certificados de usuario del sistema PKI.
  2. En cada servidor AD FS y WAP, asegúrese de que los puntos de conexión de CLR sean accesibles a través del protocolo que se usa (normalmente HTTPS o HTTP).
  3. Para la validación avanzada, habilite el registro de eventos CAPI2 en cada servidor AD FS y WAP.
  4. Compruebe el identificador de evento 41 (comprobar la revocación) en los registros operativos de CAPI2.
  5. Busque <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>.

Sugerencia

Puede dirigirse a un único servidor AD FS o WAP para facilitar la solución de problemas mediante la configuración de la resolución DNS (archivo de hosts en Windows) para que apunte a un servidor específico. Esta técnica le permite habilitar el seguimiento al dirigirse a un servidor.

Búsqueda de problemas de SNI

AD FS requiere dispositivos cliente (o exploradores) y los equilibradores de carga para admitir la indicación de nombre del servidor (SNI). Es posible que algunos dispositivos cliente (por ejemplo, versiones anteriores de Android) no admitan SNI. Además, es posible que los equilibradores de carga no admitan SNI o que no estén configurados para SNI. En estos casos, es probable que reciba errores de certificación de usuario.

Para solucionar este problema, trabaje con el ingeniero de red para asegurarse de que el equilibrador de carga para AD FS y WAP admite SNI. Si no se puede admitir SNI, use la siguiente solución alternativa en AD FS:

  1. Abra una ventana del símbolo del sistema con privilegios elevados en el servidor de AD FS principal.
  2. Escriba Netsh http show sslcert.
  3. Copie el GUID de la aplicación y el hash de certificado del servicio de federación.
  4. Escriba netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}.

Comprobación de que el dispositivo cliente se ha aprovisionado correctamente con el certificado

Es posible que observe que algunos dispositivos funcionan correctamente, pero otros no. En la mayoría de los casos, significa que el certificado de usuario no se aprovisionó correctamente en algunos dispositivos cliente. Siga estos pasos:

  1. Si el problema es específico de un dispositivo Android, la causa más común es que la cadena de certificados no es de plena confianza en el dispositivo. Consulte al proveedor de MDM para asegurarse de que el certificado se ha aprovisionado correctamente y que toda la cadena es de plena confianza en el dispositivo Android.

    Si el problema es específico de un dispositivo Windows, vea si el certificado se aprovisiona correctamente; para ello, compruebe el almacén de certificados de Windows del usuario que ha iniciado sesión (no del sistema o del equipo).

  2. Exporte el certificado de usuario de cliente a un archivo .cer y ejecute el comando certutil -f -urlfetch -verify certificatefilename.cer.

Comprobación de que la versión de TLS sea compatible entre los servidores de AD FS o WAP y el dispositivo cliente

En raras ocasiones, un dispositivo cliente se actualiza para admitir solo una versión superior de TLS (por ejemplo, 1.3). O bien, podría tener el problema inverso, donde los servidores de AD FS y WAP se actualizaron para usar solo una versión superior de TLS que el dispositivo cliente no admite.

Puede usar herramientas SSL en línea para comprobar los servidores de AD FS y WAP y ver si son compatibles con el dispositivo. Para más información sobre cómo controlar las versiones de TLS, consulte Administración de protocolos y conjuntos de cifrado TLS/SSL para AD FS.

Comprobación de que PromptLoginBehavior de Microsoft Entra está configurado correctamente en la configuración del dominio federado

Muchas aplicaciones de Office 365 envían prompt=login a Microsoft Entra ID. De manera predeterminada, Microsoft Entra ID lo convierte en un inicio de sesión con una nueva contraseña en AD FS. Como resultado, incluso si configuró la autenticación de certificados en AD FS, los usuarios solo ven un inicio de sesión con contraseña. Para corregir este problema:

  1. Obtenga la configuración de dominio federado mediante el cmdlet Get-MgDomainFederationConfiguration.
  2. Asegúrese de que el parámetro PromptLoginBehavior está establecido en Disabled o NativeSupport.

Para más información, consulte Compatibilidad con parámetros prompt=login de AD FS.

Solución de problemas adicional

En raras ocasiones, si las listas CRL son muy largas, podrían agotar el tiempo de espera al intentar descargarlas. En este caso, debe actualizar MaxFieldLength y MaxRequestByte , como se describe en Configuración del Registro de Http.sys para Windows.

Referencia: Lista completa de tipos de notificación de certificado de usuario y valores de ejemplo

Tipo de notificación Valor de ejemplo
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version 3
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm sha256RSA
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername CN=entca, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore 12/05/2016 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter 12/05/2017 20:50:18
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata {Base64 encoded digital certificate data}
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage DigitalSignature
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage KeyEncipherment
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier 9D11941EC06FACCCCB1B116B56AA97F3987D620A
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename User
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku 1.3.6.1.4.1.311.10.3.4