VPN-Zugriff ohne Rechte für Remotedesktop: vier getrennte Hürden

Ein Benutzer verbindet sich mit dem VPN, öffnet eine Dateifreigabe und eine interne Anwendung, und dann gibt ein RDP-Versuch „das Benutzerkonto ist nicht für die Remoteanmeldung berechtigt“ zurück. An dieser Meldung ist nichts am Tunnel falsch. Zwischen einem VPN-Konto und einem interaktiven Desktop stehen vier unabhängige Hürden, und nur die letzte hat sie erzeugt. Meist reagieren Leute damit, das Konto zu Administrators hinzuzufügen, was weit mehr als den Desktop gewährt und die Hürde nicht behebt, wenn eine Gruppenrichtlinie sie verweigert. Hier steht, was jede Hürde tatsächlich tut und wie man nur die ändert, die ablehnt.

Vier Hürden stehen in fester Reihenfolge

Das Gateway entscheidet zuerst, ob die Identität überhaupt einen Tunnel aufbauen darf: eine RADIUS-Richtlinie, eine Gruppenbedingung, eine Zertifikatsprüfung, eine Access-Server-Berechtigung. Dann entscheiden Routing und Firewalls, ob das Paket aus dem Tunnel-Pool den TCP-3389-Listener des Ziels erreicht. Dann authentifiziert der NLA-Handshake des Clients das Konto gegenüber dem Ziel. Erst danach prüft die lokale Sicherheitsbehörde, ob das Konto das Anmelderecht besitzt, das eine interaktive Remotesitzung verlangt.

Weil die Reihenfolge fest ist, verbirgt jede Hürde die dahinterliegenden. Ein fehlgeschlagener Tunnel sagt nichts über Routing; ein blockierter Port sagt nichts über das Anmelderecht; ein erfolgreicher Porttest sagt nichts über die Zulassung. Deshalb ist „das VPN funktioniert, aber RDP nicht“ kein einzelnes Problem, sondern eine Grenze zwischen zwei dieser Hürden, und deshalb ist der Fehlertext der schnellste Weg zu erkennen, welche man getroffen hat.

Das Recht, das die Sitzung tatsächlich verweigert

Die Anmeldung am Remotedesktop erfordert das Benutzerrecht Anmelden über Remotedesktopdienste zulassen, SeRemoteInteractiveLogonRight. Es wird bei der Anmeldung geprüft, nicht beim Tunnelaufbau, weshalb ein Konto stundenlang im Netzwerk stöbern und trotzdem einen Desktop verweigert bekommen kann. Der Dialog, der es zeigt, liegt unter Lokale Richtlinien, Zuweisen von Benutzerrechten, und das Domänenäquivalent liegt in einer GPO.

Die Standardmitgliedschaft hängt von der Rolle des Rechners ab: Arbeitsstationen und Mitgliedsserver gewähren es Administrators und Remote Desktop Users, ein Domänencontroller nur Administrators. Diese eine Tatsache erklärt den Großteil der Verwirrung, denn dasselbe Konto gelingt auf einem Dateiserver und scheitert auf einem DC. Ein Verweigerungsrecht schlägt das passende Zulassungsrecht unabhängig von der Gruppenmitgliedschaft, ein Konto, dem sowohl erlaubt als auch verweigert wird, wird verweigert. Eine breite Verweigerungsgruppe kann einen Administrator erwischen, der als Gefälligkeit hinzugefügt wurde.

Lesen Sie die effektive Richtlinie, nicht den lokalen Dialog

Lokale Richtlinien werden von jeder Domänen-GPO überschrieben, die dasselbe Recht definiert, sodass das lokale Snap-In eine korrekt aussehende Liste zeigen kann, während der effektive Zustand anders ist. Exportieren Sie, was der Rechner tatsächlich anwendet, suchen Sie dann das Recht und lesen Sie die SIDs statt der Anzeigenamen:

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

In dieser Ausgabe ist *S-1-5-32-544 Administrators und *S-1-5-32-555 Remote Desktop Users.

Wenn keines von beiden erscheint, kann niemand außer einem Richtlinieninhaber einen Desktop öffnen, egal was der lokale Dialog für Benutzer und Gruppen nahelegt. Dann nennt gpresult die GPO, die gewonnen hat, und das ist das Objekt, das Sie bearbeiten müssen; lokale Richtlinien auf einem domänengebundenen Rechner zu ändern ist ein Test, keine Behebung.

Vergeben Sie das engste passende Recht

Die übliche Antwort ist die Gruppe Remote Desktop Users auf dem Ziel. Sie trägt das Recht standardmäßig, ist viel kleiner als Administrators und trennt „darf einen Desktop öffnen“ von „darf den Server verwalten“. Wo die Richtlinie das Recht ausdrücklich neu zugewiesen hat, fügen Sie die Gruppe oder das Konto dieser Richtlinie hinzu, statt eine Gruppe hinzuzufügen, die niemand als Zugriffskontrolle gedacht hatte.

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

Prüfen Sie die Verweigerungsliste, bevor Sie etwas hinzufügen. Wenn ein Verweigerungsrecht eine Gruppe nennt, die den Benutzer enthält, ist die richtige Änderung, das Konto aus dieser Gruppe zu entfernen oder die Verweigerung zu verengen, nicht, anderswo eine zweite Zulassung hinzuzufügen. Notieren Sie, welches Recht Sie wo geändert haben, denn eine spätere GPO-Aktualisierung stellt den vorherigen Zustand still wieder her, und das Ticket öffnet sich mit derselben Meldung erneut.

Halten Sie den Netzwerkpfad getrennt

Die VPN-Gruppe muss nicht jeden Port erreichen. Wenn eine Gruppe eine Anwendung und keinen Desktop braucht, setzt eine auf den Tunnel-Pool und den Anwendungsport begrenzte Firewallregel diese Richtlinie um, während das Anmelderecht unberührt bleibt.

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

OpenVPNs eigene Konfiguration pro Client und Access-Server-Gruppenberechtigungen können die Zielpräfixe im selben Sinne einschränken; keines von beiden vergibt ein Windows-Anmelderecht, und ein Anmelderecht kann keinen Port öffnen. Halten Sie sie in getrennten Änderungsfenstern, weil eine Portregel und eine Berechtigung von verschiedenen Leuten genehmigt werden.

Prüfen Sie in derselben Reihenfolge, in der die Hürden gelten: Kann das Konto den Tunnel aufbauen, erreicht die Sitzung den Listener, authentifiziert sich der Client, und besitzt das Konto das Recht. Ein Ping, der scheitert, während der Porttest gelingt, ist eine Firewall, die auf ICMP anders antwortet, kein Beweis, dass RDP blockiert ist. Microsofts Referenz zum Anmelderecht listet die Standardwerte je Rechnerrolle und die Regel, dass Verweigerung Zulassung schlägt.