titre

Lors de la gestion de serveurs Windows ou de la connexion à un poste de travail distant, vous pourriez rencontrer un message d'erreur frustrant : "L'ordinateur distant nécessite l'authentification au niveau réseau (NLA)". Même lorsque vos paramètres semblent corrects, constater que RDP NLA ne fonctionne pas alors que NLA est activé peut stopper votre productivité et bloquer un accès critique.

Ce guide explore les causes profondes des échecs NLA et fournit des solutions étape par étape pour rétablir votre Connexion Bureau à distance.

Qu'est-ce que l'authentification au niveau réseau (NLA) ?

L'authentification au niveau réseau (NLA) est une méthode de sécurité qui finalise l'authentification de l'utilisateur avant l'établissement d'une session Bureau à distance complète et l'apparition de l'écran de connexion.

• Sécurité : Elle protège l'ordinateur distant des attaques par déni de service (DoS) et minimise le risque d'accès non autorisé.
• Efficacité : Elle utilise moins de ressources en authentifiant l'utilisateur avant la création d'une session complète.
• Le conflit : Bien que très sécurisée, elle nécessite que le client et le serveur aient des protocoles de sécurité correspondants (spécifiquement CredSSP).

Raisons courantes de "RDP NLA ne fonctionne pas"

Plusieurs facteurs peuvent déclencher cet échec de connexion, allant des mises à jour de sécurité aux mauvaises configurations réseau :

• Incompatibilité du protocole CredSSP : Souvent causée par la mise à jour de sécurité "Remédiation Oracle de chiffrement" (CVE-2018-0886).
• Connectivité au contrôleur de domaine : Le client ou le serveur ne peut pas atteindre l'Active Directory pour vérifier les informations d'identification.
• Certificats RDP corrompus : Le certificat auto-signé utilisé par le service Bureau à distance a expiré ou est défectueux.
• Paramètres de stratégie de groupe incorrects : NLA peut être appliqué sur le serveur, mais non pris en charge ou activé sur le client.
• Problèmes DNS : L'incapacité à résoudre correctement le nom d'hôte empêche la poignée de main d'authentification.

Comment résoudre RDP NLA ne fonctionne pas [7 solutions]

Si vous rencontrez des erreurs d'authentification au niveau réseau (NLA), suivez ces solutions dans l'ordre. Ces approches méthodiques aident à rétablir l'accès tout en préservant la sécurité du système.

Solution 1 : Confirmer la prise en charge de NLA sur le client et le serveur

Premièrement, assurez-vous que les deux extrémités sont techniquement capables de gérer NLA.

Étape 1. Vérifier la version du système d'exploitation : Exécutez winver sur les deux machines pour confirmer qu'elles exécutent Windows Vista / Windows Server 2008 ou une version ultérieure.

Étape 2. Mettre à jour les clients : Assurez-vous que les dernières mises à jour du client Bureau à distance sont installées via Windows Update ou l'application officielle Microsoft Remote Desktop.

Étape 3. Applications tierces : Si vous utilisez des clients RDP non-Windows, vérifiez que la prise en charge de NLA est explicitement activée dans les paramètres.

Étape 4. Planifier une mise à niveau : Si un composant ne prend pas en charge NLA, planifiez une mise à niveau plutôt que de réduire la sécurité de façon permanente.

Solution 2 : Vérifier la connectivité au contrôleur de domaine

Pour les machines jointes à un domaine, une connexion rompue à l'Active Directory (AD) déclenche souvent des échecs NLA.

Étape 1. Tester l'accessibilité : Utilisez ping dc01.yourdomain.com pour vérifier le chemin réseau vers votre contrôleur de domaine.

Étape 2. Localiser le DC : Exécutez nltest /dsgetdc:yourdomain.com pour confirmer que le client peut découvrir un DC.

Étape 3. Vérifier le canal sécurisé : Exécutez PowerShell en tant qu'administrateur et entrez :

• Test-ComputerSecureChannel

Étape 4. Réparer l'approbation : Si le résultat est Faux, réparez le canal sécurisé en utilisant :

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

Étape 5. Redémarrer : Redémarrez la machine après la réparation si vous y êtes invité.

Solution 3 : Aligner les niveaux de correctifs et les stratégies CredSSP

Des mises à jour CredSSP non correspondantes entre le client et le serveur sont la cause la plus fréquente de l'erreur "Remédiation de l'oracle de chiffrement".

Étape 1. Installer les mises à jour : Assurez-vous que toutes les mises à jour de sécurité cumulatives sont installées sur les deux terminaux.

Étape 2. Configurer la GPO : Ouvrez gpedit.msc et accédez à :

• Configuration ordinateur > Modèles d'administration > Système > Délégation des informations d'identification.

Étape 3. Ajuster la remédiation : Double-cliquez sur Remédiation de l'oracle de chiffrement. Définissez-le sur Activé et, pour un test temporaire, définissez le niveau de protection sur Vulnérable.

Étape 4. Correction à long terme : Une fois la connectivité rétablie, priorisez la mise à jour corrective de tous les systèmes à un niveau cohérent et rétablissez la stratégie sur Atténué.

Correction 4 : Activer et Valider les Protocoles TLS Requis

L'ANR repose sur des protocoles de sécurité modernes. Si TLS 1.2 est désactivé, la négociation échouera.

Étape 1. Vérification du Registre : Accédez au chemin suivant dans l'Éditeur du Registre :

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

Étape 2. Activer la Clé : Assurez-vous que la valeur DWORD Enabled est définie sur 1.

Étape 3. Clés Serveur : Vérifiez des paramètres similaires dans la sous-clé Server du même chemin.

Étape 4. Vérification du Certificat : Assurez-vous que le certificat RDP est valide et n'utilise pas de signatures obsolètes. Redémarrez les Services Bureau à distance dans services.msc pour actualiser le certificat.

Correction 5 : Examiner et Ajuster les Paramètres de Stratégie de Groupe

Les Objets de Stratégie de Groupe (GPO) peuvent imposer l'ANR d'une manière qui entre en conflit avec votre environnement spécifique.

Étape 1. Stratégie de Sécurité Locale : Ouvrez gpedit.msc et accédez à :

• Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.

Étape 2. Audit de l'Application : Vérifiez la stratégie "Exiger l'authentification de l'utilisateur pour les connexions distantes à l'aide de l'authentification au niveau réseau".

Étape 3. Vérifier la Cryptographie : Assurez-vous que les stratégies concernant les algorithmes conformes à FIPS ne bloquent pas la connexion.

Étape 4. Synchroniser la Stratégie : Alignez les niveaux d'application de l'ANR avec les capacités de vos appareils clients autorisés.

Correction 6 : Réinitialiser la Configuration du Client RDP et du Réseau

Si le problème est isolé à un appareil spécifique, effectuez une réinitialisation locale.

Étape 1. Effacer les Paramètres en Cache : Supprimez le fichier caché Default.rdp situé dans %userprofile%\Documents.

Étape 2. Réinitialiser les informations d'identification : Ouvrez le Gestionnaire d'informations d'identification Windows et supprimez toutes les entrées RDP enregistrées.

Étape 3. Vérifier le pare-feu : Confirmez que le port TCP 3389 est ouvert sur les pare-feux locaux et le matériel réseau intermédiaire.

Étape 4. Test croisé : Tentez une connexion depuis un client différent sur le même réseau pour déterminer si le problème est spécifique à l'appareil.

Solution 7 : Désactiver temporairement la NLA pour récupérer l'accès

Si vous êtes complètement bloqué hors d'un serveur critique, vous pouvez désactiver temporairement la NLA pour effectuer des réparations.

Étape 1. Méthodes : Démarrez en Mode sans échec avec prise en charge réseau ou utilisez un support de récupération pour charger la ruche système.

Étape 2. Modification du Registre : Accédez à :

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Étape 3. Modifier la valeur : Définissez UserAuthentication sur 0.

Étape 4. Avertissement de sécurité : Cela expose votre serveur à des attaques par force brute. Corrigez la cause racine immédiatement et réactivez la NLA (remettez la valeur à 1) dès que possible.

Astuce bonus : Utilisez AnyViewer comme alternative fiable au RDP

Si vous en avez assez de dépanner les erreurs NLA ou si vous avez besoin d'une connexion urgente à un serveur distant sans plonger dans les modifications du Registre ou de la Stratégie de groupe, AnyViewer est une alternative puissante et de niveau professionnel au Bureau à distance Windows.

Contrairement au RDP, qui repose fortement sur des protocoles complexes spécifiques à Windows comme CredSSP et NLA, AnyViewer utilise sa propre technologie de connexion optimisée pour contourner ces échecs de négociation courants tout en maintenant un haut niveau de sécurité.

• Pourquoi cela fonctionne : AnyViewer ne nécessite pas que NLA soit configuré sur l'hôte. Il utilise le chiffrement par courbes elliptiques (ECC) pour protéger vos données de bout en bout, garantissant la sécurité sans les tracas de configuration RDP.
• Facilité d'utilisation : Il fonctionne sur différents réseaux (y compris via Internet) sans nécessiter de redirection de ports ou de VPN.
• Performances : Il propose des transferts de fichiers à haute vitesse et un contrôle à distance à faible latence, ce qui le rend idéal pour le support informatique et le travail à distance.

Comment configurer AnyViewer :

Étape 1. Télécharger et installer : Installez AnyViewer sur les machines Windows locales et distantes.

Étape 2. Créer un compte : Inscrivez-vous pour un compte gratuit et connectez-vous sur les deux appareils.

Étape 3. Se connecter : Dans l'onglet "Appareil", trouvez l'ordinateur distant et cliquez sur "Contrôle en un clic" pour établir une session d'accès à distance sans surveillance.

En utilisant AnyViewer, vous pouvez contourner complètement les erreurs "RDP NLA Not Working" et reprendre le travail en quelques minutes.

Conclusion

Résoudre les erreurs NLA peut être une tâche complexe impliquant des configurations système approfondies. Bien que corriger la cause racine, comme les incompatibilités CredSSP ou les problèmes DNS, soit la meilleure approche pour la santé à long terme du serveur, disposer d'une solution de secours fiable comme AnyViewer garantit qu'une simple erreur de protocole ne vous bloque pas l'accès à votre infrastructure critique.

N'oubliez pas de réactiver les fonctionnalités de sécurité une fois votre dépannage terminé pour maintenir votre environnement réseau robuste et protégé.

FAQ