Après installation de Remote Desktop Services sur Windows Server 2022, vos utilisateurs du domaine n’arrivent plus à ouvrir des sessions RDP vers d’autres serveurs alors que les comptes locaux y parviennent ? Suivez ce guide concret pour diagnostiquer et corriger rapidement.
Contexte
Scénario fréquent en lab ou en production : vous avez déployé un serveur Windows Server 2022 (édition d’évaluation ou non) avec le rôle Remote Desktop Services (RDS). Les connexions entrantes fonctionnent : les utilisateurs du domaine se connectent sans souci au serveur RDS. En revanche, dès qu’ils tentent depuis ce serveur RDS d’initier une connexion sortante vers d’autres hôtes du domaine (contrôleurs de domaine, serveurs applicatifs, fichiers, etc.), la connexion échoue. Problème paradoxal : les comptes locaux (ex. . \Administrateur du serveur cible) parviennent à se connecter.
Ce différentiel indique généralement une combinaison de droits d’ouverture de session à distance, de stratégie NLA/CredSSP, et/ou d’un mauvais paramétrage de la licence RDS qui ne se manifeste que dans certaines conditions (notamment si l’on n’utilise pas le commutateur /admin côté client RDP).
Symptômes et messages d’erreur typiques
- Boîte de dialogue RDP : « L’authentification demandée n’a pas abouti » ou « Votre session a pris fin ».
- Message CredSSP : « This could be due to CredSSP encryption oracle remediation ».
- Échec immédiat après saisie des identifiants de domaine, alors que le même compte local passe.
- Journal Sécurité (ID 4625, type de connexion 10 = RemoteInteractive) avec le statut
0xC000015B(logon type not granted → l’utilisateur n’a pas le droit demandé sur la cible).
Causes probables
- Licences RDS absentes ou mal configurées
Serveur de licences non activé, pas de RDS CAL valides (par utilisateur ou par appareil), ou mode de licence incohérent. Dans certains contextes, les connexions avecmstsc /admin(mode administration) réussissent, tandis que les connexions « standard » (soumise à CAL) échouent pour les comptes du domaine. - Droits d’ouverture de session à distance insuffisants
Les comptes du domaine ne figurent pas dans la stratégie « Allow log on through Remote Desktop Services » (SeRemoteInteractiveLogonRight) de la machine cible, ou sont inclus (directement ou via un groupe) dans la stratégie inverse « Deny log on through Remote Desktop Services ». - Problème d’authentification réseau (NLA) / CredSSP
La cible exige la NLA mais une stratégie de délégation d’identifiants, une incohérence TLS/certificat, l’Oracle d’Exploit CredSSP, ou une restriction NTLM empêche la négociation. Les comptes locaux utilisés différemment (ex. saisie.\Admin) peuvent contourner le point bloquant. - Filtrage réseau / pare‑feu
Port TCP 3389 filtré entre le serveur RDS et la cible, ou profil de pare‑feu (Domaine/Privé/Public) mal aligné. - Décalage d’horloge / Kerberos
Un écart de temps entre hôtes (Skew) empêche l’authentification Kerberos requise par la NLA.
Plan de remédiation rapide (vue d’ensemble)
| Étape | Action | Détails |
|---|---|---|
| 1 | Vérifier / configurer le serveur de licences RDS | Via le Gestionnaire de serveur → Remote Desktop Services → Overview. Activer le serveur de licences, installer les RDS CAL (Per User ou Per Device). Tester une connexion mstsc /admin pour isoler un souci de CAL. |
| 2 | Accorder le droit « Allow log on through RDS » | GPO ou stratégie locale : Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment → Allow log on through Remote Desktop Services. Ajouter un groupe AD dédié (éviter « Domain Users » trop large). Vérifier aussi « Deny log on… ». |
| 3 | Contrôler / tester NLA & CredSSP | Sur chaque cible : System Properties → Remote, activer RDP. Désactiver NLA temporairement pour un test. Si l’échec disparaît : vérifier certificats, délégation d’identifiants, Oracle CredSSP, politiques NTLM/TLS. |
| 4 | Vérifier pare‑feu & ports | Confirmer l’ouverture du TCP 3389 entre RDS et les cibles. Activer la règle intégrée « Remote Desktop (TCP‑In) » pour les bons profils. Test rapide avec Test-NetConnection. |
| 5 | Mettre à jour & redémarrer | Appliquer les mises à jour cumulatives Windows Server 2022 sur toutes les machines impliquées. Redémarrer après modification de GPO/droits/licences. |
Procédure détaillée pas à pas
Vérifier et configurer le licensing RDS
Un RD Session Host sans licence valide bascule sur une période de grâce (en général 120 jours). Si le serveur héberge des sessions « classiques », l’absence de CAL peut provoquer des refus de connexion aléatoirement visibles côté comptes de domaine. À l’inverse, une connexion en mode administration (mstsc /admin) n’exige pas de CAL et réussira souvent : c’est un bon test de triage.
- Contrôler le mode de licence via GPO
Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Licensing :
– Use the specified Remote Desktop licensing mode (Per User ou Per Device)
– Specify the Remote Desktop licensing servers (nom(s) du RDLS) - Vérifier rapidement par registre (lecture seule)
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v LicensingMode reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers"LicensingMode : 2 = Per Device, 4 = Per User. - PowerShell – état de la pile RDS (hôte autonome)
Get-WindowsFeature RDS* | Where-Object {$_.InstallState -eq "Installed"} | Format-Table Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" | Select-Object LicensingMode - Test de contournement : lancer
mstsc /v:SERVEUR /admin. Si ce test réussit mais pas une connexion « normale », approfondir le licensing.
Bonnes pratiques : sur un serveur RDSH utilisé par des utilisateurs finaux, ne comptez pas sur /admin pour « vivre » sans CAL. Mettez en place un RDLS, activez‑le et installez les CAL correspondant à votre modèle d’usage (Per User pour des utilisateurs multi‑postes, Per Device pour des postes partagés).
Attribuer les droits d’ouverture de session à distance
Le symptôme « local OK, domaine KO » apparaît souvent quand le groupe AD attendu n’a pas le droit Allow log on through Remote Desktop Services sur la machine cible, ou quand un GPO de durcissement ajoute le groupe « Domain Users » (ou un groupe transitif) dans Deny log on through Remote Desktop Services.
- Vérifier les stratégies d’« User Rights Assignment » :
secpol.msc # ou via GPMC pour une vérification centraliséeChemin : Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment- Allow log on through Remote Desktop Services : ajouter un groupe AD dédié (ex. GG_RDP_Acces_Serveurs).
- Deny log on through Remote Desktop Services : s’assurer que vos groupes d’accès n’y figurent pas.
- Vérifier l’appartenance au groupe local Remote Desktop Users sur la machine cible :
Get-LocalGroupMember -Group "Remote Desktop Users"Automatisation recommandée via Group Policy Preferences → Local Users and Groups (ajout du groupe AD à Remote Desktop Users). - Observer une tentative échouée : dans le journal Sécurité de la cible, un 4625 / Status 0xC000015B trahit l’absence du droit d’ouverture de session à distance.
| Point de contrôle | Où regarder | Résultat attendu |
|---|---|---|
| Droit accordé | User Rights Assignment → Allow log on through RDS | Votre groupe AD d’accès RDP présent |
| Droit refusé | User Rights Assignment → Deny log on through RDS | Aucun groupe d’accès RDP listé |
| Groupe local | Local Groups → Remote Desktop Users | Votre groupe AD ajouté |
Contrôler la NLA et CredSSP (délégation des identifiants)
La NLA sécurise RDP en exigeant l’authentification avant d’établir la session graphique. Elle s’appuie sur CredSSP et Kerberos/NTLM. Plusieurs politiques peuvent bloquer la délégation des identifiants depuis un serveur RDS vers une autre cible (« second hop »).
- Tester sans NLA (temporaire) sur la cible : System Properties → Remote → Allow remote connections, décochez « Require NLA ». Si ça fonctionne sans NLA : le blocage vient d’une politique d’authentification (certificat, NTLM, Oracle CredSSP, délégation).
- Vérifier les politiques de délégation d’identifiants : Computer Configuration → Administrative Templates → System → Credentials Delegation.
- Allow delegating default credentials et/ou Allow delegating saved credentials : ajouter
TERMSRV/*si SSO désiré. - Encryption Oracle Remediation : aligner le niveau sur vos correctifs (éviter « Vulnerable » en production).
- Allow delegating default credentials et/ou Allow delegating saved credentials : ajouter
- Nettoyer d’anciens couples d’identifiants :
cmdkey /list cmdkey /delete:TERMSRV/serveur-cible - Synchroniser l’heure pour Kerberos :
w32tm /query /status - Certificat RDP de la cible : renouveler un certificat invalide peut résoudre des échecs de NLA.
# Exemple de régénération self-signed (cible) New-SelfSignedCertificate -DnsName $env:COMPUTERNAME ` -CertStoreLocation "Cert:\LocalMachine\Remote Desktop"
Vérifier pare‑feu & ports
Le service RDP utilise TCP 3389 par défaut. Assurez‑vous que le chemin RDS → cible n’est pas filtré et que la règle intégrée est active sur la cible pour le profil Domaine.
# Depuis le serveur RDS vers la cible
Test-NetConnection -ComputerName SERVEUR-CIBLE -Port 3389
# Activer la règle intégrée (cible)
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"Mettre à jour & redémarrer
Des divergences de correctifs côté NLA/CredSSP entre les hôtes expliquent souvent des échecs. Appliquez les mises à jour cumulatives, puis redémarrez les serveurs RDS et les cibles après tout changement de GPO/droits/licence.
Diagnostics avancés
Observer les journaux pertinents
- Security (Logon/Logoff) : événements 4624/4625 (Type 10 RemoteInteractive). Le code
0xC000015Bsignale un problème de droit. - Applications and Services Logs → Microsoft → Windows :
- TerminalServices-RemoteConnectionManager
- TerminalServices-LocalSessionManager
- RemoteDesktopServices-RdpCoreTS
- TerminalServices-Licensing
# Exemple de filtre PowerShell ciblé (cible)
Get-WinEvent -LogName Security |
Where-Object {
$_.Id -eq 4625 -and
$_.Properties.Value -match "10" # Type de connexion 10
} | Select-Object TimeCreated, Id, Message -First 5Comparer l’effet des GPO
# Depuis la cible (ou le RDS si concerné) :
gpresult /h C:\Temp\gp.html
# Examiner : User Rights Assignment, Credentials Delegation, RDS LicensingValider le type de session côté cible
qwinsta /server:SERVEUR-CIBLE
rwinsta SESSION_ID # pour libérer une session bloquée si nécessaireModèles d’implémentation recommandés
Groupe d’accès RDP dédié
- Créer un groupe AD : GG_RDP_Acces_Serveurs.
- Ajouter ce groupe à la GPO : Allow log on through Remote Desktop Services pour les serveurs ciblés.
- GPP « Local Users & Groups » : ajouter le groupe AD au groupe local Remote Desktop Users.
Avantages : moindre exposition, audits plus lisibles, révocation rapide.
Choix du type de CAL
- Per User : flexible si un utilisateur se connecte depuis plusieurs postes (bureaux, VDI, BYOD).
- Per Device : pertinent pour des postes partagés (atelier/entrepôt).
Tableaux d’aide à la décision
Matrice symptômes → pistes prioritaires
| Symptôme | Piste prioritaire | Action |
|---|---|---|
| Local OK, domaine KO | Droits RDS / GPO « Deny » | Vérifier Allow/Deny log on through RDS, groupe local Remote Desktop Users |
/admin OK, standard KO | Licences RDS | Activer RDLS, installer CAL, vérifier LicensingMode |
| Sans NLA OK, avec NLA KO | CredSSP / Certificat / Delegation | Politiques Credentials Delegation, certificat RDP, correctifs CredSSP |
| Échec après « Authentification… » | Oracle CredSSP / NTLM | Paramètre Encryption Oracle Remediation, politiques NTLM |
| Timeout immédiat | Port 3389 filtré | Activer règle « Remote Desktop (TCP‑In) », Test-NetConnection |
Paramètres GPO clés à vérifier
| Domaine GPO | Chemin | Paramètre | Attendu |
|---|---|---|---|
| RDS Licensing | Computer → Admin Templates → RDS → RDSH → Licensing | Use specified mode / Specify license servers | Mode aligné & RDLS défini |
| User Rights | Computer → Security Settings → Local Policies → User Rights | Allow/Deny log on through RDS | Groupe AD autorisé / Aucun Deny |
| Security | Computer → Admin Templates → RDS → RDSH → Security | Require user authentication for RDP | Activé (NLA) après correction |
| CredSSP | Computer → Admin Templates → System → Credentials Delegation | Delegating default/saved credentials | TERMSRV/* si SSO requis |
Scripts utiles (exemples)
Ajouter un groupe AD au groupe local « Remote Desktop Users » (cible)
$GroupAD = "CONTOSO\GG_RDP_Acces_Serveurs"
if (-not (Get-LocalGroupMember -Group "Remote Desktop Users" -ErrorAction SilentlyContinue | Where-Object {$_.Name -eq $GroupAD})) {
Add-LocalGroupMember -Group "Remote Desktop Users" -Member $GroupAD
}Définir le mode de licence via Registre (avec prudence)
# 2 = Per Device, 4 = Per User
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name "LicensingMode" -Value 4
# Déclarer le(s) RDLS
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers" -Force | Out-Null
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers\RDLS01" -Force | Out-NullTest réseau & visibilité du service RDP
Test-NetConnection SERVEUR-CIBLE -Port 3389
Get-Service TermService, UmRdpService | Format-Table Name, StatusNettoyer et rejouer une tentative d’authentification
cmdkey /delete:TERMSRV/SERVEUR-CIBLE
mstsc /v:SERVEUR-CIBLEInformations complémentaires utiles
- Édition d’évaluation : limitée dans le temps, elle n’interdit pas les connexions RDP. En revanche, un RD Session Host sans RDS CAL valide refusera les connexions « non‑administration » après la période de grâce.
- Bon usage de NLA : conservez la NLA activée après diagnostic. Elle réduit le risque d’attaque et la charge serveur.
- Automatisation : utilisez GPO/GPP ou PowerShell (
Add-ADGroupMember,Get/Set-ItemProperty) pour garantir la cohérence à grande échelle.
FAQ ciblée
Q : Pourquoi un compte local fonctionne‑t‑il alors que mon compte de domaine échoue ?
R : Sur la cible, les comptes locaux Administrateurs héritent du droit d’ouverture de session à distance et ne sont pas concernés par certaines restrictions de délégation. Un compte de domaine peut être bloqué par un Deny de GPO, par la NLA/CredSSP ou par un manque de CAL si la cible est un RD Session Host.
Q : mstsc /admin fonctionne, mais pas la connexion « normale ». C’est grave ?
R : Cela pointe le plus souvent un souci de licence RDS. Corrigez votre RDLS et installez des CAL. /admin n’est pas une solution de production.
Q : Puis‑je désactiver définitivement la NLA ?
R : Non recommandé. La NLA protège la cible et évite des sessions anonymes. Désactiver temporairement pour diagnostiquer, corriger la cause (certificat, CredSSP, délégation), puis réactiver.
Q : Dois‑je ajouter « Domain Users » à Remote Desktop Users ?
R : Évitez. Préférez un groupe AD dédié d’accès RDP pour appliquer le least privilege et tracer.
Checklist finale avant validation
- Le serveur de licences RDS est activé et les CAL correctes sont installées.
- La GPO « Use the specified Remote Desktop licensing mode / servers » est appliquée aux hôtes concernés.
- Sur les cibles, votre groupe AD d’accès figure dans Allow log on through Remote Desktop Services, et n’apparaît dans aucun Deny.
- Le groupe AD est membre du groupe local Remote Desktop Users sur les cibles.
- La NLA est activée et opérationnelle (certificat valide, délégation CredSSP correctement configurée si SSO souhaité).
- Le port TCP 3389 est accessible entre le serveur RDS et chaque cible.
- Les mises à jour sont appliquées, et un redémarrage a été effectué si nécessaire.
Résumé
Lorsque les utilisateurs du domaine ne parviennent pas à établir des connexions RDP sortantes depuis un serveur RDS Windows Server 2022 alors que des comptes locaux y arrivent, la résolution tient en trois axes : (1) licences RDS correctement posées et test /admin pour le triage ; (2) droits d’ouverture de session à distance accordés au bon groupe AD, en vérifiant toute règle Deny et l’appartenance au groupe local Remote Desktop Users ; (3) NLA/CredSSP vérifiés (délégation, certificats, Oracle CredSSP, NTLM). En consolidant ces points et en validant le port 3389, vous restaurez la capacité des comptes du domaine à initier des RDP sortants depuis le serveur RDS vers les autres serveurs du domaine.