Tags: Sicherheit, RDS, Authentifizierung, Zertifikate
Wenn man mehrere Terminal-Server zu einer Sammlung (auch "Collection" oder "Farm") zusammenfasst, dann erwartet der RDP-Client, dass man eine Verbindung mit der Farm und nicht mit einzelnen Session Hosts aufbaut. Dies führt jedoch zu Problemen mit dem Zertifikat, wenn es den Namen des Servers und nicht der Sammlung enthält. Daher sollte man auf jedem Session Host ein Zertifikat installieren, das auf die Farm ausgestellt ist. Alternativ kann man ein SAN- oder Wildcard-Zertifikat verwenden.
Möchte man die Verbindung über den RDP-Client herstellen, dann ist die Warnung zum Zertifikatsproblem nur lästig. Der Benutzer hat nämlich die Möglichkeit, trotzdem fortzufahren, und die Meldung künftig zu unterdrücken, indem er die Checkbox Nicht erneut nach Verbindungen mit diesem Computer fragen aktiviert. Dagegen lässt sich das Problem nicht umgehen, wenn man RemoteApp mittels Webfeed in den Desktop von Windows 7/8.x integrieren möchte.
Farm-Zertifikat über AD ausstellen
Ein gängiger Ansatz beim Management von Terminal-Server-Farmen besteht darin, dass man eigene Zertifikate für RD Web Access, RD Gateway, RD Connection Broker sowie für die Sammlung der Session Hosts verwendet. Dabei kann man für Gateways und RD Web auch ein gemeinsames SAN-Zertifikat (Subject Alternate Name) verwenden, das die Namen aller beteiligten Server enthält.
Will man ein Zertifikat auf eine Farm mit Hilfe der Zertifikatdienste des Active Directory ausstellen, dann kann man dies über den IIS-Manager tun. Dieser verwendet das Template WebServer, das sich für die Server-Authentifizierung eignet und das zudem den Private Key exportierbar macht. Bevorzugt man dagegen ein SAN- oder Wildcard-Zertifikat, dann greift man zum MMC-Snapin Zertifikate (siehe dazu meine Anleitungen zu Subject Alternative Names und Wildcards).
Entscheidet man sich für ein Farm-Zertifikat und verwendet dafür den IIS-Manager, dann klickt man auf das Icon Serverzertifikate und führt dann den Befehl Domänenzertifikat erstellen aus. Im folgenden Dialog gibt man unter Gemeinsamer Name jenen der Farm ein, wahlweise den Host-Namen mit oder ohne Domäne, je nachdem, welche Form man nachher im RDP-Client verwendet.
Farm-Zertifikat auf den Session Host importieren
Ist das Zertifikat erstellt, kann man es im nächsten Schritt exportieren, damit man es dann auf die (anderen) Session Hosts übertragen kann. Auch das lässt sich über den IIS-Manager bewerkstelligen. Die gespeicherte .pfx-Datei kann man anschließend auf allen Terminal-Servern in den Zertifikatsspeicher importieren.
Zu diesem Zweck öffnet man das Zertifikat-Snap-in der MMC, am einfachsten indem man unter Windows 8.x nach Computerzertifikate sucht (alternativ startet man die MMC, fügt das Snap-in Zertifikate hinzu und wählt im folgenden Dialog Computerkonto). Schließlich führt man im Kontextmenü von Eigene Zertifikate => Zertifikate unter Alle Aufgaben den Befehl Importieren aus. Bei Zertifikatspeicher belässt man es bei Eigene Zertifikate.
Keine GUI für die Auswahl des Zertifikats
Während man RD Web Access, RD Gateway und dem Verbindungsbroker im Server Manager unter den Eigenschaften einer Bereitstellung Zertifikate zuweisen kann, gibt es für diese Aufgabe bei den Session Hosts kein grafisches Tool. Das ist ein Rückschritt von Windows Server 2012 gegenüber seinem Vorgänger, wo man zu diesem Zweck noch das Tool Konfiguration des Remotedesktop-Sitzungshosts verwenden konnte.
Verfügt man noch über einen Windows Server 2008 R2, dann besteht das einfachste Vorgehen darin, dort das Konfigurations-Tool zu starten und eine Verbindung mit dem Session Host auf einem Windows Server 2012 (R2) herzustellen. Anschließend öffnet man die Eigenschaften von RDP-Tcp und wählt in der Registerkarte Allgemein das zuvor importierte Farm-Zertifikat aus. Diesen Vorgang wiederholt man für alle Terminal-Server.
Hat man keinen Windows Server 2008 R2 zur Hand, dann muss man auf den Session Hosts mit der Kommandozeile Vorlieb nehmen. Zuerst ermittelt man den Fingerabdruck des betreffenden Zertifikats, am einfachsten mit PowerShell:
gci cert:\LocalMachine\My | select FriendlyName, Thumbprint
Den passenden Thumbprint übernimmt man anschließend in diesen Aufruf von wmic:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<Fingerabdruck>"
Auch diesen Befehl muss man für alle Session Hosts wiederholen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- Security-Updates KB5014754, KB5021130 und KB5020805 erreichen demnächst Erzwingungsmodus
- NTLM-Authentifizierung überwachen oder blockieren mit Gruppenrichtlinien
- Exchange Server und IIS mit Windows Extended Protection (WEP) absichern
- Microsoft ergänzt zertifikatbasierte Authentifizierung am Azure AD um Support für Smartcards
- KrbRelayUp: Domänen-Controller gegen Angriffe auf Resource-based constrained Delegation absichern
Weitere Links
4 Kommentare
Hallo,
Vielen Dank für die schöne Anleitung! Ich wollte gerade mit dem wmic Befehl das Zertifikat auf meinen ersten Session Host einbinden, erhalte aber die folgende Fehlermeldung:
PS C:\> wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="E1FC0D049A
FB6CE7DF7632DA4675ABEA9344B8F2"
Eigenschaften von "\\TS21\root\cimv2\TerminalServices:Win32_TSGeneralSetting.TerminalName="RDP-Tcp"" werden aktualisiert
FEHLER:
Beschreibung = Der Parameter ist ungültig.
PS C:\>
Was meint er hierbei mit "Der Parameter ist ungültig"?
Vielleicht haben Sie ja einen Tipp für mich.
Viele Grüße
Rainer Frühwacht
Hallo,
die Frage ist zwar schon etwas älter, aber vielleicht hilft der Tipp ja noch jemandem.
Neben dem Zertifikat muss auch der private Schlüssel bei den Computerzertifikaten unter "Meine Zertifikate" hinzugefügt worden sein. Ferner müssen die Stammzertifikate passen, d.h. der Herausgeber des Zertifikates muss valide sein (Zertifikat öffnen->Tab "Zertifizierungspfad").
Viele Grüße,
Joachim
Hallo,
liegt Ihr Zertifikat denn auch unter "Eigene Zertifikate" ?
Ich habe das Zertifikat wie beschrieben auf dem RDB und den RDSH hinterlegt. Verbinde ich mich nun per RDP an die FARM erhalten ich nun
"Angeforderter Remotecomputer"
"RDSFARM"
"Name im Zertifikat des Remotecomputer"
"rdsfarm.domain.de"
"Der Servername auf dem Zertifikat ist falsch"
Was ich kann nun tun?
Hallo Herr Sommergut,
danke (!) erstmal für Ihre kompetenten und sehr nützlichen Posts! Ich bin schon öfter hier gelandet und habe diese und jene Lösung gefunden. Ich bin relativ neu im Server Thema, gerade auch mit SSL/Zertifikaten, doch alles läuft im Netzwerk soweit, bis auf RDWeb APP. Meine Vermutung ist, dass mit gültigen Zertifikaten die Probleme behoben sind. Über einen Tip von Ihnen würde ich mich freuen, an welcher Stelle ich graben muss ;)
Ich habe ein - wenn man sich auskennt - vermutlich triviales Problem, zu dem Sie vielleicht einen Hinweis haben...
Remote Desktop im Netzwerk funktioniert bestens, keine Probleme. Auch eine Verbindung von außerhalb auf den Server funktioniert prima (ich kann also von der grünen Wiese aus auf einem Surface1 Tablet mit meiner VM Workstation arbeiten). Zertifikate Fehlermeldungen unterdrücke ich - aber sie nerven drastisch!
Hier das Problem:
--------------------
### RDWeb Zugriff klappt nur teilweise ###
Es funktioniert der Browser Aufruf der Übersicht mit
https://192.xxx.xxx.xxx/RDWebund alle Computer im Netzkönnen (nach diversen abzuarbeitenden Dialogboxen) die App Übersicht im Browser anzeigen.
Aber: Sobald eine App (irgend eines der veröffentlichten Programme) angeklickt wird, geht es weiter mit den Fehlermeldungen wegen (...) den Zertifikaten. Die meisten PCs im Netz fangen dann trotzdem an, nach Abfrage des Benutzernamens und Passwortes das Programm xy zu laden, brechen dann aber in letzter Konsequenz ab, Fehlermedung weiter unten.
Ausnahme: Das Interessante ist, dass ein Surface3Pro Tablet mit Windows 10 alle Programme starten kann. Auch ein Windows 7 Pro in einer VMware Maschine (auf einem Windows7 Host) kommt bis zum Laden der eigentlichen Programms durch und auch ein weiteres Windows7Ult kann die Programme aus dem RDWeb erfolgreich starten.
Fehlermeldungen:
--------------------
Auf den PCs, wo esnicht geht, kommt eine von zwei möglichen Fehlermeldungen:
1. Meldung: "Der Computer kann keine Verbindung mit dem Remotecomputer herstellen, da der Remotedesktop-Gatewayserver temporär nicht erreichbar ist. Versuchen Sie später..."
2. Meldung: "Der Computer kann keine Verbindung mit dem Remotecomputer herstellen, da ein Fehler auf dem Remotecomputer aufgetreten ist. Wenden Sie sich ...."
Spielt es generell eine Rolle, welchen Browser ich verwende? Ich denke, nein.
Muss der PC in der Domäne sein, damit es klappt?
Netzwerk Umgebung
------------------
Ich setze eine virtualisierte Server 2012 R2 Umgebung ein mit W2012 R2 als Hyper V Host auf dem Blech. Jede Funktion des Netzwerks ist auf einer eigenen VM (DC, DHCP-Server(auf der Hardware Firewall), Fileserver, APP Server, Webserver). Dann sind noch einige Workstations aufgesetzt, sowohl physische (Laptops, Tablets, Stationäre) als auch virtuelle HyperV VMs. Es sind auch so ziemlich alle OS im Netz vertreten: Windows XP (POS), WinXP Pro, Win7 Pro/UItimate, Windows8, Windows10, Ubuntu, Mac OS und Raspberry...
Sofern möglich, sind alle PCs in der Domäne aufgenommen und es gibt neben dem DC "Gott-Admin" einen Admin, der alle Maschinen administrieren darf.
Mein Plan ist, ein oder mehrere Zertifikate zu erstellen oder welche zu kaufen. Ich würde eher selber welche erstellen wollen. Sobald ich soweit bin, wird mir dieser Artikel von Ihnen weiterhelfen.
Ich frage mich nur, ob ich bei meinem Problem an der richtigen Stelle grabe oder ob die Zertifikate Fehler zwar nervig aber nicht problemrelevant sind...
Über einen Tip wäre ich jedenfalls sehr dankbar!
Beste Grüße
A.Lenné