Solucionar problemas de inicio de sesión de Windows

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 ofrecen información que puedes usar para solucionar problemas de autenticación.

• Certificados e infraestructura de clave pública

• Windows Active Directory mantiene varias tiendas de certificados que gestionan los certificados para los usuarios que inician sesión.

• Almacén de certificados NTAuth: Para autenticarte en Windows, la autoridad de certificación que emite directamente 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, introduce: 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. Consulta 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).

• AllowSignatureOnlyKeys	Por defecto, Windows filtra las claves privadas de certificados que no permiten el descifrado RSA. Esta opción anula ese filtro.
  AllowTimeInvalidCertificates	Por defecto, 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 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 conexiones Kerberos, todos los servidores deben tener los certificados de “Controlador de dominio” adecuados. Estos se pueden solicitar usando 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

Por defecto, cada usuario en 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 para el bosque. Ten en cuenta que un solo dominio puede tener múltiples 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 (basado en la identidad del proceso que busca el UPN) los UPN explícitos, 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 característica se use 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 en el bosque. Este equipo se puede usar para encontrar eficientemente una cuenta de usuario en cualquier dominio, basándose solo 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 usa para la autenticación, de modo que los registros puedan habilitarse y recuperarse.

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, puedes 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 incluye 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. Ten en cuenta que esta configuración debe revertirse cuando la depuración esté completa.

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 verlo, inicia el símbolo del sistema con el comando: echo %LOGONSERVER%.

Los registros relacionados con la autenticación se almacenan en el equipo que devuelve 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 cuenta. Esto se puede controlar mediante 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.

Registros de validación de certificados

-  ### Comprobar la validez del certificado

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

Habilitar el registro CAPI

• En el controlador de dominio y en el equipo del usuario, abre el Visor de eventos y habilita el registro para Microsoft/Windows/CAPI2/Operational Logs.

• Puedes controlar el registro 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 (usa 0xffffff para todos)
  DiagProcessName (MULTI_SZ)	Filtrar por nombre de proceso (por ejemplo, LSASS.exe)

Registros CAPI

Mensajes de error

Registros de Kerberos

Para habilitar el registro de Kerberos, en el controlador de dominio y en el equipo del usuario final, crea los siguientes valores del Registro:

| Hive | 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 de confianza” deberían ser fáciles de diagnosticar.
• Dos códigos de error son informativos y se pueden ignorar sin problema:
  • KDC_ERR_PREAUTH_REQUIRED (se usa 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 Virtual Delivery Agent (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 emisor, generando una secuencia de entradas de registro con el siguiente formato.

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 su validez (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, siendo el evento clave el 4768, donde el certificado se usa 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 usándose para autenticarse en el controlador de dominio.

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, originado por winlogon.exe.

Registro CAPI del VDA

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

Registro del sistema del 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 fue exitoso.

Mensajes de error para el 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.

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/en-us/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 de Kerberos: https://support.microsoft.com/en-us/kb/262177
• Directrices para habilitar el inicio de sesión con tarjeta inteligente con autoridades de certificación de terceros: https://support.microsoft.com/en-us/kb/281245