Åtgärda att Fjärrskrivbordets inloggningsuppgifter inte fungerar

Felet Your credentials did not work i Fjärrskrivbord betyder inte att ditt lösenord är fel. I många fall skickar den anslutande datorn föråldrade cachade autentiseringsuppgifter som har legat kvar efter en lösenordsändring. I vissa konfigurationer är måldatorn i ett Windows Hello PIN-baserat inloggningsläge som kan blockera RDP-inloggning med Microsoft-konto. Detta är de vanligaste orsakerna, men fel med autentiseringsuppgifter kan ha mer än ett dussin olika grundorsaker på båda datorerna.

Den här guiden täcker de mest tillförlitliga åtgärderna som rapporterats i Microsofts dokumentation och Q&A, liksom i återkommande felsökningstrådar i communityn.

Innehållsförteckning

Identifiera den mest sannolika orsaken i tabellen nedan och gå direkt till den åtgärden i stället för att testa varje enskilt alternativ.

Orsak	Sida	Åtgärdsavsnitt
Cachelagrade eller inaktuella inloggningsuppgifter	Klient	Åtgärd 1
Windows Hello PIN-relaterat problem med Microsoft-kontoinloggning	Måldator	Åtgärd 2
Felaktigt format på användarnamn	Klient	Åtgärd 3
Användare inte i gruppen Remote Desktop Users	Måldator	Åtgärd 4
Delegering av autentiseringsuppgifter blockerad av GPO	Klient	Åtgärd 5
Mismatch i RDP-säkerhetslagret	Måldator	Åtgärd 6
`Always prompt for password` är aktiverat	Måldator	Åtgärd 7
Nätverksprofil inställd på `Public`	Måldator	Åtgärd 8
Mismatch i LAN Manager Authentication Level	Måldator	Åtgärd 9
`fDenyTSConnections` satt till `1`	Måldator	Åtgärd 10
Begränsning för tomt lösenord	Måldator	Åtgärd 11
RDP-lyssnare inte aktiv	Måldator	Åtgärd 12
Utgånget RDP-certifikat	Måldator	Specialfall
Annan RDP-port än standard	Måldator	Specialfall

Detta är den mest bekräftade lösningen när inloggningsuppgifterna för Fjärrskrivbordet inte fungerade på datorer som använder Microsoft-konton med Windows Hello-PIN aktiverad. Enligt användarrapporter har lokal inloggning med kontolösenordet återställt RDP-åtkomsten efter att endast PIN-kod hade använts på målenheten.

OBS: Windows Hello för företag är en separat företagsfunktion som stöder RDP-inloggning genom certifikatbaserad distribution via Microsoft Intune eller Active Directory Certificate Services. Det kräver PKI-infrastruktur, certifikatdistribution och certifikat för domänkontrollanter. Det är inte tillgängligt i vanliga konsument- eller SMB-miljöer och är inte relaterat till det konsument-PIN-scenario som beskrivs här.

På måldatorn, logga ut från den aktuella sessionen.
På inloggningsskärmen klickar du på Inloggningsalternativ.
Välj lösenordsalternativet (nyckelikonen).
Logga in med det fullständiga lösenordet för ditt Microsoft-konto.
Försök att ansluta via RDP igen från den anslutande datorn.

På inloggningsskärmen klickar du på Inloggningsalternativ och klickar sedan på Jag har glömt min PIN-kod.
Autentisera med inloggningsuppgifterna för ditt Microsoft-konto, inklusive eventuellt tvåfaktorsgodkännande.
När du ombeds att återställa din PIN-kod, bekräfta återställningen. Du kan ange samma PIN-kod igen.
Försök ansluta via RDP igen efter att det lösenordsbaserade inloggningsflödet har slutförts.

Flera användare bekräftade att inaktivera denna enda omkopplare löste problemet utan att behöva logga ut och in igen.

På måldatorn, gå till Inställningar > Konton > Inloggningsalternativ.
Hitta För ökad säkerhet, tillåt endast inloggning med Windows Hello för Microsoft-konton på den här enheten.
Stäng av den.
Logga ut och logga in igen med Microsoft-kontots lösenord.

Hanteraren för inloggningsuppgifter i Windows på den anslutande datorn mellanlagrar TERMSRV/-poster. Efter en lösenordsändring skickar den tyst det gamla lösenordet vid varje anslutningsförsök utan att fråga.

På den anslutande datorn öppna Hanteraren för autentiseringsuppgifter. Sök efter den i Start, eller kör control /name Microsoft.CredentialManager.
Klicka på Windows-inloggningsuppgifter.
Hitta varje post som börjar med TERMSRV/ följt av fjärrdatorns namn eller IP-adress.
Klicka på varje post och klicka sedan på Ta bort.
Återanslut. Windows kommer att be om nya inloggningsuppgifter.

Öppna Anslutning till Fjärrskrivbord (mstsc.exe).
Ange fjärrdatorns namn eller IP-adress.
Klicka på Visa alternativ.
I Inloggningsinställningar, klicka på länken redigera bredvid det sparade användarnamnet.
Ange det nuvarande lösenordet och spara.

Vissa konfigurationer behåller inte RDP-inloggningsuppgifter mellan sessioner. Genom att lägga till en allmän autentiseringsuppgift direkt i Hanteraren för autentiseringsuppgifter tvingar du Windows att använda den.

Öppna Hantering av inloggningsuppgifter > Windows-inloggningsuppgifter.
Klicka på Lägg till en generisk autentiseringsuppgift.
I Internet- eller nätverksadressen anger du TERMSRV/ följt av fjärrdatorns värdnamn eller IP-adress. Till exempel: TERMSRV/103.27.76.117 eller TERMSRV/COMPUTERNAME.
Ange användarnamn och lösenord.
Klicka på OK, stäng Hanteraren för inloggningsuppgifter och återanslut.

Formatet på det användarnamn du skriver in avgör vilken autentiseringsleverantör Windows riktar sig mot. Om du använder fel format skickas begäran till fel identitetskälla och misslyckas även med korrekt lösenord.

Microsoft dokumenterar att du för en fjärransluten enhet som är ansluten till Microsoft Entra kan logga in antingen med user@domain.com eller AzureAD\user@domain.com, beroende på vilken inloggningsmetod som används. Om ett format inte fungerar, prova det andra.

Kontotyp	Korrekt format	Kommentarer
Lokalt konto	`COMPUTERNAME\username</code`	Exempel: `DESKTOP-AB12\john`
Domänkonto (NetBIOS)	`DOMAIN\username`	Exempel: `CORP\johndoe`
Domänkonto (UPN)	`username@domain.com`	Exempel: `johndoe@corp.local`
Microsoft-konto	Fullständig e-postadress	Exempel: `john@outlook.com`
Microsoft Entra-ansluten	`AzureAD\user@domain.com` eller `user@domain.com`	Microsoft dokumenterar båda formaten för olika inloggningsmetoder. Prova det andra om det första misslyckas.

Ett konto måste tillhöra antingen gruppen Fjärrskrivbordsanvändare eller gruppen Administratörer på måldatorn. Event ID 4625 med understatus 0xC000015B bekräftar att användaren inte har beviljats den krävda inloggningstypen. Gruppmedlemskap i sig kan ändå blockeras av ett uttryckligt Neka i Tilldelning av användarrättigheter.

På målmaskinen, kör det här kommandot som administratör:
net localgroup "Remote Desktop Users" /add "DOMAIN\username" eller i PowerShell:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"
Öppna Kör och skriv secpol.msc.
Navigera till Lokala principer > Tilldelning av användarrättigheter.
Dubbelklicka på Tillåt inloggning via Fjärrskrivbordstjänster.
Klicka på Lägg till användare eller grupp.
Skriv kontonamnet och klicka på OK.
Kontrollera samma lista efter eventuella poster för Neka inloggning via Fjärrskrivbordstjänster som innehåller användaren eller deras grupp. Ta bort alla uttryckliga nekandeposter.

När principer för delegering av autentiseringsuppgifter på den anslutande datorn begränsar hur autentiseringsuppgifter vidarebefordras kan RDP-klienten inte autentisera sig ens med ett korrekt lösenord. Detta gäller alla kontotyper och är en av de mest förbisedda orsakerna till att autentiseringsuppgifter inte fungerar för Fjärrskrivbord. Åtgärden körs på klientdatorn, inte på fjärrdatorn.

På den anslutande datorn öppna Kör och skriv gpedit.msc.
Navigera till Datorkonfiguration > Administrativa mallar > System > Delegering av autentiseringsuppgifter.
Ställ in Neka delegering av sparade autentiseringsuppgifter till Inte konfigurerad.
Ange Neka delegering av nya autentiseringsuppgifter till Inte konfigurerad.
Öppna Tillåt delegering av sparade autentiseringsuppgifter med endast NTLM-serverautentisering. Ställ in den på Aktiverad.
Klicka på Visa bredvid Lägg till servrar i listan och ange TERMSRV/*. Klicka på OK.
Upprepa steg 5 för: Tillåt delegering av sparade autentiseringsuppgifter, Tillåt delegering av nya autentiseringsuppgifter med endast NTLM-serverautentisering och Tillåt delegering av nya autentiseringsuppgifter.
Navigera till Datorkonfiguration > Administrativa mallar > Windows-komponenter > Fjärrskrivbordstjänster > Klient för fjärrskrivbordsanslutning.
Ställ in Tillåt inte att lösenord sparas till Inte konfigurerad.
Ställ in Begär autentiseringsuppgifter på klientdatorn till Inte konfigurerad.
Stäng Gruppolicyredigeraren och kör gpupdate /force i en kommandotolk med administratörsbehörighet.

Flera användare bekräftade den här korrigeringen efter att alla andra lösningar hade misslyckats. När det förhandlade säkerhetslagret mellan klient och mål inte kan enas, nekas autentisering innan inloggningsuppgifterna har utvärderats fullt ut.

På måldatorn, öppna Kör och skriv gpedit.msc.
Navigera till Datorkonfiguration > Administrativa mallar > Windows-komponenter > Fjärrskrivbordstjänster > Värd för fjärrskrivbordssession > Säkerhet.
Öppna Kräv användning av ett specifikt säkerhetslager för fjärranslutningar (RDP).
Ställ in den på Enabled. I rullgardinsmenyn, välj RDP som Säkerhetslager.
Klicka på OK, kör sedan gpupdate /force i en kommandotolk med administratörsbehörighet.

När den här policyn är aktiverad på fjärrdatorn åsidosätter den sparade autentiseringsuppgifter på klienten och tvingar fram en uppmaning att autentisera sig på nytt. Den uppmaningen misslyckas tyst och ger ett autentiseringsfel i stället för en synlig lösenordsdialog.

På måldatorn, öppna Kör och skriv gpedit.msc.
Navigera till Datorkonfiguration > Administrativa mallar > Windows-komponenter > Fjärrskrivbordstjänster > Värd för fjärrskrivbordssession > Säkerhet.
Öppna Fråga alltid efter lösenord vid anslutning.
Ställ in det på Inaktiverad eller Inte konfigurerad.
Logga ut och in igen, eller kör gpupdate /force.

När måldatorns nätverksprofil är inställd på Public blockerar Windows inkommande RDP-anslutningar. Microsofts felsökningsvägledning för RDP behandlar nätverksprofil och brandväggskonfiguration som giltiga orsaker till anslutningsfel. Detta är en vanlig upptäckt när allt annat i konfigurationen ser korrekt ut.

På måldatorn, öppna Inställningar > Nätverk och Internet > Status.
Klicka på Ändra anslutningsegenskaper.
Ställ in Nätverksprofil till Privat.

En avvikelse i autentiseringsnivå mellan den anslutande datorn och fjärrdatorn leder till att autentiseringsuppgifterna avvisas på NTLM-förhandlingslagret, oavsett om lösenordet är korrekt eller inte.

På måldatorn, öppna Kör och skriv gpedit.msc.
Navigera till Datorkonfiguration > Windows-inställningar > Säkerhetsinställningar > Lokala principer > Säkerhetsalternativ.
Öppna Nätverkssäkerhet: LAN Manager-autentiseringsnivå.
Ställ in det på något av dessa tre bekräftat fungerande värden: Skicka endast NTLMv2-svar, Skicka endast NTLMv2-svar. Vägra LM, eller Skicka endast NTLMv2-svar. Vägra LM och NTLM. Vilket som helst av de tre åtgärdar omatchningen. Det mest tillåtande alternativet att prova först är Skicka endast NTLMv2-svar.
Klicka på OK.

När RDP visas som aktiverat i Inställningar men anslutningar ändå misslyckas kan två registervärden åsidosätta inställningen i användargränssnittet. Microsoft dokumenterar fDenyTSConnections som den inställning som styr om användare kan ansluta på distans med Remote Desktop Services.

Öppna Registereditorn som administratör (regedit.exe).
Navigera till: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Bekräfta att fDenyTSConnections är inställt på 0.
Kontrollera även:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. Om fDenyTSConnections förekommer här och är inställt på 1, verkställer en Gruppolicy blockeringen. Att ändra det lokala värdet kommer inte att bestå. GPO:t måste korrigeras vid källan.
För att verifiera att RDP-porten inte har ändrats från standardvärdet, navigera till: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
Hitta PortNumber. Växla visningsbasen till Decimal.
Värdet bör vara 3389. Om det inte är det måste din RDP-klient i stället ansluta till den anpassade porten, med formatet hostname:PORT.

Efter varje registerändring, starta om Fjärrskrivbordstjänster: öppna services.msc, hitta Fjärrskrivbordstjänster, högerklicka och välj Starta om.

Windows blockerar RDP som standard för konton utan lösenord. Detta är en begränsning i den lokala säkerhetspolicyn, inte en RDP-inställning.

Öppna Kör och skriv gpedit.msc.
Navigera till Datorkonfiguration > Windows-inställningar > Säkerhetsinställningar > Lokala principer > Säkerhetsalternativ.
Öppna Konton: Begränsa lokala kontons användning av tomma lösenord till endast konsolinloggning.
Ställ in det på Inaktiverat.

Innan du utgår från att problemet är relaterat till inloggningsuppgifter, bekräfta att RDP-protokollet faktiskt lyssnar efter anslutningar på måldatorn. Om RDP-lyssnaren inte är aktiv avvisar servern anslutningar på protokollnivå innan inloggningsuppgifter för Fjärrskrivbord utvärderas. Detta ger upphov till fel som ser ut som autentiseringsfel.

Kör det här kommandot med administratörsbehörighet på måldatorn, via PowerShell Remoting eller fysisk konsolåtkomst:

qwinsta

Leta efter en post med namnet rdp-tcp med STATE inställt på Listen. Om den saknas eller visar ett annat tillstånd har RDP-tjänsten ett protokollfel. Kontrollera registernycklarna i Fix 10 ovan och RDP-certifikatet i avsnittet om specialfall nedan, starta sedan om Fjärrskrivbordstjänster.

PROFFSTIPS: På varje dator som du fjärrhanterar, ha ett dedikerat lokalt administratörskonto som inte använder inloggning med ett Microsoft-konto. När problem med MSA, PIN-kod eller certifikat blockerar RDP kringgår ett lokalt konto helt MSA:s autentiseringsflöde och ger dig en fungerande väg in.

För IT-supportteam som arbetar på distans över flera datorer är HelpWire värt att ha tillsammans med RDP. Sessioner startar med en länk i stället för att kräva att fjärranvändaren ändrar några systeminställningar. Detta innebär att RDP-autentiseringsfel på fjärrdatorn inte hindrar en supportsession från att starta. Förvara inloggningsuppgifter för lokala administratörer i en lösenordshanterare, inte cachelagrade i Hanteraren för inloggningsuppgifter på din egen dator.

Öppna Händelsevisaren på måldatorn och kontrollera Windows-loggar > System efter Händelse-ID 1057 eller 1058 från Microsoft-Windows-TerminalServices-RemoteConnectionManager. Dessa händelser indikerar att det självsignerade certifikatet har misslyckats med att förnyas.

Öppna mmc.exe > Arkiv > Lägg till/ta bort snapin-modul > Certifikat > Datorkonto.
Navigera till Certificates > Remote Desktop.
Ta bort det utgångna självsignerade certifikatet.
Starta om Remote Desktop Services i services.msc. Windows återskapar certifikatet automatiskt.

Navigera till C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
Ta äganderätten till den RDP-relaterade nyckelfilen.
Ta bort filen.
Starta om Fjärrskrivbordstjänster.

När du ansluter via värdnamn, kontrollera att DNS pekar på rätt maskin, särskilt efter en ominstallation av maskinen eller en ändring av IP-adressen.

På måldatorn, kör IPCONFIG /All i en kommandotolk som administratör och notera den aktuella IP-adressen.
På den anslutande datorn, kör nslookup MACHINENAME och bekräfta att den returnerade IP-adressen matchar.
Kör även Test-NetConnection -ComputerName SERVER-IP -Port 3389 i PowerShell. Om TcpTestSucceeded returnerar False är problemet nätverk eller brandvägg, inte inloggningsuppgifter.
Om DNS-posten är inaktuell, anslut direkt via IP-adress eller uppdatera DNS-posten.

Upprepade misslyckade RDP-försök utlöser kontolåsningsprincipen på domänanslutna datorer. Kontrollera Händelsevisaren på domänkontrollanten efter Händelse-ID 4625 med Understatus 0xC0000234. För ett lokalt konto på måldatorn, kör:

net user USERNAME

Leta efter Account active: No i utdata. För att återaktivera:

net user USERNAME /active:yes

Microsoft dokumenterar att du på en fjärransluten Microsoft Entra-ansluten enhet kan logga in med user@domain.com eller AzureAD\user@domain.com, beroende på inloggningsmetod. Om ett format inte fungerar, prova det andra. I båda fallen, bekräfta att användaren har lagts till i gruppen Remote Desktop Users på måldatorn. Kontrollera dessutom enheten i Entra administrationscenter under Enheter > den specifika enheten > Lokala administratörer.

Händelse-ID 4625 i Windows säkerhetsloggar registrerar varje misslyckat inloggningsförsök. Fältet Sub Status anger den exakta orsaken till autentiseringsfelet, vilket helt eliminerar gissningar vid felsökningen.

Understatuskod	Felorsak	Åtgärd att vidta
`0xC000006A`	Korrekt användarnamn, fel lösenord	Rensa Hanteraren för inloggningsuppgifter, verifiera aktuellt lösenord
`0xC0000234`	Kontot är låst	Lås upp via ett administratörskonto eller vänta enligt låsningsprincipen
`0xC0000072`	Kontot är inaktiverat	Aktivera kontot i Datorhantering
`0xC0000071`	Lösenordet har gått ut	Ändra lösenordet för målkontot
`0xC000015B`	Användaren saknar rätt att logga in via Fjärrskrivbord	Lägg till i gruppen Användare av fjärrskrivbord och kontrollera Tilldelning av användarrättigheter

För att komma åt dessa loggar: öppna Händelsevisaren > Windows-loggar > Säkerhet > filtrera efter Händelse-ID 4625. I händelsedetaljerna, expandera Information om misslyckande och läs det hexadecimala värdet för Understatus.

Det första de flesta skulle göra när autentiseringsuppgifter för Windows Fjärrskrivbord inte fungerar är att återställa lösenordet för sitt Microsoft-konto. Det hjälper inte för de ovan beskrivna scenarierna med PIN-kod och cachade autentiseringsuppgifter. Problemet är ofta inte själva kontolösenordet utan cachade autentiseringsuppgifter eller ett autentiseringstillstånd som inte stämmer överens mellan enheter. Att återställa lösenordet löser inte problemet eftersom klienten fortsätter att skicka den äldre cachade autentiseringsuppgiften tills den sparade TERMSRV/-posten rensas eller ersätts.

Det andra vanliga försöket är att växla NLA av och på. För problemet med Windows Hello-PIN-kod och inaktuella cachade autentiseringsuppgifter är NLA-statusen inte den avgörande variabeln. PIN-problemet uppstår eftersom standardautentisering med Windows Hello-PIN-kod är bunden till enheten och inte vidarebefordras via standardflödena för RDP-autentisering. Att inaktivera NLA försvagar dessutom anslutningens säkerhet utan att åtgärda grundorsaken.

En tredje metod som cirkulerar i vissa forumtrådar innebär att ta bort registernyckeln WinStations. Detta kan dock göra datorn obrukbar och kräva en fullständig ominstallation av operativsystemet.

När det är RDP-konfigurationen i sig som är problemet, snarare än ett formateringsproblem med autentiseringsuppgifterna, är det värt att ha ett verktyg som är byggt för supportarbete i verktygslådan. Till exempel startar HelpWire sessioner genom att skicka en länk till fjärranvändaren, som kör en lättviktsklient. Därefter ansluter du utan att behöva autentisera mot fjärrdatorns lokala konton överhuvudtaget. När du behöver komma in i en dator vars RDP-autentiseringsstack är trasig eliminerar det beroendet av att RDP är korrekt konfigurerat.

När du ser att inloggningsuppgifterna för Remote Desktop inte fungerar, är den vanligaste orsaken ett inaktuellt lösenord som är cachelagrat i Windows Credential Manager på den anslutande datorn, vilket skickas automatiskt efter ett lösenordsbyte utan uppmaning. En annan vanlig orsak är att måldatorn senast autentiserades lokalt med en Windows Hello PIN, vilket i vissa konfigurationer kan blockera RDP-inloggning med Microsoft-konto.

En vanlig Windows Hello-PIN är enhetsbunden och vidarebefordras inte via standard-RDP-autentiseringsflöden. RDP kräver en lösenordsbaserad inloggningsuppgift i standardkonfigurationer för konsumenter och SMB.

Windows Hello for Business är en separat företagsfunktion som stöder RDP via certifikatbaserad autentisering, men den kräver PKI-infrastruktur, certifikatdistribution via Intune eller AD CS samt domänkontrollercertifikat. Den är inte tillgänglig i standardinstallationer för konsumenter eller SMB.

Öppna Hantering av autentiseringsuppgifter från Start-menyn, klicka på Windows-autentiseringsuppgifter och ta bort varje post som börjar med TERMSRV/ och som motsvarar fjärrdatorn. Om autentiseringsuppgifterna inte kvarstår mellan sessioner, använd Lägg till en generisk autentiseringsuppgift i Hantering av autentiseringsuppgifter och ange manuellt TERMSRV/[hostname] address tillsammans med användarnamnet och lösenordet.

Ja. Delegering av autentiseringsuppgifter-inställningarna under Datorkonfiguration > Administrativa mallar > System i Grupppolicy på den anslutande datorn styr om autentiseringsuppgifter vidarebefordras överhuvudtaget. Neka delegering av sparade autentiseringsuppgifter eller Neka delegering av nya autentiseringsuppgifter inställda på Aktiverad blockerar autentisering i tysthet. Att ställa in båda på Inte konfigurerad och aktivera TERMSRV/* under Tillåt delegering av sparade autentiseringsuppgifter med endast NTLM-serverautentisering löser detta.

Rensa poster i Hanteraren för inloggningsuppgifter på den anslutande datorn och försök igen. Om anslutningen fortfarande misslyckas, kör Test-NetConnection -ComputerName SERVER-IP -Port 3389 i PowerShell. Om TcpTestSucceeded returnerar True men inloggningsuppgifterna fortfarande misslyckas ligger problemet på måldatorn. Om den returnerar False är problemet nätverket eller brandväggen. Väl på måldatorn, läs Händelse-ID 4625 i Säkerhetsloggen för att identifiera den exakta felorsaken.

Så här åtgärdar du att fjärrskrivbordets inloggningsuppgifter inte fungerar

12 sätt att åtgärda inloggningsuppgifter för Fjärrskrivbord som inte fungerar

Åtgärd 1: Logga in en gång med ditt lösenord på måldatorn (problem med Windows Hello-PIN)

Metod A: Logga ut och logga in igen med lösenord

Metod B: Om lösenordsalternativet saknas eller är gråmarkerat

Metod C: Inaktivera omkopplaren för inloggning enbart med Windows Hello (fristående åtgärd)

Åtgärd 2: Rensa inaktuella inloggningsuppgifter från Hanteraren för inloggningsuppgifter på den anslutande datorn

Metod A: Ta bort poster via Hanteraren för inloggningsuppgifter

Metod B: Uppdatera lösenordet direkt i RDP-klienten

Metod C: Lägg till en manuell generisk autentiseringsuppgift när sparade autentiseringsuppgifter inte kvarstår

Åtgärd 3: Använd korrekt användarnamnsformat

Lösning 4: Lägg till användaren i gruppen Remote Desktop Users och verifiera inloggningsrättigheter

Åtgärd 5: Åtgärda gruppolicyn för delegering av autentiseringsuppgifter på den anslutande datorn

Åtgärd 6: Ändra RDP-säkerhetslagret via Gruppolicy på måldatorn

Åtgärd 7: Inaktivera ”Alltid fråga efter lösenord” på måldatorn

Åtgärd 8: Ändra nätverksprofilen från Offentlig till Privat på måldatorn

Lösning 9: Ställ in LAN Manager-autentiseringsnivån på måldatorn

Åtgärd 10: Kontrollera registernyckeln fDenyTSConnections och RDP-porten

Åtgärd 11: Åtgärda ett tomt lösenord på målkontot

Åtgärd 12: Kontrollera RDP-lyssnarens status

Korrigeringar för specialfall där inloggningsuppgifter inte fungerar för Fjärrskrivbord

Fel med självsignerat RDP-certifikat (Händelse-ID 1057 eller 1058)

Verifiera DNS och målinriktning för datorer

Kontolåsning

Azure AD / Entra ID-anslutna datorer

Hur man läser Händelsevisaren för RDP-inloggningsfel

Vanliga misstag som gjordes när inloggningsuppgifterna för Windows Fjärrskrivbord inte fungerade

Vanliga frågor