Punti chiave
- Conosca i sette event ID Windows che contano per l'audit dei logon AD e perché i veri logoff restano sulle postazioni.
- Costruisca uno script PowerShell parallelizzato che recupera la cronologia logon da ogni domain controller in pochi secondi.
- Pianifichi la retention dei log con una formula di sizing, impostazioni GPO e Windows Event Forwarding verso un SIEM.
- Confronti audit nativo, auditor di terze parti e prevenzione FIDO2 come tre risposte a una sola domanda.
Tracciare logon e logoff degli utenti in Active Directory significa combinare impostazioni di audit Group Policy, i giusti event ID Windows (4624, 4625, 4634, 4647, 4768, 4769, 4776), PowerShell su larga scala, forwarding dei log a un SIEM e una strategia di retention allineata a SOX, HIPAA, PCI DSS 4.0, NIS2 e DORA. I domain controller emettono ticket Kerberos ma non vedono mai la fine della sessione: il forwarding di eventi dalle postazioni non è opzionale in qualsiasi parco ibrido moderno.
Tre giorni. Questa è la profondità tipica dei log di sicurezza dei domain controller prima della sovrascrittura, lasciando gli amministratori al buio non appena si presenta un account lockout, un incidente interno o un'indagine su credenziali compromesse. L'audit nativo di Active Directory è stato progettato per postazioni statiche e domini on-prem, non per farm RDS, tunnel VPN, identità ibrida e sessioni SaaS in parallelo. Questa guida percorre ogni livello: dall'event 4624 sul domain controller all'autenticazione FIDO2 phishing-resistente che rimuove, alla fonte, gran parte del rumore legato alle password dalla pipeline di audit.
Audit nativo dei logon AD: configurazione GPO, event ID e limiti reali
Abilitare l'audit Logon/Logoff tramite Advanced Audit Policy Configuration
Le impostazioni di default di audit logon su un dominio appena installato sono troppo permissive per la forensica e troppo silenziose per la compliance. Apra la Default Domain Controllers Policy e vada a Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Logon/Logoff. Abiliti Success e Failure su Logon, Logoff, Account Lockout e Special Logon. Combini con Account Logon > Audit Kerberos Authentication Service e Audit Credential Validation per catturare i tentativi di fallback NTLM.
Riferimento Event ID (4624, 4625, 4634, 4647, 4768, 4769, 4776) e perché i domain controller non registrano veri eventi di logoff
| Event ID | Significato | Dove viene loggato |
|---|---|---|
| 4624 | Logon riuscito | DC + postazione |
| 4625 | Logon fallito | DC + postazione |
| 4634 / 4647 | Logoff / logoff iniziato dall'utente | Solo postazione |
| 4768 / 4769 | TGT Kerberos / ticket di servizio | Domain controller |
| 4776 | Validazione di credenziali NTLM | Domain controller |
I domain controller emettono ticket Kerberos ma non vedono mai la fine della sessione: i veri logoff vivono sugli endpoint, non sul DC. Il riferimento event 4624 di Microsoft Learn documenta lo schema completo e i Logon Type code che cambiano l'interpretazione a valle.
Script PowerShell per recuperare la cronologia logon su tutti i domain controller
Script moderno con Get-WinEvent + FilterHashtable e processing parallelo
Get-EventLog è deprecato dal PowerShell 5 e collassa su foreste di grandi dimensioni. Usi Get-WinEvent con un FilterHashtable e interroghi ogni domain controller in parallelo:
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
Aggiunga un try/catch attorno a ogni chiamata remota per gestire i DC non raggiungibili senza interrompere l'esecuzione.
Correlare le coppie 4624/4634 e tracciare le sessioni RDS/VPN
La vera durata di sessione richiede di accoppiare ogni 4624 con il suo 4634/4647 corrispondente tramite LogonID (Properties[7]). Per RDS interroghi Microsoft-Windows-TerminalServices-LocalSessionManager/Operational (ID 21, 23, 25) sui session host. Per VPN parsi RRAS o i log del suo concentratore e faccia join su nome utente e timestamp.
Centralizzare e conservare i log di logon senza perdere dati
I limiti di default del log di sicurezza (spesso 128 MB) spiegano perché gli amministratori su Spiceworks segnalano ripetutamente che «i log risalgono solo a tre giorni». La retention va progettata, non assunta.
Formula di sizing e impostazioni GPO per impedire la sovrascrittura dei log
Usi questa formula: eventi/utente/giorno × utenti × giorni di retention × 1,5 KB = dimensione log richiesta. Per 500 utenti che generano ~80 eventi/giorno su 90 giorni, pianifichi ~5,4 GB per DC. Configuri tramite Computer Configuration > Policies > Windows Settings > Security Settings > Event Log: imposti la dimensione massima, scelga Archivia il log quando è pieno invece di sovrascrivere, e monitorizzi la pressione disco sui domain controller.
Windows Event Forwarding (WEF) + SIEM/Splunk per ambienti ibridi AD + Entra ID
Distribuisca un collector WEF, propaghi una GPO che definisce l'URL del subscription manager e filtri gli event ID 4624/4625/4634/4647/4776 via XPath. Forward verso Splunk tramite un heavy forwarder, poi ingerisca i log di sign-in Entra ID tramite Graph API per correlare le identità ibride in un'unica vista.
Dal rilevamento alla prevenzione: come FIDO2 e il passwordless riducono la sua superficie di audit
Il rilevamento scala linearmente con il rumore delle password. Il Verizon 2025 DBIR colloca l'abuso di credenziali nel 22% di tutte le violazioni, e le credenziali rubate insieme al phishing superano la metà degli incidenti con elemento umano. Tolga la password e quel vettore collassa alla fonte: brute force, password spraying e tentativi di downgrade NTLM scompaiono. Il suo SOC smette di smistare tempeste di 4625 e inizia a cacciare anomalie reali.
Volume SIEM prima/dopo e ricette di pattern MITRE ATT&CK (T1078, T1110, T1558)
Su un parco di 1.000 utenti, si aspetti che gli eventi 4625/4776 calino di un ordine di grandezza dopo un rollout Hideez FIDO2. Le credenziali legate all'hardware neutralizzano T1110 (brute force), T1558 (Kerberoasting) e gran parte delle varianti T1078 (valid accounts), perché la chiave privata non lascia mai la security key.
Mappatura compliance: SOX, HIPAA, PCI DSS 4.0, NIS2 e DORA
PCI DSS 4.0 §8.4 e NIS2 Articolo 21 richiedono esplicitamente l'autenticazione phishing-resistente. FIDO2 soddisfa entrambi pur producendo registri di logon a prova di manomissione che gli auditor accettano.
DORA Articolo 9 estende la stessa aspettativa alle entità finanziarie UE, e NIST SP 800-63B definisce il livello di assurance AAL3 a cui tutti e cinque i framework fanno in ultima analisi riferimento.
Framework decisionale: audit nativo vs. auditor di terze parti vs. soluzione a livello di autenticazione
Scegliere tra audit nativo AD, un auditor dedicato e un controllo a livello di autenticazione non è una decisione binaria. Ogni livello risponde a una domanda distinta: cosa è successo, cosa sta succedendo ora e cosa non dovrebbe mai succedere.
Matrice di valutazione: costo, copertura ibrida, alerting in tempo reale e prevenzione vs. rilevamento
| Criterio | AD nativo | Auditor di terze parti | Hideez (livello auth) |
|---|---|---|---|
| Costo | Gratuito | 3-8 $/utente/anno | Per chiave + licenza |
| Copertura ibrida Entra ID | Parziale | Variabile | Completa |
| Alerting in tempo reale | No | Sì | N/D (previene) |
| Approccio | Rilevamento | Rilevamento | Prevenzione |
Quando ADAudit Plus, UserLock o Netwrix bastano — e perché Hideez li completa
Se la sua priorità sono prove forensi e reporting SOC 2, un auditor di terze parti copre bene il livello di rilevamento. Hideez non li sostituisce; rimuove gli eventi basati su credenziali sui quali spendono cicli di triage, in un'architettura a livelli, lasciando alle regole dell'auditor il compito di concentrarsi sulle anomalie reali invece che sul rumore delle password.
Hideez sostituisce la superficie d'attacco delle credenziali con login FIDO2 phishing-resistenti che gli auditor accettano e i SOC adorano. Prenoti una demo per vedere come si integra nel suo parco AD o Entra ID ibrido, o diventi partner Hideez per offrire lo stesso vantaggio ai suoi clienti.
Domande frequenti
Perché Active Directory non registra veri eventi di logoff sul domain controller?
Il modello di ticket Kerberos autentica l'utente una sola volta; poi la sessione vive sulla postazione. Il DC emette un TGT ma non sa quando l'utente chiude la sua sessione di accesso. Gli eventi di logoff (4634, 4647) vengono scritti localmente sull'endpoint, non centralmente. Per catturarli, faccia il forward dei log della postazione tramite Windows Event Forwarding verso un collector o un SIEM.
Come ottengo la cronologia logon utente AD con PowerShell su tutti i domain controller?
Usi Get-WinEvent -FilterHashtable contro ogni DC restituito da Get-ADDomainController -Filter *, con ForEach-Object -Parallel per la scala. Filtri sull'event ID di logon 4624, esporti in CSV, poi correli con 4634 per calcolare la durata reale della sessione.
Audit di logon vs. autenticazione senza password: quale riduce davvero il rischio legato alle credenziali?
L'audit rileva a posteriori. L'autenticazione FIDO2 hardware elimina la superficie d'attacco, neutralizzando brute force, phishing e password spraying alla radice.
