Správa Active Directory 11 min čtení

Zamykání účtů v Active Directory: Jak najít příčinu a zastavit to jednou provždy

Zjistěte, co zamyká účty v Active Directory. Praktický průvodce od zjištění zdrojového počítače přes Event ID 4740 až po PowerShell skripty pro automatizovanou diagnostiku a prevenci opakovaného zamykání.

Editorial Team

Zamykání účtů v Active Directory – pokud pracujete na helpdesku, tohle téma znáte až moc dobře. Uživatel zavolá, že se nemůže přihlásit. Odemknete mu účet. Za dvacet minut volá znovu. A pak znovu. Je to takový nekonečný kolotoč, který vám dokáže pěkně znepříjemnit den.

Problém totiž není v odemykání – to zvládne kdokoliv jedním kliknutím. Problém je najít, co ten účet pořád zamyká.

A přesně na to se tady zaměříme. Projdeme si celý diagnostický postup od začátku do konce – od základních kontrol přes Event Viewer až po PowerShell skripty, které vám (věřte mi) ušetří spoustu času. Po přečtení budete přesně vědět, odkud zamykání přichází a jak ho jednou provždy zastavit.

Proč se účty zamykají – nejčastější příčiny

Než se vrhneme na diagnostiku, pojďme si ujasnit, co zamykání účtů typicky způsobuje. Za ta léta, co se s tímhle potýkám, jsem zjistil, že většina případů spadá do jedné z těchto kategorií:

  • Zapamatovaná stará hesla: Uživatel si změnil heslo, ale na některém zařízení (notebook, telefon, tablet) zůstalo uložené to staré. Zařízení se periodicky pokouší ověřit se starým heslem a po překročení limitu účet zamkne
  • Mapované síťové disky: Síťové disky připojené přes net use se starými přihlašovacími údaji – klasický viník, hlavně na sdílených počítačích
  • Naplánované úlohy (Scheduled Tasks): Úloha běží pod servisním nebo uživatelským účtem, jehož heslo se mezitím změnilo. Task Scheduler to zkouší stále dokola a hádejte, co se stane
  • Služby Windows: Služby nakonfigurované pro spouštění pod doménovým účtem s prošlým heslem
  • Aplikace s uloženými přihlašovacími údaji: Outlook, Teams, VPN klienti, CRM systémy – prostě cokoliv, co si ukládá doménové heslo
  • RDP/vzdálený přístup: Uložená připojení ke vzdálené ploše se starým heslem
  • Mobilní zařízení: Telefony a tablety připojené k firemní Wi-Fi, Exchange nebo VPN se starým heslem (tenhle je zákeřný, protože na mobil se často zapomíná)
  • Skripty a automatizace: PowerShell skripty, dávkové soubory nebo CI/CD pipeline s hardcoded přihlašovacími údaji

Krok 1: Ověřte zásady zamykání účtů

Prvním krokem je zjistit, jaké zásady zamykání máte vlastně nastavené. Otevřete PowerShell jako správce na libovolném doménovém počítači a spusťte:

Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

Výstup vám ukáže tři klíčové hodnoty:

  • LockoutThreshold: Počet neúspěšných pokusů, po kterých se účet zamkne (typicky 3–5)
  • LockoutDuration: Jak dlouho zůstane účet zamknutý (00:30:00 = 30 minut, 00:00:00 = dokud ho admin neodemkne)
  • LockoutObservationWindow: Časové okno, ve kterém se neúspěšné pokusy počítají

Pokud máte LockoutThreshold nastavený na 3 a uživatelé si stěžují pořád dokola, zvažte zvýšení na 5. Ale pozor – nezvyšujte ho příliš, protože tím oslabíte ochranu proti brute-force útokům. Je to vždycky kompromis.

Kontrola Fine-Grained Password Policies

Od Windows Server 2008 můžete mít různé zásady pro různé skupiny uživatelů. Stojí za to ověřit, jestli nemáte nastavené Fine-Grained Password Policies:

Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, LockoutThreshold, LockoutDuration, Precedence, AppliesTo

Tyhle zásady mají přednost před výchozí doménovou politikou, takže pokud existují, rozhodně je sledujte taky.

Krok 2: Zjistěte stav zamknutého účtu

Tak, uživatel volá, že se nemůže přihlásit. Nejdřív ověřte, jestli je účet skutečně zamknutý (někdy je problém úplně jinde):

Get-ADUser -Identity "jnovak" -Properties LockedOut, LockoutTime, BadLogonCount, BadPasswordTime, LastBadPasswordAttempt |
  Select-Object Name, LockedOut, LockoutTime, BadLogonCount, LastBadPasswordAttempt

Nahraďte jnovak přihlašovacím jménem (sAMAccountName) uživatele. Výstup vám řekne:

  • LockedOut: True/False – je účet aktuálně zamknutý?
  • LockoutTime: Kdy přesně došlo k zamknutí
  • BadLogonCount: Počet neúspěšných pokusů od posledního resetu
  • LastBadPasswordAttempt: Čas posledního neúspěšného pokusu

Účet odemknete jednoduše:

Unlock-ADAccount -Identity "jnovak"

Ale to je jen dočasné řešení. Pokud nezjistíte příčinu, účet se zamkne znovu – a vy budete odemykat do nekonečna.

Krok 3: Najděte doménový řadič, který účet zamkl

Active Directory má obvykle víc doménových řadičů (DC). Zamknutí proběhne na jednom konkrétním DC a pak se replikuje na ostatní. Potřebujete najít ten původní DC, kde k zamknutí došlo.

Nejrychlejší způsob je začít u PDC Emulátoru, protože ten dostává informace o zamykání přednostně:

# Zjistěte PDC Emulator
$PDC = (Get-ADDomain).PDCEmulator
Write-Host "PDC Emulator: $PDC"

# Dotaz na zamknutí uživatele na PDC
Get-ADUser -Identity "jnovak" -Server $PDC -Properties LockedOut, LockoutTime, BadLogonCount |
  Select-Object Name, LockedOut, LockoutTime, BadLogonCount

Pro důkladnější kontrolu se ale vyplatí podívat na všechny DC najednou:

$user = "jnovak"
$DCs = Get-ADDomainController -Filter *

foreach ($DC in $DCs) {
    $result = Get-ADUser -Identity $user -Server $DC.HostName -Properties LockedOut, BadLogonCount, LockoutTime -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        DC             = $DC.HostName
        LockedOut      = $result.LockedOut
        BadLogonCount  = $result.BadLogonCount
        LockoutTime    = $result.LockoutTime
    }
} | Format-Table -AutoSize

DC s nejvyšším BadLogonCount nebo nejstarším LockoutTime je s největší pravděpodobností ten, kde k zamykání dochází. Tím si zúžíte oblast hledání.

Krok 4: Najděte zdrojový počítač pomocí Event Logu

Tohle je jádro celé diagnostiky. Na doménovém řadiči, který zamykání zpracovává, hledáte Event ID 4740 v Security logu. Tato událost obsahuje název počítače, ze kterého přišel neúspěšný pokus o přihlášení. Jakmile ho máte, jste na půl cesty k vyřešení problému.

Metoda 1: PowerShell (doporučuji)

$PDC = (Get-ADDomain).PDCEmulator
$user = "jnovak"

Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
    StartTime = (Get-Date).AddDays(-1)
} | Where-Object { $_.Properties[0].Value -eq $user } |
  Select-Object TimeCreated,
    @{N='LockedAccount';E={$_.Properties[0].Value}},
    @{N='SourceComputer';E={$_.Properties[1].Value}} |
  Format-Table -AutoSize

Výstup vám ukáže přesný čas zamknutí a název zdrojového počítače. To je ta klíčová informace, na kterou čekáte – teď víte, kam se dívat dál.

Metoda 2: Event Viewer (grafické rozhraní)

Pokud máte radši klikání než příkazový řádek (žádný stud), postup je taky jednoduchý:

  1. Přihlaste se na PDC Emulator
  2. Otevřete Event Viewer (eventvwr.msc)
  3. Přejděte na Windows Logs → Security
  4. V pravém panelu klikněte na Filter Current Log
  5. Do pole Event ID zadejte 4740
  6. Klikněte OK a projděte výsledky

V detailu události hledejte pole „Caller Computer Name" – to je počítač, ze kterého přišel požadavek na ověření se špatným heslem.

Doplňkové Event ID, které stojí za kontrolu

  • 4625: Neúspěšné přihlášení – obsahuje IP adresu zdroje a typ přihlášení
  • 4771: Selhání Kerberos pre-authentication – typicky špatné heslo
  • 4776: NTLM ověření – když klient použije starší protokol
# Hledání všech neúspěšných pokusů pro uživatele
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-4)
} | Where-Object { $_.Properties[5].Value -eq $user } |
  Select-Object TimeCreated,
    @{N='Account';E={$_.Properties[5].Value}},
    @{N='SourceIP';E={$_.Properties[19].Value}},
    @{N='LogonType';E={$_.Properties[10].Value}} |
  Format-Table -AutoSize

Hodnoty LogonType vám napoví, o jaký typ přihlášení šlo:

  • 2: Interaktivní přihlášení (fyzicky u počítače)
  • 3: Síťové přihlášení (mapované disky, sdílené složky)
  • 7: Odemknutí uzamčené obrazovky
  • 10: Vzdálená plocha (RDP)

Krok 5: Identifikujte konkrétní zdroj na cílovém počítači

Dobře, teď víte, ze kterého počítače zamykání přichází. To je skvělý posun. Dalším krokem je zjistit, co přesně na tom počítači odesílá špatné přihlašovací údaje.

Zkontrolujte uložené přihlašovací údaje

Na problémovém počítači otevřete příkazový řádek nebo PowerShell:

# Zobrazení uložených přihlašovacích údajů
cmdkey /list

Hledejte záznamy související s doménovým účtem uživatele. Pokud tam jsou staré záznamy, prostě je smažte:

# Smazání konkrétního záznamu
cmdkey /delete:Target_Name

Zkontrolujte služby Windows

# Najděte služby běžící pod doménovým účtem
Get-WmiObject Win32_Service | Where-Object {
    $_.StartName -like "*jnovak*"
} | Select-Object Name, DisplayName, StartName, State

Pokud nějaká služba běží pod účtem uživatele se starým heslem, aktualizujte heslo v konfiguraci služby. Nebo ještě líp – přepněte ji na Managed Service Account (gMSA), ať se tohle nemusí řešit znovu.

Zkontrolujte naplánované úlohy

# Najděte úlohy běžící pod doménovým účtem
Get-ScheduledTask | ForEach-Object {
    $info = $_ | Get-ScheduledTaskInfo -ErrorAction SilentlyContinue
    $principal = $_.Principal
    if ($principal.UserId -like "*jnovak*") {
        [PSCustomObject]@{
            TaskName = $_.TaskName
            TaskPath = $_.TaskPath
            UserId   = $principal.UserId
            State    = $_.State
        }
    }
}

Zkontrolujte mapované síťové disky

# Zobrazení mapovaných disků (spusťte pod profilem uživatele)
Get-PSDrive -PSProvider FileSystem | Where-Object { $_.DisplayRoot -like "\\*" }

Případně se podívejte do registru na trvalé mapování:

Get-ItemProperty "HKCU:\Network\*" | Select-Object PSChildName, RemotePath, UserName

Zkontrolujte Credential Manager

Otevřete Ovládací panely → Správce přihlašovacích údajů (nebo spusťte rundll32.exe keymgr.dll,KRShowKeyMgr) a odstraňte všechny zastaralé záznamy pro doménový účet. Tohle je mimochodem překvapivě častý viník.

Krok 6: Automatizace – skript pro kompletní diagnostiku

Pokud řešíte zamykání účtů pravidelně (a ruku na srdce – pokud jste na helpdesku, tak ho řešíte), vyplatí se mít po ruce skript, který udělá celou diagnostiku najednou:

function Get-AccountLockoutInfo {
    param(
        [Parameter(Mandatory)]
        [string]$Username,
        [int]$HoursBack = 24
    )

    $PDC = (Get-ADDomain).PDCEmulator
    $startTime = (Get-Date).AddHours(-$HoursBack)

    Write-Host "`n=== Stav uctu ===" -ForegroundColor Cyan
    Get-ADUser -Identity $Username -Properties LockedOut, LockoutTime, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet |
        Select-Object Name, LockedOut, LockoutTime, BadLogonCount, LastBadPasswordAttempt, PasswordLastSet |
        Format-List

    Write-Host "=== Zamknuti na jednotlivych DC ===" -ForegroundColor Cyan
    $DCs = Get-ADDomainController -Filter *
    foreach ($DC in $DCs) {
        $info = Get-ADUser -Identity $Username -Server $DC.HostName -Properties LockedOut, BadLogonCount -ErrorAction SilentlyContinue
        Write-Host "$($DC.HostName): LockedOut=$($info.LockedOut), BadLogonCount=$($info.BadLogonCount)"
    }

    Write-Host "`n=== Udalosti 4740 (zamknuti uctu) ===" -ForegroundColor Cyan
    try {
        Get-WinEvent -ComputerName $PDC -FilterHashtable @{
            LogName   = 'Security'
            Id        = 4740
            StartTime = $startTime
        } | Where-Object { $_.Properties[0].Value -eq $Username } |
            Select-Object TimeCreated,
                @{N='SourceComputer';E={$_.Properties[1].Value}} |
            Format-Table -AutoSize
    } catch {
        Write-Host "Zadne udalosti 4740 nenalezeny." -ForegroundColor Yellow
    }

    Write-Host "=== Udalosti 4625 (neuspesne prihlaseni) ===" -ForegroundColor Cyan
    try {
        Get-WinEvent -ComputerName $PDC -FilterHashtable @{
            LogName   = 'Security'
            Id        = 4625
            StartTime = $startTime
        } | Where-Object { $_.Properties[5].Value -eq $Username } |
            Select-Object TimeCreated,
                @{N='SourceIP';E={$_.Properties[19].Value}},
                @{N='LogonType';E={$_.Properties[10].Value}} |
            Format-Table -AutoSize
    } catch {
        Write-Host "Zadne udalosti 4625 nenalezeny." -ForegroundColor Yellow
    }
}

# Pouziti:
Get-AccountLockoutInfo -Username "jnovak" -HoursBack 48

Uložte si tento skript někam po ruce – do svého nástroje pro helpdesk, do sdíleného repozitáře, nebo ho přidejte do PowerShell profilu na administrátorské stanici. Budete ho používat častěji, než byste čekali.

Krok 7: Prevence opakovaného zamykání

Diagnostika je fajn, ale ještě lepší je zamykání účtů předcházet. Upřímně, prevence vám ušetří mnohem víc času než řešení problémů zpětně. Tady je pár osvědčených postupů:

Nasaďte Group Managed Service Accounts (gMSA)

Pokud máte služby nebo úlohy běžící pod doménovými účty, tohle je asi nejlepší věc, kterou můžete udělat. Group Managed Service Accounts fungují tak, že Active Directory automaticky rotuje jejich hesla a aplikace si nové heslo vyzvedne sama. Žádné ruční aktualizace, žádné zamykání.

# Vytvoření gMSA
New-ADServiceAccount -Name "gMSA-WebApp" `
    -DNSHostName "gmsa-webapp.domena.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebServery-Skupina"

Nastavte auditování přihlášení

Ujistěte se, že máte zapnutý audit neúspěšných přihlášení na všech doménových řadičích:

# Ověření nastavení auditu
auditpol /get /category:"Logon/Logoff"
auditpol /get /category:"Account Logon"

Obě kategorie by měly mít zapnutý audit pro Failure (a ideálně i Success). Bez toho nebudete mít v Event Logu co hledat.

Implementujte self-service reset hesla

Nástroje jako Microsoft Entra ID Self-Service Password Reset (SSPR) nebo řešení třetích stran umožní uživatelům resetovat si heslo sami. Bez volání na helpdesk. To výrazně snižuje počet situací, kdy uživatel zadává staré heslo, protože si nové nemůže rychle nastavit.

Pravidelně kontrolujte stáří hesel servisních účtů

# Servisní účty s heslem starším než 180 dní
$threshold = (Get-Date).AddDays(-180)

Get-ADUser -Filter {Enabled -eq $true -and PasswordLastSet -lt $threshold} `
    -SearchBase "OU=Servisni-Ucty,DC=domena,DC=local" `
    -Properties PasswordLastSet, Description |
    Select-Object Name, Description, PasswordLastSet |
    Sort-Object PasswordLastSet

Řešení specifických scénářů

Zamykání po změně hesla

Tohle je zdaleka nejčastější scénář. Uživatel si změní heslo, ale na některém zařízení nebo v některé aplikaci zůstane uložené to staré. Postup je celkem přímočarý:

  1. Odemkněte účet
  2. Pomocí Event ID 4740 zjistěte zdrojový počítač
  3. Na tomto počítači: vymažte Credential Manager, odpojte a znovu připojte mapované disky, aktualizujte Wi-Fi profil
  4. Na mobilním zařízení uživatele: aktualizujte heslo v nastavení Exchange/e-mailu a firemní Wi-Fi
  5. Restartujte počítač (ano, ta věčná klasika – ale funguje, protože vyčistí cachované Kerberos tikety)

Zamykání servisního účtu

Servisní účty se typicky zamykají po změně hesla, kdy se heslo neaktualizuje ve všech službách a úlohách. Tenhle typ problému bývá obzvlášť nepříjemný, protože jedna služba může běžet na více serverech.

  1. Zjistěte, na kterých serverech služba běží (pomocí Event ID 4740)
  2. Na těchto serverech aktualizujte heslo ve všech službách a naplánovaných úlohách
  3. Zvažte přechod na gMSA – tohle je přesně ten typ problému, který gMSA řeší jednou provždy

Zamykání z neznámého zdroje

Občas Event ID 4740 ukáže prázdné pole Caller Computer Name. To je frustrující, ale není to slepá ulička:

  1. Podívejte se na Event ID 4625 ve stejném časovém okně – ten obsahuje zdrojovou IP adresu
  2. Pomocí IP adresy identifikujte zařízení přes DHCP server nebo DNS
  3. Pokud je zdrojová IP adresa z externího rozsahu, může jít o brute-force útok – v takovém případě okamžitě eskalujte na bezpečnostní tým

Užitečné nástroje

  • Microsoft Account Lockout and Management Tools (ALTools): Starší sada nástrojů od Microsoftu, ale pořád funkční – LockoutStatus.exe zobrazí stav účtu na všech DC najednou
  • Netwrix Account Lockout Examiner: Bezplatný nástroj s grafickým rozhraním pro rychlou diagnostiku
  • PowerShell modul PSAccountLockout: Komunitní modul z PowerShell Gallery, automatizuje většinu diagnostických kroků
  • Microsoft Defender for Identity: Cloudové řešení, které umí detekovat podezřelé vzorce zamykání a upozornit na potenciální útoky

Často kladené otázky

Jak dlouho trvá, než se zamknutý účet automaticky odemkne?

Záleží na nastavení LockoutDuration ve vaší doménové politice. Nejčastěji vidím hodnotu 30 minut. Pokud je nastavena na 0, účet se sám neodemkne a musí ho odemknout administrátor ručně. Aktuální nastavení zjistíte příkazem Get-ADDefaultDomainPasswordPolicy.

Může zamykání účtu způsobit útočník zvenčí?

Bohužel ano. Brute-force útoky na přihlašovací rozhraní (OWA, VPN, RDP) mohou zamykat doménové účty. Pokud vidíte zamykání z externích IP adres, okamžitě eskalujte na bezpečnostní tým. Nejlepší ochrana? Nasazení vícefaktorového ověřování (MFA) a smart lockout politik v Microsoft Entra ID.

Proč se účet zamkne, i když uživatel zadá správné heslo?

Tenhle dotaz dostávám často a odpověď je většinou stejná – na jiném zařízení nebo v jiné aplikaci je uložené staré heslo. Systém se pokusí ověřit se starým heslem na pozadí (třeba při automatické synchronizaci e-mailu) a tyto neúspěšné pokusy se započítají do limitu. Uživatel pak zadá správné heslo na svém hlavním počítači, ale účet už je zamknutý.

Jak nastavím upozornění na opakované zamykání účtu?

Nejjednodušší způsob je vytvořit naplánovanou úlohu na PDC Emulátoru, která sleduje Event ID 4740 a při výskytu odešle e-mail. Pokud chcete něco robustnějšího, nasaďte Microsoft Defender for Identity nebo SIEM systém (Sentinel, Splunk), který umí korelovat události a detekovat podezřelé vzorce.

Mám zvýšit limit pokusů o přihlášení, aby se účty nezamykaly?

Zvýšení limitu (LockoutThreshold) z 3 na 5 je rozumný kompromis a osobně bych ho doporučil jako první krok. Hodnoty nad 10 ale výrazně snižují ochranu proti brute-force útokům. Lepší strategie je zachovat rozumný limit a investovat čas do nalezení a odstranění příčin zamykání – tedy přesně to, co jsme si tady prošli.

O Autorovi Editorial Team

Our team of expert writers and editors.