Fejlfinding 11 min læsning

Active Directory kontolåsninger — find kilden og løs problemet: Helpdesk-guide 2026

Låste AD-konti er et af de mest hyppige helpdesk-kald. Denne 2026-guide viser dig trin-for-trin, hvordan du finder kilden med Event ID 4740, PowerShell og LockoutStatus.exe — og forhindrer gentagne låsninger fra Credential Manager, Outlook-profiler, mobile enheder og Scheduled Tasks.

Editorial Team
Fix AD Kontolåsning: Event 4740 Guide 2026

Lad os være ærlige: låste Active Directory-konti er nok den mest gentagne henvendelse, IT-helpdesken nogensinde kommer til at håndtere. En bruger kan ikke logge ind, produktiviteten går i stå, og så starter detektivjagten — ofte en, der æder en hel eftermiddag. Og i 2026 er problemet blevet endnu mere sammensat: hybride arbejdsmønstre, Microsoft Entra (tidligere Azure AD) Connect-synkronisering, mobile mail-klienter, gemte VPN-legitimationsoplysninger, og så alle de baggrundstjenester, der autentificerer med cachelagrede passwords uden nogensinde at sige noget.

Denne guide er skrevet til IT-helpdesk og systemadministratorer, der skal løse kontolåsninger hurtigt — uden at bruge en hel eftermiddag på at nulstille passwords, som alligevel bliver låst igen 20 minutter senere (jeg har været der, og det er virkelig frustrerende). Vi gennemgår årsagerne, hvordan du pålideligt finder kilden med Event ID 4740, hvilke PowerShell-kommandoer der faktisk virker, og hvordan du forebygger gentagne låsninger med gMSA, Credential Manager-oprydning og fornuftige audit-politikker.

Hvad er en Active Directory kontolåsning egentlig?

En AD-kontolåsning (account lockout) udløses, når antallet af mislykkede logonforsøg overstiger tærsklen i domænets adgangskodepolitik. Mekanismen er designet til at beskytte mod brute-force-angreb og password spraying — men i praksis er det langt oftere operationelle årsager (ikke angreb), der rammer brugerne.

Microsoft anbefaler i 2026 en tærskel på 10 forsøg indenfor et 10-minutters vindue som et rimeligt kompromis mellem sikkerhed og brugervenlighed. Tærsklen fastsættes i Default Domain Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.

Sådan flyder en låsning

Når en bruger indtaster et forkert password, videresender den nærmeste domænecontroller forsøget til den DC, der holder PDC Emulator FSMO-rollen. PDC Emulator fungerer som "sandhedens orakel" for passwords og lockout-tællere. Når tærsklen overskrides, logges Event ID 4740 både på den lokale DC og på PDC Emulator. Det betyder, at PDC Emulator er dit første og bedste sted at kigge. Skriv det bag øret.

De mest almindelige årsager til AD-kontolåsninger i 2026

Før du begynder at grave i logs, er det værd at kende de typiske årsager. Efter mange års helpdesk-erfaring vil jeg skyde på, at cirka 80 % af alle låsninger falder i én af nedenstående kategorier:

  1. Cachelagrede legitimationsoplysninger på Windows. Efter et password-skifte forsøger Credential Manager stadig at bruge det gamle password mod filshares, SharePoint eller interne webtjenester.
  2. Outlook-profiler med gemt password. En klassiker. Brugeren har skiftet password, men Outlook på kontoret — eller på en anden maskine — kører stadig videre med den gamle værdi.
  3. Mobile enheder (ActiveSync / Outlook mobile). iOS, Android og iPadOS holder ofte stædigt fast i det gamle password, indtil brugeren manuelt genkonfigurerer kontoen.
  4. Gemte Wi-Fi- og VPN-profiler. 802.1X-profiler og Always On VPN-konfigurationer, der bruger domæne-legitimationsoplysninger, kan udløse konstante låsninger.
  5. Windows-tjenester og Scheduled Tasks. En tjeneste eller planlagt opgave, der kører som en domænekonto med et forældet password, autentificerer hvert minut og låser kontoen på rekordtid.
  6. Mapped drives. En netværkssti mappet med eksplicitte legitimationsoplysninger kan forsøge autentificering ved hver opstart.
  7. Terminal Server / RDP-sessioner. En afkoblet session på en Remote Desktop Services-host, der forsøger at genoprette forbindelse med gammel kode.
  8. Applikationer med hårdkodet password. Ældre integrationer, rapporteringsværktøjer og ETL-jobs er notoriske syndere — ofte gemt i en konfigurationsfil, ingen har rørt siden 2019.
  9. Brute-force og password spraying. Rent sikkerhedsmæssigt: bør altid undersøges, hvis kilden er en offentligt eksponeret tjeneste (ADFS, Exchange, OWA).

Forudsætning: Aktivér de rigtige audit-politikker

Du kan ikke fejlfinde kontolåsninger, hvis der ikke logges noget. Det lyder indlysende, men du vil blive overrasket over, hvor mange miljøer der kører uden fornuftig auditing. Event ID 4740 genereres kun, når Audit Account Management er aktiveret. Aktivér politikken i gpmc.msc under:

Computer Configuration
  └── Policies
      └── Windows Settings
          └── Security Settings
              └── Advanced Audit Policy Configuration
                  └── Account Management
                      └── Audit User Account Management: Success, Failure

Aktivér også Audit Logon og Audit Account Logon under Logon/Logoff, så du kan korrelere med Event ID 4625 på kildecomputeren. Husk at køre gpupdate /force på dine domænecontrollere bagefter — ellers sker der ingenting, og det er nemt at glemme.

Trin 1: Find PDC Emulator-rollen

Før du søger i sikkerhedsloggen, skal du vide, hvilken DC der holder PDC Emulator-rollen. Åbn PowerShell på en administrativ maskine med RSAT installeret:

# Find PDC Emulator i det aktuelle domæne
Get-ADDomain | Select-Object PDCEmulator

# Alternativ — alle FSMO-roller
netdom query fsmo

Output viser DNS-navnet på PDC Emulator. Det er her, du skal søge efter låsningshændelser. Simpelt.

Trin 2: Søg efter Event ID 4740 på PDC Emulator

Event 4740 indeholder de vigtigste felter, du skal bruge:

  • Account Name — den bruger, der blev låst.
  • Caller Computer Name — navnet på den maskine, hvorfra de mislykkede forsøg kom.
  • Lockout Time — tidspunktet for låsningen.

Du kan finde hændelsen i Event Viewer under Security, men personligt bruger jeg altid PowerShell — det er hurtigere, og outputtet er nemmere at dele med en kollega:

# Hent de seneste 4740-hændelser fra PDC Emulator
$PDC = (Get-ADDomain).PDCEmulator

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

Et lille tip, som kan spare dig for en masse tid: undgå at filtrere med Where-Object på selve Get-WinEvent-outputtet — brug altid -FilterHashtable. Forskellen er virkelig dramatisk. Den samme forespørgsel kan gå fra 13 minutter til under et sekund, fordi filteret eksekveres serverside. Jeg lærte det på den hårde måde, da jeg engang prøvede at søge gennem en uges 4740-hændelser på en travl DC…

Trin 3: Find kilden for en specifik bruger

Når en bruger ringer, vil du typisk vide præcis, hvor deres lockout kom fra. Følgende funktion søger på tværs af alle domænecontrollere, fordi 4740 ikke altid replikerer pålideligt:

#requires -Module ActiveDirectory
function Find-ADUserLockoutSource {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory)]
        [string] $Username,

        [int] $DaysBack = 3
    )

    $DCs       = Get-ADDomainController -Filter *
    $StartTime = (Get-Date).AddDays(-$DaysBack)
    $Results   = @()

    foreach ($DC in $DCs) {
        try {
            $Events = Get-WinEvent -ComputerName $DC.HostName -FilterHashtable @{
                LogName   = 'Security'
                Id        = 4740
                StartTime = $StartTime
            } -ErrorAction Stop

            foreach ($Event in $Events) {
                if ($Event.Properties[0].Value -eq $Username) {
                    $Results += [PSCustomObject]@{
                        Time            = $Event.TimeCreated
                        DomainController = $DC.HostName
                        LockedUser      = $Event.Properties[0].Value
                        CallerComputer  = $Event.Properties[1].Value
                    }
                }
            }
        }
        catch {
            Write-Verbose "Ingen 4740-hændelser fundet på $($DC.HostName): $_"
        }
    }

    $Results | Sort-Object Time -Descending
}

# Eksempel
Find-ADUserLockoutSource -Username 'mette.hansen' -DaysBack 2

Gem scriptet som Find-ADUserLockoutSource.ps1 i dit helpdesk-script-repo, så hele teamet kan bruge det som en one-liner under et brugeropkald. Det er — bogstaveligt talt — det script, jeg har kørt flest gange i min karriere.

Trin 4: Inspicér kildecomputeren (Event ID 4625)

Når du har fundet Caller Computer Name, er næste skridt at undersøge den pågældende maskine. Her leder du efter Event ID 4625 (An account failed to log on), som fortæller dig hvilken proces der forsøgte at autentificere med det forkerte password.

# Kør på kildemaskinen (kræver lokal admin)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated,
    @{N='FailedUser';    E={$_.Properties[5].Value}},
    @{N='SourceProcess'; E={$_.Properties[18].Value}},
    @{N='LogonType';     E={$_.Properties[10].Value}},
    @{N='Workstation';   E={$_.Properties[13].Value}} |
    Format-Table -AutoSize

Fortolk LogonType sådan her:

  • 2 — Interaktiv (nogen skrev forkert password på tastaturet).
  • 3 — Netværk (fil-share, SMB).
  • 4 — Batch (Scheduled Task).
  • 5 — Service (Windows-tjeneste).
  • 7 — Unlock (låsning af skærmlås).
  • 8 — NetworkCleartext (ofte IIS / Basic Auth).
  • 10 — RemoteInteractive (RDP).
  • 11 — CachedInteractive (offline-login med cached credentials).

LogonType 5 sammen med et proces-navn som svchost.exe eller taskhostw.exe peger næsten altid på en tjeneste eller planlagt opgave, der kører med et forældet password. Og ja, det er altid den tjeneste, ingen kan huske, hvem der har oprettet.

Trin 5: Afhjælp kildeårsagen

Cachelagrede legitimationsoplysninger

# List og ryd gemte legitimationsoplysninger
cmdkey /list
cmdkey /delete:TERMSRV/server01.contoso.local
cmdkey /delete:Domain:target=contoso.local

Alternativt kan du bare åbne Credential Manager (control /name Microsoft.CredentialManager) og rydde Windows Credentials manuelt. Samme resultat.

Outlook-profil

Tving Outlook til at bede om nye legitimationsoplysninger:

# Fjern gemte Outlook-legitimationsoplysninger
cmdkey /list | Select-String "MicrosoftOffice" |
    ForEach-Object {
        $target = ($_ -split ': ')[1].Trim()
        cmdkey /delete:$target
    }

Luk Outlook helt (tjek i Task Manager — den har det med at stikke af i baggrunden) og start igen. Brugeren vil blive bedt om at logge ind på ny.

Scheduled Tasks med gammelt password

# Find alle scheduled tasks, der kører som en bestemt bruger
Get-ScheduledTask | Where-Object { $_.Principal.UserId -like "*mette.hansen*" } |
    Select-Object TaskName, TaskPath, State

Opdater password med schtasks /change /tn "OpgaveNavn" /ru DOMAIN\bruger /rp, eller — endnu bedre — konvertér opgaven til at køre som en Group Managed Service Account (gMSA). Det er 2026-best practice for alle ikke-interaktive arbejdsbelastninger, og ærligt talt burde du gøre det uanset, næste gang du rører ved opgaven.

Windows-tjenester

# List tjenester, der kører under en domænekonto
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -like "DOMAIN\*" } |
    Select-Object Name, StartName, State

Værktøjer, du bør have i værktøjskassen

Microsoft Account Lockout and Management Tools (AlTools)

LockoutStatus.exe er Microsofts gratis værktøj, der viser lockout-status for en given konto på tværs af alle DC'er i domænet. Nyttigt, når du hurtigt vil se, hvor mange forkerte forsøg der er registreret, og hvilken DC der blev ramt først.

AD Pro Toolkit

Et kommercielt værktøj, men Lockout Status-modulet viser alle aktuelt låste brugere med ét klik. Godt for Tier 1-helpdesk, der ikke ønsker at rode med PowerShell.

Netwrix Account Lockout Examiner

Gratis, viser låsningshændelser i realtid med tydeligt kildenavn. Kører fint som desktop-værktøj på helpdesk-PC'er — en favorit blandt mange Tier 1-teams.

PowerShell + SIEM

Hvis I har en SIEM (Microsoft Sentinel, Splunk, Elastic), så opret en regel på Event ID 4740, der korrelerer med 4625 og beriger med Caller Computer Name. Derefter kan Tier 1 løse 80 % af sagerne uden overhovedet at åbne en PowerShell-prompt. Det er den investering, der giver mest igen.

Lås en konto op uden at vente på timeout

# Ved navn
Unlock-ADAccount -Identity mette.hansen

# Alle aktuelt låste konti
Search-ADAccount -LockedOut | Unlock-ADAccount -Confirm

# Nulstil password og tving skift ved næste login
Set-ADAccountPassword -Identity mette.hansen -Reset -NewPassword `
    (ConvertTo-SecureString "MidlertidigtKodeord!2026" -AsPlainText -Force)
Set-ADUser -Identity mette.hansen -ChangePasswordAtLogon $true

Gentagne låsninger — tjekliste

Hvis en konto bliver låst igen og igen, selv efter password-reset, så gennemgå følgende. Det er en liste, jeg har samlet over årene, og den dækker cirka 95 % af de hårdnakkede sager:

  1. Ryd Credential Manager på alle maskiner, brugeren har logget ind på (inkl. Remote Desktop-hosts).
  2. Glem og genkonfigurér kontoen på brugerens mobiltelefon (iOS Settings → Mail → Accounts → slet og tilføj igen).
  3. Tjek ActiveSync-partnerskaber i Exchange: Get-ActiveSyncDeviceStatistics -Mailbox mette.hansen.
  4. Gennemgå Scheduled Tasks på alle servere, brugeren har adgang til.
  5. Tjek Windows Services på arbejdsstationen og afdelings-servere.
  6. Inspicér gemte 802.1X-profiler: netsh wlan show profiles.
  7. Bed brugeren om at logge ud af alle browser-sessioner mod SharePoint, Teams og Outlook on the Web.
  8. Undersøg, om der er gamle RDP-sessioner på terminalservere: query session /server:TS01.

Forebyggelse i 2026

  • Skift til passwordless / Windows Hello for Business. Den bedste kontolåsning er den, der aldrig sker. Microsoft anbefaler i 2026, at alle organisationer kører en FIDO2 / Windows Hello-first strategi — og det er et råd, der holder.
  • Brug Group Managed Service Accounts (gMSA). Passwords roteres automatisk, og de bliver aldrig cached forkert i en applikation.
  • Konfigurér Fine-Grained Password Policies. Giv service- og administrationskonti længere lockout-vinduer og andre regler end normale brugere.
  • Aktivér Microsoft Entra Password Protection. Blokerer svage og ofte-misbrugte passwords, som er de typiske ofre for password spraying.
  • Overvåg 4740 i realtid. Opret en alarm i dit SIEM, der trigger ved mere end fem 4740-hændelser for samme bruger indenfor 15 minutter.
  • Dokumentér kendte arbejdsstationer. Hold en intern wiki med typiske Caller Computer Names (RDS-hosts, print-servere, scan-to-mail), så helpdesk kan genkende legitime kilder hurtigt.

Almindelige fejlscenarier og løsning

Scenarie 1: Caller Computer Name er tomt

Hvis feltet er blankt, kom forsøget typisk fra en netværksenhed (VPN-gateway, RADIUS, en ældre IIS-server med Basic Auth). Tjek VPN-serverens logs og NPS-loggen (%SystemRoot%\System32\LogFiles).

Scenarie 2: Caller Computer Name er navnet på en Exchange-server

Kilden er næsten altid en mobil mail-klient eller en Outlook-profil med gammelt password. Undersøg IIS-loggen på Exchange (C:\inetpub\logs\LogFiles\W3SVC1) og filtrér på brugerens alias — du vil kunne se enhedstypen i User-Agent. Ofte er det en gammel iPhone, som brugeren for længst har glemt eksisterer.

Scenarie 3: Kontoen er låst, men 4740 findes ikke

Audit-politikken er ikke aktiveret. Se trinnet "Forudsætning" ovenfor. Alternativt kan tiden være ude af sync mellem DC'erne — kør w32tm /monitor for at verificere.

Scenarie 4: Bruger klager over "konto låst", men AD siger den er oplåst

Klienten har cachet en forældet fejlmeddelelse. Bed brugeren genstarte — eller, hvis det haster, kør klist purge i en admin-prompt for at rydde Kerberos-billetter.

FAQ — Ofte stillede spørgsmål

Hvor længe er en AD-konto låst som standard?

Standard-lockout-varigheden i Windows Server 2019/2022/2025 er typisk 15–30 minutter, men det styres af Account lockout duration-politikken. Mange organisationer sætter den til 0, hvilket betyder "aldrig — indtil en administrator låser op". Undersøg altid din Default Domain Policy med net accounts /domain, før du estimerer en ventetid over for brugeren.

Hvorfor bliver min konto ved med at blive låst selv efter password-reset?

Den mest almindelige årsag er en gemt legitimation, der stadig bruger det gamle password. Tjek Credential Manager, Outlook-profiler, mobile enheder, mapped drives og planlagte opgaver. Kør Find-ADUserLockoutSource-scriptet i denne guide for at se præcis, hvilken computer der forårsager låsningen.

Hvad er forskellen på Event ID 4740 og 4625?

Event ID 4740 logges på domænecontrollere, når en konto bliver låst — det fortæller dig kilden (Caller Computer Name) på netværksniveau. Event ID 4625 logges på selve kildecomputeren, hver gang et logonforsøg mislykkes, og det fortæller dig, hvilken proces og logon-type der forårsagede fejlen. Du har brug for begge for at løse sagen: 4740 finder computeren, 4625 finder processen.

Hvad er PDC Emulator, og hvorfor er den vigtig for kontolåsninger?

PDC Emulator er den domænecontroller, der holder den gamle PDC FSMO-rolle. Den fungerer som autoritativ kilde for password-ændringer og kontolåsninger. Når en DC ikke kan verificere et password, videresender den forsøget til PDC Emulator som sidste chance. Derfor er Event 4740 altid tilgængelig på PDC Emulator, selvom andre DC'er måske ikke replikerer den.

Kan jeg finde kilden til en kontolåsning uden PowerShell?

Ja. Åbn Event Viewer direkte på PDC Emulator, gå til Windows Logs → Security, og brug Filter Current Log til at søge på Event ID 4740. Microsofts LockoutStatus.exe fra Account Lockout and Management Tools er også et grafisk alternativ, der viser status på tværs af alle DC'er uden scripting.

Hvordan forhindrer jeg, at en hackers password spraying låser mine brugere ude?

Aktivér Microsoft Entra Password Protection, som blokerer kendte svage passwords på AD-niveau. Konfigurér Smart Lockout (del af Microsoft Entra ID), der skelner mellem lockout-forsøg fra kendte brugeragenter og ukendte kilder. Implementér MFA via Windows Hello for Business eller FIDO2-nøgler — det gør brute-force-forsøg stort set meningsløse, selv når et password er kendt.

Afrunding

Active Directory-kontolåsninger er uundgåelige i ethvert domænemiljø, men med den rigtige kombination af audit-politikker, PowerShell-scripts og en systematisk arbejdsgang kan helpdesk løse langt de fleste sager på under fem minutter. Nøglen er at kende PDC Emulator-rollen, mestre Event ID 4740, og vide præcis, hvor man skal lede på kildecomputeren. Kombinér med gMSA, Windows Hello for Business og proaktiv SIEM-overvågning, så reducerer du både antallet af låsninger og den tid, hver sag trækker ud. Held og lykke derude — og husk: det er næsten aldrig brugerens skyld.

Om Forfatteren Editorial Team

Our team of expert writers and editors.

Relaterede Artikler