Erreur RDP : échec de l'authentification au niveau du réseau

Vous saisissez votre nom d'utilisateur et votre mot de passe dans la Connexion Bureau à distance, vous cliquez sur Connexion, et avant même qu'un écran d'ouverture de session apparaisse, un message d'erreur tombe. Pas de bureau, pas de barre de progression, rien. C'est exactement la signature d'un problème de NLA : l'authentification au niveau du réseau se déroule avant l'établissement de la session. Si elle échoue, vous ne verrez jamais de masque de connexion dans lequel corriger quoi que ce soit.

Cet article passe en revue les causes réalistes dans l'ordre où elles se présentent en pratique, et donne pour chacune la commande de vérification, la solution et le chemin de retour lorsque RDP est complètement mort.

Les messages d'erreur, mot pour mot

Il n'existe pas un seul message, mais une poignée, et le texte exact réduit déjà fortement le champ des causes possibles. Voici les variantes que vous rencontrerez le plus souvent :

• « L'ordinateur distant nécessite une authentification au niveau du réseau, que votre ordinateur ne prend pas en charge. » Le serveur exige NLA, le client ne le fournit pas. Typique avec les clients anciens, avec les clients tiers sous Linux ou macOS et avec des stratégies client mal configurées.
• « Une erreur d'authentification s'est produite. L'autorité de sécurité locale ne peut pas être contactée. » En anglais : « The Local Security Authority cannot be contacted ». C'est le message classique du certificat ou du décalage horaire.
• « Une erreur d'authentification s'est produite. La fonction demandée n'est pas prise en charge. » Il s'agit presque toujours de CredSSP, et non de NLA au sens strict. Nous y revenons plus bas.
• « Les informations d'identification utilisées pour vous connecter n'ont pas fonctionné. » Compte verrouillé, désactivé, mot de passe expiré ou compte absent du groupe des utilisateurs du Bureau à distance.
• « La relation d'approbation entre cette station de travail et le domaine principal a échoué. » Le compte d'ordinateur dans le domaine ne correspond plus.

Une distinction importante : si le client signale au bout de vingt secondes que l'ordinateur distant n'est pas accessible, ce n'est pas une erreur NLA, mais un problème de réseau, de pare-feu ou de service arrêté. Les erreurs NLA arrivent vite, en une à trois secondes le plus souvent, parce que la connexion TCP est bien établie et que seule l'authentification échoue.

Cause 1 : décalage horaire entre le client et le serveur

C'est de loin la cause la plus fréquente, et c'est aussi celle que l'on néglige le plus souvent, parce que « l'horloge avance un peu » sonne comme un problème anodin. Ce n'en est pas un. Deux mécanismes cassent immédiatement en cas de décalage :

• Kerberos tolère par défaut cinq minutes d'écart au maximum. Au-delà, le contrôleur de domaine rejette la demande avec KRB_AP_ERR_SKEW. Cela concerne tous les membres du domaine.
• La vérification TLS du certificat RDP échoue dès que l'horloge du client sort de la période de validité du certificat serveur. Cela touche aussi les serveurs isolés sans domaine, et précisément lorsque le serveur redémarre avec une horloge dans le passé et qu'un certificat fraîchement généré n'est pas encore valide du point de vue du client.

Vérification sur le serveur, dans une console PowerShell avec les droits d'administrateur :

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

Le stripchart vous donne l'écart en secondes. Tout ce qui reste sous une seconde est bon, tout ce qui dépasse 60 secondes est suspect, et tout ce qui dépasse 300 secondes explique l'erreur.

C'est ici que les systèmes se séparent, et la plupart des tutoriels mettent les deux cas dans le même sac :

• Serveur isolé sans domaine : configurez une source NTP externe.
• Membre du domaine : ne définissez surtout pas votre propre liste de pairs. Un serveur membre doit prendre son heure dans la hiérarchie du domaine, sinon il dérive par rapport au contrôleur de domaine.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

Ensuite, dans les deux cas, redémarrez le service et lancez une synchronisation :

net stop w32time
net start w32time
w32tm /resync /rediscover

Une particularité qui vous rattrape sur les serveurs virtualisés : si l'horloge affiche exactement une ou deux heures d'écart, ce n'est pas une dérive, mais un problème d'interprétation de l'horloge matérielle. Windows attend la RTC en heure locale, alors que beaucoup de plateformes de virtualisation la fournissent en UTC. Vérifiez d'abord le fuseau horaire, puis modifiez le cas échéant l'interprétation :

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Cause 2 : certificat expiré ou mal lié

Sans PKI propre, Windows génère pour RDP un certificat auto-signé valable environ six mois et qui se renouvelle normalement tout seul. « Normalement » est ici le mot important. Si le renouvellement échoue à cause des autorisations sur le magasin de clés, ou si un certificat lié manuellement et issu d'une autorité de certification interne arrive à expiration, vous ne pouvez plus vous connecter et vous voyez le message sur l'autorité de sécurité locale.

Vérifier l'existant :

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

Puis, quel certificat le listener utilise réellement :

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Comparez le hachage retourné avec les empreintes issues de la première commande. Deux tableaux d'erreur sont possibles : le hachage pointe vers un certificat expiré, ou il pointe vers un certificat qui ne se trouve plus du tout dans le magasin.

La réparation consiste à supprimer la liaison et à retirer l'ancien certificat. Windows en génère ensuite un nouveau au démarrage du service :

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Deux avertissements à ce sujet. Premièrement, le redémarrage de TermService coupe toutes les sessions RDP existantes, y compris la vôtre si vous êtes encore connecté d'une manière ou d'une autre. Exécutez cela depuis la console. Deuxièmement : si une stratégie de groupe impose un modèle de certificat pour l'authentification serveur, le serveur va chercher son certificat auprès de l'autorité de certification interne. Si celle-ci est injoignable ou si le modèle a expiré, aucun nouveau certificat n'arrive et l'erreur persiste. Dans ce cas, vérifiez d'abord l'autorité de certification, pas le serveur.

Contrôle de réussite : la première commande renvoie désormais un certificat dont la date NotAfter se situe dans le futur, et SSLCertificateSHA1Hash pointe exactement vers celui-ci.

Cause 3 : compte verrouillé, désactivé ou mot de passe expiré

C'est ici que se cache le piège qui distingue NLA de tous les autres problèmes de connexion : avec NLA actif, vous ne pouvez pas changer un mot de passe expiré depuis le client RDP. La boîte de dialogue « Votre mot de passe a expiré et doit être modifié » n'apparaît qu'à l'intérieur de la session, et vous n'atteignez pas la session sans authentification réussie. Le client se contente d'annoncer que les informations d'identification ne fonctionnent pas. Le mot de passe est parfaitement correct, il est simplement expiré.

Consulter l'état d'un compte local :

net user Administrator

Regardez les lignes « Compte actif », « Le compte expire », « Mot de passe expire » et « Mot de passe modifiable ». Les contre-mesures correspondantes :

net user Administrator "NouveauMotDePasseLong!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

Un compte local verrouillé après trop de tentatives infructueuses est un état à part, que ni Enable-LocalUser ni un changement de mot de passe ne lèvent. Il se déverrouille tout seul une fois la durée de verrouillage écoulée, durée que vous consultez ainsi :

net accounts

Pour déverrouiller immédiatement sans outil graphique, passez par ADSI :

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Lorsque les ports RDP sont accessibles depuis Internet, les verrouillages arrivent pratiquement tous les jours, parce que des bots essaient votre compte administrateur en boucle. C'est un argument de poids pour restreindre l'accès plutôt que de déverrouiller le compte encore et encore. Changer de port réduit sensiblement les scans de masse, voir changer le port RDP sans redémarrage.

Enfin l'appartenance au groupe. Le nom du groupe est localisé, ce qui casse volontiers les scripts. Pour une requête indépendante de la langue, utilisez le SID bien connu :

Get-LocalGroupMember -SID "S-1-5-32-555"

Cause 4 : NLA désactivé ou à moitié désactivé sur le serveur

Deux interrupteurs distincts déterminent le comportement, et c'est justement leur combinaison qui pose problème. UserAuthentication pilote NLA, SecurityLayer la sécurisation du transport, avec les valeurs 0 pour l'ancienne couche de sécurité RDP, 1 pour la négociation et 2 pour TLS imposé.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

L'impasse classique : quelqu'un désactive NLA parce qu'il soupçonne un problème de certificat, mais laisse SecurityLayer sur 2. La négociation TLS avec le certificat cassé reste donc en place, et l'erreur ne change que dans sa formulation. Si vous voulez vraiment abaisser les deux pour diagnostiquer, abaissez-les tous les deux, puis rétablissez l'état initial ensuite.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

La deuxième impasse est encore plus désagréable : vous définissez la valeur de registre, vous redémarrez, et elle est de nouveau à 1. Elle vient alors d'une stratégie de groupe. Les valeurs de stratégie se trouvent à un autre emplacement et l'emportent toujours :

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

Tant qu'une valeur y figure, toute modification locale ne tient que jusqu'à la prochaine application de la stratégie. La stratégie s'appelle « Exiger l'authentification de l'utilisateur pour les connexions à distance à l'aide de l'authentification au niveau du réseau » et doit être modifiée sur le contrôleur de domaine.

Et la règle la plus importante pour clore cette section : désactiver NLA de façon permanente n'est pas une solution, c'est une porte ouverte. Sans NLA, quiconque atteint le port peut solliciter l'écran de connexion, et donc une partie non protégée de la pile de session. Désactivez-le pour le diagnostic, puis réactivez-le.

Cause 5 : relation d'approbation de domaine rompue

Chaque compte d'ordinateur dans un domaine possède son propre mot de passe, renouvelé automatiquement tous les 30 jours par défaut. Si les versions du serveur et du contrôleur de domaine ne concordent plus, le serveur ne peut plus authentifier de comptes de domaine, et NLA échoue pour tous les utilisateurs du domaine, alors que les comptes locaux continuent de fonctionner. C'est précisément ce schéma qui prouve cette cause.

Le déclencheur classique en exploitation est un retour à un état antérieur, par exemple depuis une sauvegarde ou un snapshot plus ancien que le dernier changement de mot de passe. Vérification :

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:mondomaine.local

Réparation, connecté en tant qu'administrateur local via la console :

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset-ComputerMachinePassword -Credential (Get-Credential)

Sortir la machine du domaine puis la réintégrer n'est pas nécessaire et aggrave souvent les choses, car l'opération peut faire perdre les appartenances aux groupes et les autorisations de l'ancien compte d'ordinateur. Après la réparation, un redémarrage du service Netlogon suffit :

Restart-Service Netlogon

Quand RDP ne répond plus du tout : le passage par la console

Toutes les commandes précédentes supposent que vous arriviez d'une manière ou d'une autre sur le serveur. C'est justement ce qui manque en situation critique. Sur les serveurs root KVM de KernelHost, vous disposez pour cette raison d'une console VNC dans l'espace client, qui fonctionne indépendamment de RDP, du pare-feu Windows et même de la pile réseau du système invité. C'est l'accès de secours avec lequel vous vous sortez vous-même de chacune des situations décrites plus haut. Sur les serveurs dédiés, l'accès de secours passe par le support.

Trois choses diffèrent sur la console VNC par rapport à une session RDP et coûtent régulièrement du temps :

• Disposition du clavier. La console fournit souvent une disposition US alors que Windows est en français, ou l'inverse. Les caractères spéciaux des mots de passe arrivent alors au mauvais endroit, et vous prenez un mot de passe correct pour un mot de passe faux. En cas de doute, utilisez le clavier visuel avec osk.exe depuis l'écran de connexion.
• Presse-papiers. Copier depuis votre propre machine vers la console ne fonctionne généralement pas. Prévoyez de tout retaper et choisissez vos mots de passe temporaires en conséquence.
• Connexion avec un compte local. En cas de problème de domaine, connectez-vous avec .\Administrator, le point et la barre oblique inverse forcent le compte local plutôt que le compte de domaine.

Sur la console, vérifiez ensuite les fondamentaux avant de toucher à NLA :

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Si fDenyTSConnections est à 1, les connexions à distance sont complètement désactivées, indépendamment de NLA :

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

Vous activez les règles de pare-feu indépendamment de la langue via l'identifiant de groupe interne, parce que le nom de groupe affiché change selon la langue du système :

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

Le cas particulier CredSSP, souvent confondu

Si le message dit littéralement « La fonction demandée n'est pas prise en charge » et qu'il mentionne la correction Encryption Oracle Remediation de CredSSP, alors aucune des cinq causes ci-dessus n'est en jeu. Ici, les niveaux de correctifs du client et du serveur ne correspondent pas : un côté exige la variante CredSSP renforcée, l'autre ne la connaît pas encore.

La seule solution propre consiste à mettre à jour les deux côtés. La modification de registre qui circule sur le web avec AllowEncryptionOracle sur le client désactive précisément le durcissement qui provoque l'erreur, et rouvre ainsi une voie d'attaque connue. Si vous en avez besoin brièvement pour installer les mises à jour, remettez-la à sa valeur d'origine dès que le serveur est à jour.

Comment savoir que le problème est vraiment réglé

Une connexion réussie est la preuve la plus faible, parce qu'elle fonctionne aussi lorsque vous avez désactivé NLA pour le diagnostic. Vérifiez plutôt les points suivants dans l'ordre :

1. NLA est de nouveau actif. UserAuthentication est à 1 et SecurityLayer à 2.
2. L'horloge est juste. L'écart relevé par le stripchart reste sous une seconde, et w32tm /query /source annonce une vraie source, pas « Local CMOS Clock » ni « Free-running System Clock ».
3. Le certificat est valide. NotAfter se situe dans le futur, et le hachage lié pointe exactement vers ce certificat.
4. Le journal d'événements confirme la réussite de l'authentification réseau. L'événement 1149 n'apparaît qu'une fois NLA franchi, il constitue donc la véritable preuve.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

Pour la contre-épreuve en cas de tentatives échouées, les codes d'état de l'événement 4625 sont plus parlants que n'importe quel message client : 0xC0000071 correspond à un mot de passe expiré, 0xC0000072 à un compte désactivé, 0xC0000234 à un compte verrouillé et 0xC000006A à un mot de passe réellement faux.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

Pour finir, les sessions elles-mêmes, volontiers depuis la console :

qwinsta

Récapitulatif rapide pour le dépannage

Lorsque vous installez un nouveau serveur Windows, il vaut la peine de régler correctement la source de temps, les stratégies de compte et le chemin d'accès dès le départ, plutôt que de les réparer plus tard sous pression. La check-list pour un nouveau serveur root sert de repère, et si vous voulez sécuriser davantage l'accès RDP, changer le port RDP sans redémarrage reste la première étape la moins coûteuse contre les tentatives de connexion automatisées.