Sur Windows Server 2022, l’erreur RDP « No Response From Server » peut survenir juste après l’écran de connexion. Voici une analyse terrain et une méthode éprouvée pour diagnostiquer et corriger, avec un cas réel lié à un agent SecurEnvoy mal configuré.
Erreur RDP « No Response From Server » sur Windows Server 2022
Vue d’ensemble du problème
Sur un serveur physique Windows Server 2022 — et deux machines virtuelles Hyper‑V hébergées dessus — la connexion Bureau à distance (RDP) atteint l’écran de logon puis échoue au bout d’environ 10–15 secondes, en affichant « No Response From Server ». Les vérifications réseau basiques (Ping, résolutions DNS, accès aux partages SMB) et la prise en main via un autre outil fonctionnent. La désactivation temporaire du pare‑feu Windows n’a pas d’effet. Le paramètre NLA (Network Level Authentication) activé ou désactivé ne change rien. Les autorisations RDP sont conformes.
Dans Observateur d’événements > Applications and Services Logs > Microsoft > Windows > TerminalServices‑LocalSessionManager > Operational, on retrouve notamment :
RDP_SEC: error transitioning from FStatePassthrough ... (0x8007139F)- « Network characteristics detection function disabled (Reason Code 2: Server Configuration) »
Le phénomène touche les trois machines on‑premises, alors que des VM similaires en cloud ne présentent pas l’anomalie.
| Symptôme | Constat | Interprétation rapide |
|---|---|---|
| Écran de logon RDP visible puis échec | Message « No Response From Server » après ~10–15 s | Transport OK, échec probable lors de l’authentification interactive |
| Réseau de base OK | Ping/SMB/outil tiers fonctionnent | La pile TCP/TLS est saine ; problème au-dessus (CredSSP/CP) |
| NLA on/off sans effet | Le comportement reste identique | Suspicion d’un module qui intercepte quelle que soit la config NLA |
| Cloud VS on‑premises | Seuls les serveurs on‑premises sont touchés | Différence locale : agent, pilote, GPO ou sécurité spécifique |
Réponse et solution validées
Cause racine identifiée : présence d’un Windows Logon Agent SecurEnvoy (fournisseur MFA/2FA) installé sur les serveurs on‑premises mais jamais configuré correctement. Ce Credential Provider intercepte l’authentification RDP ; faute de configuration valide, il bloque la phase de logon et conduit à l’échec « No Response From Server » visible côté client.
Action corrective : désinstallation de l’agent SecurEnvoy puis redémarrage du service RDP (TermService) : la connexion RDP redevient immédiatement fonctionnelle.
Comprendre où ça casse : déroulé d’une session RDP
| Phase | Ce qui se passe | Symptômes en cas d’échec | Indices utiles |
|---|---|---|---|
| Transport | Négociation TCP 3389, TLS, CredSSP | Connexion impossible avant l’écran de logon | Firewall/ACL, certificats, versions TLS |
| Authentification | NLA/CredSSP + Credential Providers (CP) | Écran de logon visible, puis bascule en erreur | Modules MFA/SSO, événements LSM/RDP‑CoreTS |
| Ouverture de session | Chargement du profil, shell, GPO utilisateur | Écran « Welcome »/« Applying » interminable | Event logs User Profile Service, GPSVC |
Dans le cas étudié, tout indique un blocage à l’étape Authentification, précisément lors de l’intervention d’un Credential Provider tiers (SecurEnvoy) qui se greffe à la chaîne de logon pour appliquer le MFA.
Étapes de diagnostic utiles
Vérifier la présence d’agents de logon ou MFA tiers
Les produits comme SecurEnvoy, Duo, Okta, etc. installent des Credential Providers et/ou des Credential Provider Filters. Ils s’insèrent avant la remise du jeton de session et sont une source fréquente d’échec après l’écran de logon.
# Lister les Credential Providers installés
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers' |
Select-Object PSChildName
# Rechercher des produits susceptibles d'intercepter le logon
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -match 'SecurEnvoy|Duo|Okta|Auth|MFA|Identity' } |
Select-Object DisplayName, DisplayVersion
Corréler les symptômes
- Échec après logon visible : la session graphique s’affiche, signe que le transport RDP est OK ; l’échec survient pendant la remise des informations d’identification.
- Événements LSM/RDP‑CoreTS : les messages du type
RDP_SEC ... (0x8007139F)et notices « Network characteristics detection function disabled » appuient la piste d’un composant de sécurité qui refuse l’état courant. - Uniquement on‑premises : la différence d’inventaire logiciel oriente vers un agent local (ici, SecurEnvoy) absent sur les VM cloud.
Isoler rapidement
- Ouvrir une session console (iDRAC/iLO, console Hyper‑V/VMware) ou via l’outil de contrôle à distance qui fonctionne.
- Désinstaller ou désactiver temporairement l’agent de logon tiers identifié.
- Redémarrer le service RDP :
Restart-Service TermService -Force - Re‑tester RDP avec NLA activé (plus sûr). Ne désactiver NLA que pour un test ciblé et bref.
Si l’agent doit être conservé
- Mettre à jour vers une version compatible Server 2022.
- Effectuer la configuration complète (URL/serveurs SecurEnvoy, certificats, méthode OTP, groupes ciblés).
- Prévoir un compte d’administration de secours exclu du MFA durant les tests.
- Vérifier la synchronisation horaire (serveur ↔ DC ↔ serveur SecurEnvoy) et la connectivité vers l’infrastructure MFA.
Procédure de dépannage détaillée
Accès console et filet de sécurité
- Confirmer un accès hors RDP (console physique, BMC, hyperviseur). Ne jamais modifier la chaîne d’authentification sans voie de retour.
- Créer/valider un compte local « break‑glass » membre d’Administrateurs, protégé et journalisé.
Inventorier ce qui peut intercepter l’authentification
Au‑delà des agents MFA, pensez aux suites EDR/AV avec modules d’identités, aux greffons SSO/Kerberos alternatifs, aux solutions PAM/Password‑Vault injectant des contrôles à l’ouverture de session.
# Vérifier les deux registres clés (Providers et Filters)
'Credential Providers','Credential Provider Filters' | ForEach-Object {
$k = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\$_"
Write-Host "`n-- $k --"
Get-ChildItem $k | Select-Object PSChildName
}Observer les journaux pertinents
| Journal | Événements utiles | Lecture |
|---|---|---|
| TerminalServices‑LocalSessionManager / Operational | Transitions d’état de session, erreurs CP, codes HRESULT | Bloquage entre logon et remise de jeton = piste CP/MFA |
| RemoteDesktopServices‑RdpCoreTS / Operational | Négociation protocolaire, détection de latence, TLS | Transport OK si l’écran apparaît ; surveiller erreurs RDP_SEC |
| Sécurité | Événements d’ouverture/échec de session (4624/4625), Kerberos/NTLM | Échec sans 4625 côté serveur peut pointer un blocage avant validation |
| Système | Service TermService, dépendances, erreurs de démarrage | Confirmer l’état stable du service RDP |
# Extraire rapidement les 20 derniers événements RDP-CoreTS
wevtutil qe Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational /c:20 /rd:true /f:text
# LSM
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:20 /rd\:true /f\:text Contrôler la configuration RDP de base
# Lire NLA & SecurityLayer
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
Select-Object SecurityLayer, UserAuthentication
# Sanity‑check du service et des sessions
sc.exe query TermService
quser
qwinsta Rappel : UserAuthentication = 1 = NLA activé. SecurityLayer (0/1/2) contrôle le mode de sécurité RDP/TLS.
Tester proprement
- Avec NLA activé, tester avec un compte distinct, puis en
/admin(connexion console) depuismstsc.exe /admin. - Essayer la résolution via nom FQDN et via IP pour écarter un souci DNS/certificat côté client.
- Vérifier qu’aucune stratégie « Deny log on through Remote Desktop Services » ne cible le compte testé.
Isoler l’agent fautif
Si un agent MFA est présent, deux approches :
- Désinstaller l’agent par la méthode standard (recommandé) puis redémarrer
TermService. - Désactiver temporairement ses composants selon la documentation de l’éditeur (service propre, paramètre de bypass). Éviter les manipulations de GUID dans le registre si vous n’êtes pas certain de l’impact.
Après correction
Restart-Service TermService -Force
mstsc.exe /v:NomDuServeur
La session doit désormais s’ouvrir normalement. Conservez la configuration NLA activée pour la sécurité et revenez à des ACL/pare‑feu stricts si vous les avez assouplis pour tester.
Quand conserver SecurEnvoy ou un autre MFA
- Mettre à jour l’agent vers une version certifiée pour Windows Server 2022.
- Renseigner les paramètres obligatoires : URL/ports des serveurs SecurEnvoy, certificats racines/intermédiaires, méthodes OTP autorisées, groupes et comptes ciblés.
- Tester d’abord en mode audit/utilisateurs pilotes, avec un compte d’admin de secours exclu de la politique.
- Surveiller l’horloge et le NTPSync ; un décalage de temps casse souvent le flux d’authentification.
- Valider la connectivité sortante du serveur vers l’infrastructure MFA (proxy, TLS inspection, SNI).
Bonnes pratiques pour éviter la récidive
- Documenter l’inventaire des Credential Providers par rôle et par environnement (on‑prem/cloud).
- Automatiser une vérification post‑patch des services critiques (
TermService, EDR, agents d’identité). - Maintenir un plan de secours : accès console, mots de passe « break‑glass » scellés, procédure de rollback.
- Mettre en place une alerte sur des schémas d’événements RDP inhabituels (ex. pics d’échec après logon).
Comparaison des environnements
| Environnement | Agent MFA installé | État RDP | Conclusion |
|---|---|---|---|
| On‑premises (physique + VM Hyper‑V) | SecurEnvoy présent, non configuré | Échec « No Response From Server » | Corrélation forte avec l’agent local |
| Cloud (VM similaires) | Pas d’agent SecurEnvoy | RDP OK | Élimine un problème d’image/OS générique |
Commandes utiles prêtes à l’emploi
# Lister les Credential Providers installés
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers' |
Select-Object PSChildName
# Rechercher des produits susceptibles d'intercepter le logon
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -match 'SecurEnvoy|Duo|Okta|Auth|MFA|Identity' } |
Select-Object DisplayName, DisplayVersion
# Après correction, redémarrer le service RDP
Restart-Service TermService -Force
# Vérifier NLA et SecurityLayer
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
Select-Object SecurityLayer, UserAuthentication
# Collecte rapide des événements récents RDP
wevtutil qe Microsoft-Windows-TerminalServices-LocalSessionManager/Operational /c:30 /rd:true /f:text
wevtutil qe Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational /c:30 /rd:true /f:text
# Trace réseau ciblée (à désactiver après)
netsh trace start scenario=rdp capture=yes
# ... reproduire le problème ...
netsh trace stop
Points d’attention sécurité
- NLA doit rester activé en production. Ne l’abaissez que le temps d’un test très court.
- Ne laissez pas d’agent MFA partiellement configuré : c’est une source de panne et d’ambiguïté opérationnelle.
- Conservez des journaux exportés avant et après correction pour alimenter un post‑mortem.
État final
Le problème RDP a été résolu en désinstallant le SecurEnvoy Windows Logon Agent mal configuré sur les serveurs on‑premises. RDP fonctionne à nouveau normalement. Si vous devez conserver SecurEnvoy, procédez à une configuration complète, mettez à jour l’agent et validez le scénario avec accès console et compte de secours avant tout déploiement large.
FAQ rapide
Pourquoi Ping/SMB fonctionnent alors que RDP échoue ?
Parce que l’échec ne se situe pas au niveau du transport réseau ; il apparaît durant l’authentification interactive, typiquement interceptée par un Credential Provider.
Désactiver NLA suffit‑il à corriger ?
Non. Dans ce cas, l’agent tiers intercepte de toute façon le logon, avec ou sans NLA. NLA doit rester activé après résolution.
Peut‑on « désactiver » un Credential Provider par le Registre ?
Techniquement oui selon l’implémentation de l’éditeur, mais le plus sûr reste la désinstallation ou l’option de bypass proposée officiellement. Si vous touchez au Registre, effectuez‑le uniquement depuis une console d’administration avec un plan de retour.
Résumé exécutable en une page
- Accéder à la console et s’assurer d’un compte break‑glass.
- Inventorier les Credential Providers et produits MFA/SSO.
- Identifier SecurEnvoy (présent sur on‑prem, absent sur cloud).
- Désinstaller l’agent SecurEnvoy non configuré.
- Redémarrer
TermService, tester RDP avec NLA activé. - Si l’agent doit rester : mise à jour, configuration complète, comptes exclus de secours, vérifications NTP/connectivité/certificats.