Solucionar problemas de inicio de sesión de Windows del Servicio de autenticación federada

Este artículo describe los registros y mensajes de error que Windows proporciona cuando un usuario inicia sesión usando certificados y/o tarjetas inteligentes. Estos registros proporcionan información que puede usar para solucionar problemas de autenticación.

Certificados e infraestructura de clave pública

Windows Active Directory mantiene varios almacenes de certificados que gestionan los certificados para los usuarios que inician sesión.

  • Almacén de certificados NTAuth: Para autenticarse en Windows, la CA que emite inmediatamente los certificados de usuario (es decir, no se admite el encadenamiento) debe colocarse en el almacén NTAuth. Para ver estos certificados, desde el programa certutil, introduzca: certutil –viewstore –enterprise NTAuth.
  • Almacenes de certificados raíz e intermedios: Normalmente, los sistemas de inicio de sesión con certificados solo pueden proporcionar un único certificado, por lo que si se utiliza una cadena, el almacén de certificados intermedios en todas las máquinas debe incluir estos certificados. El certificado raíz debe estar en el Almacén de raíces de confianza, y el certificado penúltimo debe estar en el almacén NTAuth.
  • Extensiones de certificado de inicio de sesión y Directiva de grupo: Windows se puede configurar para aplicar la verificación de EKUs y otras directivas de certificado. Consulte la documentación de Microsoft: https://docs.microsoft.com/es-es/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)?redirectedfrom=MSDN.
Directiva de registro Descripción
AllowCertificatesWithNoEKU Cuando está deshabilitado, los certificados deben incluir el Uso de clave extendido (EKU) de inicio de sesión con tarjeta inteligente.
AllowSignatureOnlyKeys De forma predeterminada, Windows filtra las claves privadas de los certificados que no permiten el descifrado RSA. Esta opción anula ese filtro.
AllowTimeInvalidCertificates De forma predeterminada, Windows filtra los certificados caducados. Esta opción anula ese filtro.
EnumerateECCCerts Habilita la autenticación de curva elíptica.
X509HintsNeeded Si un certificado no contiene un nombre principal de usuario (UPN) único, o si podría ser ambiguo, esta opción permite a los usuarios especificar manualmente su cuenta de inicio de sesión de Windows.
UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors Deshabilita la comprobación de revocación (normalmente configurada en el controlador de dominio).
  • Certificados de controlador de dominio: Para autenticar las conexiones Kerberos, todos los servidores deben tener los certificados de “controlador de dominio” adecuados. Estos se pueden solicitar mediante el menú del complemento MMC “Almacén personal de certificados del equipo local”.

Nombre UPN y asignación de certificados

Se recomienda que los certificados de usuario incluyan un nombre principal de usuario (UPN) único en la extensión Nombre alternativo del sujeto.

Nombres UPN en Active Directory

De forma predeterminada, cada usuario de Active Directory tiene un UPN implícito basado en el patrón <samUsername>@<domainNetBios> y <samUsername>@<domainFQDN>. Los dominios y FQDN disponibles se incluyen en la entrada RootDSE del bosque. Tenga en cuenta que un solo dominio puede tener varias direcciones FQDN registradas en el RootDSE.

Además, cada usuario de Active Directory tiene un UPN explícito y altUserPrincipalNames. Se trata de entradas LDAP que especifican el UPN del usuario.

Al buscar usuarios por UPN, Windows busca primero en el dominio actual (según la identidad del proceso que busca el UPN) los UPN explícitos y, a continuación, los UPN alternativos. Si no hay coincidencias, busca el UPN implícito, que puede resolverse en diferentes dominios del bosque.

Servicio de asignación de certificados

Si un certificado no incluye un UPN explícito, Active Directory tiene la opción de almacenar un certificado público exacto para cada uso en un atributo “x509certificate”. Para resolver un certificado de este tipo a un usuario, un equipo puede consultar este atributo directamente (de forma predeterminada, en un solo dominio).

Se proporciona una opción para que el usuario especifique una cuenta de usuario que acelera esta búsqueda y también permite que esta función se utilice en un entorno entre dominios.

Si hay varios dominios en el bosque y el usuario no especifica explícitamente un dominio, el rootDSE de Active Directory especifica la ubicación del Servicio de asignación de certificados. Este suele estar ubicado en una máquina de catálogo global y tiene una vista en caché de todos los atributos x509certificate del bosque. Este equipo se puede utilizar para encontrar eficientemente una cuenta de usuario en cualquier dominio, basándose únicamente en el certificado.

Controlar la selección del controlador de dominio de inicio de sesión

Cuando un entorno contiene varios controladores de dominio, es útil ver y restringir qué controlador de dominio se utiliza para la autenticación, de modo que se puedan habilitar y recuperar los registros.

Controlar la selección del controlador de dominio

Para forzar a Windows a usar un controlador de dominio de Windows en particular para el inicio de sesión, puede establecer explícitamente la lista de controladores de dominio que utiliza una máquina Windows configurando el archivo lmhosts: \Windows\System32\drivers\etc\lmhosts.

Normalmente hay un archivo de ejemplo llamado “lmhosts.sam” en esa ubicación. Simplemente incluya una línea:

1.2.3.4 dcnetbiosname #PREFERIDO #DOMINIO:mydomai

Donde “1.2.3.4” es la dirección IP del controlador de dominio llamado “dcnetbiosname” en el dominio “mydomain”.

Después de un reinicio, la máquina Windows utiliza esa información para iniciar sesión en mydomain. Tenga en cuenta que esta configuración debe revertirse cuando finalice la depuración.

Identificar el controlador de dominio en uso

Al iniciar sesión, Windows establece una variable de entorno MSDOS con el controlador de dominio que inició la sesión del usuario. Para ver esto, inicie el símbolo del sistema con el comando: echo %LOGONSERVER%.

Los registros relacionados con la autenticación se almacenan en el equipo devuelto por este comando.

Habilitar eventos de auditoría de cuenta

De forma predeterminada, los controladores de dominio de Windows no habilitan los registros completos de auditoría de cuentas. Esto se puede controlar a través de las políticas de auditoría en la configuración de seguridad del editor de directivas de grupo. Una vez habilitados, el controlador de dominio produce información adicional del registro de eventos en el archivo de registro de seguridad.

imagen localizada

Registros de validación de certificados

Comprobar la validez del certificado

Si un certificado de tarjeta inteligente se exporta como certificado DER (no se requiere clave privada), puede validarlo con el comando: certutil –verify user.cer

Habilitar el registro de CAPI

En el controlador de dominio y en la máquina del usuario, abra el visor de eventos y habilite el registro para Microsoft/Windows/CAPI2/Operational Logs.

Puede controlar el registro de CAPI con las claves del Registro en: CurrentControlSet\Services\crypt32.

Valor Descripción
DiagLevel (DWORD) Nivel de detalle (0 a 5)
DiagMatchAnyMask (QUADWORD) Filtro de eventos (use 0xffffff para todos)
DiagProcessName (MULTI_SZ) Filtrar por nombre de proceso (por ejemplo, LSASS.exe)

Registros de CAPI

Mensaje Descripción
Crear cadena LSA llamó a CertGetCertificateChain (incluye el resultado)
Verificar revocación LSA llamó a CertVerifyRevocation (incluye el resultado)
Objetos X509 En modo detallado, los certificados y las listas de revocación de certificados (CRL) se vuelcan en AppData\LocalLow\Microsoft\X509Objects
Verificar política de cadena LSA llamó a CertVerifyChainPolicy (incluye los parámetros)

Mensajes de error

Código de error Descripción
Certificado no de confianza El certificado de la tarjeta inteligente no se pudo generar utilizando los certificados de los almacenes de certificados intermedios y de raíz de confianza del equipo.
Error de comprobación de revocación de certificado No se pudo descargar la CRL de la tarjeta inteligente desde la dirección especificada por el punto de distribución de CRL del certificado. Si la comprobación de revocación es obligatoria, esto impide que el inicio de sesión se realice correctamente. Consulte la sección Certificados e infraestructura de clave pública.
Errores de uso de certificados El certificado no es adecuado para el inicio de sesión. Por ejemplo, podría ser un certificado de servidor o un certificado de firma.

Registros de Kerberos

Para habilitar el registro de Kerberos, en el controlador de dominio y en la máquina del usuario final, cree los siguientes valores de registro:

Subárbol Nombre del valor Valor [DWORD]
CurrentControlSet\Control\Lsa\Kerberos\Parameters LogLevel 0x1
CurrentControlSet\Control\Lsa\Kerberos\Parameters KerbDebuglevel 0xffffffff
CurrentControlSet\Services\Kdc KdcDebugLevel 0x1
CurrentControlSet\Services\Kdc KdcExtraLogLevel 0x1f

El registro de Kerberos se envía al registro de eventos del sistema.

  • Los mensajes como «certificado no fiable» deberían ser fáciles de diagnosticar.
  • Hay dos códigos de error que son informativos y se pueden ignorar sin problema:
    • KDC_ERR_PREAUTH_REQUIRED (utilizado para la compatibilidad con versiones anteriores de controladores de dominio)
    • Error desconocido 0x4b

Mensajes del registro de eventos

Esta sección describe las entradas de registro esperadas en el controlador de dominio y la estación de trabajo cuando el usuario inicia sesión con un certificado.

  • Registro CAPI2 del controlador de dominio
  • Registros de seguridad del controlador de dominio
  • Registro de seguridad de VDA
  • Registro CAPI de VDA
  • Registro del sistema de VDA

Registro CAPI2 del controlador de dominio

Durante un inicio de sesión, el controlador de dominio valida el certificado del autor de la llamada, lo que produce una secuencia de entradas de registro con el siguiente formato.

Imagen localizada

El mensaje final del registro de eventos muestra que lsass.exe en el controlador de dominio construye una cadena basada en el certificado proporcionado por el VDA y la verifica para comprobar su validez (incluida la revocación). El resultado se devuelve como “ERROR_SUCCESS”.

Imagen localizada

Registro de seguridad del controlador de dominio

El controlador de dominio muestra una secuencia de eventos de inicio de sesión, siendo el evento clave el 4768, donde el certificado se utiliza para emitir el Ticket de concesión de tickets de Kerberos (krbtgt).

Los mensajes anteriores a este muestran la cuenta de máquina del servidor autenticándose en el controlador de dominio. Los mensajes posteriores a este muestran la cuenta de usuario perteneciente al nuevo krbtgt utilizándose para autenticarse en el controlador de dominio.

Imagen localizada

Registro de seguridad de VDA

El registro de auditoría de seguridad de VDA correspondiente al evento de inicio de sesión es la entrada con el ID de evento 4648, originada en winlogon.exe.

imagen localizada

Registro CAPI de VDA

Este ejemplo de registro CAPI de VDA muestra una única secuencia de creación y verificación de cadena desde lsass.exe, validando el certificado del controlador de dominio (dc.citrixtest.net).

imagen localizada

imagen localizada

Registro del sistema VDA

Cuando el registro de Kerberos está habilitado, el registro del sistema muestra el error KDC_ERR_PREAUTH_REQUIRED (que se puede ignorar) y una entrada de Winlogon que indica que el inicio de sesión de Kerberos se realizó correctamente.

imagen localizada

Mensajes de error del usuario final

Esta sección enumera los mensajes de error comunes que se muestran a un usuario en la página de inicio de sesión de Windows.

Mensaje de error mostrado Descripción y referencia
Nombre de usuario o contraseña no válidos El equipo cree que tiene un certificado y una clave privada válidos, pero el controlador de dominio de Kerberos ha rechazado la conexión. Consulte la sección Registros de Kerberos de este artículo.
El sistema no pudo iniciar su sesión. Sus credenciales no pudieron verificarse. No se puede contactar con el controlador de dominio, o el controlador de dominio no tiene los certificados adecuados instalados.
La solicitud no es compatible Vuelva a inscribir los certificados de “Controlador de dominio” y “Autenticación de controlador de dominio” en el controlador de dominio, tal como se describe en CTX206156. Por lo general, vale la pena intentarlo, incluso cuando los certificados existentes parecen ser válidos.
El sistema no pudo iniciar su sesión. El certificado de tarjeta inteligente utilizado para la autenticación no era de confianza. Los certificados intermedios y raíz no están instalados en el equipo local. Consulte CTX206156 para obtener instrucciones sobre cómo instalar certificados de tarjeta inteligente en equipos que no están unidos a un dominio. Consulte también la sección Certificados e infraestructura de clave pública de este artículo.
No puede iniciar sesión porque el inicio de sesión con tarjeta inteligente no es compatible con su cuenta. Una cuenta de usuario de grupo de trabajo no se ha configurado completamente para el inicio de sesión con tarjeta inteligente.
La clave solicitada no existe Un certificado hace referencia a una clave privada que no es accesible. Esto puede ocurrir cuando una tarjeta PIV no está completamente configurada y le falta el archivo CHUID o CCC.
Se produjo un error al intentar usar la tarjeta inteligente El middleware de la tarjeta inteligente no se instaló correctamente. Consulte CTX206156 para obtener instrucciones de instalación de la tarjeta inteligente.
Inserte una tarjeta inteligente No se detectó la tarjeta inteligente o el lector. Si la tarjeta inteligente está insertada, este mensaje indica un problema de hardware o middleware. Consulte CTX206156 para obtener instrucciones de instalación de la tarjeta inteligente.
El PIN es incorrecto La tarjeta inteligente rechazó un PIN introducido por el usuario.
No se encontró ningún certificado de tarjeta inteligente válido. Es posible que las extensiones del certificado no estén configuradas correctamente, o que la clave RSA sea demasiado corta (<2048 bits). Consulte CTX206901 para obtener información sobre cómo generar certificados de tarjeta inteligente válidos.
La tarjeta inteligente está bloqueada Se ha bloqueado una tarjeta inteligente (por ejemplo, el usuario introdujo un PIN incorrecto varias veces). Un administrador puede tener acceso al código de desbloqueo de PIN (PUK) de la tarjeta y puede restablecer el PIN del usuario mediante una herramienta proporcionada por el proveedor de la tarjeta inteligente. Si el código PUK no está disponible o está bloqueado, la tarjeta debe restablecerse a la configuración de fábrica.
Solicitud incorrecta Una clave privada de tarjeta inteligente no admite la criptografía requerida por el controlador de dominio. Por ejemplo, el controlador de dominio podría haber solicitado un “descifrado de clave privada”, pero la tarjeta inteligente solo admite la firma. Esto suele indicar que las extensiones del certificado no están configuradas correctamente o que la clave RSA es demasiado corta (<2048 bits). Consulte CTX206901 para obtener información sobre cómo generar certificados de tarjeta inteligente válidos.

Información relacionada