RDP Windows Server : éviter la double saisie d’identifiants avec CredSSP (SSO MMC, ADUC, UAC)

Marre de retaper votre mot de passe après une session RDP ? Voici une méthode robuste et approuvée pour que la console Active Directory (et autres MMC) réutilise automatiquement les identifiants de la session RDP, tout en gardant la maîtrise des risques.

Éviter la double saisie d’identifiants sur un serveur Windows après connexion RDP

Problématique

Après s’être connecté à un serveur Windows par RDP avec un compte A, l’administrateur est de nouveau invité à saisir des identifiants lorsqu’il ouvre la console Active Directory ou tout autre outil nécessitant des privilèges élevés. Il souhaite que le serveur réemploie automatiquement les informations d’authentification utilisées pour la session RDP.

Pourquoi ce double prompt apparaît-il ?

Deux mécanismes se combinent :

• UAC (User Account Control) sépare les jetons standard et élevé : lorsqu’un outil d’administration (MMC, PowerShell, etc.) demande une élévation, il peut requérir des informations d’identification si le contexte ne permet pas de « relayer » le jeton en toute sécurité.
• Négociation d’authentification RDP : selon que la session a obtenu un jeton via CredSSP, Kerberos ou NTLM, la capacité à réutiliser les identifiants diffère. Sans délégation explicite, beaucoup de consoles exigent un nouvel input.

La bonne nouvelle : CredSSP permet au client RDP de déléguer en toute sécurité les informations d’identification au serveur afin que les processus locaux élevés (MMC, ADUC, DNS, GPMC…) les réutilisent automatiquement.

Solutions proposées (vue d’ensemble)

Approche	Principe	Mise en œuvre (résumé)	Points d’attention
CredSSP (Credential Security Support Provider) – délégation expresse	Le client chiffre et délègue les informations d’identification au serveur, qui peut ensuite les présenter aux processus lancés localement.	1. Sur le client RDP : • Activer « Allow delegating default credentials » (et éventuellement « … with NTLM‑only server authentication ») dans les stratégies de groupe locales ou via gpedit.msc. • Ou ajouter dans le fichier .rdp : enablecredsspsupport:i:1. 2. Sur le serveur : CredSSP est activé par défaut à partir de Windows Server 2008 R2 ; sinon, vérifier la clé HKLM\System\CurrentControlSet\Control\Lsa\CredSSP\PolicyDefaults. 3. Établir la session RDP : les outils d’administration lancés dans cette session réutiliseront automatiquement les identifiants.	Fonctionne même avec un compte différent de celui du poste local. Accroît la surface d’attaque en cas de compromission du serveur : les identifiants délégués peuvent être réutilisés.
Authentification unique Kerberos (SSO)	Si le compte RDP appartient au même domaine que le serveur et si le poste client est joint au domaine, Kerberos peut fournir un SSO complet.	Utiliser le même compte AD pour ouvrir la session Windows locale et la session RDP, ou activer la « délégation contraignante Kerberos ».	Exige que poste et serveur soient dans le même domaine et que l’horloge soit synchronisée. Ne s’applique pas au scénario décrit (compte différent sur le poste).
Mode « Restricted Admin » ou « Remote Credential Guard »	Les identifiants ne sont jamais envoyés sur le serveur ; celui‑ci obtient uniquement un jeton réseau Kerberos.	Ajouter enablecredsspsupport:i:0 et restrictedadmin:i:1 (ou activer Remote Credential Guard).	Évite la fuite d’identifiants, mais certaines applications locales (dont la console AD) refusent ce mode faute de jeton d’ouverture de session interactif.
runas /savecred (déconseillé)	Stocke le mot de passe chiffré localement et le rejoue.	runas /savecred /user:DOMAINE\Compte cmd puis lancer la MMC.	Contournement ponctuel, non centralisé, peu sûr.

Recommandation pratique

1. Activer CredSSP des deux côtés ; c’est la méthode officiellement documentée par Microsoft et compatible avec les consoles MMC.
2. Limiter la portée via la liste Delegation of credentials to specified servers pour restreindre la délégation aux hôtes concernés uniquement.
3. Informer les administrateurs des implications de sécurité : avec CredSSP, un attaquant qui compromet le serveur peut réutiliser les identifiants délégués jusqu’à expiration du ticket.

Mise en œuvre pas à pas de CredSSP (méthode recommandée)

Prérequis

• Versions : CredSSP est disponible nativement à partir de Windows Vista et Windows Server 2008.
• NLA (Network Level Authentication) recommandé sur le serveur RDP.
• Compte RDP du domaine, même si le poste client est hors domaine (possible via « NTLM‑only server authentication »).
• Synchronisation horaire correcte (NTP), et résolution DNS fonctionnelle.

Configuration côté client (poste d’administration)

Méthode via Stratégie de groupe locale

1. Ouvrez gpedit.msc.
2. Allez dans Configuration ordinateur → Modèles d’administration → Système → Délégation d’informations d’identification (Credentials Delegation).
3. Activez Allow delegating default credentials, puis cliquez sur Afficher et ajoutez TERMSRV/nom‑serveur ou TERMSRV/* (plus restrictif : listez précisément vos hôtes).
4. Si le serveur ou le poste n’est pas joint au domaine, activez aussi Allow delegating default credentials with NTLM‑only server authentication et renseignez la même liste (TERMSRV/…).
5. Appliquez la stratégie et lancez gpupdate /force.

Méthode via GPO de domaine

1. Créez (ou éditez) une GPO appliquée au groupe de postes d’administration.
2. Renseignez les mêmes paramètres dans Computer Configuration → Administrative Templates → System → Credentials Delegation.
3. Inscrivez explicitement les serveurs autorisés (TERMSRV/ServeurAD01, TERMSRV/ServeurDNS02, etc.).
4. Vérifiez l’application via gpresult /h c:\temp\gp.html sur un poste cible.

Option via fichier .rdp

Si vous distribuez des fichiers RDP, vous pouvez forcer le support CredSSP :

enablecredsspsupport:i:1
full address:s:ServeurAD01.contoso.com

Placez le fichier sur le bureau des administrateurs (ou publiez‑le via un portail), et connectez‑vous en utilisant ce raccourci.

Configuration côté serveur

• Sur Windows Server 2008 R2 et ultérieurs, CredSSP côté serveur est présent par défaut. Assurez‑vous que RDP est configuré avec NLA : SystemPropertiesRemote.exe → « Autoriser les connexions uniquement à partir des ordinateurs exécutant Bureau à distance avec authentification au niveau du réseau ».
• Contrôlez que le service TermService (Services Bureau à distance) est démarré et que le port 3389/TCP est ouvert dans le pare‑feu.
• Facultatif : vérifiez la présence/valeurs de HKLM\System\CurrentControlSet\Control\Lsa\CredSSP\PolicyDefaults si vous avez des durcissements atypiques.

Validation du SSO pour les consoles d’administration

1. Purgez les tickets sur le client (si vous testez Kerberos) : klist purge.
2. Ouvrez la session RDP avec les identifiants du compte d’administration cible.
3. Lancez une console MMC (ex. dsa.msc pour ADUC) en Exécuter en tant qu’administrateur. Aucun prompt d’identification supplémentaire ne doit apparaître.
4. Contrôlez les journaux sur le serveur : Événements 4624/4634 (Logon/Logoff) et, si un prompt est apparu malgré tout, un 4648 (logon with explicit credentials).
5. Vérifiez le type de connexion : whoami /groups doit indiquer un contexte Remote Interactive et l’appartenance aux groupes administratifs attendus.

Durcissement et bonnes pratiques

• Liste blanche stricte : préférez TERMSRV/ServeurN plutôt que TERMSRV/*.
• Postes d’admin dédiés (PAW) : limitez la GPO aux machines d’administration durcies.
• Rotation des comptes : combinez avec LAPS/ICA (ou équivalent) pour réduire la fenêtre d’exposition.
• Journalisation : surveillez 4624/4634/4648 et corrélez avec vos connexions RDP.

Alternatives : quand et comment les utiliser

SSO Kerberos « pur »

Si le poste client et le serveur sont joint au même domaine et que l’administrateur ouvre sa session locale Windows avec le même compte AD, le SSO Kerberos rend souvent inutile la délégation CredSSP. Dans les environnements plus segmentés, la délégation Kerberos contraignante (KCD, y compris la KCD resource‑based) peut être envisagée, mais elle demande une ingénierie d’annuaires et des enregistrements SPN précis ; hors‑scope pour un besoin de type « admin RDP vers serveur ».

Restricted Admin et Remote Credential Guard

Ces modes empêchent l’envoi des identifiants au serveur RDP : seul un jeton réseau est utilisé, ce qui réduit fortement le risque de réutilisation en cas de compromission du serveur intermédiaire. En contrepartie, certaines consoles (dont ADUC) exigent un jeton interactif et refuseront de fonctionner.

• Restricted Admin : ajoutez dans le fichier RDP restrictedadmin:i:1 (et enablecredsspsupport:i:0). Efficace pour des actions scriptées ou outils compatibles, mais pas recommandé si votre cible est une MMC classique.
• Remote Credential Guard : idéal lorsque c’est supporté de bout en bout (Windows 10/11 et Server récents), mais même limitation : les MMC qui exigent un jeton interactif complet peuvent échouer.

runas /savecred (déconseillé)

Permet d’éviter des prompts ponctuels en stockant un secret chiffré localement. C’est un contournement fragile, difficile à gouverner, et qui ne passe pas les audits exigeants.

runas /savecred /user:DOMAINE\Compte "mmc.exe %SystemRoot%\system32\dsa.msc"

Pour purger ces secrets : control /name Microsoft.CredentialManager ou cmdkey /list puis cmdkey /delete:<cible>.

Dépannage : check‑list des cas courants

Symptôme	Cause probable	Correctif
Un prompt d’identification réapparaît à l’ouverture d’ADUC	La délégation n’est pas autorisée pour ce serveur	Ajoutez TERMSRV/ServeurAD01 dans « Allow delegating default credentials » (client), puis gpupdate /force
Le serveur n’accepte pas la délégation	NLA désactivé, ou durcissement LSA particulier	Activez NLA côté serveur, vérifiez la clé CredSSP, redémarrez le service RDP
Fonctionne avec un poste A mais pas B	La GPO ne s’applique pas au poste B	gpresult /h c:\temp\gp.html et corrigez la portée/sécurité de la GPO
Environnement hors domaine (workgroup)	Kerberos indisponible	Activez « Allow delegating default credentials with NTLM‑only server authentication » côté client
Les MMC se ferment ou refusent l’accès en Restricted Admin	Jeton non interactif	Utilisez CredSSP au lieu de Restricted Admin/RCG pour ces consoles
Prompt uniquement lors du clic « Exécuter en tant qu’administrateur »	UAC et absence de jeton délégué réutilisable	Confirmez CredSSP côté client et côté serveur, relancez la session RDP

Commandes utiles

:: Diagnostiquer les stratégies effectives
gpresult /h C:\temp\gp.html

\:: Vérifier l’identité et les groupes
whoami /user
whoami /groups

\:: Tickets Kerberos
klist

\:: Événements de logon
wevtutil qe Security /q:"\*\[System\[(EventID=4624 or EventID=4634 or EventID=4648)]]" /c:10 /f\:text /rd\:true 

Modèle d’implémentation « clé en main »

Objectif

Obtenir un SSO pour MMC/PowerShell lancé en élevé sur les serveurs d’administration, en réutilisant les identifiants fournis à la session RDP, y compris lorsque le poste client n’est pas joint au domaine.

Étapes consolidées

1. Client : activer Allow delegating default credentials et, si nécessaire, …with NTLM‑only server authentication, en listant TERMSRV/Serveur*.
2. Serveur : activer NLA, vérifier les services RDP.
3. Raccourci .rdp : forcer enablecredsspsupport:i:1.
4. Test : connexion RDP → ouverture de dsa.msc en élevé → aucun prompt supplémentaire.
5. Durcissement : restreindre la liste, surveiller 4624/4634, documenter les postes autorisés.

Notes et rappels importants

• Version minimale : CredSSP est disponible nativement à partir de Windows Vista/Server 2008.
• UAC : si l’UAC est activé, les outils d’administration lancés avec élévation (Run as administrator) héritent malgré tout des identifiants grâce à CredSSP.
• Audit : activer la journalisation des événements 4624/4634 (Logon/Logoff) pour surveiller l’utilisation de la délégation d’informations d’identification.
• Comptes séparés : l’approche est parfaitement compatible avec l’usage de comptes d’administration dédiés distincts du compte utilisateur du poste.
• Mac/Linux en client RDP : les clients Microsoft RDP modernes supportent CredSSP et NLA ; assurez‑vous d’utiliser une version à jour et un fichier .rdp cohérent.

FAQ pratique

Faut‑il désactiver UAC pour éviter le prompt ?

Non. UAC renforce la sécurité. Avec CredSSP correctement configuré, les MMC élevées n’exigeront plus de resaisir les identifiants, tout en conservant les protections UAC.

La délégation CredSSP expose‑t‑elle mon mot de passe au serveur ?

Les informations d’identification sont protégées en transit et ne sont réutilisables que par le serveur cible pendant la durée de vie du contexte. Néanmoins, si ce serveur est compromis, l’attaquant peut tenter d’abuser de ces identifiants : d’où l’importance de limiter la liste TERMSRV/…, d’auditer et de durcir les serveurs d’admin.

Kerberos ou NTLM ?

Privilégiez Kerberos quand poste et serveur sont dans le même domaine (meilleure sécurité et audit). Utilisez l’option « with NTLM‑only server authentication » uniquement si vous devez gérer du hors domaine.

Peut‑on imposer la délégation uniquement pour certains serveurs ?

Oui : c’est même recommandé. Remplissez la liste des serveurs autorisés (TERMSRV/NomServeur) et évitez le joker * sauf pour les environnements de lab.

Exemple complet de configuration documentée

Le scénario suivant illustre une configuration réaliste couvrant Active Directory, DNS et fichiers.

Élément	Paramètre / Action	Détail
Poste d’admin	Allow delegating default credentials	Valeurs : TERMSRV/AD‑PRD‑01, TERMSRV/DNS‑PRD‑01, TERMSRV/FS‑PRD‑01
Poste d’admin	Allow delegating default credentials with NTLM‑only server authentication	Uniquement si des serveurs ne sont pas rejoints au domaine
Serveurs	NLA	Cocher l’option NLA dans les propriétés Système > Bureau à distance
Fichier .rdp	enablecredsspsupport	enablecredsspsupport:i:1
Audit	Événements 4624/4634	Surveillance des connexions et déconnexions avec corrélation RDP

Modèles d’équipe et gouvernance

Pour des équipes d’administration nombreuses, standardisez :

• Une GPO « Admin‑RDP‑CredSSP » liée aux OU des PAW (postes d’admin), contenant la liste blanche TERMSRV/….
• Un jeu de fichiers .rdp signés ou contrôlés, nommés par rôle (AD‑Admin.rdp, DNS‑Admin.rdp…).
• Un guide de secours (mode dégradé) décrivant le basculement temporaire en Restricted Admin/RCG pour opérations en lecture seule.
• Des contrôles périodiques : revue trimestrielle de la liste des serveurs autorisés, tests d’audit sur 4624/4634/4648.

Conclusion

La double saisie d’identifiants après connexion RDP n’est pas une fatalité. En activant CredSSP sur le client et en s’assurant d’un serveur configuré pour NLA, vous obtenez un SSO fluide pour les consoles d’administration (ADUC, DNS, GPMC, etc.), sans sacrifier la sécurité. Combinez cette mise en œuvre avec une liste blanche stricte, une bonne hygiène d’audit et des postes dédiés pour un résultat propre, reproductible et conforme aux bonnes pratiques.