Det finns få saker som är mer nedslående än att sätta sig för att ansluta till sin egen dator på distans, skriva in sina inloggningsuppgifter och få veta, på det minst hjälpsamma sättet möjligt, att “en användarkontobegränsning (till exempel en inloggningstidsbegränsning) hindrar dig från att logga in.”

En inloggningstidsbegränsning? Jag konfigurerade den här datorn själv.

Det där var jag, utelåst från en Windows Server-maskin en timme efter att ha migrerat den till en nyare funktionell nivå för domänen. Efter att ha gått igenom Microsofts dokumentation och sysadmin-forum pusslade jag till slut ihop vad som hade gått fel, och det var inte alls vad felmeddelandet antydde.

Här är det som ingen säger dig i förväg: det här felet är inte ett enda problem, det är en kategori. Orsaken kan vara allt från ett lösenordslöst konto till att autentiseringsvägen tyst faller tillbaka till NTLM när endast Kerberos är tillåtet. När du väl förstår det är du redan halvvägs till att åtgärda det.

Användarkontobegränsning förhindrar inloggning

Innehållsförteckning

Symtom / Orsak	Miljö	Första åtgärden	Frekvens
Tomt / inget lösenord på lokalt konto	Fristående / hemdator	Åtgärd 1 — Ställ in ett lösenord	Vanlig
Konto saknas i rätten Tillåt RDP-inloggning	Alla	Åtgärd 2 — Kontrollera tilldelning av användarrättigheter	Vanlig
Konto i rätten Neka RDP-inloggning	Alla	Åtgärd 2 — Ta bort från Neka-principen	Vanlig
Ansluter via IP, NTLM begränsat	Domän	Åtgärd 3 — Använd FQDN-värdnamn	Vanlig
Konto låst	Alla	Åtgärd 4 — Lås upp i ADUC / lusrmgr	Sporadisk
Begränsning av inloggningstider	Domän	Åtgärd 4 — Kontrollera inloggningstider i ADUC	Sporadisk
Konto i Protected Users, Kerberos fungerar inte	Domän	Åtgärd 5 — Reparera Kerberos eller ta bort från gruppen	Admin/härdad
Händelseloggar visar autentiseringsfel	Alla	Åtgärd 6 — Läs säkerhetsloggen (Händelse 4625)	Diagnostik

Den åtgärd du behöver beror helt på din miljö. Gå igenom dessa frågor innan du rör något.

Kan du logga in lokalt med samma konto? Om ja, och endast RDP misslyckas, handlar det inte om felaktiga inloggningsuppgifter. Problemet är en RDP-rättighetstilldelning, en policybegränsning eller ett problem med autentiseringsvägen. Kontrollera Händelsevisaren → Windows-loggar → Säkerhet på måldatorn efter händelse-ID 4625. I domänmiljöer bör du också kontrollera domänkontrollerns säkerhetsloggar, eftersom vissa autentiseringsfel bara syns där.

En användare eller alla? Att en enskild användare spärras pekar på en inställning på kontonivå. Att alla spärras samtidigt tyder på en nylig policyändring, en Gruppolicy-uppdatering eller en serverkonfigurationsändring.

Fristående dator eller domänansluten? Domänmiljöer introducerar Active Directory-gruppolicyer, Kerberos, NTLM-begränsningar och beteendet hos Protected Users. Om du använder en fristående hemdator är troligen bara åtgärderna 1, 2 och 4 relevanta. Om du är i en domän kan alla åtgärder vara aktuella.

Ansluter du via IP-adress eller värdnamn? Detta spelar större roll än de flesta inser. Att ansluta via IP-adress förhindrar vanligtvis att Windows använder Kerberos och tvingar en återgång till NTLM. Om NTLM är begränsat i din miljö misslyckas den återgången, och du får just det här felet, även om inget med ditt faktiska konto har ändrats. Se åtgärd 3.

Ändrades något nyligen? Uppdateringar av Gruppolicy, operativsystemspatchar, uppgraderingar av domänens funktionella nivå och säkerhetshärdning kan alla slå ut RDP över en natt utan synlig varning. Ställ alltid den här frågan innan du antar att problemet är ditt konto.

Åtgärderna 1–4 är de mest relevanta här. Dessa kräver ingen Active Directory- eller domänkunskap.

Börja här, särskilt på en hemdator eller fristående dator.

Windows blockerar som standard fjärrinloggningar för lokala konton som saknar lösenord. Detta är en avsiktlig och dokumenterad säkerhetspolicy: inställningen “Accounts: Limit local account use of blank passwords to console logon only” är aktiverad som standard, vilket innebär att lösenordsfria konton är begränsade till interaktiva konsolinloggningar. RDP är en fjärrinteraktiv inloggning och blockeras därför.

Varför detta händer: Microsoft dokumenterar detta beteende under inställningen i den lokala säkerhetspolicyn “Konton: Begränsa lokala kontons användning av tomma lösenord till endast konsolinloggning.” (Microsoft Learn)

Ange ett lösenord: öppna Datorhantering → Lokala användare och grupper → Användare → högerklicka på kontot → Ange lösenord. Om det löser problemet är du klar.

Det finns en nödlösning: du kan inaktivera begränsningen mot tomma lösenord via secpol.msc eller registernyckeln LimitBlankPasswordUse. Betrakta detta som en sista utväg på alla nätverksåtkomliga datorer.

Varning: Att inaktivera begränsningar för tomma lösenord försvagar din attackyta avsevärt. Att välja ett starkt lösenord är alltid den korrekta lösningen.

Detta är en av de vanligaste orsakerna och en av de lättaste att missa.

Windows använder två kompletterande Gruppolicyinställningar för att kontrollera RDP-åtkomst:

Tillåt inloggning via Fjärrskrivbordstjänster — ger rätt att ansluta.
Neka inloggning via Fjärrskrivbordstjänster — blockerar rätten att ansluta.

Neka-policyn åsidosätter alltid Tillåt, oavsett gruppmedlemskap. Detta är ett dokumenterat Microsoft-beteende.

Var det finns: Öppna gpedit.msc → Datorkonfiguration → Windows-inställningar → Säkerhetsinställningar → Lokala principer → Tilldelning av användarrättigheter.

Kontrollera båda policyerna. Bekräfta att ditt konto, eller en grupp det tillhör, såsom Remote Desktop Users eller Administrators, finns i Tillåt. Bekräfta att det inte finns i Neka. Om ditt konto saknas helt i Tillåt blockeras RDP-åtkomst oavsett ditt lösenord eller dina autentiseringsuppgifter.

På domänanslutna datorer: Dessa rättigheter kan ställas in på domännivå via Gruppolicy och kan åsidosätta lokala inställningar. Om de lokala inställningarna ser korrekta ut men problemet kvarstår, kontrollera om det finns motstridiga GPO:er med hjälp av gpresult /h report.html på måldatorn.

Den här enda ändringen löser fler problem än vad man kan förvänta sig.

När du ansluter med en IP-adress (till exempel 192.168.1.100) kan Windows vanligtvis inte använda Kerberos-autentisering och faller i stället tillbaka på NTLM. På fristående hemdatorer är detta ofta okej. På domänanslutna datorer där NTLM är begränsat eller inaktiverat misslyckas denna fallback tyst, och du får felet om kontobegränsning, även om ingenting med ditt konto har ändrats.

Använd i stället datorns värdnamn:

server.yourdomain.com ✔ Rekommenderas

192.168.1.100 ✘ Tvingar fallback till NTLM

Använd också inloggningsuppgifter i UPN-format när du ansluter till domändatorer: user@domain.com i stället för DOMAIN\user. Detta hjälper Windows att välja rätt autentiseringsmetod och undviker förvånansvärt många specialfall.

Undantag: Microsoft har dokumenterat en nyare funktion för Kerberos över IP för Windows Server-miljöer, men den kräver explicit konfiguration och är inte aktiverad som standard. (Microsoft Learn: Konfigurera Kerberos för IP-adress).

Windows returnerar samma generiska meddelande för flera olika typer av begränsningar, vilket är en del av det som gör det här felet så frustrerande. Kontolåsningar och tidsbegränsningar för inloggning är två av de sällsynta fall där felmeddelandet är bokstavligen korrekt.

För lokala konton (fristående eller domän) Öppna lusrmgr.msc → välj användaren → kontrollera om Kontot är låst är ikryssat. Lås upp det i så fall.

För domänkonton Öppna Active Directory-användare och -datorer → hitta användaren → dubbelklicka → fliken Konto. Markera Lås upp konto och granska Inloggningstider.

En administratör av Windows Server 2016 beskrev att han/hon stötte på just denna vägg: anslutningen till servern misslyckades med felmeddelandet om kontobegränsning, men inga tidsbegränsningar hade avsiktligt konfigurerats. Orsaken var en Gruppolicy som tyst hade tillämpat en inloggningsbegränsning efter en uppdatering av domänpolicyn. Händelse-ID 4625 i säkerhetsloggen skulle ha visat den specifika underkoden.

Händelse 4625: Säkerhetsloggens post för ett misslyckat inloggningsförsök innehåller en understatuskod som identifierar den exakta orsaken. Vanliga värden: 0xC0000234 (kontot låst), 0xC000006F (inloggning utanför tillåtna tider), 0xC0000022 (åtkomst nekad). Kontrollera detta innan du gissar orsaken.

Åtgärderna 5 och 6 kräver åtkomst till Active Directory och kännedom om Kerberos och NTLM. Om du använder en fristående hemdator kan du hoppa över det här avsnittet.

Detta är felbeteendet som överrumplar erfarna administratörer, ofta efter en domänuppgradering.

Active Directorys säkerhetsgrupp Protected Users tvingar igenom striktare autentiseringsregler för sina medlemmar:

NTLM-autentisering blockeras helt.
Endast Kerberos tillåts, och då endast med AES-kryptering.
Kerberos-krypteringstyperna RC4 och DES är inte tillåtna.
Autentiseringsuppgifter cachas inte på datorn.

På pappret är detta utmärkt säkerhetshygien. I praktiken bryter det RDP-åtkomst i miljöer som tyst förlitade sig på NTL, vilket är precis vad som händer när du ansluter via IP-adress, när DNS är felkonfigurerat eller när Kerberos inte har validerats fullt ut efter en domänuppgradering. Användaren får det generiska meddelandet om kontobegränsning utan någon indikation på att Protected Users är inblandad.

Varför det dyker upp efter domänuppgraderingar: Att höja domänens funktionsnivå möjliggör ofta striktare verkställighet av befintliga principer. Konton som redan fanns i Protected Users men som tidigare tolererade NTLM-fallback kan plötsligt misslyckas. (Microsoft Learn: säkerhetsgruppen Protected Users)

Innan du tar bort någon från Protected Users, prova följande steg i denna ordning:

Använd maskinens FQDN (server.domain.com), inte en IP-adress.
Använd UPN-inloggningsuppgifter (user@domain.com).
Kontrollera att DNS-upplösning fungerar korrekt från den anslutande datorn.
Bekräfta anslutning till domänkontrollanten och att Kerberos-tjänsten körs.

Om Kerberos fungerar korrekt försvinner problemet vanligtvis utan några ändringar av kontot. Om inte kan du ta bort kontot från Protected Users som en tillfällig åtgärd:

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

Om PowerShell-fjärrkörning: Detta tillvägagångssätt fungerar när PowerShell Remoting är tillgängligt. Observera att PowerShell Remoting också använder Kerberos när det är tillgängligt och NTLM som reserv, så det kan ställas inför samma autentiseringsbegränsningar i fullt härdade miljöer. (Microsoft Learn: WinRM-säkerhet)

Varning: Att ta bort ett konto från Protected Users försvagar dess säkerhetsstatus. Behandla detta som ett diagnostiskt steg, inte en permanent lösning. Den korrekta åtgärden är att säkerställa att Kerberos fungerar korrekt i din miljö.

Logga ut och låt autentiseringen uppdateras innan du försöker ansluta via RDP igen efter varje ändring av gruppmedlemskap.

Vid det här laget, sluta gissa och börja läsa.

På målmaskinen Händelsevisaren → Windows-loggar → Säkerhet. Filtrera på händelse-ID 4625. Varje post innehåller en Failure Reason och en Sub Status-kod som identifierar den exakta orsaken, betydligt mer precist än själva RDP-felmeddelandet.

För djupare autentiseringsspårning, aktivera även: Program- och tjänstloggar → Microsoft → Windows → Authentication.

På domänkontrollanter Vissa autentiseringsfel, särskilt Kerberos-relaterade, loggas bara på den domänkontrollant som behandlade begäran, inte på målmaskinen. Kontrollera säkerhetsloggarna på dina DC:er när de lokala målloggarna inte ger hela bilden.

När du hittar Sub Status-koden i händelse 4625 slutar felet vara vagt och blir ett specifikt, diagnostiserbart problem. Vanliga koder listas i anteckningen för Fix 4 ovan.

Om du ser felkod 0xC07, särskilt på macOS med Microsoft Remote Desktop, dyker den vanligtvis upp tillsammans med samma typ av autentiserings- och begränsningsproblem som beskrivs i den här artikeln. Rapporter från communityn tyder på att anslutning via värdnamn i stället för IP-adress löser det i många fall, vilket är förenligt med det NTLM-fallbackmönster som beskrivs i Fix 3.

Det finns ingen entydig Microsoft-dokumentation som tydligt kopplar 0xC07 till en enda grundorsak. Betrakta det som en signal om att du är i rätt problemkategori snarare än en exakt diagnos. Åtgärderna ovan gäller.

När RDP-åtkomst nekas med meddelandet “user account restriction” gör Windows exakt det som det är avsett att göra, bara utan att tala om för dig vilken regel du snubblade över.

Den snabbaste vägen till en lösning är:

Använd den diagnostiska matrisen högst upp i den här artikeln för att identifiera den mest sannolika orsaken.
Tillämpa den relevanta åtgärden för din miljö (hem/fristående eller domän).
Kontrollera händelse-ID 4625 på målmaskinen om orsaken fortfarande är oklar.
För domänmiljöer, kontrollera även domänkontrollantens loggar och bekräfta att Kerberos fungerar innan du ändrar kontoinställningar.

För det mesta är det något enkelt. Även när det inte är det är det oftast något logiskt, bara dolt bakom ett mycket intetsägande meddelande.

Så här åtgärdar du att en begränsning för användarkonto hindrar dig från att logga in

Snabbdiagnostik

Del 1: Hem-PC & fristående maskiner

Lösning 1: Kontot har inget lösenord

Åtgärd 2: Kontrollera vilka som får ansluta via RDP

Åtgärd 3: Sluta ansluta via IP-adress

Åtgärd 4: Kontrollera kontolåsningar och inloggningstidsbegränsningar

Del 2: Domän- och företagsmiljöer

Åtgärd 5: Gruppen för skyddade användare

Åtgärd 6: Läs loggarna när inget annat verkar rimligt

Hur är det med felkod 0xC07?

Sammanfattning