6
Client-Hyper-V und RDP-Zertifikate
Moin.
Habe hier ein Problem der speziellen Art, was vermutlich niemand kennt.
Will man Man-in-the-middle-Attacken bei RDP vorbeugen, so kann man ja folgende GPO setzen:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Serverauthentifizierung für Client konfigurieren
->Keine Verbindung, wenn Authentifizierung fehlschlägt
Tut man das, ist keine Verbindung mehr zu auf Win10 20H2 lokal gehaltenen Hyper-V-Maschinen möglich, siehe Bild:
Das passiert auch noch bevor die Maschine ins Windows gebootet hat, sprich: das hat mit dem Gast-OS gar nichts zu tun!
Hyper-V präsentiert einfach ein Zertifikat, dass er irgendwo herzaubert (selbstsigniert, Gültigkeit 1000 Jahre!), welches aber auf den FQDN des Hosts ausgestellt ist und mit dem Namen des Gastes nichts zu tun hat. Die Hyper-V-Konsole nutzt den FQDN nicht einmal, sondern nur den netbios-Namen des Hosts, was natürlich zu einem Zertifikatsfehler führt.
Wo kann ich einstellen, dass hier von der VM ein ordentliches Zertifikat präsentiert wird?
---
PS: Man sieht mal wieder: MS fordert dazu auf zu härten, aber niemand macht es. Andernfalls würde ja bei niemandem mehr Zugriff auf die lokalen Hyper-Vs möglich sein, wie mir scheint.
Habe hier ein Problem der speziellen Art, was vermutlich niemand kennt.
Will man Man-in-the-middle-Attacken bei RDP vorbeugen, so kann man ja folgende GPO setzen:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Serverauthentifizierung für Client konfigurieren
->Keine Verbindung, wenn Authentifizierung fehlschlägt
Tut man das, ist keine Verbindung mehr zu auf Win10 20H2 lokal gehaltenen Hyper-V-Maschinen möglich, siehe Bild:
Hyper-V präsentiert einfach ein Zertifikat, dass er irgendwo herzaubert (selbstsigniert, Gültigkeit 1000 Jahre!), welches aber auf den FQDN des Hosts ausgestellt ist und mit dem Namen des Gastes nichts zu tun hat. Die Hyper-V-Konsole nutzt den FQDN nicht einmal, sondern nur den netbios-Namen des Hosts, was natürlich zu einem Zertifikatsfehler führt.
Wo kann ich einstellen, dass hier von der VM ein ordentliches Zertifikat präsentiert wird?
---
PS: Man sieht mal wieder: MS fordert dazu auf zu härten, aber niemand macht es. Andernfalls würde ja bei niemandem mehr Zugriff auf die lokalen Hyper-Vs möglich sein, wie mir scheint.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1068198402
Url: https://administrator.de/forum/client-hyper-v-und-rdp-zertifikate-1068198402.html
Ausgedruckt am: 02.04.2025 um 22:04 Uhr
6 Kommentare
Neuester Kommentar
Lösung gefunden. Microsoft ist echt eine Bastelbude.
Doppelklickt man in Hyper-V auf eine VM, dann öffnet sich vmconnect und das beschriebene Problem stellt sich.
Starte ich jedoch vmconnect.exe manuell und gebe als Server den FQDN meines Hosts ein, dann läuft alles.
Ergo: aus Hyper-V heraus wird vmconnect automatisch mit unpassenden Optionen (nämlich dem netbios-Namen als Hostname) gestartet. Tja, was soll der Quatsch, Microsoft?
Doppelklickt man in Hyper-V auf eine VM, dann öffnet sich vmconnect und das beschriebene Problem stellt sich.
Starte ich jedoch vmconnect.exe manuell und gebe als Server den FQDN meines Hosts ein, dann läuft alles.
Ergo: aus Hyper-V heraus wird vmconnect automatisch mit unpassenden Optionen (nämlich dem netbios-Namen als Hostname) gestartet. Tja, was soll der Quatsch, Microsoft?
Großartig und danke fürs teilen...
Grüße
Stefan
Grüße
Stefan
Zitat von @DerWoWusste:
Lösung gefunden. Microsoft ist echt eine Bastelbude.
Doppelklickt man in Hyper-V auf eine VM, dann öffnet sich vmconnect und das beschriebene Problem stellt sich.
Starte ich jedoch vmconnect.exe manuell und gebe als Server den FQDN meines Hosts ein, dann läuft alles.
Ergo: aus Hyper-V heraus wird vmconnect automatisch mit unpassenden Optionen (nämlich dem netbios-Namen als Hostname) gestartet. Tja, was soll der Quatsch, Microsoft?
Lösung gefunden. Microsoft ist echt eine Bastelbude.
Doppelklickt man in Hyper-V auf eine VM, dann öffnet sich vmconnect und das beschriebene Problem stellt sich.
Starte ich jedoch vmconnect.exe manuell und gebe als Server den FQDN meines Hosts ein, dann läuft alles.
Ergo: aus Hyper-V heraus wird vmconnect automatisch mit unpassenden Optionen (nämlich dem netbios-Namen als Hostname) gestartet. Tja, was soll der Quatsch, Microsoft?
Hast Du noch WINS im Einsatz?
Es wäre doch auch über zwei andere Wege kompensierbar:
1)
Die Computer bekommen Zertifikate, die ihren Gerätenamen und den vollständigen Gerätenamen (FQDN) abbilden.
2)
Es müsste auch gehen, wenn man das Domänen-Suffix über die Netzwerkverbindung mit gibt.
Gruß
bdmvg
@samrein gerne!
@beidermachtvongreyscull Nee, die Zertifikate erstellt Windows automatisch und daran ist nichts zu ändern.
Zu 2) das mache ich doch mittels vmconnect! Aber aus der Hyper-V-GUI geht es nicht.
Nein, WINS ist nicht im Einsatz und spielt hierbei nicht mit rein.
Thema durch, mein Workaround reicht mir. Es ist ja auch nur dann wichtig, wenn die VM
A kein Windows-OS ist
oder
B Windows OS ist, aber noch nicht gebootet ist.
Andernfalls kann man sich ja mit dem Gast direkt verbinden über normales RDP (wenn man's denn zulässt).
@beidermachtvongreyscull Nee, die Zertifikate erstellt Windows automatisch und daran ist nichts zu ändern.
Zu 2) das mache ich doch mittels vmconnect! Aber aus der Hyper-V-GUI geht es nicht.
Nein, WINS ist nicht im Einsatz und spielt hierbei nicht mit rein.
Thema durch, mein Workaround reicht mir. Es ist ja auch nur dann wichtig, wenn die VM
A kein Windows-OS ist
oder
B Windows OS ist, aber noch nicht gebootet ist.
Andernfalls kann man sich ja mit dem Gast direkt verbinden über normales RDP (wenn man's denn zulässt).
1
Hallo DWW,
die Zertifikate lassen sich schon ändern, das Verfahren ist dem Prinzip nach weiterhin gültig: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
Die Registry-Einträge kann man sich gut sparen, da der Computer-Store ohnehin ggü. dem VMMS-Konto bevorzugt wird und ein Betrieb mit selbstsignierten Zertifikaten unter der RDP-Policy leicht auffällt.
Weil ich noch nicht dahinter gekommen bin, wie man von den AD CS ein Zertifikat mit der (zumindest heute unter Server 2016 und 2019) nötigen Erweiterung 1.3.6.1.4.1.311.62.1.1.1 anfordert, pflege ich diese Zertifikate aber trotzdem noch manuell.
Grüße
Richard
die Zertifikate lassen sich schon ändern, das Verfahren ist dem Prinzip nach weiterhin gültig: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
Die Registry-Einträge kann man sich gut sparen, da der Computer-Store ohnehin ggü. dem VMMS-Konto bevorzugt wird und ein Betrieb mit selbstsignierten Zertifikaten unter der RDP-Policy leicht auffällt.
Weil ich noch nicht dahinter gekommen bin, wie man von den AD CS ein Zertifikat mit der (zumindest heute unter Server 2016 und 2019) nötigen Erweiterung 1.3.6.1.4.1.311.62.1.1.1 anfordert, pflege ich diese Zertifikate aber trotzdem noch manuell.
Grüße
Richard
Hallo Richard.
Interessant.
Leider gelingt mir die Umsetzung nicht, aber da vertiefe ich mich jetzt nicht rein, dazu ist der Workaround schon gut genug.
Danke
Interessant.
Leider gelingt mir die Umsetzung nicht, aber da vertiefe ich mich jetzt nicht rein, dazu ist der Workaround schon gut genug.
Danke
