Puntos clave
- Conozca los siete event IDs de Windows que importan para auditar logons en AD y por qué el verdadero logoff queda en las workstations.
- Construya un script PowerShell paralelizado que extraiga el historial de logon de cada domain controller en segundos.
- Planifique la retención de logs con una fórmula de dimensionamiento, ajustes de GPO y Windows Event Forwarding hacia un SIEM.
- Compare auditoría nativa, auditores de terceros y prevención FIDO2 como tres respuestas a una sola pregunta.
Rastrear el logon y logoff de usuarios en Active Directory implica combinar configuraciones de auditoría de Group Policy, los event IDs de Windows correctos (4624, 4625, 4634, 4647, 4768, 4769, 4776), PowerShell a escala, reenvío de logs hacia un SIEM y una estrategia de retención alineada con SOX, HIPAA, PCI DSS 4.0, NIS2 y DORA. Los domain controllers emiten tickets Kerberos pero nunca observan el final de la sesión, por lo que el reenvío de eventos desde la workstation es obligatorio en cualquier estado híbrido moderno.
Tres días. Hasta ahí llegan los logs de seguridad de la mayoría de los domain controllers antes de sobrescribirse, dejando a los administradores a ciegas cuando aparece un bloqueo de cuenta, un incidente interno o una investigación de credenciales comprometidas. La auditoría nativa de Active Directory se diseñó para workstations estáticas y dominios on-prem, no para granjas RDS, túneles VPN, identidad híbrida y sesiones SaaS corriendo en paralelo. Esta guía recorre cada capa: desde el event 4624 en el domain controller hasta la autenticación FIDO2 phishing-resistente que retira la mayor parte del ruido relacionado con contraseñas de su pipeline de auditoría en el origen.
Auditoría nativa de logons en AD: configuración GPO, event IDs y límites reales
Habilitar la auditoría de Logon/Logoff mediante Advanced Audit Policy Configuration
Los ajustes por defecto de audit logon en un dominio recién instalado son demasiado permisivos para forensia y demasiado silenciosos para compliance. Abra la Default Domain Controllers Policy y vaya a Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Logon/Logoff. Habilite Success y Failure en Logon, Logoff, Account Lockout y Special Logon. Combínelo con Account Logon > Audit Kerberos Authentication Service y Audit Credential Validation para capturar los intentos de fallback NTLM.
Referencia de Event IDs (4624, 4625, 4634, 4647, 4768, 4769, 4776) y por qué los domain controllers no registran verdaderos eventos de logoff
| Event ID | Significado | Dónde se registra |
|---|---|---|
| 4624 | Logon exitoso | DC + workstation |
| 4625 | Logon fallido | DC + workstation |
| 4634 / 4647 | Logoff / logoff iniciado por el usuario | Solo workstation |
| 4768 / 4769 | TGT Kerberos / ticket de servicio | Domain controller |
| 4776 | Validación de credenciales NTLM | Domain controller |
Los domain controllers emiten tickets Kerberos pero nunca ven el final de la sesión, así que los verdaderos logoffs viven en los endpoints, no en el DC. La referencia del event 4624 en Microsoft Learn documenta el esquema completo y los Logon Type codes que cambian la interpretación aguas abajo.
Scripts PowerShell para extraer el historial de logon en todos los domain controllers
Script moderno con Get-WinEvent + FilterHashtable y procesamiento en paralelo
Get-EventLog está deprecado desde PowerShell 5 y colapsa en bosques grandes. Use Get-WinEvent con un FilterHashtable y consulte cada domain controller en paralelo:
powershell
$DCs = (Get-ADDomainController -Filter *).HostName
$DCs | ForEach-Object -Parallel {
Get-WinEvent -ComputerName $_ -FilterHashtable @{
LogName='Security'; ID=4624,4625; StartTime=(Get-Date).AddDays(-7)
} | Select TimeCreated, MachineName, @{n='User';e={$_.Properties[5].Value}}
} -ThrottleLimit 10 | Export-Csv .\logons.csv -NoTypeInformation
Añada try/catch alrededor de cada llamada remota para gestionar DCs no accesibles sin abortar la ejecución.
Correlacionar pares 4624/4634 y rastrear sesiones RDS/VPN
La verdadera duración de sesión requiere emparejar cada 4624 con su 4634/4647 correspondiente mediante LogonID (Properties[7]). Para RDS, consulte Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (IDs 21, 23, 25) en los session hosts. Para VPN, parsee RRAS o los logs de su concentrador y haga join por nombre de usuario y timestamp.
Centralizar y retener logs de logon sin perder datos
Los topes por defecto del log de seguridad (a menudo 128 MB) explican por qué los administradores en Spiceworks reportan repetidamente que «los logs solo llegan a tres días». La retención debe diseñarse, no asumirse.
Fórmula de dimensionamiento y ajustes de GPO para evitar que los logs se sobrescriban
Use esta fórmula: eventos/usuario/día × usuarios × días de retención × 1,5 KB = tamaño de log requerido. Para 500 usuarios generando ~80 eventos/día durante 90 días, planifique ~5,4 GB por DC. Configure mediante Computer Configuration > Policies > Windows Settings > Security Settings > Event Log: fije el tamaño máximo, elija Archivar el log cuando esté lleno en lugar de sobrescribir, y monitorice la presión de disco en los domain controllers.
Windows Event Forwarding (WEF) + SIEM/Splunk para entornos híbridos AD + Entra ID
Despliegue un WEF collector, distribuya una GPO con la URL del subscription manager y filtre los event IDs 4624/4625/4634/4647/4776 mediante XPath. Reenvíe a Splunk a través de un heavy forwarder y luego ingiera los logs de sign-in de Entra ID vía Graph API para correlacionar identidades híbridas en un único panel.
De la detección a la prevención: cómo FIDO2 y passwordless reducen su superficie de auditoría
La detección escala linealmente con el ruido de contraseñas. El Verizon 2025 DBIR sitúa el abuso de credenciales en el 22 % de todas las brechas, y las credenciales robadas más el phishing combinados superan la mitad de los incidentes con elemento humano. Retire la contraseña y ese vector colapsa en su origen: brute force, password spraying y los intentos de downgrade NTLM desaparecen. Su SOC deja de triar tormentas de 4625 y empieza a cazar anomalías reales.
Volumen de SIEM antes/después y recetas de patrones MITRE ATT&CK (T1078, T1110, T1558)
En un parque de 1.000 usuarios, espere que los eventos 4625/4776 caigan en un orden de magnitud tras un despliegue de Hideez FIDO2. Las credenciales ligadas al hardware neutralizan T1110 (brute force), T1558 (Kerberoasting) y la mayoría de variantes de T1078 (valid accounts) porque la clave privada nunca abandona el security key.
Mapeo de compliance: SOX, HIPAA, PCI DSS 4.0, NIS2 y DORA
PCI DSS 4.0 §8.4 y NIS2 Artículo 21 exigen explícitamente autenticación phishing-resistente. FIDO2 satisface ambos mientras produce registros de logon a prueba de manipulaciones que los auditores aceptan.
DORA Artículo 9 extiende la misma exigencia a las entidades financieras de la UE, y NIST SP 800-63B define el nivel de aseguramiento AAL3 al que en última instancia remiten los cinco frameworks.
Marco de decisión: auditoría nativa vs. auditor de terceros vs. solución de capa de autenticación
Elegir entre auditoría nativa de AD, un auditor dedicado y un control de capa de autenticación no es una decisión binaria. Cada capa responde a una pregunta distinta: qué pasó, qué está pasando ahora y qué nunca debería pasar.
Matriz de puntuación: coste, cobertura híbrida, alertas en tiempo real y prevención frente a detección
| Criterio | AD nativo | Auditor de terceros | Hideez (capa de autenticación) |
|---|---|---|---|
| Coste | Gratis | 3-8 $/usuario/año | Por key + licencia |
| Cobertura híbrida de Entra ID | Parcial | Variable | Total |
| Alertas en tiempo real | No | Sí | N/A (previene) |
| Enfoque | Detección | Detección | Prevención |
Cuándo ADAudit Plus, UserLock o Netwrix son suficientes — y por qué Hideez los complementa
Si su prioridad son las pruebas forenses y el reporting SOC 2, un auditor de terceros cubre bien la capa de detección. Hideez no los reemplaza; retira los eventos basados en credenciales en cuyo triaje gastan ciclos, en una arquitectura por capas, dejando que las reglas del auditor se centren en anomalías reales en lugar de ruido de contraseñas.
Hideez sustituye la superficie de ataque de credenciales con logins FIDO2 phishing-resistentes que los auditores aceptan y los SOCs adoran. Reserve una demo para ver cómo encaja en su entorno AD o Entra ID híbrido, o conviértase en partner de Hideez para ofrecer el mismo beneficio a sus clientes.
Preguntas frecuentes
¿Por qué Active Directory no registra verdaderos eventos de logoff en el domain controller?
El modelo de tickets Kerberos autentica al usuario una sola vez; después la sesión vive en la workstation. El DC emite un TGT pero no es consciente de cuándo el usuario cierra su sesión de acceso. Los eventos de logoff (4634, 4647) se escriben localmente en el endpoint, no de forma centralizada. Para capturarlos, reenvíe los logs de la workstation mediante Windows Event Forwarding a un colector o SIEM.
¿Cómo obtengo el historial de logon de usuarios de AD con PowerShell en todos los domain controllers?
Use Get-WinEvent -FilterHashtable contra cada DC devuelto por Get-ADDomainController -Filter *, con ForEach-Object -Parallel para escala. Filtre por el event ID 4624, exporte a CSV y luego correlacione con 4634 para calcular la duración real de sesión.
Auditoría de logon vs. autenticación sin contraseña: ¿cuál reduce de verdad el riesgo de credenciales?
La auditoría detecta a posteriori. La autenticación FIDO2 por hardware elimina la superficie de ataque, neutralizando brute force, phishing y password spraying en la raíz.