Configurare il blocco account in Active Directory

Bloccare un account in Active Directory: cosa stai davvero configurando

Il blocco account in Active Directory non è un interruttore unico, ma il risultato di una policy che combina soglia di tentativi errati, finestra di osservazione, durata del lockout e comportamento del reset del contatore. Se imposti male anche solo uno di questi parametri, ottieni l’effetto opposto a quello desiderato: utenti bloccati per errori banali, help desk sommerso, oppure una protezione troppo debole contro i tentativi ripetuti di autenticazione.

In pratica, il punto non è “attivare il blocco”, ma decidere quanto rumore operativo sei disposto ad accettare per ridurre il rischio di password spraying, riuso credenziali e tentativi ripetitivi su servizi esposti. In un dominio ben tenuto, questa scelta va fatta insieme a log di sicurezza, procedure di reset password, MFA e controllo dei client che generano autenticazioni fallite in modo anomalo.

I tre parametri che contano davvero

La configurazione classica del blocco account vive dentro i Account Policies applicati al dominio. I tre valori da leggere insieme sono:

Account lockout threshold: il numero di tentativi errati prima del blocco. Se lo imposti a 0, il blocco è disabilitato. Se lo tieni troppo basso, bastano poche imprecisioni di password da parte di un client vecchio, un servizio salvato male o un’app mobile fuori sync per generare incidenti continui.

Account lockout duration: quanto dura il blocco. Se è troppo breve, il blocco perde efficacia; se è troppo lungo, l’utente resta fermo per errori che spesso non dipendono da lui. In molti ambienti conviene partire da un valore coerente con il tempo necessario per intercettare e correggere la causa, non con una soglia “teorica”.

Reset account lockout counter after: dopo quanti minuti il contatore dei tentativi falliti torna a zero. Questo parametro deve avere senso rispetto alla soglia e alla durata. Se è troppo alto, un utente con pochi errori intermittenti arriva comunque al blocco; se è troppo basso, il contatore si azzera troppo in fretta e la protezione diventa più permissiva di quanto pensi.

Il punto chiave è che questi tre valori non si leggono separatamente. Un lockout threshold di 5, una durata di 15 minuti e un reset dopo 15 minuti hanno un comportamento molto diverso da una combinazione 10/30/15. Prima di toccare la produzione, va definito il profilo d’uso: postazioni fisse, VPN, mobile device, servizi applicativi, account di servizio, vecchi client SMTP o IMAP, sistemi che usano credenziali salvate in task schedulati o servizi Windows.

Dove si configura: Group Policy e non “a mano” sui singoli account

Il blocco account si configura normalmente tramite Group Policy, non sui singoli utenti. La via pulita è un GPO legato al dominio, perché le Account Policies sono, di fatto, policy di dominio. Se provi a distribuirle in modo frammentato su OU o GPO non coerenti, rischi di ottenere comportamenti che sembrano casuali ma non lo sono: in Active Directory, alcune impostazioni di account policy vengono applicate solo a livello di dominio, non come pensano in molti a livello di singola unità organizzativa.

Il percorso operativo, da console, è questo:

1. Apri Group Policy Management.
2. Seleziona il dominio interessato.
3. Modifica il GPO che governa le policy di dominio, oppure crea un GPO dedicato se il tuo modello di gestione lo prevede.
4. Vai in Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.
5. Imposta soglia, durata e reset del contatore.
6. Applica e forza l’aggiornamento policy solo se necessario.

Se lavori da PowerShell o vuoi verificare rapidamente i parametri effettivi, puoi leggere la policy applicata con strumenti standard di dominio. Un controllo utile è questo:

net accounts /domain

L’output ti mostra i valori effettivi lato dominio per soglia, durata e reset. È un controllo semplice ma fondamentale, perché evita di fidarti solo della console grafica o di una modifica che magari non è stata ancora replicata.

Scelta dei valori: partire dalla protezione o dalla frizione operativa

Qui conviene essere concreti. In un dominio piccolo con client controllati, MFA già presente e pochi servizi legacy, puoi permetterti una soglia più aggressiva. In un ambiente più vecchio, con applicazioni che usano autenticazioni ripetute e password memorizzate male, una soglia troppo bassa produce falsi positivi a raffica.

Un errore frequente è copiare valori trovati in un blog o in un template di hardening senza guardare il contesto. Il lockout account non va trattato come una ricetta universale. Per esempio, in una rete con molti laptop fuori sede, un utente può generare tentativi falliti da un client che conserva una password vecchia in un profilo Outlook, in un drive mappato o in un servizio sincronizzato. Il blocco non colpisce solo il login interattivo, ma l’intero account, e il primo effetto pratico spesso è un ticket al supporto, non una mitigazione del rischio.

Una buona prassi è ragionare su due assi:

• Rischio attacco: password spraying, tentativi ripetuti, credenziali rubate usate a bassa intensità.
• Rumore operativo: account di servizio, client sporchi, dispositivi mobili, app legacy, provisioning non uniforme.

Se il rischio attacco è alto e il rumore operativo è basso, una soglia più stretta ha senso. Se il rumore operativo è alto, prima di alzare la severità conviene pulire le cause: credenziali salvate, password scadute su servizi, account di servizio non gestiti, vecchi protocolli di autenticazione e dispositivi non conformi.

Verificare che la policy sia davvero applicata

Non basta configurare il GPO. Bisogna verificare che la policy sia arrivata dove deve arrivare. Il controllo minimo è doppio: lato dominio e lato client.

1. Verifica i valori effettivi sul dominio con net accounts /domain.
2. Su un client membro, forza l’aggiornamento policy con gpupdate /force e controlla che il dominio corretto sia raggiunto.
3. Se sospetti conflitti, usa gpresult /r oppure gpresult /h report.html per vedere quale GPO sta vincendo.
4. Controlla in Event Viewer i log di sicurezza e di autenticazione per i tentativi falliti e per l’evento di lockout, così non stai solo guardando la sintesi ma anche l’origine.

Un esempio utile è cercare eventi di account lockout e fallimenti ripetuti sul Domain Controller. I log di sicurezza ti aiutano a capire se il problema nasce da un client specifico, da un servizio o da un pattern distribuito. Se vedi molti fallimenti con lo stesso account da una sola macchina, il problema è quasi sempre locale a quel sistema. Se invece il fallimento è distribuito su più host, la causa è spesso una credenziale compromessa o un servizio condiviso mal configurato.

Account di servizio: il punto dove il blocco diventa un incidente

Gli account di servizio meritano un capitolo a parte. Se applichi il blocco in modo rigido senza distinguere i tipi di account, rischi di fermare servizi critici per una password cambiata male, un task schedulato non aggiornato o un’applicazione che tenta autenticazioni automatiche con credenziali obsolete. Il risultato non è sicurezza aggiuntiva: è indisponibilità.

La mitigazione non è disabilitare tutto, ma ridurre la dipendenza da account generici e password statiche. Dove possibile, usa gMSA per i servizi Windows che lo supportano. È una scelta molto più pulita rispetto a lasciare account condivisi con password note solo a metà team. Se non puoi usare gMSA, documenta almeno dove l’account è usato, chi lo gestisce e quali sistemi lo consumano.

Se dopo aver introdotto il lockout emergono blocchi ripetuti sugli stessi account di servizio, non alzare subito la soglia. Prima individua il generatore dei tentativi errati. Un controllo rapido è cercare nel log del Domain Controller gli eventi di autenticazione fallita e risalire al client sorgente. Nella pratica, spesso trovi una macchina dimenticata, un servizio Windows con password vecchia o un’integrazione applicativa rimasta fuori dal processo di change.

Configurazione consigliata: approccio prudente e reversibile

Se devi introdurre o correggere il blocco account in un ambiente già in esercizio, la strada più sicura è procedere per passi piccoli e reversibili. La modifica della policy va trattata come change controllato, perché impatta direttamente l’accesso degli utenti.

1. Esporta lo stato attuale della policy o annota i valori correnti con net accounts /domain.
2. Definisci una baseline iniziale coerente con l’ambiente, evitando soglie estreme.
3. Applica la modifica in finestra di manutenzione o con presidio del supporto, se il parco utenti è ampio.
4. Monitora per alcune ore i ticket di lockout, gli eventi di sicurezza e i pattern di fallimento.
5. Correggi la causa primaria dei lockout ripetuti prima di irrigidire ulteriormente la soglia.

Un approccio pratico consiste nel partire con una soglia moderata e una durata non eccessiva, poi osservare il numero di blocchi reali. Se il volume di incidenti è basso e i tentativi falliti sono davvero sospetti, puoi stringere. Se il volume è alto ma i motivi sono interni e ripetitivi, il problema non è la policy: è l’igiene dell’ambiente.

Audit minimo: cosa controllare oltre al lockout

Configurare il blocco account senza guardare il resto è un mezzo lavoro. Il blocco funziona meglio se inserito in un quadro più ampio di igiene del dominio. Almeno questi punti vanno controllati:

• Politiche di password coerenti con il profilo di rischio.
• MFA dove possibile, soprattutto per accessi remoti e amministrativi.
• Disattivazione dei protocolli legacy che generano autenticazioni deboli o ripetute.
• Servizi e task schedulati che usano credenziali obsolete.
• Log centralizzati per correlare i fallimenti di autenticazione.

Se hai un SIEM o anche solo una raccolta centralizzata dei log, il blocco account diventa molto più utile. Puoi correlare orario, host sorgente, account coinvolto e frequenza dei tentativi. Senza questi dati, il lockout resta un evento isolato e non ti aiuta a distinguere tra errore umano, servizio rotto e tentativo malevolo.

Un esempio operativo realistico

Immagina un dominio con una cinquantina di utenti e alcuni server applicativi interni. Dopo aver impostato un lockout threshold troppo basso, iniziano a comparire ticket da parte di utenti che usano laptop aziendali e client di posta con profili non aggiornati. I blocchi avvengono spesso a fine giornata, quando il client tenta di sincronizzarsi con credenziali vecchie. L’impressione iniziale è che il lockout “non funzioni bene”, ma in realtà sta funzionando troppo bene rispetto all’igiene del parco macchine.

La correzione giusta non è togliere la policy. Prima individui il client che genera i fallimenti, poi sistemi la password salvata, poi verifichi che il problema non si ripresenti. Solo dopo, se serve, ritarare la soglia. Questo ordine evita il classico errore di abbassare la sicurezza per nascondere un problema di gestione.

Rollback e ripristino: cosa fare se la policy crea troppi blocchi

Se la modifica ha un blast radius troppo ampio, il rollback deve essere già deciso prima di applicarla. In Active Directory il rollback tipico consiste nel riportare i valori precedenti del GPO e forzare la replica/aggiornamento policy. Non improvvisare direttamente in produzione senza aver salvato il valore iniziale.

1. Ripristina i valori precedenti del lockout policy nel GPO.
2. Verifica con net accounts /domain che il dominio mostri di nuovo i parametri attesi.
3. Forza un aggiornamento policy solo se serve e solo sui sistemi interessati.
4. Controlla i log per confermare la riduzione dei lockout e l’assenza di nuovi errori sistemici.

Se invece il problema è un account già bloccato, il reset va fatto dal pannello utente o con strumenti amministrativi coerenti con la tua procedura interna, sempre con verifica del motivo del blocco. Sbloccare e basta, senza capire la sorgente dei tentativi falliti, significa quasi sempre vedere il problema tornare entro poco tempo.

Conclusione operativa: protezione sì, ma con telemetria

Il blocco account in Active Directory funziona bene quando è parte di una catena più ampia: policy sensata, client puliti, account di servizio sotto controllo, log leggibili e rollback pronto. Se manca uno di questi pezzi, il lockout diventa un generatore di rumore o, peggio, un falso senso di sicurezza.

La regola pratica è semplice: prima osserva, poi imposta, poi misura. Se i dati dicono che i blocchi nascono da un problema locale, correggi il client. Se i dati mostrano tentativi distribuiti, alza la difesa. In entrambi i casi, la policy deve restare reversibile e documentata, perché in Active Directory la sicurezza utile è quella che riesci a mantenere senza trasformarla in caos operativo.