Der interne Fehler des Remotedesktops versucht, nach der Installation der NSA-Patches eine Verbindung herzustellen

Ich habe gerade das neueste Windows-Update installiert (NSA-Schwachstellen-Patch Dienstag) und kann jetzt keine Verbindung zum Remotedesktop herstellen.

• Der Server wird remote gehostet. Ich habe keinen physischen Zugang. Server 2012 R1.
• Glücklicherweise laufen alle Websites nach dem Neustart einwandfrei.
• Ich habe noch keinen zweiten Neustart versucht, weil ich ein wenig Angst davor habe.
• Wenn ich versuche, eine Verbindung herzustellen, wird sofort folgende Meldung angezeigt:
• „ Remote Desktop Connection : Ein interner Fehler ist aufgetreten“

• Habe es von mehreren Kunden versucht. Sie alle scheitern - einschließlich einer iOS-App, die mir zusätzlich einen 0x00000904-Fehler gibt.
• Wenn ich laufe telnet servername 3389, wird eine Verbindung hergestellt, sodass ich weiß, dass der Port offen ist.
• Ich kann von meinem Win 10-Computer (nicht gepatcht) problemlos eine Verbindung zu anderen Servern herstellen.
• Ich kann auch keine Verbindung von meinem zweiten Laptop herstellen, bei dem es sich um die Win 10 Creators Edition handelt.
• In der Ereignisanzeige kann nichts Nützliches gefunden werden.
• Ich habe sogar Wireshark ausprobiert, was mir nichts Nützliches zeigte.
• Das Beste, was ich diagnostizieren muss, ist die Möglichkeit, eine ASPX-Seite hochzuladen und auszuführen.

Ich verstehe, dass die letzte Patch-Zusammenfassung der 'NSA Edition' einige RDP-Korrekturen hatte - aber ich kann niemanden finden, der plötzlich Probleme hatte, die Woche getroffen wurden.

Ich möchte eine Vorstellung davon haben, wo das Problem liegt, bevor ich mich an das Hosting-Unternehmen wende. Deshalb poste ich hier.

Aktualisieren:

Obwohl ich immer noch keinen physischen Serverzugriff habe, habe ich mich daran erinnert, dass auf dem Server selbst eine Windows 7-VM gehostet ist. Ich konnte darauf zugreifen und das Snap-In für Serverzertifikate öffnen, indem ich eine Verbindung zur lokalen IP 10.0.0.1 herstellte.

Dies zeigt, dass das RDP-Zertifikat tatsächlich abgelaufen ist - obwohl ich beim Verbinden keine Fehler erhalte, die dies vorschlagen. Ich habe sicherlich täglich eine Verbindung hergestellt und seit dem Ablauf vor 2 Monaten habe ich vermutet, dass durch ein Sicherheitsupdate alle anderen Zertifikate im Remotedesktop-Speicher entfernt wurden und es sich nicht selbst erneuert hat.

Versuchen Sie also, hier einen Weg zu finden, um jetzt ein anderes Zertifikat zu installieren.

Update 2

Schließlich finden Sie dies im Ereignisprotokoll unter 'Administrative Ereignisse' (durch Remote-Verbindung über die VM):

"Der Terminalserver konnte kein neues selbstsigniertes Zertifikat erstellen, das für die Terminalserverauthentifizierung bei SSL-Verbindungen verwendet werden soll. Der relevante Statuscode lautete" Objekt ist bereits vorhanden "."

Dies scheint hilfreich zu sein, wenn auch ein etwas anderer Fehler. Ich kann heute Abend nicht neu starten, muss es also morgen erneut überprüfen.

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

Die Lösung ist im Grunde hier

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

Das hat auch geholfen:

https://social.technet.microsoft.com/Forums/ie/en-US/a9c734c1-4e68-4f45-be46-8cae44c95257/unable-to-remote-desktop-to-windows-server-2012-due-to- Fehler beim Erstellen eines selbstsignierten Zertifikats? forum = winserverTS

Angenommen, Sie haben bereits überprüft, dass das unter Zertifikate> Remotedesktop> Zertifikate aufgeführte Zertifikat nicht gültig ist ...

Hinweis: Ich habe diesen Screenshot gemacht, nachdem ich alles repariert habe. Dieses Ablaufdatum ist also das neu erstellte Zertifikat, das es selbst erstellt hat.

Grundsätzlich müssen Sie diese Datei dann umbenennen oder löschen - und dann wird sie neu erstellt:

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

Dies ist ein bekannter Dateiname, der in beginnt f686aace. Starten Sie dann den Remote Desktop ConfigurationDienst neu und er sollte neu erstellt werden. (Hinweis: Möglicherweise muss der Dienst nicht neu gestartet werden. Warten Sie nur eine Minute, bis er mit demselben Dateinamen neu erstellt wurde.)

Es kann einige Zeit dauern, bis Sie mit den Berechtigungen herumspielen, und Sie müssen möglicherweise den Besitz der Datei übernehmen und dann zusätzlich die Berechtigungen anwenden. Hinweis: Eigentum impliziert keine Berechtigungen. Sie müssen nach der Übernahme des Eigentums Berechtigungen hinzufügen.

Wie gesagt, ich habe keinen physischen Zugriff auf den Server - wenn Sie dies tun, sollte das oben Genannte ausreichen.

Ich hatte das Glück, über einen anderen Computer im selben lokalen Netzwerk eine Remoteverbindung herstellen und die Registrierung ändern zu können.

Ich wollte die Authentifizierung deaktivieren, damit ich eine Verbindung herstellen und remote zugreifen kann. Die Registrierungseinträge dazu sindHKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Setzen Sie die vorhandenen Schlüssel SecurityLayerund UserAuthenticationauf0

Erstellen Sie eine RDP-Datei (öffnen Sie mstsc und klicken Sie nach Eingabe des Servernamens auf Speichern) und fügen Sie die Zeile im Editor enablecredsspsupport:i:0irgendwo hinzu. Dies deaktiviert die Erwartung von Sicherheit.

Wenn Sie dann die RDP-Datei ausführen, sollte es Ihnen UNSECURELY ermöglichen, eine Verbindung herzustellen und Zugriff auf Ihren Server zu erhalten.

Sobald Sie eine Verbindung hergestellt haben, ändern Sie diese beiden Registrierungseinträge wieder und löschen Sie die f686...Datei ...

Diese Einstellungen haben mein Problem behoben:

1.Klicken Sie in der Systemsteuerung auf Verwaltung, und doppelklicken Sie dann auf Lokale Sicherheitsrichtlinie.

2. Erweitern Sie in den lokalen Sicherheitseinstellungen die Option Lokale Richtlinien, und klicken Sie dann auf Sicherheitsoptionen.

3. Doppelklicken Sie im rechten Bereich unter Richtlinie auf Systemkryptografie: Verwenden Sie FIPS-kompatible Algorithmen zum Verschlüsseln, Hashing und Signieren, und klicken Sie dann auf Aktiviert. In meinem Fall war es deaktiviert. Also habe ich es einfach aktiviert und den unten aufgeführten Befehl ausgegeben.

4. Führen Sie gpupdate / force aus

Eine weitere Option, die dieses Problem löst:

Die Protokolle wurden auf dem Server nicht aktiviert. Ich habe IIScrypto verwendet und TLS1.2 aktiviert, und alles hat funktioniert

Hallo an alle in meiner Umgebung, dies wurde verursacht, als ein neues selbstsigniertes Zertifikat generiert wurde. TLS 1.0 ist entweder in der Registrierung deaktiviert oder in der Registrierung nicht vorhanden, und das neue selbstsignierte Zertifikat befand sich nicht im Speicher der vertrauenswürdigen Stammzertifizierungsstellen.

Sie können dies auf zwei Arten beweisen, bevor Sie die Registrierung bearbeiten. Laden Sie IIS Crypto herunter und sehen Sie, was in Protokollen, Chiffren, Hashes und Schlüsselaustausch aktiviert und deaktiviert ist.

Manchmal zeigt IIS Crypto jedoch, dass TLS aktiviert ist, obwohl es in der Registrierung nicht nur zu Ihrer Information aktiviert ist.

Ihre nächste Option ist das Aktivieren von FIPS in der lokalen Gruppenrichtlinie. Dadurch wird TLS 1.0, 1.1 und 1.2 aktiviert und verwendet. Aktivieren Sie FIPS und versuchen Sie dann, RDP auf Ihrem Computer zu installieren. Diesmal funktioniert es auch dann, wenn TLS in der Registrierung deaktiviert ist. Sie möchten FIPS nicht dauerhaft verwenden, obwohl dies nur zur Fehlerbehebung dient. Deaktivieren Sie es daher auf dem Server und rufen Sie die Registrierung auf.

Head to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNELund unter Protokolle hinzufügen drei neue Schlüssel Titel sie TLS 1.0, TLS 1.1und TLS 1.2erstellen Sie dann zwei Unterschlüssel unter jedem TLS Eintrag Titel ihnen Clientund Server.

Im Innern des Clientund ServerSchlüssel erstellen zwei 32 - Bit - DWORD - Eintrag einen Titel DisabledByDefaultmit dem Valueauf 0 gesetzt und Enabledmit dem Wert auf 1 gesetzt.

Sobald Sie dies tun und Ihr selbstsigniertes Zertifikat nicht abgelaufen ist und Sie sich in den richtigen Filialen befinden, können Sie wieder RDP auf Ihren Server übertragen.