Vous obtenez « Nom d’utilisateur ou mot de passe incorrect » en RDP sur un Windows Server 2012 R2 uniquement lorsque le VPN est actif ? Voici un guide concret, orienté diagnostic, pour rétablir l’accès rapidement et durablement.
Vue d’ensemble de la question
Un administrateur peut ouvrir une session RDP locale (sans VPN) sur un serveur 2012 R2, mais obtient l’erreur « Nom d’utilisateur ou mot de passe incorrect » lorsque la même connexion est tentée après établissement du VPN.
Réponse & solutions
| Axe de vérification | Actions détaillées |
|---|---|
| Connectivité VPN / RDP | Vérifier que le tunnel transporte bien le trafic TCP 3389 (RDP). Tester la latence et la résolution d’adresse du serveur (ping, tracert, nslookup). |
| Format des informations d’identification | Pour un compte Microsoft : MicrosoftAccount\[adresse‑courriel]. Pour un compte de domaine : DOMAINE\utilisateur ou utilisateur@domaine.com. Essayer également le préfixe .\ pour forcer un compte local. |
| Network Level Authentication (NLA) | Désactiver provisoirement NLA dans Système ➔ Paramètres d’utilisation à distance ou via la clé : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp ➔ UserAuthentication = 0. |
| Cohérence des comptes & stratégies | Vérifier que le compte n’est pas verrouillé, expiré ou soumis à une stratégie d’expiration de mot de passe. Confirmer l’appartenance au groupe Remote Desktop Users. |
| Synchronisation horaire | Un écart de temps ≥ 5 min entre client et serveur peut invalider Kerberos : synchroniser l’horloge (w32tm /resync). |
| Pare‑feu Windows & Antivirus | Contrôler l’ouverture du port 3389 côté serveur et désactiver temporairement les protections qui filtrent le VPN. |
| Licences & Limites de sessions | Assurer qu’aucune licence RDS n’est épuisée et que les limites de sessions simultanées ne sont pas atteintes. |
| Journal d’événements | Consulter Journal Windows ➔ Sécurité & Applications (ID 4625, 4624, 1029, 20499) pour des détails précis sur l’échec d’authentification. |
Diagnostic rapide : si la connexion fonctionne hors VPN mais pas via VPN, le problème est presque toujours lié (1) à la résolution/acheminement réseau ou (2) au contexte d’authentification (domaine vs local).
Méthode pragmatique : commencer par tester
DOMAINE\utilisateur, puis vérifier le port 3389 viatelnet <IP‑serveur> 3389depuis le poste VPN.
Procédure d’investigation guidée
Vérifier la connectivité RDP et la résolution DNS via le VPN
Beaucoup d’« identifiants incorrects » cachent en réalité une incapacité à atteindre le service RDP ou le contrôleur de domaine au moment de l’authentification.
- Tester la résolution de nom depuis le poste client une fois connecté au VPN :
nslookup serveur.exemple.local ping serveur.exemple.local tracert serveur.exemple.localAttendu : résolution vers l’adresse interne correcte. Si la résolution pointe une IP publique ou erronée, corriger le suffixe DNS du VPN, la recherche DNS ou utiliser l’IP interne pour isoler. - Tester le port 3389 :
powershell Test-NetConnection -ComputerName serveur.exemple.local -Port 3389 # ou telnet <IP-interne> 3389Attendu :TcpTestSucceeded = Trueou ouverture Telnet. Sinon, inspecter route, règles de pare-feu, ACL du VPN et éventuelle inspection TLS/IPS. - Vérifier le routage client (split/full tunnel) :
route print ipconfig /allAssurez‑vous qu’une route existe vers le sous‑réseau du serveur et que le DNS du VPN est prioritaire. - Écarter une boucle NAT/« hairpin » : si le FQDN résout sur une IP publique du serveur, testez l’IP interne. Si cela fonctionne, adaptez DNS interne/VPN, ou créez une entrée DNS view/split‑horizon.
Contrôler le format des identifiants et le protocole d’authentification
Via VPN, la prise en charge Kerberos peut différer (ex. connexion par IP), provoquant une bascule vers NTLM. Si la stratégie « Restreindre NTLM » est stricte ou si l’utilisateur appartient à Protected Users, l’authentification peut échouer par un message trompeur « mot de passe incorrect ».
- Essayer explicitement le domaine :
DOMAINE\utilisateurouutilisateur@domaine.com. - Forcer un compte local pour tester le serveur isolément :
.\Administrateur(ou un autre compte local membre d’Administrateurs/Remote Desktop Users). - Nettoyer d’éventuels identifiants mis en cache côté client :
cmdkey /list cmdkey /delete:TERMSRV/serveur.exemple.local mstsc /v:serveur.exemple.local /prompt - Tester la connexion par FQDN plutôt que par IP, afin de favoriser Kerberos (
TERMSRV/<FQDN>). Si le FQDN réussit et pas l’IP, revoyez vos règles NTLM.
Tester NLA / CredSSP et couches de sécurité RDP
NLA anticipe l’authentification côté client ; utile mais parfois bloquant selon patchs, certificats ou politiques. Pour diagnostiquer :
- Désactiver NLA temporairement (réactiver ensuite) :
powershell # Sur le serveur (en console locale ou via une autre session) Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 0 # (Option) Baisser la couche de sécurité pour tester (RDP Security Layer) Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value 0RemettezUserAuthentication=1etSecurityLayer=1après diagnostic. - Mettre à jour CredSSP de part et d’autre (client/serveur) si l’environnement est ancien. Un décalage de patchs peut provoquer une négociation qui échoue avec des symptômes trompeurs.
- Tester
mstsc /adminpour contourner des profils temp et certaines limites de sessions lors du diagnostic.
Cohérence des comptes, droits d’ouverture de session et stratégies
- Vérifier le statut du compte (verrouillage, expiration, mot de passe) et son appartenance à Remote Desktop Users.
net user <utilisateur> /domain net localgroup "Remote Desktop Users" - Politiques de sécurité locales/GPO :
- Autoriser l’ouverture de session via les Services Bureau à distance doit inclure le groupe/l’utilisateur.
- Refuser l’ouverture de session via les Services Bureau à distance ne doit inclure ni l’utilisateur ni son groupe.
- Network security: LAN Manager authentication level et Restrict NTLM : assouplir temporairement pour test si NTLM est bloqué.
gpedit.msc # ou rapport GPO effectives gpresult /r /scope computer - AD Sites & Services : un site AD mal mappé peut diriger vers un DC non joignable depuis le serveur. Vérifiez la découverte de site et la connectivité DC.
nltest /dsgetsite nltest /sc_verify:<DOMAINE>
Synchronisation horaire (Kerberos)
Kerberos rejette les jetons si l’horloge décale de ~5 minutes (dérive NTP, VM « paused », host mal synchronisé).
w32tm /query /status
w32tm /resync /nowait
# Forcer la source NTP (ex.)
w32tm /config /syncfromflags:manual /manualpeerlist:"ntp1.exemple.local ntp2.exemple.local" /update
net stop w32time & net start w32time
Pare‑feu Windows, antivirus et équipements de sécurité
- Activer les règles RDP sur tous les profils actifs (Domaine/Privé/Public) :
netsh advfirewall firewall set rule group="Remote Desktop" new enable=Yes # ou powershell Enable-NetFirewallRule -DisplayGroup "Remote Desktop" - AV/EDR/VPN client : désactivez temporairement l’inspection TLS/IPS, modules de « network filtering » et modules VPN « secure DNS » qui peuvent casser la résolution interne.
- Équipements réseau : vérifier que le VPN autorise TCP 3389 et éventuellement UDP 3389 (si RDP 8/8.1), ainsi que l’accès aux DC (TCP/UDP 88, 389, 445, 135, 1024‑65535 pour RPC).
Licences et limites de sessions
Sur un serveur « non‑RDS », seules deux sessions administratives simultanées sont autorisées. Au‑delà, vous pouvez recevoir des erreurs trompeuses.
qwinsta
quser
reset session <ID>
mstsc /v:serveur /admin
Sur un hôte RDS, utilisez le Diagnostiqueur des licences dans le Gestionnaire de serveur et vérifiez l’activation et le pool de CAL.
Journaux d’événements à cibler
- Sécurité : 4625 (échec ouverture), 4624 (succès), 4776 (NTLM), 4768/4769/4771 (Kerberos).
- Applications et services ➔ Microsoft ➔ Windows ➔ TerminalServices‑RemoteConnectionManager : 1149 (auth OK), 1049/1029 (négociation RDP/NLA).
- RRAS/VPN : 20499 et événements connexes pour des rejets côté tunnel.
eventvwr.msc
wevtutil qe Security "/q:*[System[(EventID=4625)]]" /f:text /c:5
Scénarios fréquents et correctifs rapides
| Symptôme observé | Cause probable | Correctif ciblé |
|---|---|---|
| FQDN échoue, IP fonctionne (ou inversement) | Résolution DNS incohérente / SPN Kerberos non utilisé | Corriger la résolution interne du FQDN, privilégier FQDN pour Kerberos ; ajuster la stratégie NTLM si IP nécessaire |
| Échec immédiat avec NLA activé | Incompatibilité CredSSP / couche TLS / patchs | Désactiver NLA pour test, mettre à jour CredSSP, remettre NLA ensuite |
| Mot de passe réputé « incorrect » pour certains comptes | Utilisateur dans Protected Users (NTLM interdit) / GPO Restrict NTLM | Utiliser FQDN (Kerberos), ou assouplir la GPO pour ce serveur, ou sortir l’utilisateur du groupe le temps du diagnostic |
| Connexion OK sur site, KO via VPN | Le VPN ne publie pas les routes/DC/DNS internes requis | Ajouter routes et DNS internes dans le profil VPN ; vérifier que le serveur joint ses DC sans latence excessive |
| Certains postes clients échouent, d’autres non | Identifiants mis en cache / client RDP trop ancien | cmdkey /delete, forcer /prompt et mettre à jour le client RDP |
| Intermittent, surtout aux heures de pointe | Limites de sessions, GPO de verrouillage, licences RDS | Contrôler sessions avec qwinsta/quser, vérifier CAL et GPO de verrouillage |
Script express de remédiation (diagnostic sécurisé)
À exécuter en console locale du serveur (ou via une autre voie d’accès) :
powershell
# 1) Autoriser RDP et ouvrir le pare-feu
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
# 2) NLA OFF (temporaire) pour test
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 0
# 3) Vérifier les groupes
net localgroup "Remote Desktop Users"
# 4) Synchroniser l’horloge
w32tm /resync
# 5) Rapport GPO rapide
gpresult /r /scope computer
# ➜ Réactiver NLA après résolution :
# Set-ItemProperty ... -Name 'UserAuthentication' -Value 1
Bonnes pratiques pour éviter la récidive
- Standardiser les formats d’identifiants dans la documentation utilisateur (
DOMAINE\utilisateurou UPN). - DNS interne cohérent sur le VPN (split‑horizon, suffixes de recherche, serveurs DNS d’entreprise).
- Supervision des journaux (4625/1149) et alerting sur taux d’échec anormal.
- Patch management côté clients et serveurs pour CredSSP/TLS/NLA.
- Durcissement progressif des politiques NTLM : commencer par l’audit, puis basculer en blocage une fois le trafic Kerberos dominant.
- Documenter la procédure de secours (
mstsc /admin, comptes locaux d’urgence, accès iLO/DRAC/KVM) pour éviter la perte totale d’accès.
Informations complémentaires utiles
- Assurez‑vous que le serveur est à jour (KB 2919355 pour WS 2012 R2 corrige plusieurs anomalies RDP).
- Sur les postes Windows 10/11, le client RDP moderne privilégie CredSSP ; maintenir CredSSP à jour côté serveur (KB 4093492) évite des rejeux d’authentification.
- Si vous utilisez un client VPN tiers, activez le mode « split‑tunnel » ou ajoutez une route manuelle afin que le trafic RDP ne soit pas renvoyé hors du tunnel.
FAQ ciblée
Pourquoi l’erreur n’apparaît qu’avec le VPN ?
Parce que la chaîne d’authentification change (résolution/DNS, protocole Kerberos vs NTLM, inspection réseau). Ce n’est pas forcément le mot de passe : c’est souvent le contexte qui échoue.
Est‑il dangereux de désactiver NLA ?
Désactiver NLA exposera la phase d’authentification au serveur. Faites‑le uniquement le temps du diagnostic, sur un réseau de confiance, puis réactivez‑le.
Faut‑il ouvrir l’UDP 3389 ?
RDP 8+ peut utiliser UDP pour de meilleures performances. Ce n’est pas indispensable pour s’authentifier, mais certains équipements qui bloquent l’UDP peuvent dégrader la négociation. Assurez a minima TCP 3389 et l’accès aux DC.
Le message « mot de passe incorrect » peut‑il indiquer un blocage NTLM ?
Oui. Si l’IP est utilisée et que le domaine bloque NTLM sortant/entrant, l’échec est possible malgré un bon mot de passe. Testez par FQDN ou ajustez la GPO Restrict NTLM pour le serveur.
Checklist minute (récapitulatif opérable)
- Résolution DNS interne OK sur le VPN (
nslookup), routage présent (route print). - Port 3389 joignable (
Test-NetConnection/telnet). - Essai avec
DOMAINE\utilisateuret.\compte_local; nettoyagecmdkey. - NLA OFF temporaire, CredSSP à jour, test
mstsc /admin. - GPO : droits RDP, aucune règle « Deny », politique NTLM vérifiée.
- Heure synchronisée (
w32tm), licences/sessions sous contrôle (qwinsta). - Journaux 4625/1149 analysés pour la cause racine.
Conclusion
Lorsque RDP échoue uniquement via VPN avec « Nom d’utilisateur ou mot de passe incorrect », pensez « contexte » avant « mot de passe ». En validant d’abord connectivité/RDP 3389 et DNS, puis en maîtrisant le protocole d’authentification (NLA, Kerberos/NTLM, format d’identifiants), on résout l’immense majorité des cas. Les contrôles restants (horloge, GPO de droits, sessions/licences) ferment la boucle et garantissent une connexion stable et sécurisée.