VPN-adgang uden rettigheder til fjernskrivebord: fire separate porte

En bruger opretter forbindelse til VPN, åbner en fildeling og en intern applikation, og derefter returnerer et RDP-forsøg »brugerkontoen er ikke autoriseret til fjernlogon«. Der er intet galt med tunnelen i den meddelelse. Fire uafhængige porte står mellem en VPN-konto og et interaktivt skrivebord, og kun den sidste frembragte den. Folk tilføjer normalt kontoen til Administrators, hvilket giver langt mere end skrivebordet og ikke retter porten, hvis gruppepolitik nægter det. Her er, hvad hver port faktisk gør, og hvordan man kun ændrer den, der nægter.

Fire porte står i fast rækkefølge

Gatewayen afgør først, om identiteten overhovedet må etablere en tunnel: en RADIUS-politik, en gruppebetingelse, et certifikattjek, en Access Server-tilladelse. Derefter afgør routing og firewalls, om pakken fra tunnelpoolen når destinationens TCP 3389-lytter. Derefter autentificerer klientens NLA-håndtryk kontoen mod destinationen. Først efter disse tre tjekker den lokale sikkerhedsmyndighed, om kontoen har den logonret, som en interaktiv fjernsession kræver.

Fordi rækkefølgen er fast, skjuler hver port dem bagved. En mislykket tunnel siger intet om routing; en blokeret port siger intet om logonretten; en vellykket porttest siger intet om adgang. Derfor er »VPN virker, men RDP gør ikke« ikke ét problem men en grænse mellem to af disse porte, og derfor er fejlteksten den hurtigste måde at se, hvilken du ramte.

Den ret, der faktisk afviser sessionen

Logon til Fjernskrivebord kræver brugerretten Tillad logon via Fjernskrivebordstjenester, SeRemoteInteractiveLogonRight. Den kontrolleres ved logon, ikke ved tunnelopsætning, og derfor kan en konto browse netværket i timevis og stadig få afvist et skrivebord. Dialogen, der viser den, ligger under Lokale politikker, Tildeling af brugerrettigheder, og domæneækvivalenten ligger i en GPO.

Standardmedlemskab afhænger af maskinens rolle: arbejdsstationer og medlemsservere giver den til Administrators og Remote Desktop Users, mens en domænecontroller kun giver den til Administrators. Den ene kendsgerning forklarer det meste af forvirringen, fordi den samme konto lykkes på en fileserver og fejler på en DC. En nægtelsesret slår den tilsvarende tilladelsesret uanset gruppemedlemskab, så en konto, der både er tilladt og nægtet, nægtes. En bred nægtelsesgruppe kan fange en administrator, der blev tilføjet som en tjeneste.

Læs den effektive politik, ikke den lokale dialog

Lokal politik overskrives af enhver domæne-GPO, der definerer samme ret, så det lokale snap-in kan vise en liste, der ser rigtig ud, mens den effektive tilstand er anderledes. Eksportér, hvad maskinen faktisk anvender, søg derefter efter retten og læs SID'erne i stedet for visningsnavnene:

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

I det output er *S-1-5-32-544 Administrators, og *S-1-5-32-555 er Remote Desktop Users.

Hvis ingen af dem vises, kan ingen undtagen en politikejer åbne et skrivebord, uanset hvad den lokale dialog for brugere og grupper foreslår. Derefter navngiver gpresult den GPO, der vandt, og det er det objekt, du skal redigere; at ændre lokal politik på en domænetilsluttet maskine er en test, ikke en rettelse.

Giv den snævreste ret, der passer

Det sædvanlige svar er gruppen Remote Desktop Users på destinationen. Den bærer retten som standard, er meget mindre end Administrators og adskiller »må åbne et skrivebord« fra »må administrere serveren«. Hvor politikken udtrykkeligt har omfordelt retten, skal du føje gruppen eller kontoen til den politik i stedet for at tilføje en gruppe, som ingen havde tiltænkt som adgangskontrol.

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

Kontrollér nægtelseslisten, før du tilføjer noget. Hvis en nægtelsesret navngiver en gruppe, der indeholder brugeren, er den korrekte ændring at fjerne kontoen fra den gruppe eller indsnævre nægtelsen, ikke at tilføje en anden tilladelse et andet sted. Notér, hvilken ret du ændrede og hvor, fordi en senere GPO-opdatering stille gendanner den forrige tilstand, og sagen åbnes igen med samme meddelelse.

Hold netværksvejen som en separat beslutning

VPN-gruppen behøver ikke nå hver port. Når en gruppe har brug for en applikation og ikke et skrivebord, giver en firewallregel afgrænset til tunnelpoolen og applikationsporten virkning til den politik, mens logonretten forbliver urørt.

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

OpenVPNs egen konfiguration pr. klient og Access Server-gruppetilladelser kan begrænse destinationspræfikserne i samme ånd; ingen af dem giver en Windows-logonret, og en logonret kan ikke åbne en port. Hold dem i separate ændringsvinduer, fordi en portregel og en ret godkendes af forskellige mennesker.

Bekræft i samme rækkefølge, som portene gælder: kan kontoen etablere tunnelen, kan sessionen nå lytteren, autentificerer klienten, og har kontoen retten. En ping, der fejler, mens porttesten lykkes, er en firewall, der svarer anderledes på ICMP, ikke bevis for, at RDP er blokeret. Microsofts reference om logonretten viser standarder pr. maskinrolle og reglen om, at nægtelse slår tilladelse.