L'ordinateur distant requiert une authentification au niveau du réseau qu'il ne prend pas en charge. Une erreur d'authentification s'est produite. La fonction spécifiée n'est pas prise en charge. Désactiver NLA pour RDP sous Windows

Après avoir installé la mise à jour KB4103718 sur mon ordinateur Windows 7, je ne peux pas me connecter à distance à un serveur exécutant Windows Server 2012 R2 via RDP Remote Desktop. Après avoir spécifié l'adresse du serveur RDP dans la fenêtre du client mstsc.exe et cliqué sur "Connect", une erreur apparaît :

Connexion Bureau à distance

Une erreur d'authentification s'est produite.

La fonction spécifiée n'est pas prise en charge.
Ordinateur distant : nom de l'ordinateur

Après avoir désinstallé la mise à jour KB4103718 et redémarré mon ordinateur, la connexion RDP a commencé à fonctionner correctement. Si je comprends bien, il ne s'agit que d'une solution de contournement temporaire, un nouveau package de mise à jour cumulative arrivera-t-il le mois prochain et l'erreur reviendra-t-elle ? Aucun conseil?

Réponse

Vous avez tout à fait raison de dire qu'il est inutile de résoudre le problème, car vous exposez ainsi votre ordinateur au risque d'exploiter diverses vulnérabilités qui sont fermées par les correctifs de cette mise à jour.

Vous n'êtes pas seul dans votre problème. Cette erreur peut apparaître sur n'importe quel système d'exploitation Windows ou Windows Server (pas seulement Windows 7). Pour les utilisateurs de la version anglaise de Windows 10, lorsqu'ils tentent de se connecter au serveur RDP/RDS, une erreur similaire ressemble à ceci :

Une erreur d'authentification s'est produite.

La fonction demandée n'est pas prise en charge.

Ordinateur distant : nom de l'ordinateur

L'erreur RDP « Une erreur d'authentification s'est produite » peut également apparaître lorsque vous essayez de lancer des applications RemoteApp.

Pourquoi cela arrive-t-il? Le fait est que votre ordinateur dispose des dernières mises à jour de sécurité (publiées après mai 2018), qui corrigent une grave vulnérabilité dans le protocole CredSSP (Credential Security Support Provider), qui est utilisé pour l'authentification sur les serveurs RDP (CVE-2018-0886) ( Je recommande de lire l'article). En même temps, du côté du serveur RDP/RDS auquel vous vous connectez depuis votre ordinateur, ces mises à jour ne sont pas installées et le protocole NLA (Network Level Authentication) est activé pour l'accès RDP. NLA utilise des mécanismes CredSSP pour pré-authentifier les utilisateurs via TLS / SSL ou Kerberos. Votre ordinateur, en raison des nouveaux paramètres de sécurité que la mise à jour que vous avez installée, bloque simplement la connexion à l'ordinateur distant qui utilise la version vulnérable de CredSSP.

Que peut-on faire pour corriger cette erreur et se connecter à votre serveur RDP ?

1. Plus à droite le moyen de résoudre le problème consiste à installer les dernières mises à jour de sécurité Windows sur l'ordinateur/serveur auquel vous vous connectez via RDP ;
2. Méthode temporaire 1 ... Vous pouvez désactiver l'authentification au niveau du réseau (NLA) du côté du serveur RDP (décrit ci-dessous) ;
3. Méthode temporaire 2 ... Vous pouvez, côté client, autoriser les connexions aux serveurs RDP avec une version non sécurisée de CredSSP, comme décrit dans l'article sur le lien ci-dessus. Pour ce faire, vous devez modifier la clé de registre Autoriser le chiffrementOracle(commande REG ADD
   HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Policies \ System \ CredSSP \ Parameters / v AllowEncryptionOracle / t REG_DWORD / d 2) ou modifier les paramètres de la stratégie locale Chiffrement Oracle Correction/ Correction de la vulnérabilité de l'oracle de chiffrement) en définissant sa valeur = Vulnérable / Quitter la vulnérabilité).

   C'est le seul moyen d'accéder à un serveur distant via RDP si vous n'avez pas la possibilité de vous connecter au serveur localement (via la console ILO, la machine virtuelle, l'interface cloud, etc.). Dans ce mode, vous pourrez vous connecter à un serveur distant et installer des mises à jour de sécurité, vous passerez donc à la méthode 1 recommandée. Après la mise à jour du serveur, n'oubliez pas de désactiver la politique ou de retourner la valeur clé AllowEncryptionOracle = 0 : REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Paramètres/v AllowEncryptionOracle/t REG_DWORD/d 0

Désactiver NLA pour RDP sous Windows

Si NLA est activé du côté du serveur RDP auquel vous vous connectez, cela signifie que CredSPP est utilisé pour pré-authentifier l'utilisateur RDP. Vous pouvez désactiver l'authentification au niveau du réseau dans les propriétés du système sur l'onglet Accès à distance(À distance) en décochant la case « Autoriser les connexions uniquement depuis les ordinateurs exécutant Remote Desktop avec authentification au niveau du réseau (recommandé) » (Windows 10 / Windows 8).

Windows 7 a un nom différent pour cette option. Dans l'onglet Accès à distance vous devez sélectionner l'option " Autoriser les connexions à partir d'ordinateurs avec n'importe quelle version de Remote Desktop (dangereux)/ Autoriser les connexions à partir d'ordinateurs exécutant n'importe quelle version de Remote Desktop (moins sécurisé)".

Il est également possible de désactiver l'authentification au niveau du réseau (NLA) à l'aide de l'éditeur de stratégie de groupe local - gpedit.msc(sous Windows 10 Home, l'éditeur de stratégie gpedit.msc peut être lancé) ou en utilisant la console de gestion des stratégies de domaine - GPMC.msc. Pour cela, rendez-vous dans la rubrique Configuration ordinateur -> Modèles d'administration -> Composantsles fenêtres-> Services Bureau à distance - Hôte de session Bureau à distance -> Sécurité(Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Services Bureau à distance - Hôte de session Bureau à distance -> Sécurité), déconnecter(Exiger l'authentification de l'utilisateur pour les connexions à distance à l'aide de l'authentification au niveau du réseau).

Aussi nécessaire en politique » Exiger un niveau de sécurité spécifique pour les connexions RDP distantes»(Nécessite l'utilisation d'une couche de sécurité spécifique pour les connexions à distance (RDP)) sélectionnez la couche de sécurité - RDP.

Pour appliquer les nouveaux paramètres RDP, vous devez mettre à jour les stratégies (gpupdate / force) ou redémarrer l'ordinateur. Après cela, vous devez vous connecter avec succès au bureau distant du serveur.

Nous ouvrons l'éditeur de registre.

Branche HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Ouvrez le paramètre Security Packages et recherchez le mot tspkg. S'il n'y est pas, ajoutez-le aux paramètres existants.

Branche HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders

Ouvrez le paramètre SecurityProviders et ajoutez credssp.dll aux fournisseurs existants, s'il n'y en a pas.

Fermez l'éditeur de registre.

Maintenant, vous devez redémarrer. Si cela n'est pas fait, l'ordinateur nous demandera un nom d'utilisateur et un mot de passe, mais au lieu du bureau à distance, il répondra à ce qui suit :

C'est tout, en fait.

Les administrateurs de serveurs basés sur Windows 2008 peuvent être confrontés au problème suivant :

La connexion via le protocole rdp à votre serveur préféré depuis une station Windows XP SP3 échoue avec l'erreur suivante :

Le bureau à distance est désactivé.

L'ordinateur distant requiert une authentification au niveau du réseau que cet ordinateur ne prend pas en charge. Contactez votre administrateur système ou le support technique pour obtenir de l'aide.

Et bien que le prometteur Win7 menace de remplacer à terme sa grand-mère WinXP, le problème restera urgent pendant encore un an ou deux.

Voici ce que vous devez faire pour activer le mécanisme d'authentification de la couche réseau :

Nous ouvrons l'éditeur de registre.

Branche HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

Ouvrir le paramètre Forfaits de sécurité et chercher un mot là-bas à soupe... S'il n'y est pas, ajoutez-le aux paramètres existants.

Branche HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders

Ouvrir le paramètre Fournisseurs de sécurité et ajouter aux fournisseurs existants crdssp.dll s'il n'y en a pas.

Fermez l'éditeur de registre.

Maintenant, vous devez redémarrer. Si cela n'est pas fait, lors de la tentative de connexion, l'ordinateur nous demandera un nom d'utilisateur et un mot de passe, mais au lieu du bureau à distance, il répondra à ce qui suit :

Connexion Bureau à distance

Erreur d'authentification (code 0x507)

C'est tout, en fait.

Il y a toujours eu des problèmes avec la sécurité et la vitesse des serveurs, et chaque année leur pertinence ne fait que croître. Par conséquent, Microsoft est passé du modèle d'authentification côté serveur d'origine à l'authentification au niveau du réseau.

Quelle est la différence entre ces modèles ?
Auparavant, lors de la connexion aux services Terminal Server, l'utilisateur créait une session avec le serveur, à travers laquelle ce dernier chargeait l'écran de saisie des informations d'identification de l'utilisateur. Cette méthode consomme les ressources du serveur avant même que l'utilisateur n'ait confirmé sa légalité, ce qui permet à un utilisateur illégal de charger complètement les ressources du serveur avec plusieurs demandes de connexion. Un serveur incapable de traiter ces requêtes refuse de traiter les requêtes des utilisateurs légitimes (attaque DoS).

L'authentification au niveau du réseau (NLA) oblige l'utilisateur à saisir ses informations d'identification dans une boîte de dialogue côté client. Par défaut, s'il n'y a pas d'authentification au niveau du réseau côté client, le serveur n'autorisera pas la connexion et cela ne se produira pas. NLA demande à l'ordinateur client de fournir ses informations d'authentification, avant même de créer une session avec le serveur. Ce processus est également appelé authentification frontale.

NLA a été réintroduit dans RDP 6.0 et était pris en charge nativement par Windows Vista. À partir de RDP 6.1 - pris en charge par les serveurs exécutant Windows Server 2008 et versions ultérieures, et une prise en charge client est fournie pour Windows XP SP3 (vous devez autoriser un nouveau fournisseur de sécurité dans le registre) et versions ultérieures. La méthode utilise le fournisseur de sécurité Credential Security Support Provider (CredSSP). Si vous utilisez un client de bureau à distance pour un autre système d'exploitation, vous devez vous renseigner sur sa prise en charge NLA.

• Ne nécessite pas de ressources serveur importantes.
• Une couche supplémentaire pour se protéger contre les attaques DoS.
• Accélère le processus de médiation entre le client et le serveur.
• Vous permet d'étendre la technologie NT de « connexion unique » pour qu'elle fonctionne avec un serveur de terminaux.

• Les autres fournisseurs de sécurité ne sont pas pris en charge.
• Non pris en charge par les versions client inférieures à Windows XP SP3 et les versions serveur inférieures à Windows Server 2008.
• Il est nécessaire de configurer manuellement le registre sur chaque client Windows XP SP3.
• Comme tout schéma de "connexion unique", il est vulnérable au vol des "clés de l'ensemble de la forteresse".
• Il n'est pas possible d'utiliser la fonction "Demander un changement de mot de passe à la prochaine connexion".

Si vous utilisez Windows XP lors de la connexion au serveur, vous pouvez obtenir une erreur : « L'ordinateur distant requiert une authentification au niveau du réseau, ce que cet ordinateur ne prend pas en charge. »

Cette erreur est due au fait qu'initialement dans Windows XP, l'authentification au niveau du réseau n'a pas été implémentée ; les développeurs ont implémenté cette fonctionnalité dans les systèmes d'exploitation suivants. Un fichier de mise à jour a également été publié plus tard. KB951608 qui a corrigé ce bogue et permis à Windows XP d'implémenter l'authentification au niveau du réseau.

Pour que vous puissiez vous connecter au bureau à distance du serveur à partir de votre ordinateur exécutant Windows XP, vous devez installer le Service Pack 3 (SP3), puis procédez comme suit :

Sur le site officiel de Microsoft sur la page en russe https://support.microsoft.com/ru-ru/kb/951608 téléchargez le fichier de correction automatique. Faites défiler la page vers le bas et cliquez sur le bouton « Télécharger » dans la section « Aide à la résolution du problème ».

Une page en anglais est également à votre disposition https://support.microsoft.com/en-us/kb/951608 où vous pouvez télécharger ce fichier en cliquant sur le bouton "Télécharger" dans la section "Comment activer CredSSP"

Après avoir téléchargé le fichier, exécutez-le pour l'exécution. Après avoir démarré ce fichier, vous verrez la fenêtre du programme. Dans celui-ci, à la première étape, cochez la case "J'accepte". Dans la deuxième étape, cliquez sur le bouton "Suivant"

Une fois l'installation terminée, vous verrez la fenêtre suivante avec la notification "Ce correctif Microsoft a été traité". Il vous suffit de cliquer sur "Fermer".

Après avoir cliqué sur le bouton "Fermer", le programme vous dira que les modifications prennent effet, vous devez redémarrer l'ordinateur, cliquez sur "Oui" pour redémarrer.

Résolvez le problème vous-même sans télécharger le fichier

Si vous avez des compétences administratives, vous pouvez apporter des modifications au registre de votre ordinateur manuellement, sans avoir à télécharger le fichier de correctif.

1. Cliquez sur le bouton Démarrer, sélectionnez l'élément Courir, entrez la commande regedit et appuyez sur la touche Entrer