VPN-tilgang utan rettar til eksternt skrivebord: fire separate portar

Ein brukar koplar til VPN, opnar ei fildeling og ein intern applikasjon, og deretter returnerer eit RDP-forsøk «brukarkontoen er ikkje autorisert for ekstern pålogging». Det er ingenting gale med tunnelen i den meldinga. Fire uavhengige portar står mellom ein VPN-konto og eit interaktivt skrivebord, og berre den siste produserte han. Folk legg vanlegvis til kontoen i Administrators, noko som gir langt meir enn skrivebordet og ikkje rettar porten dersom gruppepolicy nektar det. Her er kva kvar port faktisk gjer, og korleis du berre endrar den som nektar.

Fire portar står i fast rekkjefølgje

Gatewayen avgjer først om identiteten i det heile kan etablere ein tunnel: ein RADIUS-policy, ein gruppevilkår, ein sertifikatkontroll, ei Access Server-tillating. Deretter avgjer ruting og brannmurar om pakken frå tunnelpoolen når TCP 3389-lyttaren til destinasjonen. Deretter autentiserer NLA-handtrykket til klienten kontoen mot destinasjonen. Først etter desse tre kontrollerer den lokale tryggingsstyresmakta om kontoen har påloggingsretten som ei interaktiv fjernøkt krev.

Fordi rekkjefølgja er fast, skjuler kvar port dei bak. Ein mislukka tunnel seier ingenting om ruting; ein blokkert port seier ingenting om påloggingsretten; ein vellukka porttest seier ingenting om tilgang. Derfor er «VPN virkar, men RDP gjer det ikkje» ikkje eitt problem, men ei grense mellom to av desse portane, og derfor er feilteksten den raskaste måten å sjå kva ein trefte.

Retten som faktisk avviser økta

Pålogging til Eksternt skrivebord krev brukarretten Tillat pålogging via Eksternt skrivebord-tenester, SeRemoteInteractiveLogonRight. Han blir kontrollert ved pålogging, ikkje ved tunneloppsett, og derfor kan ein konto surfe på nettverket i timevis og likevel få avvist eit skrivebord. Dialogen som viser han, ligg under Lokale policyar, Tildeling av brukarrettar, og domenerekvivalenten ligg i ein GPO.

Standardmedlemskap avheng av rolla til maskina: arbeidsstasjonar og medlemsservarar gir han til Administrators og Remote Desktop Users, medan ein domenekontrollar berre gir han til Administrators. Det eine faktumet forklarer det meste av forvirringa, fordi same konto lykkast på ein filservar og feilar på ein DC. Ein nektingsrett slår den tilsvarande løyveretten uavhengig av gruppemedlemskap, så ein konto som både er tillaten og nekta, blir nekta. Ei brei nektingsgruppe kan fange ein administrator som vart lagd til som ei teneste.

Les den effektive policyen, ikkje den lokale dialogen

Lokal policy blir overstyrt av kvar einaste domene-GPO som definerer same rett, så den lokale snap-in-en kan vise ei liste som ser rett ut medan den effektive tilstanden er annleis. Eksporter kva maskina faktisk brukar, søk deretter etter retten og les SID-ane i staden for visingsnamna:

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

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

Viss ingen av dei visast, kan ingen utanom ein policyeigar opne eit skrivebord, uansett kva den lokale dialogen for brukarar og grupper føreslår. Då namngir gpresult GPO-en som vann, og det er objektet du må redigere; å endre lokal policy på ei domenetilkopla maskin er ein test, ikkje ei retting.

Gi den smalaste retten som passar

Det vanlege svaret er gruppa Remote Desktop Users på destinasjonen. Ho ber retten som standard, er mykje mindre enn Administrators og skil «kan opne eit skrivebord» frå «kan administrere tenaren». Der policyen uttrykkeleg har omfordelt retten, legg du gruppa eller kontoen til den policyen i staden for å leggje til ei gruppe ingen hadde tenkt som tilgangskontroll.

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

Kontroller nektingslista før du legg til noko. Viss ein nektingsrett namngir ei gruppe som inneheld brukaren, er den rette endringa å fjerne kontoen frå den gruppa eller snevre inn nektinga, ikkje å leggje til ei anna løyve ein annan stad. Noter kva rett du endra og kvar, fordi ein seinare GPO-oppdatering stille gjenopprettar den førre tilstanden, og saka opnar seg igjen med same melding.

Hald nettverksvegen som ei separat avgjerd

VPN-gruppa treng ikkje nå kvar port. Når ei gruppe treng ein applikasjon og ikkje eit skrivebord, gir ein brannmurregel avgrensa til tunnelpoolen og applikasjonsporten verknad til den policyen, medan påloggingsretten blir urørt.

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

OpenVPNs eigen konfigurasjon per klient og Access Server-gruppetillatingar kan avgrense destinasjonsprefiksa i same ånd; ingen av dei gir ein Windows-påloggingsrett, og ein påloggingsrett kan ikkje opne ein port. Hald dei i separate endringsvindauge, fordi ein portregel og ein rett blir godkjende av ulike menneske.

Stadfest i same rekkjefølgje som portane gjeld: kan kontoen etablere tunnelen, når økta lyttaren, autentiserer klienten seg, og har kontoen retten. Ein ping som feilar medan porttesten lykkast, er ein brannmur som svarar annleis på ICMP, ikkje prov på at RDP er blokkert. Microsofts referanse om påloggingsretten viser standardane per maskinrolle og regelen om at nekting slår løyve.