AD-kontoutlåsning: Hitta källan 2026

Uppdaterad: 24 juni 2026

Ett AD-konto som låses ständigt beror nästan alltid på en gammal cachad inloggning på en specifik enhet eller tjänst. Felsökningen handlar om att läsa Event ID 4740 från säkerhetsloggen på den PDC-emulator som äger lockout-flödet, identifiera Caller Computer Name, och sedan stänga av eller uppdatera den gamla sessionen. I den här guiden går jag igenom hela kedjan från policyinställning till PowerShell-detektion, runbook-stil, med exakt vad du ska köra och vilken utdata du ska förvänta dig.

Kontoutlåsning loggas som Event ID 4740 på PDC-emulatorn. Alla DC:er vidarebefordrar lockout-händelser dit.
Fältet TargetUserName visar kontot, CallerComputerName visar källan. Det är källan du måste åtgärda, inte kontot.
Standardpolicy i Windows Server 2022/2025 är 10 misslyckade försök, 30 minuters spärrtid, återställning efter 30 minuter. Justera via Default Domain Policy eller en Fine-Grained Password Policy (PSO).
PowerShell-modulen ActiveDirectory ger dig Search-ADAccount -LockedOut och Unlock-ADAccount. Du behöver inte längre LockoutStatus.exe i de flesta fall.
Vanliga källor: cachad inloggning på en mobil, en mappad nätverksenhet med gammalt lösenord, en schemalagd aktivitet, en RDP-session eller en sparad credential i Credential Manager.
Om du inte ser några 4740-händelser, kontrollera att Audit Account Management är aktiverat i Default Domain Controllers Policy.

Vad är AD-kontoutlåsning och hur fungerar den?

Kontoutlåsning är Active Directorys skydd mot brute force-attacker mot lösenord. När en användare överskrider tröskelvärdet för misslyckade inloggningar inom ett visst tidsfönster sätts attributet lockoutTime på användarobjektet till en non-zero NTFS-tidsstämpel, och alla efterföljande inloggningsförsök avvisas oavsett om lösenordet är rätt. Det är en domänomspännande effekt. När PDC-emulatorn har replikerat lockout-flaggan kan användaren inte logga in på någon resurs som autentiserar mot AD, inklusive arbetsstationer, Exchange-postlådor, RDP-sessioner och alla applikationer som använder Kerberos eller NTLM mot domänen.

Den viktiga detaljen som många helpdesk-tekniker missar: varje misslyckat lösenordsförsök replikeras omedelbart till PDC-emulatorn, inte enligt det vanliga replikeringsintervallet. Det är därför PDC alltid är den auktoritativa källan för utlåsningsräknaren, och varför Event ID 4740 till slut hamnar där även om felförsöket gjordes på en helt annan DC eller på en arbetsstation. Det här designvalet förenklar felsökningen enormt: du behöver bara fråga ett ställe. Den som vill ha det formella beteendet hittar det i Microsofts dokumentation för Account Lockout Policy.

För en bredare översikt av AD-felsökning rekommenderar jag att läsa vår kompletta guide till Active Directory-felsökning först. Det här inlägget förutsätter att du redan vet hur du hittar dina domänkontrollanter och flyttar FSMO-roller vid behov.

Standardpolicy och rekommendationer för 2026

Sedan Windows Server 2022 (och oförändrat i 2025) levereras en nyinstallerad domän med följande standardvärden i Default Domain Policy om du installerar via Server Manager eller väljer Recommended baseline i Security Compliance Toolkit:

Inställning	Standard 2022/2025	CIS Benchmark 2026	Min rekommendation
Account lockout threshold	10	5	10
Account lockout duration	30 min	15 min	15 min
Reset account lockout counter after	30 min	15 min	15 min
Allow Administrator account lockout	Disabled	Enabled	Enabled

Tröskeln på 10 försök är en kompromiss. Den är hög nog att en användare inte ska låsa sig själv på grund av cachad mobil men låg nog att stoppa en interaktiv attack. Sätt aldrig tröskeln till 0 (oändliga försök); det är inte en lockout-policy, det är frånvaron av en. På 2026-baseliner är jag personligen mer benägen att rekommendera CIS-värdena om miljön redan har MFA på alla kritiska konton. Då är spärrtiden mer en irritation än ett skydd och kortare återställningstid sänker helpdesk-trycket.

För privilegierade konton (Domain Admins, Enterprise Admins, tjänstekonton som inte borde misslyckas alls) använder du en Fine-Grained Password Policy via Password Settings Object (PSO). Det är det enda sättet att differentiera policy per säkerhetsgrupp utan att skapa en barn-domän. Skapa PSO:n via ADSI Edit eller PowerShell:

New-ADFineGrainedPasswordPolicy `
    -Name "PSO-Tier0-Admins" `
    -Precedence 10 `
    -ComplexityEnabled $true `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:15:00" `
    -LockoutThreshold 5 `
    -MaxPasswordAge "30.00:00:00" `
    -MinPasswordLength 16 `
    -PasswordHistoryCount 24 `
    -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject `
    -Identity "PSO-Tier0-Admins" `
    -Subjects "Domain Admins","Enterprise Admins"

Förväntad utdata: inget returneras vid lyckad körning. Verifiera med Get-ADFineGrainedPasswordPolicy -Filter * och kontrollera att AppliesTo-fältet listar de avsedda grupperna. PSO:ns precedence bestämmer vinnaren när ett konto är medlem i flera grupper med olika PSO:er, lägst nummer vinner.

Hitta PDC-emulatorn där 4740 hamnar

Innan du kan läsa lockout-händelserna behöver du veta vilken DC som är PDC-emulator. Kör från valfri domänansluten Windows:

Get-ADDomain | Select-Object PDCEmulator
# eller från cmd:
netdom query fsmo

Förväntad utdata: ett FQDN, till exempel DC01.corp.contoso.com. Notera namnet, du kommer fråga säkerhetsloggen på exakt den maskinen i nästa steg. Om miljön har flera domäner i samma skog har varje domän sin egen PDC-emulator; lockout-händelser för en användare i eu.contoso.com hamnar på den domänens PDC, inte på rotens.

Om du planerar att felsöka regelbundet rekommenderar jag att samla 4740-händelser till en Windows Event Collector eller en SIEM (Sentinel, Splunk, Elastic). Då slipper du RDP:a till PDC varje gång supportbiljetten dyker upp och du har historik kvar även efter att DC:n roterat loggen. Glöm inte att lockout-händelser också är värdefulla som detektionssignal för password spraying. En plötslig topp av 4740 över många användare är ofta första tecknet på en attack.

Läsa Event ID 4740 med PowerShell

Standardflödet är att fråga säkerhetsloggen direkt på PDC. Det här är vad jag kör först varje gång ett ärende landar i kön:

$pdc = (Get-ADDomain).PDCEmulator
$user = "anna.svensson"

Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'
    Id      = 4740
    StartTime = (Get-Date).AddDays(-3)
} | Where-Object { $_.Properties[0].Value -eq $user } |
    Select-Object TimeCreated,
                  @{N='User';      E={ $_.Properties[0].Value }},
                  @{N='Source';    E={ $_.Properties[1].Value }},
                  @{N='DC';        E={ $_.MachineName }}

Förväntad utdata: en eller flera rader där Source är ett NetBIOS-namn eller IP. Om Source är tomt eller står som \\ är källan en non-Windows-enhet (mobiltelefon med IMAP/EAS, en Linux-server som binder mot LDAP, eller en applikation som proxyar autentisering). Då måste du följa upp via nätverksloggen eller applikationens egen logg. Du kan korsreferera mot DHCP-loggar eller dina nätverksdiagnostikverktyg för att översätta IP till enhet.

Om kommandot returnerar "No events were found" trots att du vet att kontot har låst sig, kontrollera först att Audit Account Management → Success är aktiverat i Default Domain Controllers Policy. Utan det skrivs ingen 4740 alls. Det är förvånansvärt vanligt i miljöer som har migrerats flera gånger eller där någon härdat GPO:erna manuellt utan att läsa STIG-referensen.

Varför låses mitt AD-konto upprepade gånger?

I min erfarenhet faller 90 % av alla återkommande utlåsningar i en av sex kategorier. Det här är checklistan jag går igenom innan jag öppnar tekniska verktyg:

Mobil enhet med gammalt Exchange-lösenord. Användaren bytte lösenord på datorn men telefonen försöker fortfarande synka med det gamla. Exchange ActiveSync re-tryar var 5–15 minut. Fixet: ta bort kontot från telefonen, lägg till på nytt.
Mappad nätverksenhet med sparade credentials. Användaren har net use Z: \\server\share /user:domän\anna gammalt-lösen i en startup-script eller i Credential Manager.
Schemalagd aktivitet (Task Scheduler) som kör som användaren. Vanlig orsak i shared workstations. Granska med schtasks /query /v /fo LIST och leta efter Run As User.
Outlook-profil på en gammal dator som inte stängts av. Profilen försöker autentisera mot Exchange varje gång den startar.
Sparade webbläsarcredentials mot interna SharePoint/Confluence/Jira. Särskilt vanligt med Edge och Chrome som synkar credentials över enheter.
Tjänstekonto som används av en applikation (SQL Linked Server, IIS App Pool, scheduled SSIS). Här krävs koordination med applikationsägaren, ändra lösenord på båda ställen samtidigt.

I ovanliga fall är källan en faktisk attack, password spraying från en kompromitterad endpoint eller från internet om du har Outlook on the web exponerat. Mönstret är då många konton som låses ungefär samtidigt med olika CallerComputerName eller med ett enda externt IP. Då blir det incidentrespons, inte helpdesk.

Hur hittar man källan till en kontoutlåsning?

När 4740 på PDC pekar på en specifik CallerComputerName går du vidare till den maskinen och letar efter Event ID 4625 i dess egen säkerhetslogg. 4625 innehåller mer detaljer än 4740: vilken process som gjorde försöket, vilken logon-typ (interaktiv, nätverk, batch, service, RDP) och i många fall vilken arbetsstationsnamn klienten påstår sig vara.

$source = "WS-ANNA-LAPTOP"
$user   = "anna.svensson"

Get-WinEvent -ComputerName $source -FilterHashtable @{
    LogName = 'Security'
    Id      = 4625
    StartTime = (Get-Date).AddHours(-2)
} | Where-Object { $_.Properties[5].Value -eq $user } |
    Select-Object TimeCreated,
                  @{N='LogonType'; E={ $_.Properties[10].Value }},
                  @{N='Process';   E={ $_.Properties[18].Value }},
                  @{N='IpAddress'; E={ $_.Properties[19].Value }} |
    Format-Table -AutoSize

Logon Type-koderna är avgörande för att tolka utdata. De viktigaste:

Logon Type	Betydelse	Typisk källa till lockout
2	Interactive	Användaren skriver fel lösenord på låsskärmen
3	Network	Mappad enhet, SMB-share, RPC-anrop
4	Batch	Schemalagd aktivitet
5	Service	Windows-tjänst som körs som användaren
8	NetworkCleartext	IIS Basic Auth, gammal LDAP simple bind
10	RemoteInteractive	RDP-session med cachat lösenord
11	CachedInteractive	Offline-cachad domäninloggning

Logon Type 4 och 5 är de absolut vanligaste vid återkommande utlåsningar. När du ser dem, be användaren öppna Credential Manager (control /name Microsoft.CredentialManager) och rensa Windows Credentials för domänen, kontrollera Task Scheduler för aktiviteter som körs som användaren, och kontrollera Services för tjänster som har användaren angiven som Log On As. Det löser ärendet i de flesta fall utan att du behöver återställa något lösenord.

Hur låser man upp ett AD-konto med PowerShell?

Att låsa upp själva kontot är trivialt. Men gör det INTE förrän du har identifierat källan, annars låser den sig igen inom några minuter och användaren ringer tillbaka.

# Lista alla låsta konton i domänen
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LastLogonDate

# Lås upp ett specifikt konto
Unlock-ADAccount -Identity "anna.svensson" -Confirm:$false

# Bulkupplåsning (var försiktig, bara om du är säker på att källan är hanterad)
Search-ADAccount -LockedOut | Unlock-ADAccount -Confirm:$false

Förväntad utdata: inget vid lyckad upplåsning. Verifiera med Get-ADUser anna.svensson -Properties LockedOut, lockoutTime. LockedOut ska vara False och lockoutTime ska vara 0. Cmdleten replikerar förändringen omedelbart till PDC; övriga DC:er får uppdateringen vid nästa replikeringsintervall (15 minuter standard inom site, 180 minuter mellan sites). Vill du tvinga replikering kör du repadmin /syncall /AdeP.

Komplett runbook för helpdesk

Det här är versionen jag delar med tier 1 så de kan stänga 80 % av lockout-ärendena utan eskalering:

Verifiera att det faktiskt är en lockout. Kör Get-ADUser anna.svensson -Properties LockedOut. Om LockedOut = False är det inte en lockout. Det är ett bortglömt lösenord, en utgången smartkortcert eller en MFA-bug. Annan runbook.
Hitta PDC. (Get-ADDomain).PDCEmulator
Läs senaste 4740 från PDC med PowerShell-snippet ovan. Notera CallerComputerName.
Om Source är användarens egen dator, be dem rensa Credential Manager och granska Task Scheduler. Lås upp kontot. Stäng ärendet.
Om Source är en server, kontakta server-/applikationsägaren innan du gör något. Vanliga misstänkta: gamla schemalagda jobb, IIS App Pools, SQL-tjänster.
Om Source är en mobiltelefon (IP istället för namn), be användaren ta bort företagskontot från enheten och lägga till på nytt med aktuellt lösenord.
Om Source är tomt eller okänt, eskalera till tier 2. Detta är där du behöver mer avancerad nätverksforensik.
Lås upp kontot med Unlock-ADAccount först när källan är åtgärdad eller dokumenterad i ärendet.
Skapa en uppföljningsbiljett om kontot låsts mer än två gånger under samma vecka. Det är ett tecken på en orsak du inte hittat.

Kombinera den här runbooken med en konsekvent GPO-tillämpning så att alla DC:er har samma auditpolicy. Det är där loggarna kommer ifrån. En miljö där Default Domain Controllers Policy avviker mellan DC:er kommer ge inkonsekventa 4740-resultat och göra runbooken oanvändbar.

Förebygga upprepade utlåsningar

Det enskilt mest effektiva förebyggande arbetet är att migrera bort från lösenord på resurser som lämnar kontoret. Konkret innebär det:

Aktivera Windows Hello for Business eller FIDO2-säkerhetsnycklar för slutanvändare. När det inte finns något lösenord att skriva fel kan kontot inte heller låsas av en cachad credential.
Migrera applikations- och tjänstekonton till Group Managed Service Accounts (gMSA). gMSA-lösenord roteras automatiskt av Windows var 30:e dag och kan aldrig låsa sig på samma sätt som ett vanligt konto.
Aktivera Self-Service Password Reset i Microsoft Entra ID. Detta minskar inte antalet utlåsningar men minskar drastiskt helpdesk-belastningen när de inträffar.
Implementera Smart Lockout i Entra ID, Microsofts ML-baserade lockout som skiljer på legitima typos och attacker. Detaljerna finns i Microsofts officiella Smart Lockout-dokumentation.
Lägg in en monitoringregel för "användare med >3 lockouts på 24h". Det är där proaktiv felsökning ger mest värde.

Vanliga frågor

Vilken händelse-ID är kontoutlåsning i Active Directory?

Event ID 4740 i säkerhetsloggen, loggat på PDC-emulatorn. Föregående misslyckade inloggningar som ledde fram till utlåsningen loggas som Event ID 4625 på maskinen där försöket gjordes.

Hur länge varar en AD-kontoutlåsning som standard?

30 minuter i en standardinstallation av Windows Server 2022 och 2025, styrt av Account lockout duration i Default Domain Policy. Du kan sätta värdet till 0 för att kräva manuell upplåsning eller justera ner till exempelvis 15 minuter för en mer användarvänlig policy.

Varför står Caller Computer Name tomt i Event 4740?

Det innebär nästan alltid att autentiseringen kom från en non-Windows-klient som inte skickade ett NetBIOS-namn, exempelvis en mobiltelefon med EAS/IMAP, en Linux-server med LDAP, eller en applikation som proxyar autentisering. Korsreferera tidsstämpeln mot DHCP-loggar eller en SIEM för att hitta källan.

Replikeras kontoutlåsning omedelbart mellan domänkontrollanter?

Ja för PDC-emulatorn. Varje DC vidarebefordrar misslyckade lösenordsförsök och själva lockout-flaggan till PDC direkt utan att vänta på normalt replikeringsintervall. Övriga DC:er får upplåsningen via det vanliga schemat (15 minuter inom site). Kör repadmin /syncall /AdeP om du behöver tvinga konvergens.

Kan jag använda LockoutStatus.exe i Windows Server 2025?

Verktyget startar och rapporterar fortfarande korrekt, men det är inte längre rekommenderat. Använd Search-ADAccount -LockedOut och Get-WinEvent -Id 4740 via PowerShell. Det är supportat, snabbare och fungerar utan att behöva installeras lokalt på varje DC.

Hur stoppar jag att samma konto låses gång på gång?

Lås inte upp förrän du har identifierat källan via Event 4740 → Event 4625-flödet. När källan är en mappad enhet eller cachad credential, rensa Credential Manager, granska Task Scheduler och Services efter aktiviteter som körs som användaren. För återkommande fall, överväg Windows Hello for Business eller FIDO2-nycklar så att lösenordet inte längre kan vara fel på en cachad enhet.