Bitte beachten Sie, dass sich dieses Szenario von einem ähnlichen unterscheidet: Wie deaktiviere ich TLS 1.0, ohne RDP zu unterbrechen?
Die verknüpfte Frage betrifft RDP und das Deaktivieren von TLS 1.0.
Diese Frage betrifft RemoteApps und das Deaktivieren von TLS 1.0
Ich habe bereits direktes RDP über Port 3389, das mit TLS 1.2 funktioniert.
Wir haben einen 2012R2-Server, der RemoteApps hostet.
Wir haben die Rollen RD-Gateway, RD-Webzugriff, RD-Verbindungsbroker und RD-Sitzungshost auf diesem Server installiert.
RemoteApps werden über das RD-Gateway per https bereitgestellt. Der einzige öffentliche Port, den wir geöffnet haben, ist 443.
Wir haben in allen RD-Rollen und IIS ein von einer öffentlichen Zertifizierungsstelle bereitgestelltes Wildcard-SSL-Zertifikat installiert, sodass alles auf ein vertrauenswürdiges Stammzertifikat zurückgeführt werden kann.
Das Zertifikat unterstützt TLS 1.2, ich sehe dies in einem Webbrowser, wenn ich die RDWeb-Website ansehe.
Wir versuchen, TLS 1.0 auf diesem Server zu deaktivieren, um die Sicherheit zu erhöhen. Wir verwenden IISCrypto 2.0, um TLS 1.0 zu deaktivieren.
Wenn wir TLS 1.0 deaktivieren, werden zwei Dinge beobachtet:
1. Die RemoteApps funktionieren nicht mehr. Sie können nicht von einem Endbenutzercomputer aus gestartet werden.
2. Direkte RDP-Verbindungen funktionieren einwandfrei.
Wenn wir TLS 1.0 wieder aktivieren, funktionieren die RemoteApps wieder.
Die SChannel-Protokollierung bestätigt, dass RemoteApps TLS 1.2 verwenden. Daher würde ich erwarten, dass die RemoteApps weiterhin funktionieren, wenn TLS 1.0 deaktiviert ist. Das ist jedoch nicht das, was ich beobachte.
Alle Clients verwenden vollständig aktualisierte/gepatchte Versionen von Windows 8.1 und 10.
Antwort1
Nach fast einem Jahr habe ich endlich eine funktionierende Lösung gefunden, um TLS 1.0/1.1 zu deaktivieren, ohne die RDP- und Remotedesktopdienste-Konnektivität zu unterbrechen.
Führen Sie IISCrypto aus und deaktivieren Sie TLS 1.0, TLS 1.1 und alle fehlerhaften Chiffren.
Öffnen Sie auf dem Remotedesktopdienste-Server, auf dem die Gateway-Rolle ausgeführt wird, die lokale Sicherheitsrichtlinie und navigieren Sie zu Sicherheitsoptionen – Systemkryptografie: Verwenden Sie FIPS-kompatible Algorithmen für Verschlüsselung, Hashing und Signierung. Ändern Sie die Sicherheitseinstellung auf Aktiviert. Führen Sie einen Neustart durch, damit die Änderungen wirksam werden.
Beachten Sie, dass in einigen Fällen (insbesondere bei Verwendung selbstsignierter Zertifikate auf Server 2012 R2) die Sicherheitsrichtlinienoption „Netzwerksicherheit: LAN Manager-Authentifizierungsebene“ möglicherweise auf „Nur NTLMv2-Antworten senden“ eingestellt werden muss.
Lassen Sie mich wissen, ob das auch für Sie funktioniert.
Antwort2
Systemkryptografie: Verwenden Sie FIPS-kompatible Algorithmen für Verschlüsselung, Hashing und Signierung.
Dadurch werden die älteren Protokolle heimlich wieder aktiviert. Microsoft empfiehlt sogar nicht mehr, diese Einstellung zu verwenden.
Ich kämpfe auch damit. Ich habe noch nicht die richtige Lösung gefunden.
Antwort3
Altes Posting, aber ich habe gerade zufällig einen Artikel gelesen, in dem steht, dass, wenn Sie den internen SQL-Server (WID) für die Verbindungsbroker-Datenbank verwenden, der Verbindungsbroker TLS 1.0 aktiviert haben muss, um mit WID kommunizieren zu können. Sie können dies umgehen, indem Sie für den Verbindungsbroker anstelle des internen SQL WID eine „echte“ SQL Server-Datenbank verwenden.