RDP sans exposer d'identifiants : RCG et Restricted Admin

Une connexion Bureau à distance classique envoie vos identifiants au serveur pour qu'il puisse ouvrir votre session et agir en votre nom. C'est ce qui permet l'authentification unique vers les partages de fichiers depuis la session. Cela signifie aussi qu'un administrateur qui se connecte à un serveur compromis laisse des identifiants réutilisables dans le LSASS de ce serveur : une empreinte NTLM, des tickets et des clés Kerberos. Pour un attaquant qui dispose déjà de l'admin local sur un serveur membre, attendre une connexion RDP privilégiée est l'un des moyens les plus fiables d'élever ses privilèges.

Deux fonctionnalités changent la donne. Le mode Restricted Admin ouvre votre session sans envoyer du tout d'identifiants réutilisables. Remote Credential Guard conserve les identifiants sur votre client et lui renvoie les requêtes Kerberos. Ce guide montre comment les activer des deux côtés, en imposer l'usage et vérifier qu'elles sont réellement en vigueur. Pour le volet transport du RDP (NLA, TLS, qui peut se connecter, exposition du port), voir le durcissement RDP.

Comparaison des modes

Remote Credential Guard est le meilleur choix par défaut pour les administrateurs. Restricted Admin est la solution de repli lorsque Kerberos n'est pas disponible ou que le client et le serveur ne sont pas dans des domaines liés par une approbation.

Les deux fonctionnalités complètent bien Credential Guard sur le serveur. Credential Guard rend les secrets plus difficiles à extraire de LSASS ; ces modes font en sorte que les secrets n'y soient jamais.

Étape 1 : autoriser les modes sur les serveurs

Les deux modes sont désactivés sur la cible par défaut. La valeur concernée est :

Key:   HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Value: DisableRestrictedAdmin  (REG_DWORD) = 0

La valeur 0 autorise les connexions entrantes Restricted Admin et Remote Credential Guard. Par stratégie de groupe, réglez Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Remote host allows delegation of non-exportable credentials sur Enabled sur chaque serveur et chaque cible d'administration. Ce paramètre écrit AllowProtectedCreds = 1 sous HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation et a le même effet pour les connexions entrantes.

Déployez-le avec la GPO que vous utilisez pour le durcissement des serveurs membres, et incluez les serveurs de rebond. Il n'y a aucun inconvénient côté serveur : un client qui ne demande pas ces modes se connecte toujours normalement.

Étape 2 : imposer les modes sur les clients d'administration

Autoriser ne suffit pas : c'est le client qui décide du mode demandé. Sur les postes d'administration sécurisés et les serveurs de rebond d'administration, réglez Computer Configuration > Policies > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers sur Enabled et choisissez un mode :

La stratégie écrit RestrictedRemoteAdministration = 1 et une valeur RestrictedRemoteAdministrationType sous HKLM\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation. Restrict Credential Delegation est le choix pragmatique pendant le déploiement : les administrateurs ne se connectent jamais en mode par défaut, et les serveurs qui ne prennent en charge que Restricted Admin fonctionnent toujours. Une fois que tous les serveurs prennent en charge Remote Credential Guard, passez à Require Remote Credential Guard.

Dans Intune, recherchez Credentials Delegation dans le catalogue de paramètres ; les paramètres client et serveur y sont exposés sous forme de stratégies basées sur ADMX.

Chaque administrateur peut aussi demander un mode par connexion, ce qui est utile pour les tests :

mstsc.exe /remoteGuard /v:srv-app01.corp.example
mstsc.exe /restrictedAdmin /v:srv-app01.corp.example

Étape 3 : vérifier les prérequis de Remote Credential Guard

Remote Credential Guard échoue avec des symptômes qui ressemblent à des erreurs RDP génériques. Les causes habituelles :

• Le client ne peut pas joindre de contrôleur de domaine. Les requêtes Kerberos sont renvoyées au client, qui doit alors voir un DC. Les administrateurs sur un VPN qui ne route pas vers les DC échoueront.
• La cible est désignée par son adresse IP. Kerberos a besoin d'un nom de principal de service ; connectez-vous par nom DNS.
• Identifiants enregistrés. Remote Credential Guard accepte les identifiants de la session ouverte ou ceux saisis à l'invite, mais pas ceux enregistrés dans Credential Manager. Ouvrir la session sur le PAW avec le compte d'administration du tier concerné reste de toute façon la conception la plus propre du modèle en tiers.
• Approbation. Le client et le serveur doivent être dans le même domaine ou dans des domaines liés par une approbation.
• Type de jonction et chemin de la cible. La cible doit être jointe à Active Directory ; Remote Credential Guard ne peut pas être utilisé vers des cibles jointes à Microsoft Entra (un client joint à Entra peut se connecter à un hôte joint à AD s'il peut obtenir des tickets Kerberos). Il ne fonctionne que pour les connexions directes, pas via Remote Desktop Connection Broker ou Remote Desktop Gateway.
• Application cliente. Il faut le client Bureau à distance Windows (mstsc.exe) ; l'application UWP Bureau à distance ne le prend pas en charge.

Étape 4 : réduire le risque lié à Restricted Admin

Restricted Admin comporte un compromis connu : il ouvre la session avec une authentification de type réseau, si bien que l'empreinte NTLM d'un administrateur suffit pour ouvrir une session RDP sur un serveur qui l'autorise. C'est la technique du « pass-the-hash via RDP ». Atténuez-la avec des contrôles que vous devriez déjà avoir :

• Placez les comptes d'administration humains dans Protected Users, qui leur refuse NTLM. Voir modèle en tiers et Protected Users.
• Utilisez les droits Deny log on through Remote Desktop Services du modèle en tiers pour que chaque compte d'administration ne puisse atteindre que son propre tier.
• Privilégiez Require Remote Credential Guard dès que vos serveurs le prennent en charge, puisqu'il exige Kerberos.

Étape 5 : supprimer les autres chemins de délégation d'identifiants

Le nœud de stratégie Credentials Delegation contrôle aussi CredSSP, qui par conception délègue des identifiants réutilisables. Examinez ces paramètres sur les clients :

• Allow delegating default credentials, Allow delegating saved credentials et Allow delegating fresh credentials : laissez-les non configurés sauf si un service précis en a besoin, et dans ce cas, limitez strictement la liste des serveurs (par exemple TERMSRV/rds-farm.corp.example, jamais TERMSRV/* ou *).
• Encryption Oracle Remediation : conservez Force Updated Clients afin que les points de terminaison CredSSP non corrigés soient refusés.

Activez aussi Do not allow passwords to be saved sous Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client, pour que les administrateurs ne conservent pas de mots de passe RDP dans Credential Manager. Le guide sur les identifiants en cache et WDigest couvre plus largement les paramètres liés aux identifiants stockés.

Ce qui casse

• L'accès en double saut sous Restricted Admin. Les partages de fichiers, SQL et les autres ressources sont atteints avec le compte ordinateur du serveur. Les scripts qui s'attendent à s'exécuter sous l'identité de l'administrateur échouent ou, pire, réussissent avec les permissions du serveur.
• Les identifiants RDP enregistrés, et les connexions via RD Gateway ou Connection Broker, avec Require Remote Credential Guard.
• Les connexions par adresse IP ou via des VPN sans accès aux DC avec Remote Credential Guard.
• Les utilisateurs RDP non administrateurs avec Restricted Admin, puisque ce mode exige l'admin local sur la cible.
• Certains clients RDP et gestionnaires de connexions tiers qui n'implémentent pas ces modes. Testez vos outils, y compris les passerelles web.

Vérifier

1. Sur le serveur. L'événement Security 4624 avec le Logon Type 10 (RemoteInteractive) contient un champ Restricted Admin Mode et, sur les builds récentes, un champ Remote Credential Guard. Pour les comptes privilégiés, l'un des deux doit indiquer Yes.
2. Dans la session. Exécutez klist. Avec Remote Credential Guard, vous obtenez toujours des tickets de service pour les ressources réseau sous votre identité ; avec Restricted Admin, l'accès réseau se fait avec le compte ordinateur.
3. Dérive de configuration. Vérifiez DisableRestrictedAdmin sur les serveurs et RestrictedRemoteAdministrationType sur les clients d'administration via un script de conformité.

Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4624} -MaxEvents 200 |
  Where-Object { $_.Properties[8].Value -eq 10 } |
  Select-Object TimeCreated, @{n="User";e={$_.Properties[5].Value}}, Message -First 20

Recherchez les comptes privilégiés avec Restricted Admin Mode: No et Remote Credential Guard: No. Ce sont les connexions qui ont laissé des identifiants derrière elles.

Liste de contrôle

• DisableRestrictedAdmin = 0 (ou « Remote host allows delegation of non-exportable credentials ») sur tous les serveurs
• PAW et serveurs de rebond réglés sur Restrict Credential Delegation, puis Require Remote Credential Guard
• Les administrateurs ouvrent leur session sur le PAW avec le compte d'administration du tier et se connectent par nom DNS
• Comptes d'administration dans Protected Users pour fermer le pass-the-hash via Restricted Admin
• Délégation CredSSP des identifiants par défaut et enregistrés non configurée ou strictement limitée
• Client RDP non autorisé à enregistrer les mots de passe
• Événements 4624 de type 10 examinés pour repérer les connexions privilégiées sans aucun des deux modes

C'est l'un des moyens les moins coûteux d'empêcher un attaquant présent sur un serveur Tier 1 de récolter des identifiants d'administration. Il a sa place dans la série Protection des identifiants, aux côtés de l'entrée Remote Credential Guard du glossaire.