Active Directory e Identità 14 min di lettura

Account Bloccato in Active Directory: Guida Completa al Troubleshooting

Il blocco degli account in Active Directory è tra i ticket più frequenti in helpdesk. Questa guida copre diagnosi con PowerShell, ricerca delle cause su PDC Emulator, ambienti ibridi con Entra ID e strategie di prevenzione concrete.

Editorial Team

Se lavorate in un helpdesk IT, lo sapete già: il blocco degli account in Active Directory è il pane quotidiano. Non esagero — in molte organizzazioni rappresenta dal 20% al 40% dei ticket di primo livello. L'utente chiama frustrato, non riesce ad accedere al PC, alle risorse di rete, alle applicazioni aziendali. E il tempo stringe, ovviamente.

Ora, il problema vero non è sbloccare l'account. Quello è facile. Il problema è capire perché si è bloccato. Perché se non trovate la causa reale, l'account si bloccherà di nuovo nel giro di pochi minuti. E l'utente richiamerà. E voi vi ritroverete in quel ciclo infinito che fa venire voglia di cambiare mestiere.

In questa guida vi porto attraverso un framework operativo completo per diagnosticare, risolvere e (soprattutto) prevenire i blocchi degli account — sia in ambienti on-premises tradizionali che nelle configurazioni ibride con Microsoft Entra ID. Troverete comandi PowerShell pronti all'uso, procedure passo-passo e checklist operative. Niente teoria fine a sé stessa, solo roba che funziona sul campo.

Come Funziona il Blocco degli Account in Active Directory

Prima di buttarci nel troubleshooting, un rapido ripasso del meccanismo. Active Directory usa una policy di blocco account (Account Lockout Policy) definita a livello di dominio tramite Group Policy.

I Tre Parametri Chiave della Policy

La policy è controllata da tre parametri nel Default Domain Policy:

  • Account lockout threshold — quanti tentativi di accesso falliti servono per bloccare l'account (tipicamente 5-10)
  • Account lockout duration — per quanto tempo (in minuti) l'account resta bloccato. Se impostato a 0, resta bloccato finché un admin non lo sblocca manualmente (e sì, qualcuno lo imposta davvero a 0)
  • Reset account lockout counter after — dopo quanto tempo il contatore dei tentativi falliti si azzera

Verificare la Policy Corrente

Prima di tutto, dovete sapere quale policy è attiva nel vostro dominio:

# Visualizza la policy di blocco del dominio
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

# Risultato tipico:
# LockoutThreshold         : 5
# LockoutDuration          : 00:30:00
# LockoutObservationWindow : 00:30:00

Se la vostra organizzazione usa Fine-Grained Password Policies (FGPP), la policy potrebbe variare per gruppi specifici di utenti:

# Elenca tutte le Fine-Grained Password Policies
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, LockoutThreshold, LockoutDuration, Precedence

# Verifica quale policy si applica a un utente specifico
Get-ADUserResultantPasswordPolicy -Identity "mario.rossi" | Select-Object Name, LockoutThreshold, LockoutDuration

Il Ruolo del PDC Emulator

Questo è un punto che molti operatori di helpdesk sottovalutano: in Active Directory, il PDC Emulator è il domain controller che gestisce centralmente i blocchi degli account. Quando un account viene bloccato su un qualsiasi DC, l'informazione viene inoltrata subito al PDC Emulator.

Cosa significa in pratica? Che per un troubleshooting accurato dovete sempre interrogare il PDC Emulator. Se andate a cercare i log sul DC sbagliato, rischiate di perdere tempo inutilmente.

# Identifica il PDC Emulator del dominio
Get-ADDomain | Select-Object PDCEmulator

# Oppure:
netdom query pdc

Primo Intervento: Sbloccare l'Account e Raccogliere Informazioni

Quando arriva il ticket, la priorità è rimettere l'utente in condizione di lavorare. Ma — e qui sta il punto — non limitatevi a sbloccare. Raccogliete subito tutte le informazioni che vi serviranno per capire cosa è successo.

Sblocco e Analisi Rapida con PowerShell

# Sblocca l'account
Unlock-ADAccount -Identity "mario.rossi"

# Verifica lo stato dell'account (esegui contro il PDC Emulator)
$PDC = (Get-ADDomain).PDCEmulator
Get-ADUser -Identity "mario.rossi" -Server $PDC -Properties `
    LockedOut, `
    LockoutTime, `
    BadLogonCount, `
    BadPasswordTime, `
    LastLogonDate, `
    PasswordLastSet, `
    PasswordExpired, `
    Enabled | Format-List

# Risultato di esempio:
# LockedOut        : False (dopo lo sblocco)
# LockoutTime      : 18/03/2026 09:15:32
# BadLogonCount    : 5
# BadPasswordTime  : 18/03/2026 09:15:28
# LastLogonDate    : 18/03/2026 08:30:15
# PasswordLastSet  : 15/01/2026 14:22:08
# PasswordExpired  : False
# Enabled          : True

Cosa Guardare Subito

Dall'output del comando, ecco gli indicatori chiave:

  • BadLogonCount — se corrisponde esattamente alla soglia di lockout, il blocco è "legittimo" (password errata ripetuta). Se è molto più alto, c'è quasi sicuramente un processo automatico che continua a martellare
  • BadPasswordTime vs LockoutTime — se sono a pochi secondi di distanza, pensate subito a un processo automatizzato. Se distanziati, è più probabilmente un errore umano
  • PasswordLastSet — password cambiata di recente? Bingo: il colpevole è probabilmente una credenziale vecchia rimasta salvata da qualche parte
  • PasswordExpired — non causa direttamente un lockout, ma può confondere l'utente (e di conseguenza anche voi)

Identificare la Fonte del Blocco: Il Metodo Sistematico

Ecco la parte che fa la differenza tra un operatore che risolve davvero e uno che mette cerotti. Dovete trovare da dove arrivano i tentativi di accesso falliti.

Metodo 1: Event Viewer sul PDC Emulator

L'evento da cercare è il 4740 (Account Lockout) nel Security Event Log del PDC Emulator. Contiene il nome del computer da cui è partito il tentativo — ed è la vostra prima pista concreta.

# Cerca gli eventi di lockout sul PDC Emulator per un utente specifico
$PDC = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
    StartTime = (Get-Date).AddHours(-24)
} | Where-Object { $_.Properties[0].Value -eq "mario.rossi" } |
ForEach-Object {
    [PSCustomObject]@{
        TimeCreated    = $_.TimeCreated
        TargetAccount  = $_.Properties[0].Value
        CallerComputer = $_.Properties[1].Value
    }
} | Format-Table -AutoSize

Il campo CallerComputer vi dice da quale macchina è partito il tentativo. Segnatevelo: è il vostro punto di partenza.

Metodo 2: Controllare Tutti i Domain Controller

In ambienti con molti DC, conviene controllare i log di autenticazione su tutti quanti. Gli eventi da cercare sono il 4771 (Kerberos Pre-Authentication Failed) e il 4776 (NTLM Authentication):

# Cerca eventi di autenticazione fallita su tutti i DC
$DCs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName
$Username = "mario.rossi"

foreach ($DC in $DCs) {
    Write-Host "`n--- $DC ---" -ForegroundColor Cyan

    # Evento 4771: Kerberos pre-auth fallita
    Get-WinEvent -ComputerName $DC -FilterHashtable @{
        LogName   = 'Security'
        Id        = 4771
        StartTime = (Get-Date).AddHours(-4)
    } -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[0].Value -eq $Username } |
    ForEach-Object {
        [PSCustomObject]@{
            DC        = $DC
            Time      = $_.TimeCreated
            EventId   = 4771
            ClientIP  = $_.Properties[6].Value
        }
    }

    # Evento 4776: NTLM authentication fallita
    Get-WinEvent -ComputerName $DC -FilterHashtable @{
        LogName   = 'Security'
        Id        = 4776
        StartTime = (Get-Date).AddHours(-4)
    } -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[1].Value -eq $Username } |
    ForEach-Object {
        [PSCustomObject]@{
            DC        = $DC
            Time      = $_.TimeCreated
            EventId   = 4776
            Workstation = $_.Properties[2].Value
        }
    }
}

Metodo 3: Microsoft Account Lockout and Management Tools

Se non vi sentite a vostro agio con PowerShell (nessun giudizio, ci siamo passati tutti), Microsoft offre un set di strumenti grafici gratuiti: gli Account Lockout and Management Tools (ALTools).

Lo strumento principale è LockoutStatus.exe, che interroga tutti i DC contemporaneamente e vi mostra lo stato dell'account su ciascuno. Molto più immediato che lanciare script su ogni server.

  • Scaricate gli ALTools dal Microsoft Download Center
  • Lanciate LockoutStatus.exe
  • Inserite nome utente e dominio
  • Lo strumento mostrerà per ogni DC: stato di blocco, tentativi falliti, ora dell'ultimo tentativo e dell'ultimo accesso riuscito

Nel pacchetto trovate anche EventCombMT.exe, che cerca eventi specifici nei log di sicurezza di più DC contemporaneamente. Un vero risparmio di tempo rispetto a controllare manualmente ogni server.

Le Cause Più Comuni di Blocco Account (e Come Risolverle)

Dopo anni passati a gestire questi ticket, posso dirvi che il 90% dei blocchi ricorrenti rientra in una di queste categorie. Vediamole una per una.

Causa 1: Credenziali Salvate nel Credential Manager

Questa è di gran lunga la causa numero uno. L'utente cambia la password, ma le vecchie credenziali restano nel Credential Manager di Windows. Ogni volta che un'app o una connessione di rete prova a usarle — boom, tentativo fallito.

Come risolvere:

  1. Aprite il Pannello di controllo > Gestione credenziali
  2. Controllate sia Credenziali Web che Credenziali di Windows
  3. Rimuovete tutte le voci relative al dominio aziendale, SharePoint, server file e altre risorse interne
  4. Oppure, se preferite fare pulizia in modo più rapido:
# Elenca tutte le credenziali salvate
cmdkey /list

# Rimuovi una credenziale specifica
cmdkey /delete:Domain:target=server.contoso.com

# Rimuovi tutte le credenziali del dominio (attenzione: rimuove TUTTE)
cmdkey /list | ForEach-Object {
    if ($_ -match "Target:\s+(.+)") {
        $target = $Matches[1].Trim()
        if ($target -like "*contoso*") {
            cmdkey /delete:$target
        }
    }
}

Causa 2: Sessioni RDP Disconnesse

Questa è subdola. Le sessioni Remote Desktop disconnesse (non chiuse correttamente, come fanno quasi tutti) mantengono attivi i processi con le vecchie credenziali. Se la password è stata cambiata ma c'è una sessione RDP ancora aperta con quella vecchia, i rinnovi del ticket Kerberos falliranno sistematicamente.

# Trova le sessioni disconnesse dell'utente sui server RDS
$servers = @("RDS01", "RDS02", "RDS03")
foreach ($server in $servers) {
    Write-Host "`n--- $server ---" -ForegroundColor Cyan
    query user /server:$server 2>$null | Where-Object { $_ -match "mario.rossi" }
}

# Per disconnettere forzatamente una sessione (richiede i permessi)
# logoff  /server:

Causa 3: Servizi Windows con Credenziali dell'Utente

A volte qualcuno configura un servizio Windows per eseguirsi con l'account di dominio di un utente normale anziché con un account di servizio dedicato. Non è una best practice (per usare un eufemismo), ma succede più spesso di quanto pensiate. Quando la password cambia, il servizio continua a tentare l'autenticazione con quella vecchia.

# Cerca i servizi che usano un account di dominio specifico
Get-WmiObject Win32_Service | Where-Object {
    $_.StartName -like "*mario.rossi*"
} | Select-Object Name, DisplayName, StartName, State, StartMode | Format-Table -AutoSize

# Per controllare su un computer remoto
Get-WmiObject Win32_Service -ComputerName "PC-MARIO" | Where-Object {
    $_.StartName -like "*contoso*"
} | Select-Object Name, DisplayName, StartName, State

Causa 4: Attività Pianificate (Scheduled Tasks)

Le attività pianificate con credenziali utente sono un classico. Qualcuno le crea, le dimentica, e se ne ricorda solo quando causano lockout dopo un cambio password. A volte passano mesi prima che il problema si manifesti, a seconda della frequenza di esecuzione del task.

# Cerca le attività pianificate che usano un account specifico
Get-ScheduledTask | ForEach-Object {
    $task = $_
    $principal = $task.Principal
    if ($principal.UserId -like "*mario.rossi*") {
        [PSCustomObject]@{
            TaskName  = $task.TaskName
            TaskPath  = $task.TaskPath
            UserId    = $principal.UserId
            State     = $task.State
        }
    }
} | Format-Table -AutoSize

# Per controllare su un computer remoto
Invoke-Command -ComputerName "PC-MARIO" -ScriptBlock {
    Get-ScheduledTask | Where-Object { $_.Principal.UserId -like "*mario.rossi*" } |
    Select-Object TaskName, TaskPath, State
}

Causa 5: Dispositivi Mobili e App con Credenziali Aziendali

Smartphone e tablet con account aziendali configurati (Exchange ActiveSync, Wi-Fi 802.1X, app varie) sono tra le cause più frustranti da scovare. Il motivo? L'evento di lockout riporta spesso l'IP del gateway mobile o del server Exchange, non il dispositivo vero e proprio. Quindi dovete scavare un po' più a fondo.

Come diagnosticare:

  1. Controllate i dispositivi registrati dell'utente nel portale Entra ID o in Exchange Admin Center
  2. Verificate i log di Exchange ActiveSync:
# Verifica i dispositivi ActiveSync dell'utente
Get-MobileDevice -Mailbox "[email protected]" | Select-Object FriendlyName, DeviceModel, DeviceOS, LastSuccessSync, DeviceAccessState

# Verifica i log IIS per accessi ActiveSync falliti
# Percorso tipico: C:\inetpub\logs\LogFiles\W3SVC1
# Cercate righe con /Microsoft-Server-ActiveSync e codice 401
  1. Chiedete all'utente di rimuovere e riconfigurare l'account aziendale su tutti i dispositivi mobili con la nuova password. Lo so, è noioso. Ma è l'unico modo sicuro.

Causa 6: Unità di Rete Mappate con Credenziali Salvate

Le connessioni a cartelle condivise create con "Connetti usando credenziali diverse" possono trattenere vecchie password:

# Elenca le connessioni di rete attive
net use

# Disconnetti tutte le connessioni
net use * /delete /yes

# Ricrea le connessioni (senza salvare le credenziali)
net use Z: \\fileserver\condivisione /user:CONTOSO\mario.rossi

Troubleshooting Avanzato: Ambienti Ibridi con Microsoft Entra ID

Nel 2026, diciamocelo, quasi nessuno ha più un ambiente puramente on-premises. La maggior parte delle organizzazioni è in configurazione ibrida con Active Directory sincronizzato a Microsoft Entra ID (ex Azure AD) tramite Entra Connect. E questo complica un po' le cose.

Smart Lockout di Entra ID

Microsoft Entra ID ha un proprio sistema di blocco, lo Smart Lockout, che funziona indipendentemente dalla policy AD on-premises. È un po' più intelligente del meccanismo tradizionale:

  • Blocca dopo 10 tentativi falliti per default (configurabile)
  • Durata iniziale: 60 secondi, con incremento progressivo ad ogni blocco successivo
  • Distingue tra posizioni "familiari" e sconosciute dell'utente
  • Le posizioni familiari hanno una soglia più alta — un dettaglio che fa la differenza

Come Interagiscono AD On-Premises e Entra ID

Qui è dove le cose si fanno interessanti (e un po' confuse, onestamente). Il comportamento cambia in base alla configurazione:

  • Con PHS (Password Hash Sync): Entra ID valida la password con il proprio hash. Un lockout in Entra ID non blocca automaticamente l'account on-premises e viceversa, a meno che non abbiate abilitato il Password Writeback
  • Con PTA (Pass-Through Authentication): l'autenticazione viene inoltrata ai server PTA on-premises. Qui un blocco on-premises si riflette subito in Entra ID. Lo Smart Lockout interviene prima, proteggendo l'AD on-premises da tentativi brute force
  • Con Federation (ADFS): il blocco dipende dalle policy configurate sia su ADFS che sull'AD. L'Extranet Lockout di ADFS aggiunge un ulteriore strato di protezione (e di complessità, va detto)

Verificare lo Stato del Lockout in Entra ID

# Connessione a Microsoft Graph con i permessi necessari
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All"

# Cerca i sign-in falliti per un utente nelle ultime 24 ore
$userId = (Get-MgUser -Filter "userPrincipalName eq '[email protected]'").Id
$startDate = (Get-Date).AddHours(-24).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "userId eq '$userId' and status/errorCode ne 0 and createdDateTime ge $startDate" -Top 50 |
Select-Object CreatedDateTime, AppDisplayName,
    @{N='ErrorCode';E={$_.Status.ErrorCode}},
    @{N='FailureReason';E={$_.Status.FailureReason}},
    @{N='IPAddress';E={$_.IpAddress}},
    @{N='Location';E={"$($_.Location.City), $($_.Location.CountryOrRegion)"}} |
Format-Table -AutoSize

I codici di errore che dovete tenere a mente:

  • 50053 — Account bloccato (quello che state cercando)
  • 50126 — Nome utente o password non validi
  • 50132 — Password scaduta
  • 53003 — Bloccato da Conditional Access (è un caso diverso, ma gli utenti lo confondono spesso con un lockout)

Controllare la Configurazione di Entra Connect

A volte il problema non è l'account ma la sincronizzazione. Un disallineamento tra stato on-premises e cloud può causare comportamenti bizzarri:

# Controlla lo stato di sincronizzazione di Entra Connect (sul server Entra Connect)
Get-ADSyncScheduler

# Verifica l'ultimo ciclo di sincronizzazione
Get-ADSyncRunProfileResult | Select-Object -First 5 ConnectorName, RunProfileName, Result, StartDate, EndDate

# Forza una sincronizzazione delta
Start-ADSyncSyncCycle -PolicyType Delta

Script Operativo Completo: Diagnostica Account Lockout

Ok, arriviamo alla parte pratica. Ecco uno script PowerShell che automatizza l'intera procedura diagnostica. Salvatelo come Diagnose-AccountLockout.ps1 e rendetelo lo strumento standard del vostro helpdesk — vi ringrazieranno.

#Requires -Modules ActiveDirectory

param(
    [Parameter(Mandatory = $true)]
    [string]$Username,

    [int]$HoursBack = 24,

    [switch]$Unlock
)

Write-Host "=== DIAGNOSTICA ACCOUNT LOCKOUT ===" -ForegroundColor Yellow
Write-Host "Utente: $Username" -ForegroundColor Cyan
Write-Host "Periodo: ultime $HoursBack ore`n"

# 1. Identifica il PDC Emulator
$PDC = (Get-ADDomain).PDCEmulator
Write-Host "PDC Emulator: $PDC" -ForegroundColor Gray

# 2. Stato attuale dell'account
Write-Host "`n--- STATO ACCOUNT ---" -ForegroundColor Green
$user = Get-ADUser -Identity $Username -Server $PDC -Properties `
    LockedOut, LockoutTime, BadLogonCount, BadPasswordTime, `
    LastLogonDate, PasswordLastSet, PasswordExpired, Enabled

$user | Format-List LockedOut, LockoutTime, BadLogonCount, `
    BadPasswordTime, LastLogonDate, PasswordLastSet, PasswordExpired, Enabled

# 3. Sblocca se richiesto
if ($Unlock -and $user.LockedOut) {
    Unlock-ADAccount -Identity $Username
    Write-Host "Account sbloccato con successo." -ForegroundColor Green
}

# 4. Cerca eventi 4740 sul PDC
Write-Host "`n--- EVENTI DI LOCKOUT (4740) ---" -ForegroundColor Green
$lockoutEvents = Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
    StartTime = (Get-Date).AddHours(-$HoursBack)
} -ErrorAction SilentlyContinue |
Where-Object { $_.Properties[0].Value -eq $Username }

if ($lockoutEvents) {
    $lockoutEvents | ForEach-Object {
        [PSCustomObject]@{
            Ora       = $_.TimeCreated
            Computer  = $_.Properties[1].Value
        }
    } | Format-Table -AutoSize
} else {
    Write-Host "Nessun evento di lockout trovato nelle ultime $HoursBack ore." -ForegroundColor Yellow
}

# 5. Cerca eventi 4771 e 4776 su tutti i DC
Write-Host "`n--- AUTENTICAZIONI FALLITE SU TUTTI I DC ---" -ForegroundColor Green
$DCs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName

$failedAuth = foreach ($DC in $DCs) {
    # Evento 4771 - Kerberos
    Get-WinEvent -ComputerName $DC -FilterHashtable @{
        LogName = 'Security'; Id = 4771
        StartTime = (Get-Date).AddHours(-$HoursBack)
    } -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[0].Value -eq $Username } |
    ForEach-Object {
        [PSCustomObject]@{
            DC = $DC; Ora = $_.TimeCreated
            Tipo = "Kerberos (4771)"
            Origine = $_.Properties[6].Value
        }
    }

    # Evento 4776 - NTLM
    Get-WinEvent -ComputerName $DC -FilterHashtable @{
        LogName = 'Security'; Id = 4776
        StartTime = (Get-Date).AddHours(-$HoursBack)
    } -ErrorAction SilentlyContinue |
    Where-Object { $_.Properties[1].Value -eq $Username } |
    ForEach-Object {
        [PSCustomObject]@{
            DC = $DC; Ora = $_.TimeCreated
            Tipo = "NTLM (4776)"
            Origine = $_.Properties[2].Value
        }
    }
}

if ($failedAuth) {
    $failedAuth | Sort-Object Ora -Descending | Format-Table -AutoSize

    Write-Host "`n--- RIEPILOGO ORIGINI ---" -ForegroundColor Green
    $failedAuth | Group-Object Origine | Sort-Object Count -Descending |
    Select-Object Count, Name | Format-Table -AutoSize
} else {
    Write-Host "Nessuna autenticazione fallita trovata." -ForegroundColor Yellow
}

Write-Host "`n=== DIAGNOSTICA COMPLETATA ===" -ForegroundColor Yellow

Utilizzo (semplicissimo):

# Solo diagnostica
.\Diagnose-AccountLockout.ps1 -Username "mario.rossi"

# Diagnostica + sblocco automatico
.\Diagnose-AccountLockout.ps1 -Username "mario.rossi" -Unlock

# Cerca nelle ultime 48 ore
.\Diagnose-AccountLockout.ps1 -Username "mario.rossi" -HoursBack 48

Strategie di Prevenzione per l'Helpdesk

Risolvere i lockout è importante. Ma sapete cosa è meglio? Non doverli risolvere affatto. Ecco le strategie di prevenzione più efficaci.

Implementare il Self-Service Password Reset (SSPR)

Francamente, se la vostra organizzazione non ha ancora implementato SSPR, sta perdendo tempo e soldi. Microsoft Entra ID offre il Self-Service Password Reset che permette agli utenti di reimpostare la password e sbloccare l'account da soli, senza chiamare l'helpdesk. Con Password Writeback, il reset si propaga anche all'AD on-premises.

  • Richiede una licenza Microsoft Entra ID P1 o P2
  • Si configura nel portale Entra ID > Protezione > Reimpostazione password
  • Supporta più metodi: app Microsoft Authenticator, SMS, email, domande di sicurezza
  • Secondo le statistiche di Microsoft, riduce i ticket di lockout del 40-60%. Non è poco.

Monitoraggio Proattivo dei Lockout

Non aspettate che l'utente chiami. Create un sistema che vi avvisi quando qualcuno viene bloccato ripetutamente:

# Script per monitoraggio lockout ricorrenti (da eseguire ogni 15 minuti)
$threshold = 3  # Numero di lockout nelle ultime 4 ore
$lookback = 4   # Ore da controllare

$PDC = (Get-ADDomain).PDCEmulator
$lockouts = Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
    StartTime = (Get-Date).AddHours(-$lookback)
} -ErrorAction SilentlyContinue

$repeated = $lockouts | Group-Object { $_.Properties[0].Value } |
    Where-Object { $_.Count -ge $threshold }

foreach ($user in $repeated) {
    $sources = ($user.Group | ForEach-Object { $_.Properties[1].Value } |
        Sort-Object -Unique) -join ", "

    # Invio notifica (esempio con email)
    $body = "L'utente $($user.Name) e' stato bloccato $($user.Count) volte nelle ultime $lookback ore. Fonti: $sources"

    Send-MailMessage -From "[email protected]" -To "[email protected]" `
        -Subject "ALERT: Lockout ricorrente - $($user.Name)" `
        -Body $body -SmtpServer "smtp.contoso.com"
}

Audit e Pulizia delle Credenziali Salvate

Dopo ogni cambio password, mandate all'utente questa checklist. Semplice, ma fa una differenza enorme:

  1. Disconnettersi da tutte le sessioni RDP
  2. Bloccare e sbloccare il PC (Win+L) per aggiornare le credenziali di sessione
  3. Pulire il Credential Manager di Windows
  4. Aggiornare la password sui dispositivi mobili (email, Wi-Fi aziendale)
  5. Aggiornare la password nelle VPN configurate
  6. Riavviare il computer per eliminare i token di autenticazione in cache

Configurare Policy di Blocco Ragionevoli

Una policy troppo aggressiva genera un mare di ticket inutili. Una troppo permissiva è un rischio di sicurezza. Ecco i valori che consiglio nel 2026:

  • Lockout threshold: 10 tentativi (è il minimo consigliato da Microsoft nelle linee guida aggiornate — non ha più senso usare 3 o 5)
  • Lockout duration: 15-30 minuti
  • Reset counter: 15-30 minuti
  • Usate le Fine-Grained Password Policies per applicare policy più stringenti solo agli account privilegiati, dove ha senso essere più severi

Checklist Operativa per il Primo Livello

Per finire, ecco la checklist che ogni operatore di primo livello dovrebbe avere stampata (o meglio, incollata su un monitor). Da seguire ogni volta che arriva un ticket di account bloccato:

  1. Sblocca l'account e annota l'ora del blocco
  2. Controlla il BadLogonCount — corrisponde alla soglia?
  3. Cerca l'evento 4740 sul PDC Emulator — da quale computer arriva?
  4. Chiedi all'utente se ha cambiato la password di recente
  5. Controlla il Credential Manager sulla sua postazione
  6. Verifica sessioni RDP disconnesse sui server
  7. Controlla servizi e attività pianificate sulla postazione
  8. Chiedi dei dispositivi mobili — la password è aggiornata su tutti?
  9. Se il blocco persiste, scala al secondo livello con tutte le informazioni raccolte

Domande Frequenti (FAQ)

Come faccio a sapere quale computer ha causato il blocco dell'account?

Cercate l'evento 4740 nel Security Event Log del PDC Emulator: il campo "Caller Computer Name" indica la macchina da cui è partito il tentativo fallito. Potete usare il comando PowerShell Get-WinEvent con il filtro per l'evento 4740, oppure lo strumento gratuito LockoutStatus.exe di Microsoft che è ancora più immediato.

Perché l'account si blocca di nuovo pochi minuti dopo lo sblocco?

Nel 99% dei casi, la causa è una credenziale salvata non aggiornata. Dopo un cambio password, le vecchie credenziali possono restare nel Credential Manager di Windows, nelle sessioni RDP disconnesse, nei servizi Windows, nelle attività pianificate, sui dispositivi mobili o nelle connessioni VPN. Il trucco è identificare e aggiornare tutte queste fonti prima di sbloccare l'account, altrimenti il ciclo ricomincia.

Il blocco on-premises si propaga anche a Microsoft Entra ID?

Dipende dalla configurazione. Con Pass-Through Authentication (PTA), sì: il blocco on-premises si riflette in Entra ID perché l'autenticazione transita dall'AD locale. Con Password Hash Sync (PHS), no: i due sistemi operano in modo indipendente, e Entra ID usa il proprio Smart Lockout. In entrambi i casi, il Self-Service Password Reset con Password Writeback può sbloccare l'account su entrambi i fronti.

Qual è la differenza tra gli eventi 4740, 4771 e 4776?

In breve: il 4740 (Account Lockout) si genera sul PDC Emulator quando l'account viene effettivamente bloccato. Il 4771 (Kerberos Pre-Authentication Failed) registra ogni singolo tentativo Kerberos fallito e include l'indirizzo IP del client. Il 4776 (Credential Validation) riguarda l'autenticazione NTLM e riporta il nome della workstation. Per un'indagine completa, controllate tutti e tre.

Come posso ridurre il numero di ticket di account bloccato?

Le mosse più efficaci: implementare il Self-Service Password Reset (SSPR) di Entra ID (taglio del 40-60% dei ticket, numeri alla mano), configurare una soglia di lockout ragionevole (10 tentativi, non 3-5), mandare agli utenti una checklist post-cambio password e impostare un monitoraggio proattivo che vi avvisi prima che l'utente debba chiamare.

Sull'Autore Editorial Team

Our team of expert writers and editors.