Trusted RDP Files: Herausgeber kann nicht identifiziert werden

Als Administrator einer RDS-Collection dürfte man bereits auf Warnungen wie „Der Herausgeber dieser Remotedesktopverbindung kann nicht identifiziert werden“ oder „Vertrauen Sie dem Herausgeber dieser Remoteverbindung?“ gestoßen sein. Es ist zwar nicht weiter betriebsrelevant und Benutzer können sich nach wie vor auf die Terminalserver verbinden, doch störend sind die Pop-Ups alle mal. Daher empfiehlt es sich die folgenden Schritte durchzuführen, um in Zukunft keine störenden Warnungen mehr angezeigt zu bekommen. Der Fokus dieses Beitrags bezieht sich auf folgende Warnung.

Der Herausgeber dieser Remoteverbindung kann nicht identifiziert werden. Möchten Sie die Verbindung trotzdem herstellen?

Dieses Pop-Up kann aufgrund folgender zwei Gegebenheiten auftreten:

• Die RDP-Datei wurde noch nicht signiert (siehe RDP-Files signieren)
• Die RDP-Datei wurde zwar signiert, allerdings ist das Zertifikat nicht vertrauenswürdig (siehe RDP-File wurde bereits signiert)

RDP-Files signieren

Wenn wir ein RDP-File selbst erstellen, ist grundsätzlich kein Zertifikat hinterlegt. Somit wird bei jedem Verbindungsversuch die oben genannte Fehlermeldung aufploppen. Um ein RDP-File zu signieren benötigen wir ein passendes Zertifikat und die PowerShell. Ist das Zertifikat bereits auf dem Computer im Zertifikatsspeicher hinterlegt, öffnet man eine MMC und das „Certificate“ Add-In.

Dort wählt man das Zertifikat aus und kopiert unter dem Reiter „Details“ den Thumbprint. Anschließend öffnet man eine PowerShell als Administrator und führt folgenden Befehl aus:

rdpsign /sha256 <HASH> <RDP-FILE>

Das CMDLET für unsere Zwecke adaptiert sähe wie folgt aus:

rdpsign /sha256 ‎12df6ce9ce5442e20349c0b350128c05b3e0c4ed RDP_Default.rdp

Offizielle Doku seitens Microsoft: „Rdpsin | Microsoft Docs„. Somit wurde das RDP-File erfolgreich mit unserem Zertifikat signiert. Solltet ihr ein Zertifikat gewählt haben, welches nicht von einer offiziellen Certificate Authority ausgestellt worden ist, wird es nur auf jenen PCs vertrauenswürdig sein, auf denen zumindest das Root-Zertifikat der CA importiert worden ist.

RDP-Files wurde bereits signiert

Verbindet man sich auf das Web-Portal einer RDS-Farm und lädt die entsprechende RDP-Datei herunter, wurde das File bereits mit dem hinterlegten Zertifikat am Connection Broker signiert. Das findet man relativ einfach heraus, indem man die heruntergeladene Datei mit einem Texteditor seiner Wahl öffnet. Unterhalb der regulären Einstellungen dürfte man in diesem Fall das Zertifkatsinformationen finden.

Somit wissen wir bereits, dass die Datei zwar signiert wurde, allerdings mit einem Zertifikat, welches von unserem Computer als „nicht vertrauenswürdig“ eingestuft wird. Nun hat man mehrere Möglichkeiten:

• Falls ein Zertifikat aus einer eigenen CA (Certificate Authority) verwendet wurde, muss das Root-Zertifikat jener CA in den Zertifikatsspeicher des eigenen Clients importiert werden.
• Das hinterlegte Zertifikat am Connection Broker muss durch ein Zertifikat von einer vertrauenswürdigen CA ausgetauscht werden.

Doch warum wird es als nicht vertrauenswürdig eingestuft? Dazu müssen wir einen kurze Schwenk in die Theorie machen und klären, wie Zertifikate eigentlich funktionieren. Ein Zertifikat wird immer von einer vertrauenswürdigen Organisation ausgeben. Dabei sind wir schon beim springenden Punkt: der ganze Prozess passiert auf Vertrauen. Weltweit gibt es nur einige Dutzend Organisation, welche von jedem Client akzeptiert werden. Wenn wir eine eigene Active-Directory Domäne besitzen, haben wir dort vermutlich auch eine eigene Certificate Authority installiert. Die Zertifikate diese CA werden allerdings nur innerhalb dieser AD-Domäne als vertrauenswürdig eingestuft. Möchte man nun von einem PC außerhalb der Domäne auf die RDS-Collection zugreifen, sind alle Zertifikate, welche von der AD-CA ausgestellt wurden, nicht vertrauenswürdig.

Um dieses Problem zu umgehen, kann man das Root-Zertifikat der AD-CA in den eigenen Speicher des Computers importieren. Somit wären alle Zertifikate dieser CA auf unserem Computer als trustworthy eingestuft. Eine Anleitung dazu gibt es direkt von Microsoft und kann hier abgerufen werden.

Abschließende Worte

Zum Abschluss sei gesagt, dass CAs ein sehr großes Themengebiet darstellt, welches sich nicht in einem Beitrag abdecken lässt. Grundsätzlich ist es wichtig zu verstehen, dass Zertifikate ausschließlich auf der Vertrauensebene funktionieren. Alle Windows-Computer haben bereits bestimmte Certificate Authorities in ihrem Zertifikatsspeicher hinterlegt. Allen anderen CAs werden als nicht vertrauenswürdig eingestuft. Es ist allerdings kein Problem das Root-Zertifikat einer anderen CA auf dem jeweiligen Computer zu importieren und so eine Vertrauensbasis herzustellen.

Im zweiten Teil gehen wir auf das Pop-Up „Vertrauen Sie dem Herausgeber dieser Remoteverbindung?“ ein.