Authentification RDP au niveau réseau, mode Admin restreint, Active Directory : les trois paramètres qui décident qui possède votre session

Chaque checklist de durcissement Remote Desktop se termine par les trois mêmes points : authentification RDP au niveau réseau, mode Admin restreint, Active Directory — identifiants mis en cache. Cocher les trois cases ne rend pas pour autant une session Remote Desktop sûre. Deux de ces contrôles sont de vraies avancées défensives, et le troisième — le mode Admin restreint — protège les identifiants que vous saisissez tout en offrant à un attaquant qui possède déjà un hash un moyen d’entrer.

Cet article distingue les trois paramètres, montre comment ils se contraignent mutuellement, et donne les valeurs de registre, les chemins de Group Policy et les champs d’événements nécessaires pour auditer chacun d’eux.

Authentification RDP au niveau réseau, mode Admin restreint, Active Directory : les trois décisions du durcissement

Une connexion Remote Desktop vers un hôte joint au domaine implique trois décisions indépendantes, chacune configurée à un endroit différent :

1. L’authentification au niveau réseau (NLA) — l’utilisateur est-il authentifié avant l’établissement de la session ?
2. La couche de sécurité — comment le canal lui-même est-il authentifié et chiffré ?
3. Le mode de délégation des identifiants — le client envoie-t-il ses identifiants à l’hôte distant, tout court ?

Un quatrième paramètre, le nombre de connexions mises en cache, décide de la quantité d’identifiants laissée sur l’hôte par la suite. La plupart des outils d’audit rapportent ces éléments comme quatre cases à cocher indépendantes. En pratique, ils interagissent : choisir la mauvaise couche de sécurité désactive silencieusement NLA, et activer le mode de délégation « sûr » change ce dont un attaquant a besoin pour se connecter.

La couche de sécurité vient en premier

Les trois couches de sécurité

Microsoft documente trois couches de sécurité pour une connexion RD Session Host. La distinction compte plus qu’il n’y paraît, car l’une des trois est mutuellement exclusive avec NLA :

Cette dernière phrase est de Microsoft, tirée de Configure Server Authentication and Encryption Levels. C’est la raison pour laquelle un hôte peut porter une politique « NLA requis » sans que NLA soit réellement en jeu : lorsque la couche négociée retombe sur le chiffrement RDP natif, l’exclusion propre de Microsoft s’applique et l’authentification au niveau réseau ne peut pas être utilisée.

Le fait que Negotiate soit la valeur par défaut est le problème silencieux, et ce n’est pas un artefact hérité du passé : la référence SecurityLayer actuelle de Microsoft documente toujours 1 (negotiate) comme « la valeur par défaut ». Elle n’impose pas TLS — elle accepte ce que le client propose et redescend vers la couche de sécurité RDP pour un client qui prétend ne pas supporter TLS. Un attaquant qui contrôle le côté client de la négociation contrôle ce choix.

Niveaux de chiffrement

Un paramètre distinct, le niveau de chiffrement, régit la force des clés. Microsoft liste quatre valeurs, avec Client Compatible comme valeur par défaut :

Low mérite d’être énoncé clairement : il laisse le trafic serveur-vers-client — le contenu de l’écran d’une session administrative — en clair.

Tous ces paramètres se trouvent sous Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security, et Microsoft précise que ces paramètres de Group Policy « prennent le pas sur les paramètres configurés dans Remote Desktop Session Host Configuration, à l’exception du paramètre de politique Server Authentication Certificate Template ».

Pourquoi l’authentification au niveau réseau compte

NLA avance l’authentification de l’utilisateur avant l’établissement de la session. La description d’origine de Microsoft reste la plus claire : elle « termine l’authentification de l’utilisateur avant que vous n’établissiez une connexion Remote Desktop et que l’écran de connexion n’apparaisse », et les avantages énoncés sont que l’ordinateur distant « utilise un nombre limité de ressources avant d’authentifier l’utilisateur » et que cela « peut aider à améliorer la sécurité en réduisant le risque d’attaques par déni de service » (Configure Network Level Authentication).

La valeur de cette barrière de pré-authentification n’est pas théorique. Dans les contournements publiés avec son avis pour CVE-2019-0708, la vulnérabilité d’exécution de code à distance pré-authentification de Remote Desktop Services communément appelée BlueKeep, Microsoft écrivait :

NLA a transformé un bug pré-authentification exploitable en ver en un bug post-authentification. C’est tout l’argument en faveur de son activation obligatoire — cela place chaque future vulnérabilité RDP pré-authentification derrière une vérification d’identifiants.

Le paramètre côté hôte est une simple valeur de registre :

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication

1 exige NLA, 0 le désactive. La documentation Microsoft de dépannage des VM Azure utilise exactement cette valeur pour désactiver puis réactiver temporairement NLA — ce qui explique aussi pourquoi il arrive qu’elle soit désactivée définitivement pendant un incident, et jamais réactivée.

Le mode Admin restreint : le contrôle à double tranchant

Le mode Admin restreint change ce que le client envoie. La documentation Remote Credential Guard de Microsoft liste précisément ses bénéfices en matière de sécurité :

• Les identifiants ne sont pas envoyés à l’hôte distant
• La session Remote Desktop se connecte aux autres ressources sous l’identité de l’hôte distant
• Un attaquant ne peut pas agir au nom de l’utilisateur, et toute attaque reste locale au serveur

Le tableau comparatif de Microsoft indique que le mode Admin restreint empêche le Pass-the-Hash, et pour les scénarios de support technique il le recommande explicitement : « les connexions RDP ne devraient être initiées qu’avec le commutateur /RestrictedAdmin ». Notez aussi que l’accès RDP en mode Admin restreint est accordé par l’appartenance au groupe Administrators sur l’hôte distant, et non au groupe Remote Desktop Users.

Le mode lui-même et Remote Credential Guard dépendent tous deux d’une seule valeur côté hôte :

reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

L’inversion

C’est ici que les deux lectures divergent, et la distinction est directionnelle.

L’affirmation de Microsoft porte sur les identifiants qui quittent le client : avec le mode Admin restreint, rien n’atterrit sur l’hôte distant, donc rien ne peut y être récupéré puis rejoué. C’est vrai.

La conséquence porte sur les identifiants qui entrent sur l’hôte. Comme le client n’envoie plus de mot de passe, la connexion est satisfaite avec des identifiants que le client possède déjà — ce qui signifie qu’un hash NTLM suffit. Une recherche publique a documenté cela l’année même où la fonctionnalité a été livrée. Portcullis Labs (auteur MRL, 20 octobre 2013) a décrit le client envoyant des « empty credentials in the TSPasswordCreds structure » sur Windows 8.1 et Windows Server 2012 R2, et a démontré l’authentification en passant un hash à la place du mot de passe. Leur preuve de concept n’était pas un client standard : elle nécessitait FreeRDP-pth, une version patchée de FreeRDP dont l’argument -p porte un hash NT au lieu d’un mot de passe.

# FreeRDP-pth, le client patché de 2013 — -p porte le hash NT
xfreerdp -u test -p 36374BD2767773A2DD4F6B010EC5EE0D 192.168.226.129

Un client standard n’acceptera pas cela : il traite le hash comme un mot de passe en clair et la connexion échoue. FreeRDP actuel implémente cette capacité nativement, avec l’option documentée comme « Pass the hash (restricted admin mode) » :

xfreerdp3 /u:test /pth:36374BD2767773A2DD4F6B010EC5EE0D /v:192.168.226.129

Le même billet précise que la technique ne fonctionne que pour les administrateurs — les membres du groupe Remote Desktop Users ne peuvent pas s’authentifier de cette manière. Avec le client Windows natif, l’équivalent consiste à injecter d’abord le hash dans une session de connexion :

sekurlsa::pth /user:Administrator /domain:CORP /ntlm:<hash> /run:"mstsc.exe /restrictedadmin"

Les deux affirmations tiennent donc en même temps. Le mode Admin restreint empêche vos identifiants d’être volés depuis l’hôte distant, et il abaisse la barrière pour se connecter à cet hôte, la faisant passer d’un mot de passe en clair à un simple hash. Si le pass-the-hash est déjà viable dans votre environnement, activer le mode Admin restreint à l’échelle du domaine l’étend à l’accès RDP interactif sur chaque hôte où il est activé.

Il y a une seconde conséquence. Comme l’authentification est évaluée sur un jeton plutôt que sur un mot de passe saisi, les contrôles appliqués à la destination peuvent être contournés. SpiderLabs (Apurva Goenka, 15 novembre 2023 — publié sous Trustwave, depuis rachetée par LevelBlue) a documenté que l’authentification « ne se déroule pas sur le serveur Remote Desktop mais sur le client lui-même », de sorte que « les facteurs d’authentification appliqués sur le serveur de destination comme MFA via Duo, Okta... sont rendus inefficaces » (Restricted Admin Mode – Circumventing MFA On RDP Logons).

Connexions mises en cache : ce qui reste sur place

Les identifiants de domaine mis en cache permettent à un utilisateur de se connecter quand aucun contrôleur de domaine n’est joignable. La documentation Microsoft sur Interactive logon: Number of previous logons to cache (in case domain controller is not available) énonce le risque directement : « Un attaquant capable d’accéder au système de fichiers du serveur pourrait localiser cette information mise en cache et l’utiliser dans une attaque par force brute pour tenter de déterminer les mots de passe des utilisateurs. » L’information mise en cache « n’expire pas, mais peut être écrasée ».

La valeur par défaut est de 10 connexions sur les serveurs membres et les postes clients, et la plage acceptée va de 0 à 50. Le tableau des valeurs par défaut de Microsoft indique que la valeur effective par défaut sur un contrôleur de domaine est Sans effet — le paramètre ne s’applique tout simplement pas là.

Il faut citer cette recommandation avec prudence, car la page de Microsoft elle-même n’est pas univoque. Sa section Countermeasure indique de configurer la valeur à 0, désactivant la mise en cache locale. Sa section Best practices indique que les baselines de sécurité Windows « ne recommandent pas de configurer ce paramètre » du tout. Sa section Potential impact suggère 2 pour les postes utilisateurs finaux, afin que les utilisateurs mobiles puissent quand même se connecter hors réseau. La position défendable pour un serveur membre Tier 0 est une valeur basse ; pour les ordinateurs portables, 0 casse entièrement la connexion hors ligne. Une nuance régulièrement mal comprise : ce paramètre ne s’applique pas aux contrôleurs de domaine, dont la valeur effective par défaut est listée par Microsoft comme « Sans effet » — les DC hébergent l’annuaire et ne mettent pas en cache les connexions de domaine.

Détection

L’événement 4624 porte les champs nécessaires pour distinguer ces connexions. La version 2 de l’événement (Windows 10 et versions ultérieures) a ajouté un champ RestrictedAdminMode, qui, selon Microsoft, n’est « peuplé que pour les sessions de connexion de type RemoteInteractive » et constitue un indicateur Oui/Non signalant si le mode Admin restreint a été utilisé.

Ce détail compte pour écrire une règle correcte : une session RDP en mode Admin restreint reste Logon Type 10 (RemoteInteractive), pas Type 3. Le mode est visible dans le drapeau, pas dans le type de connexion.

La recommandation de supervision de Microsoft sur cette même page mérite d’être reprise telle quelle : si le mode Admin restreint doit être utilisé par certains comptes, surveillez les connexions de ces comptes avec Logon Type = 10 et Restricted Admin Mode = « Yes », et déclenchez une alerte quand Restricted Admin Mode = « No » pour eux. L’inverser est tout aussi utile — alerter quand RestrictedAdminMode = « Yes » pour des comptes qui ne devraient jamais l’utiliser, puisque les outils d’attaquants recherchent précisément /restrictedadmin parce qu’il accepte un hash.

Auditer la configuration

Auditer la configuration elle-même consiste en une lecture de registre sur chaque hôte :

$ts = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp"
Get-ItemProperty -Path $ts -Name UserAuthentication, SecurityLayer, MinEncryptionLevel
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name DisableRestrictedAdmin -ErrorAction SilentlyContinue

L’absence de la valeur DisableRestrictedAdmin signifie que le mode n’est pas activé ; une valeur de 0 signifie qu’il l’est.

Remédiation

1. Exiger TLS comme couche de sécurité. Activez Require use of specific security layer for remote (RDP) connections et sélectionnez SSL, sous Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security. Émettez les certificats RD Session Host depuis votre autorité de certification interne plutôt que d’accepter le certificat autosigné par défaut.

2. Exiger NLA. Dans le même chemin de politique, activez Require user authentication for remote connections by using Network Level Authentication. Group Policy prend le pas sur la configuration locale, ce qui est exactement ce que vous voulez pour maîtriser la dérive de configuration.

3. Relever le niveau de chiffrement. Configurez Set client connection encryption level sur High afin que le trafic soit en 128 bits dans les deux sens, et confirmez qu’aucun hôte n’est resté à Low.

4. Décider du mode Admin restreint de manière délibérée, par tier. Ne l’activez pas à l’échelle du domaine par réflexe. Là où des administrateurs se connectent à des hôtes de moindre confiance, privilégiez Remote Credential Guard via la politique Restrict delegation of credentials to remote servers configurée sur Require Remote Credential Guard. Là où il est réellement nécessaire pour le support technique, activez-le uniquement sur ces hôtes et alertez sur son usage ailleurs. Notez la précision de Microsoft : quand Restrict Credential Delegation est activé, « le commutateur /restrictedAdmin sera ignoré » et Remote Credential Guard est utilisé à la place.

5. Activer la délégation d’identifiants non exportables sur les hôtes distants — requis à la fois pour le mode Admin restreint et pour Remote Credential Guard — via Remote host allows delegation of nonexportable credentials.

6. Réduire les connexions mises en cache sur les serveurs. Configurez Interactive logon: Number of previous logons to cache sur une valeur basse sous Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Validez cela vis-à-vis de vos besoins de connexion hors ligne avant de l’appliquer aux ordinateurs portables.

7. Déployer LAPS. Microsoft associe sa recommandation sur le mode Admin restreint à Windows LAPS, qui « atténue le risque d’escalade latérale » lié aux mots de passe administrateur local partagés — exactement la condition qui rend un seul hash volé exploitable sur chaque hôte.

Vérifier le résultat

Vérifiez le résultat plutôt que de faire confiance au rapport GPO :

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" |
    Select-Object UserAuthentication, SecurityLayer, MinEncryptionLevel

UserAuthentication doit valoir 1 et SecurityLayer doit valoir 2 (TLS).

Ces contrôles se renforcent mutuellement avec le reste de votre durcissement de l’authentification — exiger TLS sur RDP relève du même raisonnement que d’exiger la signature SMB et la signature LDAP sur les chemins de relay NTLM, et contraindre qui peut atteindre Tier 0 via RDP est indissociable de la maîtrise de la délégation Kerberos et de la politique de mots de passe.

Comment EtcSec détecte cela

EtcSec audite ces quatre paramètres indépendamment, car ils échouent indépendamment. PA038_RDP_NLA_NOT_REQUIRED remonte un finding quand aucune GPO du domaine ne configure UserAuthentication à 1. PA038_RDP_SECURITY_LAYER_WEAK se déclenche à moins qu’une politique n’impose la couche de sécurité TLS, de sorte que la valeur par défaut Negotiate, qui peut redescendre silencieusement, est également remontée. TERMINAL_SERVICES_NOT_HARDENED couvre la surface plus large de configuration de Terminal Services et RDP, et CACHED_LOGONS_EXCESSIVE se déclenche quand Winlogon\CachedLogonsCount dépasse 4. Ce sont des contrôles au niveau politique : un résultat propre signifie que la politique existe, et confirmer qu’elle est réellement appliquée sur chaque hôte reste la lecture de registre ci-dessus.