VPN-tilgang uten rettigheter til eksternt skrivebord: fire separate porter

En bruker kobler til VPN, åpner en fildeling og en intern applikasjon, og deretter returnerer et RDP-forsøk «brukerkontoen er ikke autorisert for ekstern pålogging». Det er ingenting galt med tunnelen i den meldingen. Fire uavhengige porter står mellom en VPN-konto og et interaktivt skrivebord, og bare den siste produserte den. Folk legger vanligvis til kontoen i Administrators, noe som gir langt mer enn skrivebordet og ikke retter porten hvis gruppepolicy nekter det. Her er hva hver port faktisk gjør, og hvordan du bare endrer den som nekter.

Fire porter står i fast rekkefølge

Gatewayen avgjør først om identiteten i det hele tatt kan etablere en tunnel: en RADIUS-policy, en gruppebetingelse, en sertifikatkontroll, en Access Server-tillatelse. Deretter avgjør ruting og brannmurer om pakken fra tunnelpoolen når destinasjonens TCP 3389-lytter. Deretter autentiserer klientens NLA-håndtrykk kontoen mot destinasjonen. Først etter disse tre kontrollerer den lokale sikkerhetsmyndigheten om kontoen har påloggingsretten som en interaktiv fjernøkt krever.

Fordi rekkefølgen er fast, skjuler hver port dem bak. En mislykket tunnel sier ingenting om ruting; en blokkert port sier ingenting om påloggingsretten; en vellykket porttest sier ingenting om adgang. Derfor er «VPN virker, men RDP gjør det ikke» ikke ett problem, men en grense mellom to av disse portene, og derfor er feilteksten den raskeste måten å se hvilken du traff.

Retten som faktisk avviser økten

Pålogging til Eksternt skrivebord krever brukerretten Tillat pålogging via Eksternt skrivebord-tjenester, SeRemoteInteractiveLogonRight. Den kontrolleres ved pålogging, ikke ved tunneloppsett, og derfor kan en konto surfe på nettverket i timevis og likevel få avvist et skrivebord. Dialogen som viser den, ligger under Lokale policyer, Tildeling av brukerrettigheter, og domeneekvivalenten ligger i en GPO.

Standardmedlemskap avhenger av maskinens rolle: arbeidsstasjoner og medlemsservere gir den til Administrators og Remote Desktop Users, mens en domenekontroller bare gir den til Administrators. Det ene faktum forklarer det meste av forvirringen, fordi samme konto lykkes på en filserver og feiler på en DC. En nektelsesrett slår den tilsvarende tillatelsesretten uavhengig av gruppemedlemskap, så en konto som både er tillatt og nektet, nektes. En bred nektelsesgruppe kan fange en administrator som ble lagt til som en tjeneste.

Les den effektive policyen, ikke den lokale dialogen

Lokal policy overskrives av enhver domene-GPO som definerer samme rett, så det lokale snap-in kan vise en liste som ser riktig ut mens den effektive tilstanden er annerledes. Eksporter hva maskinen faktisk anvender, søk deretter etter retten og les SID-ene 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 den utskriften er *S-1-5-32-544 Administrators, og *S-1-5-32-555 er Remote Desktop Users.

Hvis ingen av dem vises, kan ingen unntatt en policyeier åpne et skrivebord, uansett hva den lokale dialogen for brukere og grupper foreslår. Da navngir gpresult GPO-en som vant, og det er objektet du må redigere; å endre lokal policy på en domenetilkoblet maskin er en test, ikke en rettelse.

Gi den smaleste retten som passer

Det vanlige svaret er gruppen Remote Desktop Users på destinasjonen. Den bærer retten som standard, er mye mindre enn Administrators og skiller «kan åpne et skrivebord» fra «kan administrere serveren». Der policyen uttrykkelig har omfordelt retten, legger du gruppen eller kontoen til den policyen i stedet for å legge til en gruppe ingen hadde tenkt som tilgangskontroll.

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

Kontroller nektelseslisten før du legger til noe. Hvis en nektelsesrett navngir en gruppe som inneholder brukeren, er den riktige endringen å fjerne kontoen fra den gruppen eller snevre inn nektelsen, ikke å legge til en annen tillatelse et annet sted. Noter hvilken rett du endret og hvor, fordi en senere GPO-oppdatering stille gjenoppretter den forrige tilstanden, og saken åpnes igjen med samme melding.

Hold nettverksveien som en separat beslutning

VPN-gruppen trenger ikke nå hver port. Når en gruppe trenger en applikasjon og ikke et skrivebord, gir en brannmurregel begrenset til tunnelpoolen og applikasjonsporten virkning til den policyen, mens påloggingsretten forblir urørt.

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

OpenVPNs egen konfigurasjon per klient og Access Server-gruppetillatelser kan begrense destinasjonsprefiksene i samme ånd; ingen av dem gir en Windows-påloggingsrett, og en påloggingsrett kan ikke åpne en port. Hold dem i separate endringsvinduer, fordi en portregel og en rett godkjennes av forskjellige mennesker.

Bekreft i samme rekkefølge som portene gjelder: kan kontoen etablere tunnelen, når økten lytteren, autentiserer klienten, og har kontoen retten. En ping som feiler mens porttesten lykkes, er en brannmur som svarer annerledes på ICMP, ikke bevis for at RDP er blokkert. Microsofts referanse om påloggingsretten viser standardene per maskinrolle og regelen om at nektelse slår tillatelse.