Cómo verificar CachedLogonsCount: REG_SZ e inicio sin conexión

¿Qué es la verificación de los inicios de sesión de dominio en caché?

La verificación de los inicios de sesión de dominio en caché conecta tres pruebas en una misma estación piloto: la directiva de equipo aplicada, el valor y el tipo del registro local, y un inicio de sesión sin conexión observado. Un hallazgo a nivel de directiva inicia esa investigación. No identifica una cuenta privilegiada en la caché ni demuestra que la estación haya sido comprometida.

Microsoft documenta CachedLogonsCount en HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon como REG_SZ. Su referencia sobre los inicios de sesión de dominio en caché indica que cero desactiva la caché y que los cambios directos en esta clave de registro requieren un reinicio. Las indicaciones independientes sobre el reinicio de la Security Option se tratan en la sección de Remediación. Estos detalles importan cuando un recopilador de auditoría espera un tipo de registro distinto o no detecta el canal de distribución de la directiva.

El entregable práctico es un registro de decisión: qué dispositivo se revisó, qué debería permitir, qué se observó realmente y quién aceptó cualquier excepción restante. El procedimiento siguiente propone un flujo de verificación, no informa de pruebas realizadas en un dominio en producción. Las fuentes y el comportamiento del detector se comprobaron el 6 de octubre de 2026; no se ejecutó ningún inicio de sesión de Windows ni ningún comando de remediación para este artículo.

Cómo funciona: separar directiva, tipo y disponibilidad

Utilice tres niveles de prueba con conclusiones separadas:

Los dos primeros son observaciones de configuración. El tercero es una observación de comportamiento con una identidad, una máquina y un momento concretos. Mantenga esas precisiones en la conclusión final. Una prueba satisfactoria en un portátil no cubre todos los portátiles de su OU, y una prueba fallida necesita una explicación antes de respaldar una decisión de cambio.

Nuestra guía de refuerzo de RDP separa las decisiones sobre NLA, la capa de seguridad y la delegación de credenciales. Ya trata la configuración de los inicios de sesión en caché junto con esos controles. Este flujo añade las pruebas necesarias cuando el hallazgo sobre los inicios de sesión en caché contradice la configuración del equipo; no repite la guía general de configuración de RDP.

Mantenga separado también el trabajo de aislamiento de credenciales. La guía de Credential Guard tras una actualización comprueba las excepciones heredadas y el servicio en ejecución. Utilice esa investigación para su propia pregunta sobre el estado de protección. Ni una lectura del registro de inicios de sesión en caché ni el detector descrito a continuación mide el funcionamiento de Credential Guard.

Definir primero el piloto y el comportamiento requerido

Antes de recopilar pruebas, designe al responsable del piloto y el flujo de trabajo del usuario que requiere acceso sin conexión. Describa el resultado esperado en términos operativos: por ejemplo, si un usuario de prueba no privilegiado designado debe llegar al escritorio local durante una pérdida planificada de conectividad con el dominio. Es un criterio de aceptación específico de la organización, no una cuota de caché universal de Microsoft o de ANSSI.

Registre la autoridad de cambio, la ventana de mantenimiento, el contacto de recuperación y la fecha de revisión. Si no existe un requisito sin conexión acordado, no permita que el mensaje del detector se convierta implícitamente en ese requisito. Pida al responsable que elija el comportamiento previsto antes de proponer un valor.

Verificación: conciliar la GPO aplicada y el REG_SZ local

Paso 1: capturar el informe de directiva resultante del equipo

En el piloto, utilice la sintaxis y las opciones de salida documentadas de gpresult. Estos comandos locales adaptan esa sintaxis al ámbito de equipo; ejecute cada uno por separado en un símbolo del sistema de Windows autorizado:

gpresult /scope computer /r

gpresult /scope computer /h cached-logon-computer-policy.html

El primero devuelve datos de resumen; el segundo guarda un informe HTML. En Windows ARM64, Microsoft especifica que la opción /h requiere el ejecutable gpresult de SysWow64. El nombre de archivo relativo es un ejemplo: seleccione el directorio de pruebas aprobado para la revisión real. Conserve la identidad del equipo y la hora de recopilación del informe y después examine las pruebas específicas de la configuración disponibles en él. Una lista de nombres de GPO aplicadas aporta contexto útil, pero no identifica por sí sola qué valor prevaleció para esta Security Option.

Para la GPO pertinente, conserve su nombre, GUID, versión y la configuración exacta de inicio de sesión en caché obtenida de las pruebas administrativas. Compárelos con la información de directiva resultante del piloto. Cuando el informe no establezca el origen de la configuración, registre la procedencia como no resuelta y obtenga pruebas específicas del ajuste antes de decidir qué directiva cambiar.

Examine el archivo Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf de la GPO pertinente y su entrada [Registry Values], si existe. Conserve solo el fragmento específico de la configuración y la identidad de la directiva necesarios para esta revisión. Esta comprobación responde al punto ciego documentado del recopilador en el canal estándar, detallado más adelante. Una declaración de SYSVOL todavía debe conciliarse con el piloto; no sustituya las pruebas de directiva aplicada por la declaración de una GPO ajena.

Paso 2: leer el valor local sin ocultar su tipo

Utilice la referencia de reg query con la ruta de Winlogon y el nombre del valor documentados:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount

Es una adaptación de sintaxis de solo lectura, no un comando copiado de un ejemplo desarrollado por Microsoft. Examine el nombre del valor, el tipo y los datos devueltos. Para la configuración documentada, espere la etiqueta de tipo REG_SZ y el texto numérico configurado. No filtre la consulta por DWORD: hacerlo ocultaría precisamente la discrepancia de tipo que se está investigando.

Guarde la salida real junto con el informe de directiva. Si falta el valor, el tipo difiere, falla el acceso o la salida se recopiló en otro equipo, etiquete explícitamente esa observación. Ninguno de esos resultados permite inventar un valor local de diez a partir de un mensaje de auditoría.

Construya una fila de conciliación para el piloto con el origen de directiva notificado, las pruebas de GptTmpl.inf, el tipo y los datos locales, la hora de recopilación y el contexto de reinicio. Asigne un responsable y una acción siguiente a las discrepancias. Por ejemplo, un cero REG_SZ documentado junto con un hallazgo persistente apunta a la limitación del recopilador; no es motivo para reescribir el valor de la estación como DWORD y hacer desaparecer la auditoría.

Detección: conservar LsaSrv 45058 y probar el inicio de sesión sin conexión

El artículo de resolución de problemas de LsaSrv 45058 de Microsoft describe un evento informativo del registro System que registra la expulsión de la entrada de usuario en caché más antigua cuando se alcanza la cuota. El evento identifica al usuario eliminado y la marca de tiempo de la entrada. Proporciona contexto útil para un fallo de inicio de sesión sin conexión; no demuestra un robo de credenciales.

Si el evento existe en el período pertinente, conserve su hora, el equipo, el origen, el identificador del evento, la identidad de prueba eliminada y la marca de tiempo de la entrada. Correlaciónelo con la cronología de inicios de sesión del piloto. Si la recopilación o la retención está incompleta, registre esa carencia. Trate la ausencia de un evento observado como una limitación de las pruebas, no como un inventario completo de identidades en caché.

Paso 3: utilizar una identidad no privilegiada y registrar las condiciones

Elija una identidad de prueba de dominio dedicada y no privilegiada cuyo responsable autorice el ejercicio. Registre cómo se verificó la ausencia de acceso privilegiado mediante el proceso de revisión de cuentas de la organización. No utilice un administrador privilegiado solo porque el título del detector menciona cuentas privilegiadas.

Planifique una prueba de inicio de sesión en la consola local con una vía de recuperación aprobada. Registre la referencia inicial con conexión, la condición de red controlada, cómo se excluyó la accesibilidad a los controladores de dominio, el método de inicio de sesión y el resultado exacto observado. Restaure la conectividad después del ejercicio. Si no puede establecerse la condición de red de la prueba, informe de que el resultado no es concluyente.

La conclusión debe ser acotada: la identidad de prueba identificada llegó o no al escritorio del piloto identificado en las condiciones indicadas. Microsoft señala por separado que el acceso al escritorio sin conexión no da acceso a recursos que requieren validación del dominio. No informe de un acceso satisfactorio al escritorio como si fuera un acceso satisfactorio a los servicios del dominio.

Si una expulsión requiere investigación, utilice un evento 45058 observado para la identidad de prueba o un ejercicio de laboratorio aprobado por separado. No haga rotar cuentas de producción simplemente para forzar un evento. Registre «expulsión no observada» cuando esa sea la prueba disponible. Este protocolo no necesita un volcado de caché, una exportación del verificador, una extracción de subárboles del registro ni una recuperación de contraseñas.

Paso 4: registrar la decisión antes de cambiar la configuración

Un registro de revisión útil puede usar esta plantilla:

Plantee tres preguntas explícitas en la revisión: ¿Qué piloto y qué restricción sin conexión justifican una excepción? ¿Qué pruebas GptTmpl.inf/REG_SZ y qué GPO resultante deben conservarse cuando el hallazgo difiere del estado local? ¿Qué identidad no privilegiada puede demostrar el comportamiento pertinente sin manejar secretos? Nombre al responsable de la decisión en lugar de dejar implícitas estas preguntas.

Remediación: aplicar la decisión y repetir la comprobación piloto (Remediation)

Si la decisión aprobada consiste en cambiar la caché, utilice la Security Option identificada en el artículo 45058 de Microsoft: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options, y después Interactive logon: Number of previous logons to cache (in case domain controller is not available). Limite el cambio a los dispositivos previstos.

Para una decisión de desactivar la caché, Microsoft documenta cero como valor de desactivación. Una excepción que mantenga la caché necesita su propia justificación de flujo de trabajo, un responsable y una fecha de revisión. No convierta el máximo global del detector, su mensaje de valor predeterminado de diez o una expulsión informativa en una cuota universal aceptable.

La referencia de Microsoft sobre esta Security Option indica que los cambios de directiva surten efecto sin reiniciar cuando se guardan localmente o se distribuyen mediante Group Policy. Su artículo de resolución de problemas del registro exige por separado un reinicio para cambios directos en la clave de registro. Registre qué vía de configuración se utilizó y siga las indicaciones documentadas sobre reinicio para esa vía. Una vez que el cambio surta efecto, repita el mismo informe de directiva, la lectura del tipo y valor locales y la prueba piloto controlada. Compare elementos equivalentes: los mismos niveles de prueba y el mismo criterio de aceptación. Conserve las diferencias no resueltas en lugar de cerrar el registro solo porque la auditoría deja de alertar.

Para un usuario afectado por una expulsión, la recuperación documentada por Microsoft consiste en restaurar la conectividad con el controlador de dominio y la resolución de nombres y completar un inicio de sesión de dominio autenticado; volver a almacenar la información en caché depende de que la caché esté habilitada. Mantenga la recuperación separada de una decisión de directiva para ampliar la cuota. Una sesión de usuario restaurada no justifica por sí sola un cambio de configuración en toda la flota.

Cómo detecta EtcSec este problema

La comprobación BP039_PRIV_ACCOUNTS_CACHED de etc-collector de EtcSec, leída en el commit bcd03c54, examina los ajustes de registro de las GPO recopiladas. Cualquier CachedLogonsCount cero observado en cualquier GPO suprime el hallazgo. En caso contrario, devuelve un único hallazgo de gravedad Medium con Count=1, incluso cuando no se ha recopilado ningún valor de GPO. Su valor worstSeen es el máximo entre las GPO recopiladas, no la directiva resultante de cada estación.

El proveedor rellena este campo desde Registry.pol mediante getDWORDValue, que acepta REG_DWORD. Microsoft documenta el ajuste real como REG_SZ. El analizador de GptTmpl.inf no rellena CachedLogonsCount desde [Registry Values]. El propio código del detector explica que, por tanto, el canal estándar de la Security Option puede ser invisible y producir un falso positivo.

Dos consecuencias deben figurar en el registro de revisión. Un cero del canal estándar puede coexistir con un hallazgo; a la inversa, un cero observado en otra GPO puede suprimir el hallazgo sin demostrar la cobertura del piloto. La referencia al valor predeterminado de Windows de diez en el mensaje de ausencia de valor es una inferencia de ese mensaje, no una configuración local medida.

Esta comprobación no observa una cuenta concreta en caché, sus privilegios efectivos, una vulneración, eventos LsaSrv, el comportamiento de inicio de sesión sin conexión ni el funcionamiento de Credential Guard. Trátela como una solicitud de verificar la configuración por el canal correcto. Cierre la revisión piloto con las pruebas de directiva, la observación REG_SZ local, el resultado de comportamiento y la decisión autorizada; mantenga visible cualquier cobertura de la flota no medida.