8
RDS Remotedesktop Services Web Access URL und Zertifikat
Hi,
ich rolle grade neue Terminal Server aus und habe dazu unter Windows Server 2022 eine neue VM für Web Access, Lizenzserver und Broker auf gesetzt. Die Gateway-Rolle kommt wie bisher auch nicht zum Einsatz - Wir machen RDP nur mit VPN und ich habe bisher keinen Mehrwert erkennen können - korrigiert mich wenn ich falsch liege. Basis für die Einrichtung ist im Wesentlichen https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-se ... .
Soweit habe ich mich schnell wieder eingefunden aber eine Sache irritiert mich sehr und das auch schon auf der bestehenden Umgebung unter 2012 R2:
Die "RD Web Access"-URL und ihr Zertifikat passen (nachvollziehbar) nicht zusammen. Als Zertifikat habe ich (im Setup Assistent) host.domain.de als DNS-Name gewählt, der Host ist aber tatsächlich host.intern.domain.de . Der RD Web Access nutzt als URL https://host.intern.domain.de/RdWeb , https://host.domain.de/RdWeb kann als Seite nicht aufgerufen werden (im DNS ist beides korrekt hinterlegt). Wenn ich also https://host.intern.domain.de/RdWeb bekomme ich natürlich eine Zertifikatswarnung ERR_CERT_COMMON_NAME_INVALID.
Ich habe schon ein bisschen mit dem Binding der Site im IIS rum probiert, bin da aber echt ein DAA. Sowohl die URL für die Seite als auch ein anderes Zertifikat konnte ich hier nicht zum laufen bringen.
Die Zertifikatswarnung ist kein riesen Problem, die User gehen nicht über die Web Access-Seite. Ich möchte aber verstehen was hier best practice ist, auch falls mal ein Gateway dazu kommt:
a) Sollte ich das Zertifikat als host.intern.domain.de noch mal neu erzeugen?
b) Sollte ich ein Zertifikat mit alternate hostname erzeugen?
c) Sollte ich im IIS die URL manipulieren und wenn ja wie?
d) Oder gibt's einen anderen, sinnvolleren Weg?
Bitte erleuchtet mich...
PS: Ich habe das Zertifikat in den Zertifikatsspeicher der VM importiert. Dennoch zeigt mir der Server in den Bereitstellungseigenschaften das verwendete Zertifikat als "nicht vertrauenswürdig" an. Das Zertifikat wurde wie in der Anleitung von Microsoft unter Punkt 6 beschrieben erstellt und dann in allen Rollen hinterlegt, ist das nicht richtig?
ich rolle grade neue Terminal Server aus und habe dazu unter Windows Server 2022 eine neue VM für Web Access, Lizenzserver und Broker auf gesetzt. Die Gateway-Rolle kommt wie bisher auch nicht zum Einsatz - Wir machen RDP nur mit VPN und ich habe bisher keinen Mehrwert erkennen können - korrigiert mich wenn ich falsch liege. Basis für die Einrichtung ist im Wesentlichen https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-se ... .
Soweit habe ich mich schnell wieder eingefunden aber eine Sache irritiert mich sehr und das auch schon auf der bestehenden Umgebung unter 2012 R2:
Die "RD Web Access"-URL und ihr Zertifikat passen (nachvollziehbar) nicht zusammen. Als Zertifikat habe ich (im Setup Assistent) host.domain.de als DNS-Name gewählt, der Host ist aber tatsächlich host.intern.domain.de . Der RD Web Access nutzt als URL https://host.intern.domain.de/RdWeb , https://host.domain.de/RdWeb kann als Seite nicht aufgerufen werden (im DNS ist beides korrekt hinterlegt). Wenn ich also https://host.intern.domain.de/RdWeb bekomme ich natürlich eine Zertifikatswarnung ERR_CERT_COMMON_NAME_INVALID.
Ich habe schon ein bisschen mit dem Binding der Site im IIS rum probiert, bin da aber echt ein DAA. Sowohl die URL für die Seite als auch ein anderes Zertifikat konnte ich hier nicht zum laufen bringen.
Die Zertifikatswarnung ist kein riesen Problem, die User gehen nicht über die Web Access-Seite. Ich möchte aber verstehen was hier best practice ist, auch falls mal ein Gateway dazu kommt:
a) Sollte ich das Zertifikat als host.intern.domain.de noch mal neu erzeugen?
b) Sollte ich ein Zertifikat mit alternate hostname erzeugen?
c) Sollte ich im IIS die URL manipulieren und wenn ja wie?
d) Oder gibt's einen anderen, sinnvolleren Weg?
Bitte erleuchtet mich...
PS: Ich habe das Zertifikat in den Zertifikatsspeicher der VM importiert. Dennoch zeigt mir der Server in den Bereitstellungseigenschaften das verwendete Zertifikat als "nicht vertrauenswürdig" an. Das Zertifikat wurde wie in der Anleitung von Microsoft unter Punkt 6 beschrieben erstellt und dann in allen Rollen hinterlegt, ist das nicht richtig?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3759181954
Url: https://administrator.de/contentid/3759181954
Ausgedruckt am: 18.12.2024 um 21:12 Uhr
8 Kommentare
Neuester Kommentar
SAN-Zertifikat oder Wildcard ist das Stichwort.
https://en.wikipedia.org/wiki/Subject_Alternative_Name
https://en.wikipedia.org/wiki/Subject_Alternative_Name
Zitat von @2423392070:
SAN-Zertifikat oder Wildcard ist das Stichwort.
https://en.wikipedia.org/wiki/Subject_Alternative_Name
SAN-Zertifikat oder Wildcard ist das Stichwort.
https://en.wikipedia.org/wiki/Subject_Alternative_Name
Jupp
SSO Single-Sign-On to your onPremise RDS Remote Desktop Services 2016/2019 Environment
If you are not using a wildcard certificate, make sure to include the DNS names from your RD Web Access FQDN and your RD Connection Broker FQDN.
Ich würde das heute so auch nicht mehr machen.
Bei getrennten Hosts CB und RDWeb muss ich das Zertifikat immer händisch registrieren, so dass es die Namen beider Maschinen hat. Dann geht's.
Bei einer neuen Installation habe ich RDWeb und CB auf einer VM und alles ist schick!
Bei getrennten Hosts CB und RDWeb muss ich das Zertifikat immer händisch registrieren, so dass es die Namen beider Maschinen hat. Dann geht's.
Bei einer neuen Installation habe ich RDWeb und CB auf einer VM und alles ist schick!
Nun ich habe auf CB verzichtet weil ich die Notwendigkeit (noch) nicht sehe.
Aber mich irritiert sehr das ich die Webseite des RD Web Access nur über
host.intern.domain.de
nicht aber über
host.domain.de (im Zertifikat)
aufrufen kann. Beide DNS Namen werden auf die selbe IP aufgelöst, aber der IIS liefert nur auf der ersten URL eine Webseite, auf der zweiten kommt ERR_TUNNEL_CONNECTION_FAILED und kein Zertifikat. Ich bin im IIS nicht sonderlich fit und will da auch nichts verbiegen aber ich hätte angenommen das hier, egal welche URL angesprochen wird, die selbe Seite und das selbe Zertifikat ausgeliefert werden.
Aber mich irritiert sehr das ich die Webseite des RD Web Access nur über
host.intern.domain.de
nicht aber über
host.domain.de (im Zertifikat)
aufrufen kann. Beide DNS Namen werden auf die selbe IP aufgelöst, aber der IIS liefert nur auf der ersten URL eine Webseite, auf der zweiten kommt ERR_TUNNEL_CONNECTION_FAILED und kein Zertifikat. Ich bin im IIS nicht sonderlich fit und will da auch nichts verbiegen aber ich hätte angenommen das hier, egal welche URL angesprochen wird, die selbe Seite und das selbe Zertifikat ausgeliefert werden.
@beidermachtvongreyscull
@ukulele-7
Gruß,
Dani
Bei getrennten Hosts CB und RDWeb muss ich das Zertifikat immer händisch registrieren, so dass es die Namen beider Maschinen hat. Dann geht's.
wäre mir neu. Aus welchen Grund?@ukulele-7
Nun ich habe auf CB verzichtet weil ich die Notwendigkeit (noch) nicht sehe.
Oben schreibst du, dass CB installiert ist nun sagst du das Gegenteil. Aber mich irritiert sehr das ich die Webseite des RD Web Access nur über
Ist es möglich, dass im der Webseite im IIS ein Header eingetragen ist?!Gruß,
Dani
Sry ich meinte die Gateway Rolle ist nicht installiert (ein turbulenter Morgen). Connection Broker und RD Web Access sind beide installiert, auf der selben VM.
Ich habe jetzt selbst ein neues Zertifikat erstellt mit beiden Hostnames und das läuft auch soweit auf allen Rollen und im IIS. Das hätte ich auch jetzt so erwartet, wundere mich aber ein bischen über die Anleitung von MS die das scheinbar nicht vorsieht.
Aber was bleibt ist die Frage warum der Web Access auf dem IIS nicht auf beiden Hostnames zu erreichen ist. Ich habe keine Einschränkung gefunden @Dani
Aber was bleibt ist die Frage warum der Web Access auf dem IIS nicht auf beiden Hostnames zu erreichen ist. Ich habe keine Einschränkung gefunden @Dani
Zitat von @ukulele-7:
Aber was bleibt ist die Frage warum der Web Access auf dem IIS nicht auf beiden Hostnames zu erreichen ist. Ich habe keine Einschränkung gefunden @Dani
Aber was bleibt ist die Frage warum der Web Access auf dem IIS nicht auf beiden Hostnames zu erreichen ist. Ich habe keine Einschränkung gefunden @Dani
Ganz einfach, für die genutzten DNS Namen müssen die entsprechenden SPNs registriert sein, wegen Kerberos.
Alternative DNS Namen lassen sich mit netdom hinzufügen.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
