AD Account Lockout Oplossen: PowerShell 2026

Een vergrendeld Active Directory-account is zo'n klassiek helpdesk-ticket waar elke beheerder een bloedhekel aan heeft. Je ontgrendelt het account, de gebruiker werkt twee minuten door, en hop — ticket weer open. Eerlijk? Zolang je niet weet welke bron de mislukte aanmeldpogingen veroorzaakt, blijf je gewoon dweilen met de kraan open.

In deze gids laat ik je zien hoe je de oorzaak in een paar minuten boven tafel krijgt met Event ID 4740, Get-WinEvent en wat PowerShell-scripts die je vandaag nog in productie kunt zetten. Geschreven voor Windows Server 2022 en 2025, met een knipoog naar de hybride realiteit van 2026 (Microsoft Defender for Identity, Azure AD Connect Health, Entra-koppelingen — je kent het rijtje).

Waarom een account vergrendeld raakt (en wat 4740 wel én niet vertelt)

Active Directory vergrendelt een account zodra het aantal mislukte aanmeldpogingen de drempel uit het wachtwoordbeleid overschrijdt. Microsoft adviseert in 2026 een drempel van 10 tot 50 mislukte pogingen en een vergrendelingsduur van 30 tot 60 minuten. Daarmee blokkeer je brute-force-aanvallen, zonder dat je je gebruikers continu het systeem uittrapt.

Bij elke vergrendeling wordt Event ID 4740 weggeschreven naar het Security-log van de domeincontroller die de mislukte authenticatie heeft afgehandeld. En hier zit een addertje onder het gras: dit event wordt niet gerepliceerd. Zoek dus altijd op de PDC Emulator, of beter nog: op alle domeincontrollers tegelijk.

Wat het event je wel vertelt:

Account Name — de getroffen gebruiker.
Caller Computer Name — de hostnaam van het apparaat dat de pogingen deed.
Tijdstip en de DC die de gebeurtenis logde.

Wat het event je niet vertelt: welk wachtwoord werd geprobeerd, hoeveel mislukte pogingen er vooraf gingen, en of de poging interactief, via een service of via een netwerkclient kwam. Daarvoor heb je Event ID 4625 nodig op de bron-machine zelf. Daar komen we later op terug.

Snelle ontgrendeling: zo krijg je de gebruiker direct weer aan het werk

Voer dit op een domeincontroller of een werkstation met de Active Directory PowerShell-module uit:

Unlock-ADAccount -Identity "jdevries"

Wil je álle vergrendelde accounts in het domein in één keer ontgrendelen — bijvoorbeeld nadat iemand een verkeerd wachtwoord op een file-share had gehardcodeerd? Een one-liner volstaat:

Search-ADAccount -LockedOut | Unlock-ADAccount

Maar let op. Ontgrendelen lost de oorzaak niet op. Sterker nog, ik heb het zelf vaker meegemaakt dan me lief is: je ontgrendelt vrolijk, en binnen drie minuten staat hetzelfde account er weer op zwart zodra de volgende synchronisatieronde van het schuldige proces begint. Dus eerst zoeken, dan pas ontgrendelen (of in elk geval bijna gelijktijdig).

Stap 1: vind de PDC Emulator

De PDC Emulator is in de meeste omgevingen de DC waar lockout-events naartoe stromen. Bepaal eerst welke DC die rol heeft:

Get-ADDomain | Select-Object PDCEmulator

Voer de volgende scripts vervolgens tegen die hostnaam uit, of laat het script automatisch alle DC's doorlopen (zie verderop — dat scheelt vaak een hoop gepriegel).

Stap 2: de bron vinden via Event Viewer

Open Event Viewer (eventvwr.msc) op de PDC Emulator.
Navigeer naar Windows Logs → Security.
Kies in het rechterpaneel Filter Current Log… en vul bij Event IDs in: 4740.
Open de meest recente gebeurtenis voor de getroffen gebruiker.
Lees onder Account That Was Locked Out de gebruikersnaam, en onder Caller Computer Name het bron-systeem.

Is de Caller Computer Name een werkstation? Ga daar verder met Event ID 4625. Is het een server, een Exchange-host of een mobiele MDM-server? Dan ligt de oorzaak vrijwel zeker in een opgeslagen credential of een service die zijn wachtwoord nooit heeft bijgewerkt.

Stap 3: PowerShell-scripts om de bron te vinden

De GUI is leuk voor één geval, maar wie meerdere accounts of meerdere DC's tegelijk wil onderzoeken, ontkomt niet aan PowerShell. Hieronder een paar snippets die ik in vrijwel elke omgeving gebruik.

Basisquery — alle 4740-events op de huidige DC

Get-WinEvent -FilterHashTable @{LogName='Security'; ID=4740} |
  Select-Object TimeCreated, Message |
  Format-Table -Wrap

Beperkt tot de afgelopen 24 uur

In productieomgevingen krijg je al snel honderden 4740's per week. Filter standaard op tijd, anders verzuip je in de output:

$Start = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashTable @{LogName='Security'; ID=4740; StartTime=$Start} |
  Select-Object TimeCreated, Message |
  Format-Table -Wrap

Account Name en Caller Computer Name uit het event halen

Het Message-veld is vrije tekst en daardoor lastig te parseren. Gebruik liever de gestructureerde Properties-array — dat scheelt je een hoop regex-ellende:

$properties = @(
    'TimeCreated',
    @{n='Account Name';         e={$_.Properties[0].Value}},
    @{n='Caller Computer Name'; e={$_.Properties[1].Value}}
)

Get-WinEvent -FilterHashTable @{LogName='Security'; ID=4740} |
    Select-Object $properties

Zoek in alle domeincontrollers tegelijk

Omdat 4740 niet gerepliceerd wordt, is het soms gewoon het efficiëntst om elke DC af te gaan. Het volgende script doorzoekt het hele domein voor één gebruiker:

function Find-UserLockOut {
    param(
        [Parameter(Mandatory=$true)]
        [string]$Name,
        [int]$DaysBack = 1
    )

    $DCs       = Get-ADDomainController -Filter *
    $startDate = (Get-Date).AddDays(-$DaysBack)

    $properties = @(
        'TimeCreated',
        @{n='Account';      e={$_.Properties[0].Value}},
        @{n='ComputerName'; e={$_.Properties[1].Value}}
    )

    foreach ($DC in $DCs) {
        Write-Host "Onderzoek $($DC.HostName)..." -ForegroundColor Cyan
        try {
            Get-WinEvent -ComputerName $DC.HostName -FilterHashTable @{
                LogName   = 'Security'
                ID        = 4740
                StartTime = $startDate
            } -ErrorAction Stop |
                Where-Object Message -Match $Name |
                Select-Object $properties
        }
        catch {
            Write-Warning "Kan geen verbinding maken met $($DC.HostName): $_"
        }
    }
}

Find-UserLockOut -Name 'jdevries' -DaysBack 7

Werkt het script niet meteen? Geen paniek — check de sectie Veelvoorkomende fouten verderop.

Stap 4: bekijk Event ID 4625 op de bron-machine

Zodra je via 4740 weet welk apparaat verantwoordelijk is, log je in op die machine (of bevraag je hem remote) en duik je Event ID 4625 — Failed Logon — in. Hier vind je het echte verhaal: welk proces, welk logon-type, en welke applicatie probeerde te authenticeren.

$Start = (Get-Date).AddHours(-2)
Get-WinEvent -ComputerName 'WS-FIN-014' -FilterHashTable @{
    LogName   = 'Security'
    ID        = 4625
    StartTime = $Start
} | Select-Object TimeCreated,
    @{n='Account';     e={$_.Properties[5].Value}},
    @{n='Source IP';   e={$_.Properties[19].Value}},
    @{n='Process';     e={$_.Properties[18].Value}},
    @{n='LogonType';   e={$_.Properties[10].Value}},
    @{n='Failure';     e={$_.Properties[7].Value}}

Vergelijk de tijdstempels met die van de 4740: meestal vind je een hele serie 4625-events vlak voor de lockout, allemaal van hetzelfde proces. Bingo — daar zit je dader.

De zes meest voorkomende oorzaken

Gecachede inloggegevens in Windows Credential Manager of de browser-autofill. Wis ze met cmdkey /list en cmdkey /delete:<target>.
Serviceaccounts waarvan het wachtwoord is veranderd, terwijl de service nog vrolijk het oude wachtwoord gebruikt. Controleer met Get-WmiObject Win32_Service | Where-Object StartName -like "*username*".
Geplande taken (Task Scheduler) met opgeslagen credentials. Bekijk met schtasks /query /v /fo LIST.
Mobiele apparaten via Exchange ActiveSync. Verwijder verlopen apparaten met Get-ActiveSyncDeviceStatistics en Clear-MobileDevice.
Mapped drives en RDP-verbindingen die met expliciete credentials zijn opgeslagen.
Brute-force-aanvallen vanaf het internet, vooral via RDP-poort 3389 of een Exchange OWA-endpoint.

In mijn ervaring zijn de eerste twee samen verantwoordelijk voor zo'n 70% van alle lockouts. Begin dus daar — bespaart je een hoop tijd.

Wat als Caller Computer Name leeg is?

Een leeg Caller Computer Name-veld in 4740, of een ontbrekend Client Address in Event 4771, betekent meestal één van twee dingen:

De aanvalsbron is een externe machine die geen volledige Kerberos-uitwisseling voltooit.
Een NTLM-relay-aanval of een brute-force-poging vanaf het internet (RDP, OWA, VPN-portaal).

Om de bron toch te lokaliseren schakel je Netlogon-debugging in:

nltest /dbflag:2080FFFF

Het log verschijnt vervolgens in C:\Windows\debug\netlogon.log. Zoek op de gebruikersnaam en bekijk welk IP-adres de pogingen doet. En vergeet niet de debugging weer uit te zetten zodra je klaar bent (anders groeit dat log als kool):

nltest /dbflag:0x0

Veelvoorkomende fouten bij remote query's

"RPC server is unavailable" — Schakel de Windows Firewall-regel Remote Event Log Management (RPC) in op de DC, controleer of de RPC-service draait, en verifieer DNS-resolutie.
"Access is denied" — Het account dat de query uitvoert moet lid zijn van de groep Event Log Readers op de doel-DC.
"No events were found" — Óf er zijn écht geen lockouts, óf je zit op een DC die de gebeurtenis niet heeft afgehandeld. Voer het script gewoon tegen alle DC's uit.

Preventieve best practices voor 2026

Centraliseer 4740-events in een SIEM (Microsoft Sentinel, Splunk, Wazuh) zodat je niet meer per DC hoeft te zoeken.
Stel alerts in op high-frequency lockouts (>5 per uur per gebruiker) en op lockouts van bevoorrechte accounts.
Beperk legacy-authenticatie: schakel NTLMv1 en LM-hashes uit via GPO en forceer Kerberos waar het kan.
Gebruik gMSA (Group Managed Service Accounts) voor services. Wachtwoorden roteren automatisch — en dat betekent: geen lockout-bron meer voor service accounts.
Activeer Microsoft Defender for Identity als je een Microsoft 365 E5- of stand-alone licentie hebt; dat detecteert verdachte authenticatiepatronen voordat ze 4740 triggeren.
Self-service password reset via Entra ID verlaagt het aantal helpdesk-tickets met gemiddeld 30%. Niet niks, dus.

Helpdesk-checklist: AD-lockout in 5 minuten

Verifieer de gebruiker en ontgrendel met Unlock-ADAccount.
Voer Find-UserLockOut -Name <username> -DaysBack 1 uit.
Identificeer de Caller Computer Name.
Op de bron: bekijk Event ID 4625 en correleer op tijdstip.
Adresseer de oorzaak: credential cache wissen, service-wachtwoord bijwerken, geplande taak vernieuwen of mobiel apparaat opnieuw koppelen.
Documenteer de oorzaak in het ticket — toekomstige helpdesk-collega's zullen je dankbaar zijn (en jezelf over een half jaar trouwens ook).

Veelgestelde vragen

Hoe vind ik snel welke DC mijn 4740-events logt?

Begin altijd bij de PDC Emulator. Blijft de Caller Computer Name daar leeg, doorzoek dan álle DC's via een PowerShell-loop. In moderne hybride omgevingen kunnen lockouts trouwens ook via Azure AD Pass-Through Authentication binnenkomen — controleer dan ook even het PTA-agentlog.

Waarom raakt mijn account 's nachts om 3 uur vergrendeld?

Bijna altijd een geplande taak met een verlopen wachtwoord, een back-upservice, of een mobiel apparaat dat netjes om die tijd synchroniseert. Bekijk de Task Scheduler en draai Get-ActiveSyncDeviceStatistics op je Exchange-server.

Helpt het verhogen van de lockout-drempel?

Het kan symptomen verlichten, maar het lost de oorzaak niet op. Microsoft adviseert 10–50 mislukte pogingen — ga niet hoger dan 50, want dan verzwak je je beveiliging tegen brute-force-aanvallen serieus.

Wat is het verschil tussen Event ID 4740 en 4771?

4740 is de lockout zelf en wordt geschreven door de DC die de mislukte pogingen telde. 4771 (Kerberos pre-authenticatie mislukt) wordt bij elke individuele mislukte poging gelogd op de DC die het Kerberos-ticket valideerde. Combineer beide voor een compleet beeld.

Kan ik lockouts voorkomen zonder beleid te wijzigen?

Ja, en eerlijk: dat is vaak de beste route. Implementeer gMSA voor services, gebruik Windows Hello for Business of FIDO2-keys voor gebruikers, en activeer Microsoft Defender for Identity. Daarmee verdwijnt de meerderheid van de "fantoom"-lockouts vanzelf.