VPN-toegang zonder rechten voor extern bureaublad: vier afzonderlijke poorten

Een gebruiker verbindt met de VPN, opent een bestandsshare en een interne applicatie, en dan geeft een RDP-poging „het gebruikersaccount is niet gemachtigd voor externe aanmelding“ terug. Aan die melding is niets mis met de tunnel. Vier onafhankelijke poorten staan tussen een VPN-account en een interactief bureaublad, en alleen de laatste heeft het veroorzaakt. Mensen reageren meestal door het account aan Administrators toe te voegen, wat veel meer dan het bureaublad geeft en de poort niet repareert als groepsbeleid die weigert. Dit is wat elke poort werkelijk doet, en hoe je alleen degene wijzigt die weigert.

Vier poorten in een vaste volgorde

De gateway beslist eerst of de identiteit überhaupt een tunnel mag opzetten: een RADIUS-beleid, een groepsconditie, een certificaatcontrole, een Access Server-machtiging. Daarna beslissen routing en firewalls of het pakket uit de tunnelpool de TCP 3389-listener van de bestemming bereikt. Daarna authenticeert de NLA-handshake van de client het account tegen de bestemming. Pas daarna controleert de lokale beveiligingsautoriteit of het account het aanmeldrecht bezit dat een interactieve externe sessie vereist.

Omdat de volgorde vastligt, verbergt elke poort de poorten erachter. Een mislukte tunnel zegt niets over routing; een geblokkeerde poort zegt niets over het aanmeldrecht; een geslaagde poorttest zegt niets over toelating. Daarom is „de VPN werkt, maar RDP niet“ geen enkel probleem maar een grens tussen twee van deze poorten, en daarom is de fouttekst de snelste manier om te zien welke je trof.

Het recht dat de sessie werkelijk weigert

Aanmelden op het externe bureaublad vereist het gebruikersrecht Aanmelden via Extern bureaublad-services toestaan, SeRemoteInteractiveLogonRight. Het wordt bij aanmelding gecontroleerd, niet bij het opzetten van de tunnel, waardoor een account uren door het netwerk kan bladeren en toch een bureaublad geweigerd krijgt. De dialoog die het toont, staat onder Lokaal beleid, Toewijzing van gebruikersrechten, en het domeinequivalent staat in een GPO.

Het standaardlidmaatschap hangt af van de rol van de machine: werkstations en lidservers verlenen het aan Administrators en Remote Desktop Users, terwijl een domeincontroller het alleen aan Administrators verleent. Dat ene feit verklaart het grootste deel van de verwarring, omdat hetzelfde account slaagt op een fileserver en faalt op een DC. Een weigeringsrecht verslaat het bijbehorende toestemmingsrecht ongeacht groepslidmaatschap, dus een account dat zowel is toegestaan als geweigerd, wordt geweigerd. Een brede weigeringsgroep kan een beheerder vangen die als gunst is toegevoegd.

Lees het effectieve beleid, niet de lokale dialoog

Lokaal beleid wordt overschreven door elk domein-GPO dat hetzelfde recht definieert, dus de lokale snap-in kan een correct uitziende lijst tonen terwijl de effectieve status anders is. Exporteer wat de machine werkelijk toepast, zoek dan het recht en lees de SID's in plaats van de weergavenamen:

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

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

Als geen van beide verschijnt, kan niemand behalve een beleidseigenaar een bureaublad openen, wat de lokale dialoog voor gebruikers en groepen ook suggereert. Dan noemt gpresult het GPO dat heeft gewonnen, en dat is het object dat je moet bewerken; lokaal beleid wijzigen op een domeinmachine is een test, geen oplossing.

Geef het smalste recht dat past

Het gebruikelijke antwoord is de groep Remote Desktop Users op de bestemming. Die draagt het recht standaard, is veel kleiner dan Administrators en scheidt „mag een bureaublad openen“ van „mag de server beheren“. Waar het beleid het recht uitdrukkelijk opnieuw heeft toegewezen, voeg je de groep of het account aan dat beleid toe in plaats van een groep toe te voegen die niemand als toegangscontrole bedoelde.

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

Controleer de weigeringslijst voordat je iets toevoegt. Als een weigeringsrecht een groep noemt die de gebruiker bevat, is de juiste wijziging het account uit die groep verwijderen of de weigering versmallen, niet elders een tweede toestemming toevoegen. Noteer welk recht je waar hebt gewijzigd, want een latere GPO-verversing herstelt de vorige status stil en het ticket gaat opnieuw open met dezelfde melding.

Houd het netwerkpad een aparte beslissing

De VPN-groep hoeft niet elke poort te bereiken. Wanneer een groep een applicatie nodig heeft en geen bureaublad, geeft een firewallregel beperkt tot de tunnelpool en de applicatiepoort uitvoering aan dat beleid, terwijl het aanmeldrecht onaangetast blijft.

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

OpenVPN's eigen configuratie per client en Access Server-groepsmachtigingen kunnen de bestemmingsprefixen in dezelfde geest beperken; geen van beide verleent een Windows-aanmeldrecht, en een aanmeldrecht kan geen poort openen. Houd ze in aparte wijzigingsvensters, omdat een poortregel en een recht door verschillende mensen worden goedgekeurd.

Verifieer in dezelfde volgorde als de poorten gelden: kan het account de tunnel opzetten, bereikt de sessie de listener, authenticeert de client, en bezit het account het recht. Een ping die faalt terwijl de poorttest slaagt, is een firewall die anders op ICMP antwoordt, geen bewijs dat RDP geblokkeerd is. Microsofts referentie over het aanmeldrecht vermeldt de standaardwaarden per machinerol en de regel dat weigering toestemming verslaat.