Åtgärda RDP-felet 'Logon Attempt Failed' i Windows

Du skriver in dina inloggningsuppgifter, Windows Security-prompten blinkar till och en röd rad visas: The logon attempt failed. Sessionen öppnas aldrig. Jag har stött på detta i hemlabb, på klientdatorer och på servrar. Och felet ser identiskt ut oavsett om orsaken är en saknad Gruppolicy-behörighet, en inaktuell Credential Manager-post, en Windows-uppdatering som bröt CredSSP eller en domänkontrollant som tillfälligt inte gick att nå.

I den här artikeln går jag igenom de vanligaste bekräftade grundorsakerna och testade åtgärderna för RDP-felet logon attempt failed.

Innehållsförteckning

The logon attempt failed är det generiska Windows-meddelandet för en avvisning av autentiseringsuppgifter någonstans i RDP-autentiseringskedjan. Det visas som text i RDP-dialogrutan för inloggningsuppgifter innan fjärrskrivbordet upprättas. Problemet är att Windows returnerar samma sträng för fel vid flera olika punkter.

Windows säkerhetslogg på måldatorn registrerar detta som Event ID 4625, och status- eller understatuskoden i den händelsen är det som faktiskt identifierar var felet inträffade.

Detta löser en stor del av de fall där inloggningsuppgifterna är korrekta, men anslutningen misslyckas. Jag börjar här innan jag rör något annat.

På måldatorn, tryck på Windows-tangenten + R, skriv secpol.msc, och tryck på Enter för att öppna Lokal säkerhetspolicy.
Expandera Lokala principer och välj Tilldelning av användarrättigheter.
I den högra rutan, dubbelklicka på Tillåt inloggning via Fjärrskrivbordstjänster.
Klicka på Lägg till användare eller grupp och ange det exakta användarnamnet för det konto som du använder för att ansluta.
Klicka på OK och stäng Lokala säkerhetsprinciper.
Öppna en förhöjd kommandotolk och kör gpupdate /force för att tillämpa ändringen utan att starta om.

När du är i Datorhantering, kontrollera också att kontot är medlem i gruppen Fjärrskrivbordsanvändare under Lokala användare och grupper. Detta ersätter inte principrättigheten men är en del av den förväntade konfigurationen. Som standard ger medlemskap i gruppen Fjärrskrivbordsanvändare vanligtvis denna rättighet, om det inte åsidosätts av lokal eller domänbaserad Gruppolicy. Om en Gruppolicy uttryckligen åsidosätter detta kan du dock behöva lägga till kontot direkt i principrättigheten, även om gruppmedlemskapet redan finns.

Kör denna åtgärd omedelbart efter Fix 1 om felet kvarstår, särskilt efter ett lösenordsbyte på måldatorn.

På den dator som ansluter, öppna Start-menyn och sök efter Hanteraren för inloggningsuppgifter.
Välj Windows-referenser.
Leta efter poster som börjar med TERMSRV/ följt av IP-adressen eller värdnamnet för målmaskinen.
Expandera varje matchande post och klicka på Ta bort.
Stäng Hantering av autentiseringsuppgifter.
Öppna Fjärrskrivbordsanslutning, ange inloggningsuppgifterna manuellt och anslut.

Låt inte Fjärrskrivbordsanslutningen spara inloggningsuppgifterna igen medan du fortfarande felsöker. Avmarkera kryssrutan Låt mig spara inloggningsuppgifter innan du ansluter, så att Windows inte skriver en ny föråldrad post.

För Win11-till-Win11-fallet på build 26100.6584 som rapporterats i Microsoft Q&A kan man också åtgärda fall där delegeringsprincipen för inloggningsuppgifter stör genom att manuellt lägga till målmaskinens inloggningsuppgifter via Kontrollpanelen > Hanteraren för inloggningsuppgifter > Windows-inloggningsuppgifter > Lägg till en Windows-inloggningsuppgift.

Lägga till en Windows-autentiseringsuppgift i Hanteraren för autentiseringsuppgifter

Testa också med en ny RDP-profil genom att starta mstsc, klicka på Visa alternativ och undvika att använda sparade anslutningsprofiler. Skadade eller föråldrade RDP-konfigurationsfiler (.rdp) kan återanvända ogiltiga parametrar eller inloggningsuppgifter.

NLA autentiserar sessionen i förväg med dina autentiseringsuppgifter innan fjärrskrivbordet läses in. När måldatorn inte kan nå domänkontrollanten, när det finns en versionsinkompatibilitet för CredSSP, eller när kontotypen är inkompatibel med NLA-handskakningen, kan NLA misslyckas med autentiseringshandskakningen och visa samma logon attempt failed-meddelande på klientsidan. Att inaktivera NLA tillfälligt bekräftar om det är orsaken.

På måldatorn, tryck på Windows-tangenten + Paus för att öppna Systemegenskaper, klicka sedan på Fjärrinställningar i den vänstra rutan.
På fliken Fjärr, avmarkera Tillåt endast anslutningar från datorer som kör Fjärrskrivbord med nätverksnivåautentisering.
Klicka på Verkställ.
Försök att ansluta från klientdatorn.

Om anslutningen lyckas med NLA inaktiverat ligger problemet i NLA-autentiseringskedjan, och du kan felsöka vidare utan att gissa. För åtkomst via registret lagras NLA-inställningen på:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Värdets namn är UserAuthentication. Sätt det till 0 för att inaktivera NLA eller 1 för att kräva det. Värdet SecurityLayer på samma sökväg styr det bredare säkerhetslagret: 0 för endast RDP-säkerhet, 1 för förhandling, 2 för SSL.

Ändra värdena SecurityLayer och UserAuthentication i Registereditorn

NLA:s förautentiseringssteg är just det som går sönder i de supportsituationer som IT-tekniker oftast stöter på:

Fjärrdatorer utanför företagsnätverket
Slutpunkter där domänkontrollanten inte går att nå
Datorer där ingen IT-konfiguration har gjorts

Om ditt användningsfall är fjärrsupport snarare än självåtkomst till dina egna datorer, tar HelpWire bort detta lager ur ekvationen helt och hållet. Slutanvändaren öppnar en sessionslänk och ansluter utgående utan NLA, utan krav på att domänen går att nå och utan någon kontokonfiguration på deras sida.

Microsoft-konton kan användas för RDP, men autentiseringen kan misslyckas om Windows Hello eller en PIN-kod används i stället för kontolösenordet, om användarnamnsformatet är felaktigt (till exempel att använda e-postadress i stället för MicrosoftAccount\email i vissa konfigurationer), eller om konflikter med cachelagrade inloggningsuppgifter uppstår. I dessa fall kan det vara mer tillförlitligt att uttryckligen använda kontolösenordet eller ett lokalt konto som en tillfällig lösning:

På måldatorn, öppna Inställningar och gå till Konton, sedan Andra användare.
Klicka på Lägg till konto, klicka sedan på Jag har inte den här personens inloggningsinformation.
Välj Lägg till en användare utan Microsoft-konto.
Skapa ett användarnamn och ett starkt lösenord för det lokala kontot.
Efter att kontot har skapats, klicka på det i Andra användare, välj Ändra kontotyp och ställ in det på Administratör.
Gå tillbaka till åtgärd 1 och ge det här lokala kontot rätten Tillåt inloggning via Fjärrskrivbordstjänster i den lokala säkerhetsprincipen.
Använd användarnamnet och lösenordet för det lokala kontot när du ansluter via RDP.

I många fall åtgärdas problemet mer tillförlitligt genom att byta till ett lokalt administratörskonto, särskilt när lösenordsfri eller PIN-baserad autentisering är aktiverad.

Två uppdateringsrelaterade scenarier har rapporterats orsaka det här felet. Det första är åtgärden för CredSSP Encryption Oracle som infördes i maj 2018 års uppdatering (KB4103727 och relaterade). Det andra är KB5065426 på Windows 11 24H2 och 25H2, vilket gör att RDP-autentisering slutar fungera på datorer med dubbletter av SID från felaktigt syspreppade avbilder.

För CredSSP-felet (Ett autentiseringsfel har inträffat. Den begärda funktionen stöds inte) är den korrekta åtgärden att säkerställa att både klienten och måldatorn är fullt uppdaterade så att deras CredSSP-versioner är kompatibla. Endast som en tillfällig lösning, tillämpa följande på den anslutande datorn:

Tryck på Windows-tangenten + R, skriv gpedit.msc och tryck på Enter.
Navigera till Datorkonfiguration > Administrativa mallar > System > Delegering av autentiseringsuppgifter.
Öppna Encryption Oracle Remediation och ställ in den på Aktiverad.
Ställ in Skyddsnivå till Sårbar.
Kör gpupdate /force i en förhöjd Kommandotolk.

Detta är endast en tillfällig åtgärd. Den permanenta lösningen är att uppdatera målmaskinen så att båda sidor kör en kompatibel CredSSP-version.

För regressionsfelet med KB5065426 i Windows 11 24H2 och 25H2 försöker en communityrapporterad tillfällig lösning i registret inaktivera funktionsflaggan som introducerades av den uppdateringen:

På målmaskinen, öppna Registereditorn genom att trycka på Windows-tangenten + R och skriva regedit.exe.
Navigera till HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides.
Skapa ett nytt DWORD-värde (32-bitars) med namnet 718619.
Ställ in data till 0.
Starta om måldatorn.

Den permanenta lösningen för den här miljön är att köra sysprep /generalize /oobe /shutdown på basavbildningen innan någon driftsättning.

Observera: Denna registerlösning är framtagen av communityn och är inte officiellt dokumenterad av Microsoft. Kontrollera att den gäller för din specifika build innan du tillämpar den.

I domänmiljöer upplever vissa användare att det första RDP-försöket misslyckas men det andra lyckas, eller att kontot blir låst vid det andra försöket. Felaktiga inställningar för NTLM-autentisering (lmcompatibilitylevel) kan orsaka autentiseringsfel i domän- eller äldre miljöer där olika NTLM-principer tillämpas på olika datorer.

Lösningen är att anpassa lmcompatibilitylevel på båda datorerna:

På både domänkontrollanten och RDP-värden, tryck på Windows-tangenten + R och skriv regedit.exe.
Navigera till HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
Hitta eller skapa ett DWORD-värde med namnet lmcompatibilitylevel.
Ange värdet till 5, vilket tvingar igenom: Skicka endast NTLMv2-svar, neka LM och NTLM.
Starta om båda maskinerna.

Detta motsvarar sökvägen i Gruppolicy: Datorkonfiguration > Windows-inställningar > Säkerhetsinställningar > Lokala principer > Säkerhetsalternativ > Nätverkssäkerhet: LAN Manager-autentiseringsnivå. Att ställa in den till Skicka endast NTLMv2-svar. Neka LM och NTLM på båda datorerna eliminerar den missmatchning som utlöser de upprepade felen.

Händelsevisaren på måldatorn är det snabbaste sättet att exakt identifiera vilken rotorsak som gäller innan du ändrar några inställningar. Jag kör detta först på alla datorer där lösningen inte är omedelbart uppenbar.

På måldatorn, tryck på Windows-tangenten + R, skriv eventvwr.msc och tryck på Enter.
I den vänstra rutan, expandera Windows-loggar och välj Säkerhet.
I den högra Åtgärder-rutan, klicka på Filtrera aktuell logg.
Ange 4625 i fältet Händelse-ID och klicka på OK.
Klicka på den senaste posten med Händelse-ID 4625 och läs detaljerna i den nedre rutan.

Status- och understatuskod	Betydelse	Åtgärd att vidta
0xC000006A	Korrekt användarnamn, fel lösenord	Verifiera lösenordet, kontrollera Credential Manager
0xC0000064	Användarnamnet finns inte på målmaskinen	Verifiera det exakta kontonamnet bland de lokala användarna
0xC0000234	Kontot är låst	Lås upp i Active Directory eller lokal användarhantering
0xC0000072	Kontot är inaktiverat	Aktivera kontot i användarhanteringen
0xC000015B	Inloggningstyp inte beviljad	Åtgärd 1 ovan (lägg till rättigheten `Allow log on through Remote Desktop Services`)
0xC000006F	Kontot är begränsat av inloggningstider	Kontrollera kontots egenskaper
0xC0000070	Arbetsstationsbegränsning	Konto begränsat till specifika datorer

Om SubStatus visar 0x0, förlita dig i stället på Status-koden. Om Status eller SubStatus visar 0xC000015B men kontot redan finns i gruppen Remote Desktop Users, kontrollera om en domännivå-GPO åsidosätter den lokala rättigheten innan du tillämpar Fix 1.

Fältet Logon Type är också värt att kontrollera. Type 10 är fjärrinteraktiv, vilket är vad RDP använder. Logon Type 10 indikerar RDP (RemoteInteractive). Andra inloggningstyper kan tyda på andra autentiseringsvägar eller misslyckad sessionshantering, vilket pekar mot ett problem med nätverksrelä eller gatewaykonfiguration snarare än ett lokalt policyproblem.

I domänmiljöer, kör samma sökning efter Event ID 4625 i domänkontrollantens Security-logg samt på målmaskinen. Domänkontrollanten registrerar ofta autentiseringsavslaget innan målmaskinen loggar det över huvud taget, och de två posterna tillsammans visar exakt var autentiseringskedjan bröts.

Alla RDP-fel genererar inte en tydlig 4625-post på målmaskinen i domänmiljöer, särskilt när autentiseringen misslyckas tidigare på domänkontrollanten.

Om det inte fungerade återstår två specialfall efter åtgärderna ovan:

Målmaskinen är i ett fastnat sessionsläge för Remote Desktop Services. Efter ett oväntat strömavbrott eller en tvingad frånkoppling kan TermService hamna i ett tillstånd som avvisar ny autentisering. En fullständig omstart av målmaskinen rensar detta. Om du har en alternativ väg in i maskinen kan du starta om endast Remote Desktop Services via services.msc utan en fullständig omstart.
En Group Policy på domän- eller organisationsenhetsnivå tillämpar en Deny logon through Remote Desktop Services-rättighet för ditt konto, vilket åsidosätter alla Allow-rättigheter under den. Kör rsop.msc på målmaskinen och navigera till Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

Om ditt konto visas under både Allow log on through Remote Desktop Services och Deny log on through Remote Desktop Services, vinner Deny oavsett gruppmedlemskap. Du måste ta bort kontot från Deny-posten på den policynivå där den tillämpas, vilket kräver åtkomst till Group Policy Management Console.

6 grundorsaker utgör den överväldigande majoriteten av fall jag har sett och rapporteras ofta i Microsofts dokumentation, communityforum och vid felsökning i fält.

Felmeddelande	Grundorsak	Miljö
`The logon attempt failed.`	Saknad användarrättighet `Allow log on through Remote Desktop Services` Felaktigt format för användarnamn (lokalt kontra domän matchar inte)	Arbetsgrupp eller domän
`Your credentials did not work. The logon attempt failed.`	Inaktuella eller motstridiga inloggningsuppgifter i Hanteraren för inloggningsuppgifter	Alla miljöer
`Logon credentials invalid.`	Problem med Microsoft-kontots inloggningsuppgifter i vissa RDP-scenarier (ofta på grund av att lösenord/PIN inte stämmer överens eller hur uppgifterna hanteras)	Windows 11
`An authentication error has occurred. The function requested is not supported.`	Säkerhetsinkompatibilitet för CredSSP/NLA mellan klient och mål (ofta efter uppdateringar eller när ena sidan inte är fullt uppdaterad)	Efter uppdatering, alla miljöer
`An authentication error has occurred. The Local Security Authority cannot be contacted.`	NLA-fel när domänkontrollanten inte kan nås	Domännätverk
`Logon failure: user has not been granted the requested logon type at this computer.`	Kontot har uttryckligen nekats RDS-inloggningsrättigheten via Gruppolicy	Domän- eller lokal policy

Observera: I blandade miljöer orsakar ett felaktigt användarnamnsformat (till exempel ett lokalt användarnamn i stället för DOMAIN\username, eller tvärtom) ett omedelbart autentiseringsfel även när lösenordet är korrekt.

Felet kan också uppstå när du ansluter till en helt annan värd (till exempel när DNS pekar mot en annan maskin) eller när Fjärrskrivbord inte är korrekt aktiverat på målmaskinen.

De flesta av dessa orsaker kan spåras tillbaka till hur RDP staplar sina autentiseringslager innan en enda pixel av fjärrskrivbordet är synlig. Den utformningen är logisk för ett företagsnätverksprotokoll. Men för IT-tekniker som ger fjärrsupport på ändpunkter de inte har full kontroll över är dessa lager en oundviklig källa till sessionsfel. HelpWire är byggt för just det specifika användningsfallet. Du startar helt enkelt en session genom att skicka en länk, och slutanvändaren ansluter utan någon kontokonfiguration på sin sida. Dessutom gör obevakad åtkomst det möjligt att utföra uppföljningsarbete utan att tvinga dig tillbaka genom autentiseringskedjan.

Korrekt angivna inloggningsuppgifter åsidosätter inte en saknad policyrättighet. Rättigheten Allow log on through Remote Desktop Services i Lokal säkerhetspolicy är en separat kontroll skild från lokala administratörsbehörigheter. Om ditt konto inte finns med under den rättigheten på måldatorn nekar Windows anslutningen innan det bekräftar om lösenordet är giltigt. Jag har sett personer återställa sitt lösenord två gånger, lägga till sitt konto i den lokala gruppen Administratörer och ändå få samma fel, eftersom ingen av åtgärderna rör den policyinställningen.

Den andra tysta orsaken är Hanteraren för inloggningsuppgifter på den anslutande datorn. Windows lagrar RDP-inloggningsuppgifter kopplade till värdnamnet eller IP-adressen för målet. Om dessa sparade uppgifter är inaktuella eller tillhör ett annat konto kan Windows automatiskt använda de sparade uppgifterna för målet innan du blir tillfrågad, beroende på hur posten är sparad. Du ser felet, antar att lösenordet är felaktigt, ändrar det och kör in i samma vägg igen. I vissa fall åsidosätter sparade uppgifter i Hanteraren för inloggningsuppgifter manuell inmatning, särskilt efter lösenordsändringar.

Kontolåsning är en tredje orsak som ofta förbises i arbetsgruppsmiljöer. Om en annan enhet, en föråldrad sparad inloggningsuppgift i en webbläsare, eller en frånkopplad RDP-session cyklar igenom gamla uppgifter mot samma konto, låses kontot innan du ens öppnar Fjärrskrivbordsanslutning. Att kontrollera måldatorns lokala användarhantering under Datorhantering bekräftar detta på under 30 sekunder.

Att inaktivera Windows-brandväggen är det instinktiva första steget. Brandväggsregler styr om TCP 3389-anslutningen överhuvudtaget når målet. Om du kommer till dialogrutan för inloggningsuppgifter är brandväggsproblem vanligtvis inte orsaken.

Att lägga till kontot i den lokala gruppen Administratörer är den andra instinkten. Administratörsbehörigheter ger inte inloggningsrättigheten för Fjärrskrivbordstjänster. Det är separata kontroller. Du kan vara lokal administratör och ändå blockeras från RDP om den rättigheten saknas i policyn.

Att växla mellan användarnamnsformat utan att först läsa Händelsevisaren är rena gissningar. DOMAIN\user, user@domain.com och det rena användarnamnet kan alla representera samma konto. Utan Event ID 4625 framför dig har du ingen grund för att veta vad som faktiskt misslyckas.

Att köra Fjärrskrivbordsanslutningsklienten som administratör på den anslutande datorn har ingen effekt. Autentisering sker mot måldatorns säkerhetspolicy, inte klientens.

Verifiera också att Fjärrskrivbord är aktiverat på måldatorn och att Windows-utgåvan stöder RDP-värdanslutningar (Windows Home gör det inte).

NLA autentiserar sessionen innan fjärrskrivbordet läses in. När målmaskinen inte kan nå domänkontrollanten, eller när det finns en CredSSP-versionskonflikt mellan klient och målmaskin, kan NLA avbryta autentiseringsförsöket innan sessionen initieras. Detta visar sig ofta som meddelandet The logon attempt failed på klientsidan. Att tillfälligt inaktivera NLA på målmaskinen under Systemegenskaper > Fjärranvändning fliken bekräftar om NLA är orsaken.

Kör rsop.msc på måldatorn och navigera till Datorkonfiguration > Windows-inställningar > Säkerhetsinställningar > Lokala principer > Tilldelning av användarrättigheter. Om det berörda kontot visas under Neka inloggning via Fjärrskrivbordstjänster åsidosätter den posten alla Tillåt-rättigheter och måste tas bort på den Gruppolicy-nivå där den tillämpas, med hjälp av Gruppolicyhanteringskonsolen.

Från och med Windows-uppdateringen i april 2026 (KB5083769) lade Microsoft till obligatoriska varningar innan .rdp-filer ansluter, där användarna ombeds bekräfta vilka lokala resurser som ska delas. Detta är en säkerhetsfunktion för att förhindra spoofingattacker, men den kan upplevas som repetitiv om dialogrutan inte sparar inställningar. Att ställa in RedirectionWarningDialogVersion till 1 återställer dialogrutans beteende till hur det var före april 2026 som en tillfällig lösning, även om de underliggande säkerhetsförbättringarna förblir aktiva.

Proffstips: Skapa ett dedikerat lokalt administratörskonto för RDP-åtkomst på varje dator du fjärrhanterar innan du behöver det. Ge det ett starkt lösenord som lagras i en lösenordshanterare och tilldela det rätten Allow log on through Remote Desktop Services redan vid konfigurationen. När domänkontrollanten går ner, NLA slutar fungera efter en uppdatering eller huvudkontot hamnar i en policikonflikt, är det lokala kontot den enda vägen in i datorn som kringgår hela autentiseringskedjan som beskrivs i den här artikeln.

Om du hanterar .rdp-filer åt användare, överväg att signera dem med PowerShell efter uppdateringen i april 2026 för att undvika upprepade förtroendevarningar. Osignerade .rdp-filer utlöser den nya spoofingvarningen vid varje körning i Windows 11 med KB5083769 eller senare.

Om felet logon attempt failed blockerar din enda väg in i datorn och du varken har konsolåtkomst, något alternativt lokalt konto eller någon på plats som kan ändra inställningar, når standardfelsökning för RDP en återvändsgränd. Du kan inte öppna secpol.msc, rensa Credential Manager eller inaktivera NLA på en dator du inte kan logga in på.

I det här scenariot ger HelpWire en praktisk utväg. Slutanvändaren öppnar en sessionslänk utan krav på kontokonfiguration, NLA-handshake eller domänåtkomst på deras sida. När sessionen är igång kan du tillämpa någon av åtgärderna i den här artikeln inifrån datorn och återställa RDP för framtida användning.

Åtgärda Logon Attempt Failed RDP-felet i Windows

Vad betyder ”RDP Logon Attempt Failed”?

Hur åtgärdar du felet ”Remote Desktop Logon Attempt Failed”?

Åtgärd 1: Bevilja inloggningsrättigheten för Fjärrskrivbordstjänster

Åtgärd 2: Rensa inaktuella autentiseringsuppgifter i Hanteraren för inloggningsuppgifter

Åtgärd 3: Diagnostisera och inaktivera nätverksnivåautentisering

Lösning 4: Åtgärda RDP-felet ”The Logon Attempt Failed” med ett Microsoft-konto

Lösning 5: Åtgärda RDP ”Logon Attempt Failed” efter en Windows-uppdatering

Åtgärd 6: Åtgärda misslyckat RDP-inloggningsförsök vid andra försöket i domänmiljöer

Använda Händelsevisaren för att diagnostisera RDP-autentiseringsfel

Orsaker till RDP-felet Logon Attempt Failed

Varför säger RDP ”Remote Desktop Connection Logon Attempt Failed” även med rätt lösenord?

Vad de flesta försöker först efter ”Remote Desktop Login Failed” (och varför det inte fungerar)

Vanliga frågor