1 14/10/2026 8 min

Se devi capire chi ha creato un account utente in Active Directory, la risposta giusta non è “andare a tentativi” sui controller di dominio: serve verificare il tracciamento degli eventi di sicurezza. In AD la creazione di un utente genera normalmente l’evento 4720 nel registro Security del Domain Controller che ha ricevuto l’operazione. Da lì puoi risalire all’account amministrativo che ha eseguito la creazione, all’orario, e spesso anche alla workstation o al processo di origine, se l’auditing è configurato bene.

La cosa importante è questa: non sempre il dato è ancora disponibile. Se il log è troppo corto, ruotato, filtrato male o non inoltrato a un SIEM, potresti non trovare nulla. In quel caso non bisogna inventare: si verifica prima se l’audit era attivo e dove finiscono gli eventi. Se il log c’è, il percorso è lineare; se non c’è, l’unica strada seria è chiudere il gap di logging per il futuro.

Dove guardare per primo: l’evento 4720

L’evento da cercare è 4720 - A user account was created. Lo trovi nel registro Security del Domain Controller che ha processato la richiesta. I campi più utili sono quelli che identificano:

  • Subject: l’account che ha eseguito l’azione
  • Target Account: l’utente creato
  • Caller Computer Name o dati correlati: da quale macchina è partita l’operazione, se disponibili
  • Time Created: finestra temporale dell’evento

In pratica, il campo davvero decisivo è il Subject: è lì che trovi l’identità di chi ha creato l’utente, non il nuovo account stesso. Se l’operazione è avvenuta tramite script, tool di provisioning o console remota, il soggetto può essere un account di servizio o un amministratore delegato, e non la persona che ha materialmente cliccato nel pannello.

Ricerca rapida dal Domain Controller

Se hai accesso al DC, puoi cercare l’evento direttamente con PowerShell. Questo è il modo più rapido per verificare se il dato esiste davvero:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720} -MaxEvents 20 |
Select-Object TimeCreated, Id, ProviderName, Message | Format-List

Se l’output è troppo verboso, filtra per nome account creato o per intervallo orario:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720; StartTime=(Get-Date).AddHours(-24)} |
Where-Object {$_.Message -match 'NomeUtente'} |
Select-Object TimeCreated, Message

Quando il messaggio è disponibile, cerca le righe che riportano Subject: e New Account:. Il primo indica chi ha creato l’account, il secondo quale utente è stato creato. Se il messaggio non compare, il problema non è “tecnico” ma di visibilità: o il log è stato ripulito, o l’auditing non era attivo, o stai guardando il DC sbagliato.

Correlare l’evento con il controller corretto

In ambienti con più Domain Controller, l’evento può trovarsi solo sul nodo che ha gestito la scrittura, almeno prima della replica. Se cerchi sul DC “sbagliato” potresti non vedere nulla o vedere l’evento più tardi. Per questo, se sai l’orario approssimativo, conviene controllare i DC più vicini alla creazione o quelli che ricevono più spesso le richieste amministrative.

Un controllo utile è verificare la replica e la coerenza dei log con strumenti nativi:

repadmin /replsummary
repadmin /showrepl

Questi comandi non ti dicono chi ha creato l’utente, ma ti aiutano a capire se stai cercando nel posto giusto e se ci sono problemi di replica che falsano la lettura degli eventi. Se la replica è in ritardo, l’account può esistere in AD ma il log non essere ancora allineato con quello che vedi da un altro controller.

Se il 4720 non basta: eventi collegati da usare in catena

In un audit fatto bene, il 4720 non è l’unico evento utile. A seconda di come è stata eseguita l’operazione, puoi correlare anche:

  • 4624: logon riuscito dell’account amministrativo
  • 4672: privilegi speciali assegnati a un logon
  • 4722: account utente abilitato, se la procedura prevedeva creazione e successiva attivazione
  • 4728 / 4732 / 4756: aggiunta a gruppi privilegiati, spesso successiva alla creazione
  • 4738: modifica dell’account, utile per capire se il provisioning ha fatto altro oltre alla creazione

La lettura corretta è sequenziale: prima individui il 4720, poi verifichi se nello stesso intervallo temporale c’è un 4624 o un 4672 dello stesso soggetto, infine controlli se l’account appena creato è stato inserito in gruppi sensibili. Questo ti permette di capire non solo chi ha creato l’utente, ma anche cosa ha fatto subito dopo.

Ricerca nel Visualizzatore eventi

Se preferisci la GUI, il percorso è quello classico del Visualizzatore eventi sul Domain Controller. Vai su Windows Logs → Security e filtra per Event ID 4720. Se hai troppi eventi, restringi per intervallo orario o per nome account creato.

Il vantaggio della GUI è che vedi subito il dettaglio leggibile del messaggio. Lo svantaggio è che, in ambienti con molto rumore, la ricerca manuale è lenta e fragile. Per questo in pratica conviene usare la GUI solo per confermare il dato, non come metodo principale di indagine.

Se hai centralizzazione dei log, la ricerca va fatta nel SIEM o nel collector, non sul singolo DC. In quel caso l’artefatto da cercare è sempre lo stesso: Event ID 4720, con il relativo Subject. Il vantaggio è che puoi cercare in modo trasversale su più controller e non dipendere dalla retention locale di Windows.

Quando l’auditing non è stato attivato

Qui c’è il punto più delicato: se l’auditing della directory non era configurato, potresti non avere abbastanza evidenza per stabilire chi abbia creato l’utente. Non è una lacuna da coprire con supposizioni. Si verifica invece se la policy di audit era presente e se il log Security conserva ancora gli eventi.

Puoi controllare la policy applicata sul DC con:

auditpol /get /category:*

Per gli ambienti moderni, ti interessa soprattutto che la categoria relativa alla gestione degli account e alla directory service access sia effettivamente tracciata. Se non è stata abilitata, non puoi ricostruire il passato con affidabilità: puoi solo correggere la configurazione per il futuro.

Come rendere la risposta affidabile in produzione

Se questa domanda nasce spesso, la soluzione non è scavare ogni volta a mano. La soluzione è predisporre un minimo di osservabilità:

  • abilitare l’auditing della creazione account su tutti i DC rilevanti
  • inoltrare i Security log verso un collector centralizzato o SIEM
  • allungare la retention dei log rispetto alla finestra di indagine tipica
  • documentare quali gruppi o OU possono creare utenti e con quali account di servizio

Questo riduce il tempo di diagnosi da ore a minuti. Inoltre evita il classico problema operativo: un account viene creato di venerdì sera, il log locale ruota nel weekend e lunedì non c’è più nessuna prova utile. In AD, senza retention e forwarding, il dato storico è fragile per definizione.

Esempio di lettura corretta dell’evento

Supponiamo di trovare un 4720 con questi elementi: il Subject è un account amministrativo delegato, il New Account è un utente appena creato, e il timestamp coincide con l’orario del ticket interno. In quel caso hai già una risposta solida: l’account è stato creato da quell’identità, su quel DC, in quel momento. Se subito dopo compare un 4732 che aggiunge il nuovo utente a un gruppo privilegiato, hai anche una seconda informazione importante: la creazione non è stata un semplice provisioning, ma un’operazione con impatto di sicurezza da verificare.

Se invece trovi il 4720 ma il Subject è un account di servizio, devi risalire al processo o al tool che lo usa. In quel caso la domanda si sposta da “chi ha creato l’utente” a “quale sistema ha creato l’utente e con quale workflow”. È una differenza sostanziale, soprattutto quando la creazione è automatizzata da HR, IAM o script di provisioning.

Se vuoi tracciare il dato in modo più robusto

Per ambienti con controllo serio degli accessi, conviene associare la creazione account ad almeno tre livelli di prova: evento AD, account che ha eseguito l’azione, origine operativa. Il primo ti dice che l’oggetto è stato creato; il secondo ti dice chi lo ha fatto; il terzo ti aiuta a capire da quale console o host è partita l’operazione. Senza il terzo livello, spesso hai solo metà della storia.

Se usi Windows Event Forwarding o un SIEM, conserva almeno questi metadati: timestamp, hostname del DC, Event ID, Subject, Target Account e, se disponibile, Caller Computer Name. Sono i campi che servono davvero quando devi rispondere a un audit interno o ricostruire un’azione sospetta senza perdere tempo in schermate poco utili.

Conclusione operativa

Per scoprire chi ha creato un account in Active Directory, la strada corretta è cercare l’evento 4720 nel Security log del Domain Controller e leggere il campo Subject. Se il dato non c’è, non si forza una risposta: si verifica se l’audit era attivo, se i log sono stati conservati e se la ricerca va estesa a un SIEM o a più DC. In pratica, il risultato dipende quasi sempre dalla qualità del logging, non da qualche trucco nascosto. Assunzione: ambiente Windows domain-based con almeno un Domain Controller e logging di sicurezza accessibile all’operatore autorizzato.