VPN-toegang sonder regte vir afgeleë lessenaar: vier afsonderlike hekke

’n Gebruiker koppel aan die VPN, open ’n lêerdeling en ’n interne toepassing, en dan gee ’n RDP-poging terug “die gebruikersrekening is nie vir afgeleë aanmelding gemagtig nie”. Niks omtrent die tonnel is verkeerd in daardie boodskap nie. Vier onafhanklike hekke lê tussen ’n VPN-rekening en ’n interaktiewe lessenaar, en net die laaste een het dit veroorsaak. Mense reageer gewoonlik deur die rekening by Administrators te voeg, wat veel meer as die lessenaar toeken en nie die hek regstel as Groepbeleid dit weier nie. Hier is wat elke hek werklik doen, en hoe om net die een te verander wat weier.

Vier hekke staan in ’n vaste volgorde

Die poort besluit eers of die identiteit hoegenaamd ’n tonnel mag opstel: ’n RADIUS-beleid, ’n groepvoorwaarde, ’n sertifikaatkontrole, ’n Access Server-toestemming. Dan besluit roetering en firewalls of die pakkie uit die tonnelpoel die bestemming se TCP 3389-luisteraar bereik. Dan verifieer die kliënt se NLA-handdruk die rekening teenoor die bestemming. Eers ná daardie drie kyk die plaaslike sekuriteitsowerheid of die rekening die aanmeldreg het wat ’n interaktiewe afgeleë sessie vereis.

Omdat die volgorde vas is, verberg elke hek diegene agter hom. ’n Mislukte tonnel sê niks oor roetering nie; ’n geblokkeerde poort sê niks oor die aanmeldreg nie; ’n suksesvolle poorttoets sê niks oor toelating nie. Daarom is “die VPN werk maar RDP nie” nie een probleem nie, maar ’n grens tussen twee van hierdie hekke, en daarom is die foutteks die vinnigste manier om te sien watter een jy getref het.

Die reg wat die sessie werklik weier

Aanmelding by Remote Desktop vereis die gebruikersreg Laat aanmelding deur Remote Desktop Services toe, SeRemoteInteractiveLogonRight. Dit word by aanmelding nagegaan, nie by tonnelopstelling nie, en daarom kan ’n rekening ure lank deur die netwerk blaai en steeds ’n lessenaar geweier word. Die dialoog wat dit wys, is onder Plaaslike beleid, Toewysing van gebruikersregte, en die domeinekwivalent is in ’n GPO.

Die versteklidmaatskap hang van die masjien se rol af: werkstasies en lidbedieners ken dit aan Administrators en Remote Desktop Users toe, terwyl ’n domeinbeheerder dit net aan Administrators toeken. Daardie enkele feit verduidelik die meeste verwarring, want dieselfde rekening slaag op ’n lêerbediener en misluk op ’n DC. ’n Weierreg klop die ooreenstemmende toestaanreg ongeag groepslidmaatskap, so ’n rekening wat beide toegestaan en geweier word, word geweier. ’n Breë weiergroep kan ’n administrateur vang wat as ’n guns bygevoeg is.

Lees die effektiewe beleid, nie die plaaslike dialoog nie

Plaaslike beleid word deur enige domein-GPO wat dieselfde reg definieer, oorskryf, so die plaaslike snap-in kan ’n korrek-lykende lys wys terwyl die effektiewe toestand anders is. Voer uit wat die masjien werklik toepas, soek dan na die reg en lees die SID's eerder as die vertoonname:

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

In daardie uitvoer is *S-1-5-32-544 Administrators en *S-1-5-32-555 Remote Desktop Users.

As nie een van die twee verskyn nie, kan niemand behalwe ’n beleidhouer ’n lessenaar oopmaak nie, ongeag wat die plaaslike dialoog vir gebruikers en groepe voorstel. gpresult noem dan die GPO wat gewen het, en dit is die objek wat jy moet wysig; om plaaslike beleid op ’n domeingekoppelde masjien te verander, is ’n toets, nie ’n regstelling nie.

Ken die smalste reg toe wat pas

Die gewone antwoord is die Remote Desktop Users-groep op die bestemming. Dit dra die reg by verstek, dit is veel kleiner as Administrators, en dit skei “mag ’n lessenaar oopmaak” van “mag die bediener bestuur”. Waar beleid die reg eksplisiet hertoeken het, voeg die groep of die rekening by daardie beleid eerder as om ’n groep by te voeg wat niemand as toegangsbeheer bedoel het nie.

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

Kontroleer die weierlys voordat jy iets byvoeg. As ’n weierreg ’n groep noem wat die gebruiker bevat, is die korrekte verandering om die rekening uit daardie groep te verwyder of die weier te vernou, nie om ’n tweede toestaan elders by te voeg nie. Teken aan watter reg jy verander het en waar, want ’n latere GPO-verfrissing sal die vorige toestand stilweg herstel en die kaartjie sal met dieselfde boodskap heropen.

Hou die netwerkpad ’n aparte besluit

Die VPN-groep hoef nie elke poort te bereik nie. Wanneer ’n groep ’n toepassing en nie ’n lessenaar nodig het nie, gee ’n firewallreël wat op die tonnelpoel en die toepassingspoort beperk is, aan daardie beleid gevolg, terwyl die aanmeldreg onaangeraak bly.

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

OpenVPN se eie per-kliënt-konfigurasie en Access Server-groepstoestemmings kan die bestemmingsvoorvoegsels in dieselfde gees beperk; nie een van hulle verleen ’n Windows-aanmeldreg nie, en ’n aanmeldreg kan nie ’n poort oopmaak nie. Hou hulle in aparte veranderingsvensters, want ’n poortreël en ’n reg word deur verskillende mense goedgekeur.

Verifieer in dieselfde volgorde waarin die hekke geld: kan die rekening die tonnel opstel, kan die sessie die luisteraar bereik, verifieer die kliënt, en het die rekening die reg. ’n Ping wat misluk terwyl die poorttoets slaag, is ’n firewall wat anders vir ICMP antwoord, nie ’n bewys dat RDP geblokkeer is nie. Microsoft se naslaan oor die aanmeldreg lys die verstekke per masjienrol en die reël dat weiering bo toestaan geld.