När Windows visar att anslutningen nekades eftersom användarkontot inte är auktoriserat för fjärrinloggning, är lösenordet inte problemet. Det accepterades; sessionen avvisades ett steg senare, vid auktorisering.
Två kontroller avgör det utfallet: kontot måste tillhöra den lokala Remote Desktop Users-gruppen eller Administrators-gruppen, och det måste finnas med i principen Allow log on through Remote Desktop Services i secpol.msc. Missas någon av dem får du det här felet.
En inställning trumfar båda: Deny log on through Remote Desktop Services. Om kontot, eller någon grupp det tillhör, finns på den listan, blockeras det oavsett vad annat är konfigurerat.
På domänanslutna datorer finns ett fjärde lager. Gruppolicy från domän- eller OU-nivå kan i tysthet återställa lokala inställningar vid nästa uppdatering och upphäva en åtgärd som verkade klar för bara några minuter sedan.
Börja med gruppmedlemskapet, det är den vanligaste orsaken.
Väg för snabbåtgärd
Om du vill börja direkt utan att läsa hela förklaringen, gå igenom dessa i ordning och avsluta när felet försvinner.
-
Lägg till kontot i den lokala gruppen Remote Desktop Users på måldatorn.
-
Öppna secpol.msc och bekräfta att kontots grupp visas under Tillåt inloggning via Fjärrskrivbordstjänster.
-
På samma plats, kontrollera Neka inloggning via Fjärrskrivbordstjänster och bekräfta att kontot inte finns med där.
-
Om datorn är domänansluten, kontrollera domänens GPO i GPMC, inte bara den lokala policyn i secpol.msc.
-
Rensa inaktuella sparade autentiseringsuppgifter från Hanteraren för autentiseringsuppgifter endast efter att du har bekräftat att policyinställningarna ovan är korrekta.
Vad riktiga användare rapporterar om det här felet
Det vanligaste klagomålet på forum: allt ser korrekt ut, och felet kvarstår ändå. En domänadministratör på Microsoft Q&A beskrev en Windows 11-arbetsstation som nekade alla RDP-anslutningar från icke-administratörer trots korrekt gruppmedlemskap och en lokal secpol.msc som såg korrekt ut. Den verkliga stoppklossen var ett GPO på domännivå som tyst åsidosatte de lokala inställningarna. (Microsoft Q&A, september 2024)
På Azure-VM:ar uppträder ett relaterat problem som en loop: ett konto läggs till manuellt, sessioner fungerar, sedan försvinner kontot efter en omstart och felet återkommer. Orsaken var ett GPO för Restricted Groups som tog bort medlemskap vid varje policyuppdatering, och ingen ändring via gränssnittet består förrän själva GPO:t uppdateras. (Microsoft Tech Community, juni 2023)
Sparade inloggningsuppgifter är en mindre uppenbar utlösare. En RDS-pool som hade fungerat i åratal började plötsligt neka alla användare med detta fel. Behörigheterna hade inte ändrats. Att ta bort det sparade lösenordet och ange det på nytt manuellt löste det omedelbart, bekräftat av flera användare i samma tråd. (Microsoft Q&A, oktober 2022)
På domänanslutna Azure-VM:ar lade en administratör som hanterar 1 000 användare till konton i principen Allow log on through Remote Desktop Services, körde gpupdate /force och fick ändå felet. Det som saknades var att lägga till användarna i den lokala gruppen Remote Desktop Users på själva VM:en. Båda kontrollerna krävs. (Microsoft Q&A, november 2022)
I Intune-hanterade miljöer visar inte lusrmgr.msc Azure-domänen som en tillgänglig plats, så den vanliga korrigeringen via gruppmedlemskap gäller inte. En lyckad Intune-konfigurationsprincip räcker inte i sig. En separat princip som riktar in sig på rättigheten Allow log on through Remote Desktop Services krävs för Entra-anslutna enheter. (Microsoft Q&A, december 2024)
Så här åtgärdar du att anslutningen nekades eftersom användarkontot inte har behörighet för fjärrinloggning
Åtgärd 1: Lägg till användaren i gruppen Fjärrskrivbordsanvändare
Avsaknad av gruppmedlemskap är den vanligaste orsaken till det här felet på fristående datorer. Kör dessa steg på den fjärranslutna datorn, inte på den dator du ansluter från. Observera att lusrmgr.msc inte är tillgängligt i Windows Home-utgåvor, och Home-utgåvor kan dessutom inte fungera som RDP-värdar.
-
Tryck på Win + R, skriv lusrmgr.msc och tryck på Enter.
-
Välj Grupper i den vänstra rutan och dubbelklicka sedan på Fjärrskrivbordsanvändare.
-
Klicka på Lägg till.
-
Ange användarnamnet, klicka på Kontrollera namn för att bekräfta att det hittas, klicka sedan på OK.
-
Klicka på OK för att stänga fönstret för gruppens egenskaper.
För ett snabbare alternativ via Systemegenskaper: tryck Win + R, skriv sysdm.cpl, välj fliken Fjärr, klicka på Välj användare och lägg till kontot där.
Från en förhöjd PowerShell-prompt på fjärrdatorn:
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “username”
Ersätt username med det faktiska kontonamnet. En omstart krävs inte.
Åtgärd 2: Kontrollera policyn Tillåt inloggning via Fjärrskrivbordstjänster
Gruppmedlemskap och policyn för användarrättigheter kontrolleras oberoende av varandra. Båda måste klara kontrollen, och att åtgärda den ena utan den andra lämnar felet kvar. Kör dessa steg på fjärrdatorn.
-
Tryck på Win + R, skriv secpol.msc och tryck på Enter.
-
Navigera till Säkerhetsinställningar > Lokala principer > Tilldelning av användarrättigheter.
-
Dubbelklicka på Tillåt inloggning via Fjärrskrivbordstjänster.
-
Kontrollera att både Användare av Fjärrskrivbord och Administratörer finns med i listan. Om någon av dem saknas, klicka på Lägg till användare eller grupp, skriv gruppnamnet och klicka på OK.
-
Klicka på OK och kör sedan följande från en kommandotolk med administratörsbehörighet: gpupdate /force
På en domänansluten dator kan en konflikterande domän-GPO skriva över den här inställningen inom några minuter efter att den har sparats. Om inställningen återställs, gå till Åtgärd 4.
Åtgärd 3: Kontrollera om en policy med Neka åsidosätter inställningen Tillåt
Policyn Neka inloggning via Fjärrskrivbordstjänster blockerar åtkomst oavsett gruppmedlemskap eller Tillåt-policyn. Kontrollera detta även om Tillåt-inställningarna verkar vara kompletta.
-
I secpol.msc, navigera till Säkerhetsinställningar > Lokala principer > Tilldelning av användarrättigheter.
-
Dubbelklicka på Neka inloggning via Fjärrskrivbordstjänster.
-
Granska listan. Om det konto som ansluter, eller någon grupp som det tillhör, inklusive Gäster eller Domängäster, visas här, markera det och klicka på Ta bort.
-
Klicka på OK och kör sedan gpupdate /force.
Om inställningen fortsätter att återställas efter att du sparat den och kört gpupdate /force, styr en domän-GPOOm inställningen fortsätter att återställas efter att du sparat den och kört gpupdate /force, styr en domän-GPO på domännivå. Hantera denna princip endast via Lokal säkerhetspolicy eller Gruppolicyhantering. Undvik att försöka redigera tilldelning av användarrättigheter direkt i registret, eftersom rättigheterna för att tillåta och neka inloggning hanteras av Windows som namngivna privilegiekonstanter (SeRemoteInteractiveLogonRight och SeDenyRemoteInteractiveLogonRight), inte som enkla registervärden. För granskning, använd secpol.msc, gpresult eller secedit.
Lösning 4: Hantera domänens GPO direkt
På en domänansluten dator där lokala ändringar fortsätter att återställas skriver en domän-GPO över dem. Den här åtgärden kräver åtkomst till Group Policy Management Console, som vanligtvis finns tillgänglig på en domänkontrollant eller en dator med RSAT installerat.
-
Öppna GPMC via Serverhanteraren > Verktyg > Gruppolicyhantering.
-
Expandera domänen, högerklicka på den GPO som styr den berörda datorn och välj Redigera.
-
Navigera till Datorkonfiguration > Principer > Windows-inställningar > Säkerhetsinställningar > Lokala principer > Tilldelning av användarrättigheter.
-
Öppna Tillåt inloggning via Fjärrskrivbordstjänster och bekräfta att både Fjärrskrivbordsanvändare och Administratörer är listade.
-
Öppna Neka inloggning via Fjärrskrivbordstjänster och bekräfta att det berörda kontot och dess grupper inte finns med i listan.
-
Spara ändringarna och kör sedan följande på den berörda datorn: gpupdate /force
Om den relevanta GPO:n inte är omedelbart uppenbar, kör detta på den berörda datorn och öppna den resulterande filen för att identifiera vilken princip som styr Tilldelning av användarrättigheter:
gpresult /h gpreport.html
Åtgärd 5: Rensa inaktuella sparade inloggningsuppgifter från Hanteraren för inloggningsuppgifter
Detta är en mindre vanlig orsak, men värt att kontrollera efter att ha bekräftat att gruppmedlemskap och policyinställningar är korrekta. Sparade RDP-inloggningsuppgifter kan bli inaktuella efter ett lösenordsbyte, en kontomigrering eller ändringar i en RDS-pool. I vissa fall leder detta till inloggningsfel som liknar behörighetsfel. Åtgärden, dokumenterad i en Microsoft Q&A-tråd där en RDS-pool med flera års sparade inloggningsuppgifter plötsligt började misslyckas för alla användare, var att rensa den sparade posten och ange inloggningsuppgifterna manuellt på nytt.
-
Öppna Kontrollpanelen, gå till Användarkonton, klicka sedan på Hanteraren för inloggningsuppgifter.
-
Välj Windows-referenser.
-
Leta efter poster som börjar med TERMSRV/ följt av datornamnet eller IP-adressen för den fjärranslutna datorn.
-
Expandera varje relevant post och klicka på Ta bort.
-
Stäng Hanteraren för inloggningsuppgifter och försök att ansluta via RDP igen, genom att ange inloggningsuppgifterna manuellt när du uppmanas.
Åtgärd 6: Använd HelpWire som ett kostnadsfritt alternativ medan du åtgärdar RDP
Om ett behörighetsfel blockerar åtkomsten till en maskin du behöver just nu ger HelpWire dig en fungerande fjärranslutning medan du reder ut policykonfigurationen. Den använder inte Windows Remote Desktop-tjänsten eller port 3389, så problem med gruppmedlemskap och användarrättigheter som orsakar felet “user account not authorized” påverkar inte HelpWire.
HelpWire körs på Windows, macOS och Linux och är gratis att använda. Installationen tar några minuter: installera operatörsklienten på din maskin, installera HelpWire-agenten på den fjärranslutna maskinen och anslut. För obevakad åtkomst till en maskin du hanterar kan agenten konfigureras att köras som en bakgrundstjänst utan att någon i den fjärranslutna änden behöver godkänna varje anslutning.
Vanliga frågor
Administratörskonton tillhör den lokala gruppen Administratörer, som Windows alltid inkluderar i policyn Tillåt inloggning via Fjärrskrivbordstjänster. Standardanvändarkonton läggs som standard inte till i Fjärrskrivbordsanvändare eller i policyn Tillåt inloggning via Fjärrskrivbordstjänster, så de nekas åtkomst tills båda uttryckligen har konfigurerats.
Ja. GPO-inställningar i domänen som tillämpas på domän-, plats- eller OU-nivå skriver över lokala secpol.msc-inställningar vid varje Gruppolicyuppdatering. Om en lokal ändring hela tiden återställs är en motstridig GPO aktiv. Använd GPMC för att åtgärda det på domännivå och kör gpresult /h gpreport.html på den berörda datorn för att identifiera vilken princip som styr Tilldelning av användarrättigheter.
Det blockerar varje konto som listas i den, eller varje grupp som innehåller det kontot, från att ansluta via RDP. Nekandepolicyn åsidosätter både inställningen Tillåt inloggning via Fjärrskrivbordstjänster och medlemskap i gruppen Fjärrskrivbordsanvändare. Konton kan hamna i en nekandegrupp av misstag, till exempel genom att tillhöra gruppen Gäster, som många härdade miljöer inkluderar i nekandepolicyn som standard.
“Anslutningen nekades eftersom användarkontot inte är auktoriserat för fjärrinloggning” betyder att sessionsbegäran nådde målmaskinen och avslogs i auktoriseringslagret, vanligtvis på grund av saknat gruppmedlemskap, en brist i användarrättighetspolicyn eller en aktiv nekandepolicy. “Åtkomst nekad” är bredare och kan också indikera Credential Guard-begränsningar, åtkomstbegränsningar i SAM eller allmänna behörighetsproblem som inte specifikt rör rättigheter för fjärrinloggning. Skillnaden är viktig eftersom de leder till olika felsökningsvägar.
