Accès VPN sans droits de bureau à distance : quatre portes distinctes

Un utilisateur se connecte au VPN, ouvre un partage de fichiers et une application interne, puis une tentative RDP renvoie « le compte d’utilisateur n’est pas autorisé à ouvrir une session à distance ». Rien ne cloche dans le tunnel d’après ce message. Quatre portes indépendantes se dressent entre un compte VPN et un bureau interactif, et seule la dernière l’a produit. Les gens réagissent généralement en ajoutant le compte à Administrators, ce qui accorde bien plus que le bureau et ne corrige pas la porte si une stratégie de groupe la refuse. Voici ce que fait réellement chaque porte et comment modifier uniquement celle qui refuse.

Quatre portes dans un ordre fixe

La passerelle décide d’abord si l’identité peut établir un tunnel : une stratégie RADIUS, une condition de groupe, un contrôle de certificat, une autorisation Access Server. Ensuite le routage et les pare-feu décident si le paquet du pool de tunnels atteint l’écouteur TCP 3389 de la destination. Ensuite la poignée de main NLA du client authentifie le compte auprès de la destination. C’est seulement après ces trois étapes que l’autorité de sécurité locale vérifie si le compte détient le droit d’ouverture de session qu’exige une session distante interactive.

Comme l’ordre est fixe, chaque porte masque celles qui se trouvent derrière. Un tunnel en échec ne dit rien du routage ; un port bloqué ne dit rien du droit d’ouverture de session ; un test de port réussi ne dit rien de l’admission. C’est pourquoi « le VPN fonctionne mais pas RDP » n’est pas un seul problème mais une frontière entre deux de ces portes, et pourquoi le texte d’erreur est le moyen le plus rapide de savoir laquelle vous avez heurtée.

Le droit qui refuse réellement la session

L’ouverture de session sur le bureau à distance exige le droit d’utilisateur Autoriser l’ouverture de session via les services Bureau à distance, SeRemoteInteractiveLogonRight. Il est vérifié à l’ouverture de session, pas à l’établissement du tunnel, ce qui explique qu’un compte puisse parcourir le réseau pendant des heures et se voir néanmoins refuser un bureau. La boîte de dialogue qui l’affiche se trouve sous Stratégies locales, Attribution des droits utilisateur, et l’équivalent de domaine réside dans une GPO.

L’appartenance par défaut dépend du rôle de la machine : les stations de travail et les serveurs membres l’accordent à Administrators et Remote Desktop Users, tandis qu’un contrôleur de domaine ne l’accorde qu’à Administrators. Ce seul fait explique l’essentiel de la confusion, car le même compte réussit sur un serveur de fichiers et échoue sur un DC. Un droit de refus l’emporte sur le droit d’autorisation correspondant quel que soit l’appartenance au groupe, si bien qu’un compte à la fois autorisé et refusé est refusé. Un groupe de refus étendu peut attraper un administrateur ajouté par complaisance.

Lisez la stratégie effective, pas la boîte de dialogue locale

La stratégie locale est remplacée par toute GPO de domaine qui définit le même droit, si bien que le composant logiciel enfichable local peut afficher une liste d’apparence correcte alors que l’état effectif diffère. Exportez ce que la machine applique réellement, puis recherchez le droit et lisez les SID plutôt que les noms d’affichage :

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

Dans cette sortie, *S-1-5-32-544 correspond à Administrators et *S-1-5-32-555 à Remote Desktop Users.

Si aucun des deux n’apparaît, personne hormis un titulaire de stratégie ne peut ouvrir un bureau, quoi que suggère la boîte de dialogue locale Utilisateurs et groupes. gpresult nomme alors la GPO qui l’a emporté, et c’est l’objet que vous devez modifier ; changer la stratégie locale sur une machine jointe au domaine est un test, pas un correctif.

Accordez le droit le plus étroit qui convient

La réponse ordinaire est le groupe Remote Desktop Users sur la destination. Il porte le droit par défaut, il est bien plus petit qu’Administrators et il sépare « peut ouvrir un bureau » de « peut administrer le serveur ». Là où la stratégie a réattribué le droit explicitement, ajoutez le groupe ou le compte à cette stratégie au lieu d’ajouter un groupe que personne ne destinait à être un contrôle d’accès.

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

Vérifiez la liste des refus avant d’ajouter quoi que ce soit. Si un droit de refus nomme un groupe qui contient l’utilisateur, la correction consiste à retirer le compte de ce groupe ou à resserrer le refus, non à ajouter une seconde autorisation ailleurs. Notez quel droit vous avez modifié et où, car une actualisation ultérieure de la GPO rétablira silencieusement l’état précédent et le ticket se rouvrira avec le même message.

Gardez le chemin réseau comme une décision distincte

Le groupe VPN n’a pas besoin d’atteindre tous les ports. Lorsqu’un groupe a besoin d’une application et non d’un bureau, une règle de pare-feu limitée au pool de tunnels et au port de l’application donne effet à cette stratégie, tandis que le droit d’ouverture de session reste intact.

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

La configuration par client d’OpenVPN et les autorisations de groupe d’Access Server peuvent restreindre les préfixes de destination dans le même esprit ; ni l’une ni les autres n’accordent un droit d’ouverture de session Windows, et un droit d’ouverture de session ne peut pas ouvrir un port. Gardez-les dans des fenêtres de changement distinctes, car une règle de port et un droit sont approuvés par des personnes différentes.

Vérifiez dans l’ordre où les portes s’appliquent : le compte peut-il établir le tunnel, la session atteint-elle l’écouteur, le client s’authentifie-t-il et le compte détient-il le droit. Un ping qui échoue alors que le test de port réussit est un pare-feu qui répond différemment à ICMP, non la preuve que RDP est bloqué. La référence de Microsoft sur le droit d’ouverture de session répertorie les valeurs par défaut selon le rôle de la machine et la règle selon laquelle le refus l’emporte sur l’autorisation.