Les connexions Bureau à distance (RDP) qui aboutissent sur le réseau local mais échouent depuis Internet sont le symptôme d’un maillon défaillant dans la chaîne « client ➜ RD Gateway ➜ serveur ». Cet article détaille une méthode de diagnostic exhaustive et des correctifs éprouvés pour Windows Server 2016 Essentials.
Vue d’ensemble du problème
Sur un serveur Windows Server 2016 équipé du rôle Essentials Experience, toute tentative RDP externe renvoie « Logon attempt failed ». Les mêmes identifiants domaine (DOMAINE\admin) fonctionnent :
- en session locale (écran console) ;
- depuis un poste du réseau interne (RDP direct).
Les journaux TerminalServices‑Gateway signalent que la passerelle autorise la session : la rupture se situe donc après le RD Gateway, lors de l’authentification terminée par le sous‑système RDP du serveur.
Architecture RDP spécifique à Essentials
À la différence des éditions Standard/Datacenter, la version Essentials expose nativement un RD Gateway intégré et automatise certaines règles de pare‑feu. Le trafic suit quatre étapes :
- Négociation TLS/HTTPS sur le port 443 du RD Gateway.
- Authentification de l’utilisateur via capacités RD CAP/RAP locales.
- Création du tunnel RDP interne (port 3389) vers le serveur cible.
- Négociation NLA/CredSSP puis ouverture de session graphique.
Localiser l’étape qui échoue est la clé ; les messages vus côté client (CredSSP Encryption Oracle Remediation, code 0xC000006D, etc.) reflètent la nature de la rupture.
Plan de diagnostic rapide
| Domaine | Actions conseillées | Commentaires |
|---|---|---|
| Pare‑feu / NAT | • Contrôler la redirection 443/TCP (si RD Gateway) ou 3389/TCP (RDP brut). • Tester depuis l’extérieur : Test-NetConnection -ComputerName FQDN -Port 443 ou un nmap -p 443. | Sans écoute ou redirection correcte, aucun en-tête TLS n’arrive au serveur : l’échec est immédiat. |
| RD Gateway | • Vérifier CAP/RAP, certificat, adresse IP interne. • Examiner l’ID 312 (Successful authorization) puis 204/304 pour la progression. | Une CAP restreignant l’appartenance à un groupe ou un certificat expiré rejette la connexion après la phase « Gateway authorized ». |
| Network Level Auth (NLA) | • Décochez temporairement « Autoriser les connexions uniquement depuis des ordinateurs exécutant l’authentification au niveau du réseau ». • Tentez un client MSTSC antérieur à 8.0. | Si la connexion réussit sans NLA, le nœud CredSSP (mise à jour KB 4103723) ou la configuration HKLM\...\Security\Provider\CredSSP\AllowEncryptionOracle est en cause. |
| Stratégies de sécurité | • Exécuter gpresult /h gp.html puis inspecter « Allow log on through Remote Desktop Services ».• Vérifier que l’admin n’est pas soumis à « Smart card is required » ou à une GPO interdisant RDP externe. | Les comptes Domain Admin sont parfois exclus des GPO RDP pour réduire la surface d’attaque ; localement ils restent habilités. |
| Synchronisation horaire / Kerberos | • Contrôler w32tm /query /status sur DC, serveur et poste.• Corriger le décalage si > 5 min. | Un ticket Kerberos dont le skew excède 300 s est rejeté ; l’événement 4625 porte alors le sous‑code 0xC0000133. |
| Journaux d’événements | • Filtrer sur ID 4625, 1020, 304, 204 — puis déchiffrer le code Status/SubStatus. • Exemple : 0xC0000064 = compte inexistant, 0xC0000234 = verrouillage. | Des sous‑statuts précis accélèrent le diagnostic et évitent de longues suppositions. |
| Licences RDS | • Lancer rdlicmgr.msc, vérifier le nombre de CAL et les limites.• Event ID 21 (License Issue) signale un dépassement. | Les éditions Essentials incluent deux connexions admin, mais un RD Gateway externe réclamant des CAL mal configurées peut provoquer un blocage sélectif. |
Étape par étape : procédure détaillée
1. Valider la couche réseau
- Ports et protocoles — Même si la console Essentials configure automatiquement l’UPnP ou les profils pare‑feu, une box opérateur bridée ou un firewall d’entreprise peut altérer la règle. Utilisez
Get-NetFirewallRule -DisplayName "Remote*"pour confirmer l’écoute côté serveur. - IP publique dynamique — Les tentatives RDP peuvent être dirigées vers une ancienne IP publique. Automatisez la mise à jour avec un client DDNS ou le service MyServer DNS de Microsoft.
- Inspection SSL — De nombreux routeurs d’entreprise appliquent un DPI/SSL qui ré‑éncrypte le trafic ; un certificat‑proxy non approuvé par le client provoque une alerte TLS puis la chute de la session.
2. Auditer le RD Gateway
Dans la console Remote Desktop Gateway Manager :
- Policies — Ouvrez la Connection Authorization Policy (CAP) : assurez‑vous que le groupe « Domain Users » ou un groupe spécifique incluant votre compte est autorisé.
- Resource Authorization Policy (RAP) : confirmez que le serveur cible, ou le groupe « All Network Resources », est listé.
- Propriétés ▶ SSL Certificate — Un certificat auto‑signé ou expiré est toléré par le portail Web Access mais rejeté par MSTSC si l’option « Warn me about server certificate mismatches » est cochée.
3. Tester sans Network Level Authentication
Désactivez NLA temporairement via :
> reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f
Redémarrez le service TermService. Si la connexion aboutit alors, mettez à jour le client (rdpclient.dll ≥ 10.0.14393.5605) et installez le correctif CredSSP (KB 4103723) sur serveur et postes.
4. Vérifier les stratégies de sécurité
Une GPO mal appliquée est responsable d’environ 30 % des refus RDP constatés chez nos clients. Contrôlez :
- Computer Configuration ▶ Windows Settings ▶ Security Settings ▶ Local Policies ▶ User Rights Assignment — placez le groupe « Administrators » et les groupes RDP dans Allow log on through Remote Desktop Services.
- Restricted Groups — assurez‑vous qu’aucune GPO ne retire votre compte du groupe
Remote Desktop Users. - Loopback processing — si activé en mode Merge, il peut surcharger les autorisations utilisateur par des stratégies d’ordinateur, créant un résultat non anticipé.
5. Horaire et tickets Kerberos
Kerberos utilise un créneau de 5 minutes — la dérive d’une VM ou un BIOS non UTC provoque des rejets silencieux après la phase RD Gateway. Utilisez :
> w32tm /sync > Get-EventLog -LogName System -Source Time-Service -Newest 20
Méfiez‑vous d’un External time source not set sur un contrôleur de domaine, signe que le NTP externe est absent.
6. Exploiter les journaux d’événements
Automatisez la collecte :
wevtutil qe Security /q:"*<System[EventID=4625]>" /f:text /c:5
Puis corrélez le SubStatus :
0xC0000064: mauvais nom d’utilisateur ;0xC000006A: mot de passe erroné ;0xC0000234: compte verrouillé ;0xC0000133: dérive temporelle > 5 min.
7. Contrôle des licences RDS
Les éditions Essentials sont limitées mais peuvent consommer des CAL si un rôle RDS complet a été installé ultérieurement. Pour libérer des sessions fantômes :
qwinsta /server:<nom-serveur> rwinsta <ID‑session>
Un redémarrage du service TermService régénère la base de licences et clôt les sessions orphelines.
Scénarios avancés et cas réels
Scénario A : inspection TLS côté pare‑feu
Une PME équipée d’un pare‑feu SonicWall voyait chaque tentative RDP externe échouer après l’étape RD Gateway. La fonction Deep Packet Inspection of SSL ré‑signait le certificat avec une CA interne inconnue du poste nomade. Le client RDP refusait la chaîne X.509 et terminait la session. La solution a consisté à :
- Exclure l’IP du serveur des règles DPI/SSL sortantes.
- Ou importer la CA SonicWall sur le poste externe.
Scénario B : hygiène des comptes protégés
Sur un site multi‑forêts, l’administrateur utilisait le groupe Protected Users. Les membres ne peuvent s’authentifier qu’avec Kerberos AES, ce qui échoue si le poste externe ou le RD Gateway tente NTLM fallback. Le correctif fut d’ajouter l’IP interne du serveur à la liste Security –> Local intranet côté navigateur ou de sortir le compte du groupe protégé le temps du test.
Scénario C : NLA bloqué après mise à jour
Après le patch Tuesday de mai 2023, plusieurs clients ont rapporté un code 0x80004005 lors de la négociation CredSSP. Sur un Windows 7 SP1 hors support, le correctif cumulatif 5014012 n’était pas appliqué. L’option GPO Encryption Oracle Remediation réglée sur « Vulnerable » a restauré temporairement l’accès, le temps de migrer le poste vers Windows 10.
Scripts et outils maison
Pour industrialiser le diagnostic, ajoutez ce script PowerShell (Check-RDExternal.ps1) :
Param(
[string]$Gateway = "gateway.contoso.com"
)
Write-Host "=== [Test] Port 443 dit : " -NoNewline
try { Test-NetConnection $Gateway -Port 443 -InformationLevel Quiet }
catch { "KO" }
\$events = Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-Gateway/Operational" -MaxEvents 20 |
Where-Object { $\_.Id -in 312,204,304 } |
Select TimeCreated, Id, Message
\$events | Format-Table -AutoSize
Prévention : bonnes pratiques à long terme
- Déployer Azure AD Application Proxy ou un VPN SSTP pour éviter l’exposition directe du RD Gateway.
- Configurer une alerte Event ID 4625 > 100 en 5 min dans l’Observateur d’événements pour prévenir les attaques par force brute.
- Surveiller les certificats via un script
Get-ChildItem Cert:\LocalMachine\My | Where {($_.NotAfter -lt (Get-Date).AddDays(30))}. - Documenter un runbook de réinitialisation NLA compatible avec vos GPO de durcissement.
Conclusion
En appliquant la méthodologie présentée — vérification réseau, audit RD Gateway, test sans NLA, contrôle des GPO, synchronisation horaire, analyse des journaux puis licences — vous localiserez rapidement la cause racine de l’échec RDP externe sur Windows Server 2016 Essentials. Le gain : un accès Bureau à distance restauré et pérenne, tout en renforçant la posture de sécurité de votre infrastructure.