Soluciones a problemas de inicio de sesión en Windows relacionados con el Servicio de autenticación federada
En este artículo, se describen los registros y los mensajes de error que Windows muestra cuando un usuario inicia sesión con certificados y/o tarjetas inteligentes. Estos registros ofrecen información que se puede utilizar para solucionar fallos de autenticación.
Certificados e infraestructura de clave pública
Active Directory de Windows mantiene varios almacenes de certificados que administran certificados para los usuarios que inician sesión.
- Almacén de certificados NTAuth: Para autenticarse en Windows, la entidad de certificación (CA) que acaba de emitir los certificados de usuario (es decir, no se admiten entidades de certificación en cadena) debe colocarse en el almacén NTAuth. Para ver los certificados, desde el programa CertUtil, escriba: certutil –viewstore –enterprise NTAuth.
- Almacén de certificados raíz e intermedios: Por lo general, los sistemas de inicios de sesión con certificados pueden proporcionar solo un certificado, de modo que, si se utilizan certificados en cadena, el almacén de certificados intermedios de todas las máquinas debe incluir esos certificados. El certificado raíz debe estar en el almacén raíz de confianza y el penúltimo certificado debe estar en el almacén NTAuth.
- Extensiones del certificado de inicio de sesión y directivas de grupo. Windows se puede configurar para aplicar la verificación de EKU y otras directivas de certificados. Consulte la documentación de Microsoft: https://docs.microsoft.com/en-us/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á inhabilitada, los certificados deben incluir la propiedad Uso mejorado de clave (EKU) para el inicio de sesión con tarjeta inteligente. |
| AllowSignatureOnlyKeys | De forma predeterminada, Windows filtra y excluye las claves privadas de los certificados que no permiten el descifrado RSA. Esta opción anula ese filtro. |
| AllowTimeInvalidCertificates | De forma predeterminada, Windows filtra y excluye 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 contiene uno que puede ser ambiguo, esta opción permite a los usuarios especificar manualmente su cuenta de inicio de sesión en Windows. |
| UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors | Inhabilita la comprobación de revocación (normalmente establecida en el controlador de dominio). |
- Certificados de controlador de dominio: Para la autenticación de conexiones Kerberos, todos los servidores deben tener los certificados “Domain Controller” (Controlador de dominio) que corresponden. Se pueden solicitar desde el menú de complemento MMC “Local Computer Certificate Personal Store” (Almacén personal de certificados del equipo local).
Nombre UPN y asignación de certificados
Se recomienda que los certificados de usuario contengan un nombre principal de usuario (UPN) único en la extensión Nombre alternativo del firmante.
Nombres UPN en Active Directory
De forma predeterminada, en Active Directory todos los usuarios tienen un UPN implícito que se forma siguiendo el formato <samUsername>@<domainNetBIOS> y <samUsername>@<domainFQDN>, es decir, <nombre de usuario SAM>@<NetBIOS del dominio> y <nombre de usuario SAM>@<FQDN de dominio>. Los dominios y los nombres 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, todo usuario en Active Directory tiene un nombre UPN explícito y altUserPrincipalNames. Son las entradas de LDAP que especifican el nombre UPN para el usuario.
Cuando se buscan usuarios por nombre UPN, Windows examina primero el dominio actual (basado en la identidad del proceso que busca el nombre UPN) para buscar nombres UPN explícitos y luego busca nombres UPN alternativos. Si no hay coincidencias, busca el nombre UPN implícito, lo que puede resultar en varios dominios en el bosque.
Servicio de asignaciones de certificado
Si un certificado no incluye un nombre 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 así para un usuario, el sistema puede consultar ese atributo directamente (de forma predeterminada, en un único dominio).
Se ofrece una opción para que el usuario especifique una cuenta de usuario que acelere la búsqueda, lo que también permite que esta funcionalidad se utilice en un entorno de varios dominios.
Si hay varios dominios en el bosque y el usuario no especifica explícitamente un dominio, RootDSE de Active Directory especifica la ubicación del servicio de asignaciones de certificado. Por regla general, este servicio se encuentra en una máquina del catálogo global y tiene una vista en caché de todos los atributos “x509certificate” del bosque. Ese equipo resulta eficaz para buscar cuentas de usuario en cualquier dominio basándose solamente en el certificado.
Controlar la selección del controlador de dominio para iniciar sesión
Cuando un entorno contiene varios controladores de dominio, es muy útil ver y precisar el controlador de dominio concreto (restringir los demás) que debe utilizarse para la autenticación, de modo que los registros se puedan habilitar y recuperar.
Controlar la selección del controlador de dominio
Para forzar Windows a usar un controlador de dominio Windows concreto para el inicio de sesión, puede establecer explícitamente la lista de los controladores de dominio que una máquina Windows puede utilizar. Para ello, debe configurar el archivo lmhosts: \Windows\System32\drivers\etc\lmhosts.
Por regla general, hay un archivo de muestra denominado “lmhosts.sam” en esa ubicación. Solo necesita incluir una línea:
1.2.3.4 cnetbiosname #PRE #DOM:mydomain
Donde “1.2.3.4” es la dirección IP del controlador de dominio llamado “dcnetbiosname” en el dominio “mydomain”.
Después de reiniciarse, la máquina Windows usará esa información para iniciar sesión en “mydomain”. Tenga en cuenta que esta configuración debe revertirse cuando la depuración se complete.
Identificar el controlador de dominio en uso
Durante el inicio de sesión, Windows aplica una variable de entorno MSDOS con el controlador de dominio que inició la sesión del usuario. Para verlo, inicie el símbolo del sistema con el comando: echo %LOGONSERVER%.
Los registros relacionados con la autenticación se almacenan en el equipo que devuelva este comando.
Habilitar eventos de auditoría de cuentas
De forma predeterminada, los controladores de dominio de Windows no habilitan los registros de auditoría completa de la cuenta. La captura de registros se puede controlar mediante directivas de auditoría, ubicadas en la configuración de seguridad del Editor de directivas de grupo. Una vez habilitadas, el controlador de dominio genera más información de registro de sucesos que se guarda en el archivo del registro de seguridad.
Registros de validación de certificados
Comprobar la validez del certificado
Si un certificado de tarjeta inteligente se exporta como certificado DER (sin clave privada requerida), se puede validar con el comando: certutil –verify user.cer
Habilitar la captura de registros de CAPI
En el controlador de dominio y la máquina de usuarios, abra el visor de eventos y habilite la captura de registros de Microsoft/Windows/CAPI2/Operational Logs.
Puede gestionar la captura de registros CAPI con las claves de Registro en: CurrentControlSet\Services\crypt32.
| Valor | Descripción |
|---|---|
| DiagLevel (DWORD) | Nivel de detalle (de 0 a 5) |
| DiagMatchAnyMask (QUADWORD) | Filtro de eventos (use 0xffffff para todo) |
| DiagProcessName (MULTI_SZ) | Filtrar por nombre del proceso (por ejemplo, LSASS.exe) |
Registros de CAPI
| Mensaje | Descripción |
|---|---|
| Compilar cadena | LSA llamado CertGetCertificateChain (incluye resultado) |
| Comprobar revocación | LSA llamado CertVerifyRevocation (incluye resultado) |
| Objetos X509 | En el modo detallado, los certificados y las listas de revocación de certificados (CRL) se vuelcan en AppData\LocalLow\Microsoft\X509Objects |
| Comprobar directiva de cadena | LSA llamado CertVerifyChainPolicy (incluye parámetros) |
Mensajes de error
| Código de error | Descripción |
|---|---|
| Certificate not trusted (El certificado no es de confianza) | El certificado de tarjeta inteligente no se ha podido crear con certificados provenientes de los almacenes de certificados intermedios y certificados raíz de confianza alojados en el equipo. |
| Certificate revocation check error (Error en la comprobación de revocaciones de certificados) | La lista de revocación de certificados de la tarjeta inteligente no se ha podido descargar desde la dirección que especifica el punto de distribución de la CRL del certificado. Si la comprobación de revocación de certificados es obligatoria, este error impide el inicio de sesión. Consulte la sección Certificados e infraestructura de clave pública. |
| Certificate Usage errors (Errores de uso de certificados) | El certificado no es adecuado para el inicio de sesión. Por ejemplo, puede tratarse de un certificado de servidor o un certificado de firma. |
Registros Kerberos
Para habilitar captura de registros Kerberos, en el controlador de dominio y la máquina del usuario final, cree los siguientes valores de Registro:
| Subárbol de Registro | 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 Kerberos se guarda en el registro de eventos del sistema.
- Los mensajes del tipo “El certificado no es de confianza” deberían ser fáciles de diagnosticar.
- Hay dos códigos de error que son informativos y se pueden ignorar sin consecuencias negativas:
- KDC_ERR_PREAUTH_REQUIRED (utilizado para la compatibilidad con versiones anteriores de controladores de dominio)
- Error desconocido 0x4b
Mensajes del registro de sucesos
En esta sección, se describen entradas de registro previstas en el controlador de dominio y en la estación de trabajo cuando el usuario inicia sesión con un certificado.
- Registro de CAPI2 del controlador de dominio
- Registros de seguridad del controlador de dominio
- Registro de seguridad del VDA
- Registro de CAPI del VDA
- Registro del sistema del VDA
Registro de CAPI2 del controlador de dominio
Durante el inicio de sesión, el controlador de dominio valida el certificado del autor de llamada, con lo que genera la siguiente secuencia de entradas de registro.
El último mensaje del registro de eventos muestra Isass.exe en el controlador de dominio creando una cadena basada en el certificado proporcionado por el agente VDA y comprobando la validez de ese certificado (incluida la revocación). El resultado se devuelve como “ERROR_SUCCESS”.
Registro de seguridad del controlador de dominio
El controlador de dominio muestra una secuencia de eventos de inicio de sesión (la clave es 4768), donde el certificado se usa para emitir el vale de concesión de vales Kerberos (krbtgt).
Los mensajes anteriores a este muestran la cuenta de máquina del servidor que se autentica en el controlador de dominio. Los mensajes siguientes muestran la cuenta de usuario que pertenece al nuevo vale krbtgt que se usa para autenticarse en el controlador de dominio.
Registro de seguridad del VDA
El registro de auditoría de seguridad del VDA que corresponde al evento de inicio de sesión es la entrada cuyo ID de evento es 4648, originado de winlogon.exe.
Registro de CAPI del VDA
En este ejemplo, el registro de CAPI del VDA muestra una sola secuencia de compilación de cadena y comprobación desde lsass.exe, que valida el certificado del controlador de dominio (dc.citrixtest.net).
Registro del sistema del VDA
Si la captura de registros Kerberos está habilitada, el registro del sistema muestra el error KDC_ERR_PREAUTH_REQUIRED (que se puede ignorar) y una entrada de Winlogon con el mensaje de que el inicio de sesión con Kerberos se realizó correctamente.
Mensajes de error del usuario final
En esta sección, se ofrece una lista de los mensajes de error comunes que ve 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 usted tiene un certificado y una clave privada válidos, pero el controlador de dominio Kerberos ha rechazado la conexión. Consulte la sección Registros Kerberos de este artículo. |
| El sistema no pudo iniciar sesión. No se pudieron comprobar las credenciales. | No se puede contactar con el controlador de dominio, o bien, el controlador de dominio no tiene instalados los certificados correspondientes. |
| La solicitud no se admite. | Vuelva a inscribir los certificados “Domain Controller” y “Domain Controller Authentication” en el controlador de dominio, como se describe en CTX206156. Suele valer la pena intentarlo incluso cuando los certificados existentes parezcan válidos. |
| El sistema no pudo iniciar sesión. No se puede determinar el estado de revocación del certificado de la tarjeta inteligente usado para la autenticación. | Los certificados intermedios y de raíz no están instalados en el equipo local. Consulte CTX206156 para obtener instrucciones sobre la instalación de certificados de tarjeta inteligente en equipos sin dominio. Además, consulte la sección Certificados e infraestructura de clave pública en este artículo. |
| No puede iniciar sesión porque el inicio de sesión con tarjeta inteligente no se admite en su cuenta. | No se ha configurado completamente ninguna cuenta de usuario de grupo de trabajo para el inicio de sesión con tarjeta inteligente. |
| La clave solicitada no existe. | Un certificado hace referencia a una clave privada a la que no se puede acceder. Puede ocurrir cuando la tarjeta inteligente PIV no se ha configurado completamente y falta el archivo CHUID o CCC. |
| Ha ocurrido un error al intentar usar la tarjeta inteligente. | El middleware de la tarjeta inteligente no se ha instalado correctamente. Consulte CTX206156 para obtener las instrucciones de instalación de tarjetas inteligentes. |
| Inserte una tarjeta inteligente. | No se ha detectado el lector o la tarjeta inteligente. Si la tarjeta inteligente está insertada, este mensaje indica un problema de hardware o middleware. Consulte CTX206156 para obtener las instrucciones de instalación de tarjetas inteligentes. |
| El PIN no es correcto. | La tarjeta inteligente ha rechazado el PIN especificado por el usuario. |
| No se ha encontrado ningún certificado de tarjeta inteligente válido. | Es posible que las extensiones del certificado no estén configuradas correctamente o puede que la clave RSA sea demasiado corta (<2048 bits). Consulte CTX206901 para obtener información acerca de la generación de certificados de tarjeta inteligente válidos. |
| La tarjeta inteligente está bloqueada. | Se ha bloqueado una tarjeta inteligente (por ejemplo, el usuario ha introducido un PIN incorrecto varias veces). Un administrador puede tener acceso al código PUK (el código para desbloquear el PIN) de la tarjeta inteligente, por lo que puede restablecer el PIN de usuario mediante una herramienta suministrada por el proveedor de la tarjeta inteligente. Si el código PUK no está disponible (o está bloqueado), la tarjeta inteligente debe restablecerse a los parámetros de fábrica. |
| Solicitud incorrecta. | La clave privada de la tarjeta inteligente no admite el cifrado que requiere el controlador de dominio. Por ejemplo, puede que el controlador de dominio haya solicitado “un descifrado de clave privada”, pero la tarjeta inteligente solo admite la firma. Normalmente, esto indica que las extensiones del certificado no están configuradas correctamente o la clave RSA es demasiado corta (<2048 bits). Consulte CTX206901 para obtener información acerca de la generación de certificados de tarjeta inteligente válidos. |
Información relacionada
- Configuración de un dominio para el inicio de sesión con tarjeta inteligente: https://support.citrix.com/article/CTX206156
- Directivas de inicio de sesión de tarjeta inteligente: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)?redirectedfrom=MSDN
- Habilitación del registro de CAPI: https://social.technet.microsoft.com/wiki/contents/articles/242.troubleshooting-pki-problems-on-windows.aspx
- Habilitación del registro de Kerberos: https://support.microsoft.com/en-us/kb/262177
- Instrucciones para habilitar el inicio de sesión mediante tarjeta inteligente con entidades externas de certificación: https://support.microsoft.com/en-us/kb/281245
En este artículo
- Certificados e infraestructura de clave pública
- Nombre UPN y asignación de certificados
- Controlar la selección del controlador de dominio para iniciar sesión
- Habilitar eventos de auditoría de cuentas
- Registros de validación de certificados
- Registros Kerberos
- Mensajes del registro de sucesos
- Registro de CAPI2 del controlador de dominio
- Registro de seguridad del controlador de dominio
- Registro de seguridad del VDA
- Registro de CAPI del VDA
- Registro del sistema del VDA
- Mensajes de error del usuario final
- Información relacionada