Compartir a través de

Configuración de la compatibilidad de AD FS con la autenticación de certificados de usuario

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 proporciona información de solución de problemas para problemas comunes con este tipo de autenticación.

Hay dos casos de uso principales para 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.

Prerrequisitos

  • 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, lo hace a través del objeto de directiva de grupo (GPO) en servidores AD FS y WAP.
  • Asegúrese de que el certificado raíz de la cadena de confianza para 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 a través del firewall.
  • Si usa la autenticación de certificados desde la extranet, asegúrese de que al menos un acceso a la información de autoridad (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 son accesibles desde Internet.
  • Si va a configurar AD FS para la autenticación de certificados de Microsoft Entra, asegúrese de que ha configurado las opciones 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 RFC822 al atributo de dirección de proxy en el 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-AdfsGlobalAuthenticationPolicyde 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. Vea la lista completa de reclamaciones de certificados 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 para 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 para 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 realizan la autenticación de certificados. Un caso común es cambiar Iniciar sesión con el certificado X509 a algo más fácil de usar.

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

Cuando una máquina tiene varios certificados de usuario (como Wi-Fi certificados) que cumplen 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. Este mensaje puede resultar confuso 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 si realiza un cambio en el Registro o puede configurarla automáticamente a través de GPO (para establecer las claves del Registro). Esto requiere que los certificados de cliente de usuario para la autenticación en AD FS tengan emisores distintos de otros casos de uso.

Para obtener 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 para los usuarios.

Compruebe si 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: "Sin 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 asegurarse de que coincide con un emisor de confianza validando la cadena de confianza del certificado. 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 Analizador de diagnósticos 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 errores.

Compruebe si 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 obtener más información, consulte Compatibilidad de AD FS con el enlace de nombre de host alternativo para la autenticación de certificados.

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 hosts adfs.contoso.com y certauth.adfs.contoso.com con el puerto 443. Necesita un certificado SSL que admita 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 más tarde a través de 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 para la autenticación de certificados de usuario. Normalmente, verá una pantalla en blanco o un error de servidor 500 cuando se produce este problema. Para corregirlo:

  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.

Comprobar la conectividad 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 de AD FS y WAP debe alcanzar el punto de conexión CRL para validar si el certificado que le fue presentado 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 AD FS y WAP no pueden llegar al punto de conexión, se producirá un error en la autenticación. Siga estos pasos para solucionar problemas:

  1. Consulte con el ingeniero de infraestructura de clave pública (PKI) para determinar qué puntos de conexión CRL se usan para revocar certificados de usuario de tu sistema PKI.
  2. En cada servidor de AD FS y WAP, asegúrese de que los puntos de conexión crL son 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 de AD FS y WAP.
  4. Verifique el identificador de evento 41 (Verify Revocation) 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 tener como destino un único servidor de 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 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 experimente 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. Escribe Netsh http show sslcert.
  3. Copie el GUID de la aplicación y el hash de certificado del servicio de federación.
  4. Escribe netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}.

Compruebe si el dispositivo cliente se ha aprovisionado correctamente con el certificado.

Es posible que observe que algunos dispositivos funcionan correctamente, pero otros dispositivos 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 el 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, compruebe si el certificado se aprovisiona correctamente comprobando el almacén de certificados de Windows para el usuario que ha iniciado sesión (no el sistema o el equipo).

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

Compruebe si la versión de TLS es compatible entre los servidores de AD FS/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, es posible que tenga el problema inverso, donde los servidores AD FS y WAP se actualizaron para usar solo una versión tls superior que el dispositivo cliente no admite.

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

Compruebe si Microsoft Entra PromptLoginBehavior está configurado correctamente en la configuración del dominio federado.

Muchas aplicaciones de Office 365 envían prompt=login a Microsoft Entra ID. Microsoft Entra ID, de forma predeterminada, lo convierte en un inicio de sesión de contraseña nuevo 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 de contraseña. Para corregir este problema:

  1. Obtenga la configuración del dominio federado mediante el Get-MgDomainFederationConfiguration cmdlet .
  2. Asegúrese de que el PromptLoginBehavior parámetro 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 Http.sys configuración del Registro para Windows.

Referencia: Lista completa de tipos de declaraciones de certificados de usuario y valores de ejemplo

Tipo de reclamación Ejemplo de valor
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