«Erreur interne» du bureau distant atteignant la connexion après l'installation des correctifs «NSA»


9

Je viens d'installer la dernière mise à jour de Windows (patch de vulnérabilité NSA mardi) et maintenant je ne peux plus me connecter au bureau distant.

  • Le serveur est hébergé à distance. Je n'ai pas d'accès physique. Server 2012 R1.
  • Heureusement, tous les sites Web fonctionnent correctement après le redémarrage.
  • Je n'ai pas encore essayé un deuxième redémarrage car j'ai un peu peur.
  • Lorsque j'essaie de me connecter, je reçois immédiatement ce message:
  • " Connexion Bureau à distance : une erreur interne s'est produite"

entrez la description de l'image ici

  • J'ai essayé de plusieurs clients. Ils échouent tous - y compris une application iOS qui me donne en outre une erreur 0x00000904.
  • Si je lance, telnet servername 3389il lance une connexion, donc je sais que le port est ouvert.
  • Je peux très bien me connecter à d'autres serveurs depuis ma machine Win 10 (non corrigée).
  • Je ne peux pas non plus me connecter à partir de mon deuxième ordinateur portable, qui est l'édition Win 10 Creators.
  • Impossible de trouver quoi que ce soit d'utile dans l'Observateur d'événements.
  • J'ai même essayé WireShark qui ne m'a rien montré d'utile.
  • Le meilleur que j'ai à diagnostiquer est la possibilité de télécharger une page ASPX et de l'exécuter.

Je comprends que la récente rafle de correctifs «édition NSA» contenait des correctifs RDP - mais je ne trouve personne d'autre qui a soudainement eu des problèmes pendant la semaine.

Je veux avoir une idée du problème avant de contacter la société d'hébergement, c'est pourquoi je poste ici.


Mise à jour:

Bien que je n'aie toujours pas accès au serveur physique, je me suis souvenu que j'avais une machine virtuelle Windows 7 hébergée sur le serveur lui-même. J'ai pu y entrer et ouvrir le composant logiciel enfichable de certificats de serveur en me connectant à l'IP locale 10.0.0.1.

Cela montre que le certificat RDP est en effet expiré - bien que je ne reçoive aucune erreur lors de la connexion de cette suggestion en tant que telle. Je me connecte certainement tous les jours et depuis son expiration il y a 2 mois, je suppose qu'une sorte de mise à jour de sécurité a supprimé tout autre certificat dans le magasin Remote Desktop et qu'il ne s'est pas renouvelé.

Donc, essayer de trouver un moyen d'installer un certificat différent ici maintenant.

Update 2

Enfin trouvé cela dans le journal des événements sous «Événements administratifs» (en se connectant à distance via la machine virtuelle):

"Le serveur Terminal Server n'a pas réussi à créer un nouveau certificat auto-signé à utiliser pour l'authentification Terminal Server sur les connexions SSL. Le code d'état correspondant était Objet existe déjà."

Cela semble utile, bien qu'il s'agisse d'une erreur légèrement différente. Je ne peux pas redémarrer ce soir, alors je devrai vérifier à nouveau demain.

https://blogs.technet.microsoft.com/the_9z_by_chris_davis/2014/02/20/event-id-1057-the-terminal-server-has-failed-to-create-a-new-self-signed-certificate/

entrez la description de l'image ici


2
Il serait bon que vous nous indiquiez exactement quelle ou quelles mises à jour vous avez installées au lieu de vous y référer en tant que NSA vulnerability patch tuesday. Tout le monde ne se soucie pas de jouer à "Mystery Update Theater 3000".
joeqwerty

J'aimerais vous le dire - mais je viens de lancer la mise à jour de Windows, puis il a redémarré - et maintenant je ne peux pas entrer. J'ai joué au Theater 3000 toute la journée en essayant de penser à une stratégie. Il y a de fortes chances que si je fais redémarrer la société d'hébergement, ce sera bien, mais j'ai l'impression de m'être enfermé hors de ma maison et j'envoie un serrurier alors que je ne serai même pas là. Dieu merci, j'ai un accès à distance pour le serveur SQL / FTP et tous les sites Web fonctionnent correctement. S'il y a une commande à exécuter pour voir les mises à jour, je peux essayer cela
Simon

1
Vous pouvez essayer de consulter l'historique des mises à jour Windows et de désinstaller les mises à jour une par une (si elles prennent en charge la désinstallation) jusqu'à ce que le problème se résout. Notez les mises à jour que vous désinstallez afin de pouvoir identifier la mise à jour suspecte.
joeqwerty

mais je n'ai pas accès au bureau pour le faire. c'est le problème. Je n'ai accès à la ligne de commande qu'en exécutant une commande via une page Web ASPNET. J'essaie d'exécuter systeminfo.exe pour obtenir la sortie maintenant
Simon

Droite. J'ai oublié ça. Ma faute. Mes excuses.
joeqwerty

Réponses:


9

La solution est fondamentalement là

https://blogs.technet.microsoft.com/askpfeplat/2017/02/01/removing-self-signed-rdp-certificates/

Cela a également aidé:

https://social.technet.microsoft.com/Forums/ie/en-US/a9c734c1-4e68-4f45-be46-8cae44c95257/unable-to-remote-desktop-to-windows-server-2012-due-to- échec de création d'un certificat auto-signé? forum = winserverTS

En supposant que vous avez déjà vérifié que le certificat répertorié sous Certificats> Bureau à distance> Certificats n'est pas valide ...

entrez la description de l'image ici

Remarque: J'ai pris cette capture d'écran après avoir tout résolu - cette date d'expiration est donc le certificat nouvellement créé qui a tout fait par lui-même.

Vous devez ensuite renommer ou supprimer ce fichier - puis il le recréera:

"C: \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys \ f686aace6942fb7f7ceb231212eef4a4_a54b3870-f13c-44bb-98c7-d0511f3e1757"

Il s'agit d'un nom de fichier bien connu commençant par f686aace. Redémarrez ensuite le Remote Desktop Configurationservice et il devrait le recréer. (Remarque: il peut ne pas être nécessaire de redémarrer le service - attendez simplement de voir s'il est recréé avec le même nom de fichier pendant une minute).

Cela peut prendre un peu de temps avec les autorisations et vous devrez peut-être vous approprier le fichier, puis appliquer des autorisations. Remarque: la propriété n'implique pas d'autorisations. Vous devez ajouter des autorisations après avoir pris possession.


Comme je l'ai dit, je n'ai pas d'accès physique au serveur - si vous le faites, ce qui précède devrait suffire.

J'ai eu la chance de pouvoir me connecter à distance via une autre machine sur le même réseau local et de changer le registre.

Je voulais désactiver l'authentification pour pouvoir me connecter et accéder à distance. Les entrées de registre pour ce faire sontHKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Définissez les clés existantes SecurityLayeret UserAuthenticationà0

Créez un fichier RDP (ouvrez mstsc et cliquez sur Enregistrer après avoir entré le nom du serveur) et dans le bloc-notes, ajoutez la ligne enablecredsspsupport:i:0quelque part. Cela désactive l'attente de sécurité.

Lorsque vous exécutez ensuite le fichier RDP, il devrait vous permettre de vous connecter de manière non sécurisée et d'accéder à votre serveur.

Dès que vous vous connectez, modifiez ces deux entrées de registre, puis continuez et supprimez le f686...fichier ...


J'utilise le certificat auto-signé et je n'ai jamais créé explicitement de certificat RDP. Si vous rencontrez ce même problème, la solution peut être légèrement différente si vous avez créé un certificat vous-même.
Simon

Semble coïncider avec les derniers correctifs - et j'ai eu quelques mois de toute façon!
Simon

PS. excusez ma réponse désorganisée - cela vient de gâcher tout un week-end. OK, j'ai terminé
Simon

C'est bizarre d'avoir soudain des votes positifs à ce sujet. Une nouvelle mise à jour est-elle à l'origine de ce problème?
Simon

3

Ces paramètres ont résolu mon problème:

Dans le Panneau de configuration, cliquez sur Outils d'administration, puis double-cliquez sur Stratégie de sécurité locale.

Dans Paramètres de sécurité locaux, développez Stratégies locales, puis cliquez sur Options de sécurité.

Sous Stratégie dans le volet droit, double-cliquez sur Cryptographie système: utilisez des algorithmes compatibles FIPS pour le cryptage, le hachage et la signature, puis cliquez sur Activé. Dans mon cas, il a été désactivé. Je viens donc de l'activer et j'ai lancé la commande ci-dessous.

  1. Exécutez gpupdate / force

Une autre option qui résoudra ce problème:

Les protocoles n'étaient pas activés sur le serveur. J'ai utilisé IIScrypto et activé TLS1.2 et tout a commencé à fonctionner


-1

Bonjour à tous dans mon environnement, cela a été provoqué lors de la génération d'un nouveau certificat auto-signé TLS 1.0 est désactivé dans le registre ou n'existe pas dans le registre et le nouveau certificat auto-signé n'était pas dans le magasin des autorités de certification racine de confiance.

Vous pouvez prouver cela de deux façons avant de modifier le registre. téléchargez IIS Crypto et voyez ce qui est activé et désactivé dans les protocoles, les chiffrements, les hachages et les échanges de clés.

Parfois, bien que IIS Crypto montre que TLS est activé même s'il n'est pas activé dans le registre, juste un FYI.

Votre prochaine option consiste à activer FIPS dans la stratégie de groupe locale, ce qui force TLS 1.0, 1.1 et 1.2 à être activé et utilisé. Activez FIPS, puis essayez de RDP sur votre ordinateur, cela fonctionnera cette fois même si TLS est désactivé dans le registre. Vous ne voulez pas utiliser FIPS de façon permanente bien que ce soit juste pour le dépannage, désactivez-le sur le serveur et dirigez-vous vers le registre.

À la tête HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELet sous Protocoles ajouter les trois nouveaux titres clés TLS 1.0, TLS 1.1et TLS 1.2puis créer deux sous - clés sous chaque titre d'entrée TLS les Clientet Server.

A l' intérieur du Clientet les Servertouches créer deux entrées DWORD 32 bits un titrés DisabledByDefaultavec l' Valueensemble à 0 et Enabledavec l'ensemble de la valeur à 1.

Une fois que vous faites cela et que votre certificat auto-signé n'est pas expiré et dans les magasins appropriés, vous pourrez à nouveau RDP sur votre serveur.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.