Solucionar problemas de inicio de sesión de Windows

Last published : Oct 24, 2026
Este artículo describe los registros y los mensajes de error que Windows proporciona cuando un usuario inicia sesión con certificados y/o tarjetas inteligentes. Estos registros proporcionan información que puede utilizar para solucionar problemas de errores de autenticación.
Related information
Configuración avanzada

Certificados e infraestructura de clave pública

Windows Active Directory mantiene varios almacenes de certificados que administran los certificados para los usuarios que inician sesión.
  • Almacén de certificados NTAuth: Para autenticarse en Windows, la autoridad de certificación 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, escriba: 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 de 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 certificados de inicio de sesión y directiva 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/es-es/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)>.
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 utilizando el menú del complemento MMC "Almacén personal de certificados del equipo local".

Asignación de nombre UPN y certificado

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 en Active Directory tiene un UPN implícito basado en el patrón \&lt;samUsername>@\&lt;domainNetBios> y \&lt;samUsername>@\&lt;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 en Active Directory tiene un UPN explícito y altUserPrincipalNames. Estas son entradas LDAP que especifican el UPN para el usuario.
Al buscar usuarios por UPN, Windows busca primero en el dominio actual (basándose en la identidad del proceso que busca el UPN) los UPN explícitos, y luego 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 dicho certificado a un usuario, un equipo puede consultar este atributo directamente (por defecto, 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 particular para el inicio de sesión, puede establecer explícitamente la lista de controladores de dominio que usa 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 #PRE #DOM: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 usa 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 directivas 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 –verificar user.cer

Habilitar el registro de CAPI

En el controlador de dominio y en la máquina de los usuarios, abra el visor de eventos y habilite el registro para Microsoft/Windows/CAPI2/Operational Logs.
Puede controlar el registro de CAPI con las claves de registro en: CurrentControlSet\Services\crypt32.
Valor Descripción
DiagLevel (DWORD) Nivel de detalle (0 a 5)
DiagMatchAnyMask (QUADWORD) Filtro de eventos (usar 0xffffff para todos)
DiagProcessName (MULTI_SZ) Filtrar por nombre de proceso (por ejemplo, LSASS.exe)

Registros 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 Directiva de cadena LSA llamó a CertVerifyChainPolicy (incluye 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 certificados de los almacenes de certificados raíz intermedios y 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 (/es-es/federated-authentication-service/1912-ltsr/config-manage/troubleshoot-logon.html#certificates-and-public-key-infrastructure) [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 (se utiliza 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 del Virtual Delivery Agent (VDA)
  • Registro CAPI del VDA
  • Registro del sistema del VDA

Registro CAPI2 del controlador de dominio

Durante un inicio de sesión, el controlador de dominio valida el certificado del emisor, lo que produce una secuencia de entradas de registro con el siguiente formato.
imagen localizada
El mensaje final del registro de eventos muestra lsass.exe en el controlador de dominio construyendo una cadena basada en el certificado proporcionado por el VDA y verificando 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 del VDA

El registro de auditoría de seguridad del 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 registro CAPI de VDA de ejemplo muestra una única secuencia de compilación y verificación de cadena de lsass.exe, validando el certificado del controlador de dominio (dc.citrixtest.net).
imagen localizada
imagen localizada

Registro del sistema de 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 muestra que el inicio de sesión de Kerberos fue correcto.
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. / La solicitud no es compatible No se puede contactar con el controlador de dominio, o el controlador de dominio no se ha configurado con un certificado para admitir la autenticación con tarjeta inteligente. Inscriba el controlador de dominio para un certificado de "Autenticación Kerberos", "Autenticación de controlador de dominio" o "Controlador de dominio". Esto suele valer la pena intentarlo, incluso cuando el certificado existente parece ser válido.
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 Certificados e infraestructura de clave pública.
Solicitud incorrecta Esto suele indicar que las extensiones del certificado no están configuradas correctamente, o que la clave RSA es demasiado corta (<2048 bits).

Información relacionada

  • Configuración de un dominio para el inicio de sesión con tarjeta inteligente: <http://support.citrix.com/article/CTX206156>
  • Directivas de inicio de sesión con tarjeta inteligente: <https://docs.microsoft.com/es-es/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff404287(v=ws.10)>
  • Habilitación del registro CAPI: <http://social.technet.microsoft.com/wiki/contents/articles/242.troubleshooting-pki-problems-on-windows.aspx>
  • Habilitación del registro Kerberos: <https://support.microsoft.com/es-es/kb/262177>
  • Directrices para habilitar el inicio de sesión con tarjeta inteligente con autoridades de certificación de terceros: <https://support.microsoft.com/es-es/kb/281245>