VPN-åtkomst utan rättigheter till fjärrskrivbord: fyra separata portar

En användare ansluter till VPN, öppnar en filresurs och ett internt program, och sedan returnerar ett RDP-försök »användarkontot är inte behörigt för fjärrinloggning«. Det är inget fel på tunneln i det meddelandet. Fyra oberoende portar står mellan ett VPN-konto och ett interaktivt skrivbord, och bara den sista producerade det. Folk lägger vanligtvis till kontot i Administrators, vilket ger långt mer än skrivbordet och inte åtgärdar porten om grupprincip nekar den. Här är vad varje port faktiskt gör, och hur du bara ändrar den som nekar.

Fyra portar i fast ordning

Gatewayen avgör först om identiteten överhuvudtaget får upprätta en tunnel: en RADIUS-princip, ett gruppvillkor, en certifikatkontroll, ett Access Server-tillstånd. Sedan avgör routning och brandväggar om paketet från tunnelpoolen når destinationens TCP 3389-lyssnare. Sedan autentiserar klientens NLA-handskakning kontot mot destinationen. Först efter dessa tre kontrollerar den lokala säkerhetsmyndigheten om kontot har den inloggningsrätt som en interaktiv fjärrsession kräver.

Eftersom ordningen är fast döljer varje port dem bakom. En misslyckad tunnel säger inget om routning; en blockerad port säger inget om inloggningsrätten; ett lyckat porttest säger inget om insläpp. Därför är »VPN fungerar men RDP inte« inte ett problem utan en gräns mellan två av dessa portar, och därför är feltexten det snabbaste sättet att se vilken du träffade.

Rättigheten som faktiskt avvisar sessionen

Inloggning till Fjärrskrivbord kräver användarrättigheten Tillåt inloggning via Fjärrskrivbordstjänster, SeRemoteInteractiveLogonRight. Den kontrolleras vid inloggning, inte vid tunneluppsättning, och därför kan ett konto surfa på nätverket i timmar och ändå nekas ett skrivbord. Dialogen som visar den ligger under Lokala principer, Tilldelning av användarrättigheter, och domeinekvivalenten ligger i en GPO.

Standardmedlemskap beror på maskinens roll: arbetsstationer och medlemsservrar ger den till Administrators och Remote Desktop Users, medan en domänkontrollant bara ger den till Administrators. Det enda faktumet förklarar det mesta av förvirringen, eftersom samma konto lyckas på en filserver och misslyckas på en DC. En nekanderätt slår den motsvarande tillåtanderätten oavsett gruppmedlemskap, så ett konto som både är tillåtet och nekat nekas. En bred nekgrupp kan fånga en administratör som lades till som en tjänst.

Läs den effektiva principen, inte den lokala dialogen

Lokal princip skrivs över av alla domän-GPO:er som definierar samma rättighet, så den lokala snap-in kan visa en lista som ser korrekt ut medan det effektiva tillståndet är annat. Exportera vad maskinen faktiskt tillämpar, sök sedan upp rättigheten och läs SID:erna i stället för visningsnamnen:

secedit /export /cfg C:\temp\secpol.cfg
Select-String -Path C:\temp\secpol.cfg -Pattern SeRemoteInteractiveLogonRight
gpresult /scope computer /v

I den utdata är *S-1-5-32-544 Administrators och *S-1-5-32-555 Remote Desktop Users.

Om ingen av dem visas kan ingen utom en principinnehavare öppna ett skrivbord, vad den lokala dialogen för användare och grupper än föreslår. Då namnger gpresult den GPO som vann, och det är objektet du måste redigera; att ändra lokal princip på en domänansluten maskin är ett test, inte en rättelse.

Ge den smalaste rättigheten som passar

Det vanliga svaret är gruppen Remote Desktop Users på destinationen. Den bär rättigheten som standard, är mycket mindre än Administrators och skiljer »får öppna ett skrivbord« från »får administrera servern«. Där principen uttryckligen har omfördelat rättigheten lägger du till gruppen eller kontot i den principen i stället för att lägga till en grupp som ingen hade tänkt som åtkomstkontroll.

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "CORP\a.user"

Kontrollera nekandelistan innan du lägger till något. Om en nekanderätt namnger en grupp som innehåller användaren är den korrekta ändringen att ta bort kontot från den gruppen eller snäva in nekandet, inte att lägga till en andra tillåtelse någon annanstans. Anteckna vilken rättighet du ändrade och var, eftersom en senare GPO-uppdatering tyst återställer det tidigare tillståndet och ärendet öppnas igen med samma meddelande.

Håll nätverksvägen som ett separat beslut

VPN-gruppen behöver inte nå varje port. När en grupp behöver ett program och inte ett skrivbord, ger en brandväggsregel begränsad till tunnelpoolen och programporten verkan åt den principen, medan inloggningsrätten förblir orörd.

Get-NetFirewallRule -DisplayGroup "Remote Desktop"
Test-NetConnection -ComputerName 10.20.0.50 -Port 3389

OpenVPN:s egen konfiguration per klient och Access Server-grupptillstånd kan begränsa destinationsprefixen i samma anda; ingen av dem ger en Windows-inloggningsrättighet, och en inloggningsrättighet kan inte öppna en port. Håll dem i separata ändringsfönster, eftersom en portregel och en rättighet godkänns av olika människor.

Verifiera i samma ordning som portarna gäller: kan kontot upprätta tunneln, når sessionen lyssnaren, autentiserar klienten, och har kontot rättigheten. En ping som misslyckas medan porttestet lyckas är en brandvägg som svarar annorlunda på ICMP, inte bevis för att RDP är blockerat. Microsofts referens om inloggningsrätten listar standardvärdena per maskinroll och regeln att nekande slår tillåtande.