Cont Blocat Active Directory 2026: Fix Rapid

Conturile blocate în Active Directory generează între 20% și 35% din tichetele unui helpdesk corporativ obișnuit, conform rapoartelor de operațiuni IT din 2025-2026. Sincer, nu deblocarea în sine este problema — aceea durează vreo 10 secunde — ci faptul că aceleași conturi se blochează din nou peste 5, 15 sau 30 de minute, iar utilizatorul ridică din umeri și nu știe de ce. În spatele fiecărei blocări recurente stă o credențială veche stocată undeva: pe un telefon, într-un serviciu Windows, într-o sesiune RDP uitată sau într-o biată mapare de rețea creată acum doi ani.

Eu am pățit asta cu un coleg care își bloca contul ca un ceasornic, la fix 30 de minute după fiecare deblocare. Vinovatul? Un iPad vechi, abandonat într-un sertar, care încerca în continuare să sincronizeze poșta. Așa că haide să vedem cum identifici sursa rapid și — mai ales — cum scapi definitiv de tichetul ăla care îți revine săptămânal.

Acest ghid documentează fluxul complet folosit de echipele de helpdesk în 2026: cum confirmi că un cont este într-adevăr blocat, cum identifici exact calculatorul care trimite parola greșită, cum deblochezi corect și cum elimini cauza pentru ca tichetul să nu reapară mâine dimineață.

Cum funcționează blocarea conturilor în Active Directory

Active Directory blochează un cont când numărul de încercări eșuate de autentificare depășește pragul setat în Default Domain Policy sau într-o politică Fine-Grained Password Policy (FGPP) aplicată direct utilizatorului. Trei valori controlează comportamentul:

Account lockout threshold — câte încercări eșuate sunt permise (recomandare NIST 2026: între 5 și 10).
Account lockout duration — cât timp rămâne contul blocat (recomandat: 15-30 minute, sau 0 pentru deblocare strict manuală).
Reset account lockout counter after — fereastra în care se contorizează încercările eșuate.

Verifici politica activă cu:

Get-ADDefaultDomainPasswordPolicy

# Pentru politici fine-grained
Get-ADFineGrainedPasswordPolicy -Filter *
Get-ADUserResultantPasswordPolicy -Identity ion.popescu

Diferența critică: blocat vs. parolă expirată vs. dezactivat

Înainte de orice investigație, confirmă că este într-adevăr un lockout. E o greșeală pe care o face toată lumea cel puțin o dată — cele trei stări sunt distincte și se rezolvă diferit:

Get-ADUser -Identity ion.popescu -Properties LockedOut, Enabled, PasswordExpired, AccountExpirationDate, badPwdCount, lastBadPasswordAttempt |
    Select-Object SamAccountName, LockedOut, Enabled, PasswordExpired, AccountExpirationDate, badPwdCount, lastBadPasswordAttempt

Dacă LockedOut = True, ai un lockout real. Dacă PasswordExpired = True, utilizatorul trebuie să-și schimbe parola, nu să fie deblocat. Iar dacă Enabled = False, contul a fost dezactivat de un administrator (sau de un script de offboarding uitat — am văzut și asta).

Pasul 1: Deblocarea imediată

Deblocarea în sine este trivială. Folosește una dintre metodele de mai jos, în funcție de instrumentele disponibile pe stația de helpdesk.

Cu PowerShell (RSAT instalat)

Unlock-ADAccount -Identity ion.popescu

# Verificare imediată
Get-ADUser ion.popescu -Properties LockedOut | Select SamAccountName, LockedOut

Din Active Directory Users and Computers

Click dreapta pe utilizator → Properties → tab-ul Account → bifează Unlock account → OK. Pe sisteme moderne, opțiunea apare doar când contul chiar este blocat (deci, dacă nu o vezi, nu este nimic de deblocat).

De la o stație fără RSAT (un singur agent fără privilegii speciale)

Dacă agentul de helpdesk are doar drepturi delegate pe OU și nu are RSAT, folosește net user împotriva unui DC explicit:

net user ion.popescu /domain
# Caută "Account active" și "Account locked out"

# Deblocare prin specificarea DC-ului
dsmod user "CN=Ion Popescu,OU=Utilizatori,DC=firma,DC=ro" -disabled no

Atenție: niciodată nu reseta parola „preventiv" la fiecare deblocare. Dacă utilizatorul nu cere reset, schimbarea parolei poate provoca un val nou de blocări de la dispozitivele care încă cache-uiesc parola veche. E un cerc vicios pe care l-am tot văzut prin tichete.

Pasul 2: Identificarea sursei blocării

Aici se opresc majoritatea articolelor — și de aici începe, de fapt, treaba serioasă. Un cont care se blochează repetitiv are întotdeauna o sursă concretă: un dispozitiv, un serviciu, o sesiune. Trebuie găsit, altfel tichetul revine. Ciclic. La nesfârșit.

Metoda 1: Event ID 4740 pe PDC Emulator

Domain Controller-ul cu rolul PDC Emulator înregistrează Event ID 4740 în Security log de fiecare dată când un cont este blocat. Câmpul Caller Computer Name conține numele exact al stației care a trimis ultima parolă greșită. Acesta este, de obicei, glonțul de argint.

# Identifică PDC Emulator
$pdc = (Get-ADDomain).PDCEmulator

# Caută ultimele 10 evenimente 4740 pentru un utilizator specific
Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
} -MaxEvents 50 |
Where-Object { $_.Properties[0].Value -eq 'ion.popescu' } |
Select-Object TimeCreated,
    @{n='User';     e={$_.Properties[0].Value}},
    @{n='Source';   e={$_.Properties[1].Value}}

Dacă Source arată un nume de calculator (ex. LAPTOP-ION05), acela este punctul de pornire pentru investigație. Dacă, în schimb, vezi numele unui DC, sursa reală este în alt log — vezi metoda 3.

Metoda 2: Event ID 4625 pe sursa raportată

După ce ai numele calculatorului, conectează-te la el (sau interoghează-l remote) și caută Event ID 4625 (failed logon). Câmpurile Logon Type și Process Name îți spun ce anume a încercat să se autentifice — și aici se rezolvă, de obicei, misterul.

Get-WinEvent -ComputerName LAPTOP-ION05 -FilterHashtable @{
    LogName = 'Security'
    Id      = 4625
} -MaxEvents 20 |
Where-Object { $_.Properties[5].Value -eq 'ion.popescu' } |
Select-Object TimeCreated,
    @{n='LogonType';   e={$_.Properties[10].Value}},
    @{n='Process';     e={$_.Properties[18].Value}},
    @{n='IpAddress';   e={$_.Properties[19].Value}}

Tipuri de logon relevante:

2 — interactiv (cineva tastează la tastatură).
3 — network (mapări de rețea, share-uri SMB).
4 — batch (Task Scheduler).
5 — service (un Windows Service rulează cu credențiale vechi).
10 — RemoteInteractive (RDP).
11 — CachedInteractive (login offline cu credențiale cache-uite).

Metoda 3: Microsoft Account Lockout and Management Tools (LockoutStatus.exe)

Pachetul oficial ALTools conține LockoutStatus.exe, un instrument grafic care interoghează toate DC-urile simultan și arată exact unde și când a fost detectată ultima parolă greșită. E un tool vechi, dar — surprinzător — rămâne util în 2026, mai ales pentru cazurile cu replicare lentă între DC-uri sau atunci când vrei să confirmi rapid pe ce DC s-a produs blocarea.

LockoutStatus.exe /U:firma\ion.popescu

Metoda 4: Audit pe DC (când 4740 nu apare)

Dacă PDC Emulator nu loghează 4740, auditul nu este activat. Verifică:

auditpol /get /subcategory:"User Account Management"
auditpol /get /subcategory:"Logon"

# Activare (necesită drepturi pe DC)
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Modificările ar trebui aplicate prin Default Domain Controllers Policy, nu local, ca să supraviețuiască replicării. Altfel, le pierzi la prima resincronizare.

Pasul 3: Cauze comune și remedierea lor

După ce identifici dispozitivul-sursă, problema este aproape întotdeauna una dintre situațiile de mai jos. Procentajele sunt orientative, din rapoarte de helpdesk publicate în 2025 — variază în funcție de cât de „mobil" e parcul de echipamente.

Telefon mobil cu Exchange/Outlook (35-45% din cazuri)

Utilizatorul și-a schimbat parola pe Windows, dar profilul Exchange ActiveSync de pe telefon încă o folosește pe cea veche. Clasic. Verifică în Exchange Admin Center sau în Microsoft 365 admin:

Get-MobileDeviceStatistics -Mailbox [email protected] |
    Select DeviceModel, DeviceOS, LastSuccessSync, LastSyncAttemptTime, Status

Soluția: utilizatorul actualizează parola în aplicația de mail de pe telefon. Dacă dispozitivul este vechi sau nefolosit (cum era iPad-ul colegului meu), șterge-l direct prin Remove-MobileDevice.

Servicii Windows cu credențiale vechi (15-20%)

Pe stația-sursă, identifică serviciile care rulează sub contul utilizatorului:

Get-CimInstance Win32_Service -ComputerName LAPTOP-ION05 |
    Where-Object { $_.StartName -like "*ion.popescu*" } |
    Select Name, StartName, State, StartMode

Soluția: actualizează credențialele serviciului sau, mai bine, migrează la un Group Managed Service Account (gMSA). Pe termen lung, gMSA-urile îți elimină complet această categorie de tichete.

Task Scheduler (10-15%)

Get-ScheduledTask -CimSession LAPTOP-ION05 |
    Where-Object { $_.Principal.UserId -like "*ion.popescu*" } |
    Select TaskName, TaskPath, State

Mapări de rețea persistente (10%)

Mapările create cu Reconnect at sign-in și o parolă explicită rămân stocate în Credential Manager. Pe stația utilizatorului:

cmdkey /list
cmdkey /delete:Domain:target=server-fisiere.firma.ro

Sesiuni RDP deconectate (5-10%)

O sesiune RDP veche pe un terminal server, deconectată dar nu închisă, poate continua să trimită heartbeat-uri cu parola veche. Sună inofensiv, dar generează lockout-uri perfect curate.

quser /server:terminal01
logoff <ID_sesiune> /server:terminal01

Browser cu parole salvate (5%)

Mai rar în 2026, datorită Windows Hello și passkeys, dar încă apare: extensii sau aplicații web care folosesc autentificare integrată cu o parolă cache-uită incorectă în profilul browserului.

Pasul 4: Script complet de triaj pentru helpdesk

Salvează scriptul de mai jos ca Get-AdLockoutSource.ps1 și rulează-l de pe orice stație cu RSAT și acces la PDC Emulator. Returnează un raport gata de inclus în tichet — exact ce vrea managerul de helpdesk să vadă.

param(
    [Parameter(Mandatory=$true)]
    [string]$User
)

Import-Module ActiveDirectory

$pdc = (Get-ADDomain).PDCEmulator
Write-Host "PDC Emulator: $pdc" -ForegroundColor Cyan

$adUser = Get-ADUser -Identity $User -Properties LockedOut, badPwdCount, lastBadPasswordAttempt, PasswordLastSet, LastLogonDate
Write-Host "`n--- Stare cont ---" -ForegroundColor Yellow
$adUser | Select SamAccountName, LockedOut, badPwdCount, lastBadPasswordAttempt, PasswordLastSet, LastLogonDate | Format-List

Write-Host "`n--- Ultimele evenimente 4740 (lockout) ---" -ForegroundColor Yellow
$lockoutEvents = Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'; Id = 4740
} -MaxEvents 200 -ErrorAction SilentlyContinue |
Where-Object { $_.Properties[0].Value -eq $User } |
Select-Object TimeCreated,
    @{n='Source'; e={$_.Properties[1].Value}} -First 10

$lockoutEvents | Format-Table -AutoSize

if ($lockoutEvents) {
    $sourceComputer = $lockoutEvents[0].Source
    Write-Host "`n--- Verificare 4625 pe $sourceComputer ---" -ForegroundColor Yellow
    try {
        Get-WinEvent -ComputerName $sourceComputer -FilterHashtable @{
            LogName = 'Security'; Id = 4625
        } -MaxEvents 50 -ErrorAction Stop |
        Where-Object { $_.Properties[5].Value -eq $User } |
        Select-Object TimeCreated,
            @{n='LogonType'; e={$_.Properties[10].Value}},
            @{n='Process';   e={$_.Properties[18].Value}},
            @{n='IP';        e={$_.Properties[19].Value}} -First 10 |
        Format-Table -AutoSize
    } catch {
        Write-Warning "Nu pot citi log-ul de pe $sourceComputer : $_"
    }
}

Rulare:

.\Get-AdLockoutSource.ps1 -User ion.popescu

Prevenirea blocărilor recurente

Politici recomandate pentru 2026

NIST SP 800-63B (revizia 2024) și ghidurile Microsoft pentru Active Directory în 2026 recomandă:

Threshold de blocare între 5 și 10 încercări — suficient de strict pentru a opri atacuri brute-force, suficient de tolerant pentru a evita blocările din pură neatenție.
Durată de blocare 15-30 minute cu auto-deblocare, în loc de 0 (blocare permanentă, care îți umple coada de tichete inutil).
Fereastră de reset 15 minute.
Activarea Smart Lockout pentru conturile sincronizate în Entra ID — protejează de atacurile cu parolă din afara rețelei fără a-l bloca pe utilizatorul intern.
Folosirea Fine-Grained Password Policies pentru reguli mai stricte aplicate conturilor privilegiate (Tier 0).

Monitorizare proactivă

Un alert SIEM pe Event ID 4740 cu aceeași sursă, în mai puțin de 30 de minute, pentru utilizatori diferiți este un indicator clasic de password spray. Configurează regula în Microsoft Sentinel, Splunk sau în orice colector folosești. (Dacă încă nu ai unul, poate că acum e momentul.)

Self-service password reset

Cea mai eficientă reducere de tichete în 2025-2026, fără excepție, vine din activarea Self-Service Password Reset (SSPR) în Entra ID, combinată cu password writeback către Active Directory. Utilizatorii își deblochează singuri contul printr-o aplicație de autentificare, fără tichet la helpdesk și fără apel la 8 dimineața.

Greșeli frecvente de evitat

Resetarea parolei la fiecare deblocare — provoacă un val nou de blocări de la dispozitivele care încă cache-uiesc parola veche.
Ignorarea sursei — dacă deblochezi fără să identifici dispozitivul, tichetul revine în 15 minute. Pierdere netă de timp pentru toată lumea, inclusiv pentru tine.
Verificarea log-urilor pe DC-ul greșit — doar PDC Emulator centralizează 4740. Pe alte DC-uri vei vedea evenimente parțiale sau, mai des, deloc.
Lockout threshold prea mic (1-3) — provoacă blocări la fiecare typo. Industria s-a îndepărtat de această abordare după 2020 din motive bune.
Nu activezi auditul Logon failures — fără el, 4625 nu apare și investigația devine pură ghicitoare.

Întrebări frecvente

Cum aflu de pe ce calculator s-a blocat contul în Active Directory?

Pe Domain Controller-ul cu rolul PDC Emulator, caută în Security log evenimentele cu ID 4740. Câmpul Caller Computer Name conține numele calculatorului care a trimis ultima parolă greșită. Scriptul PowerShell de mai sus automatizează interogarea.

De ce se blochează contul în mod repetat după ce schimb parola?

Cel mai probabil un dispozitiv mobil, un serviciu Windows, o mapare de rețea sau o sesiune RDP veche cache-uiește parola anterioară și o trimite în continuare. Identifică sursa cu Event ID 4740 pe PDC, apoi 4625 pe stația-sursă pentru a vedea exact ce proces încearcă autentificarea.

Cum deblochez un cont AD cu PowerShell?

Cu RSAT-ADDS instalat, comanda este Unlock-ADAccount -Identity nume.utilizator. Verifică imediat starea cu Get-ADUser nume.utilizator -Properties LockedOut.

Care este politica recomandată de blocare în 2026?

NIST și Microsoft recomandă în 2026 un threshold de 5-10 încercări eșuate, durată de blocare 15-30 minute cu auto-deblocare și o fereastră de reset de 15 minute. Pentru conturile privilegiate, aplică Fine-Grained Password Policies cu reguli mai stricte.

Pot detecta atacurile de tip password spray prin Event ID 4740?

Indirect, da. Un volum anormal de evenimente 4740 cu surse diferite, pe perioade scurte, indică un atac. Mai precise sunt Event ID 4625 cu Logon Type 3 și aceeași adresă IP sursă pentru utilizatori multipli. Configurează un alert SIEM pe această corelație și o să dormi mai liniștit.