ukulele-7
Goto Top

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?
unbenannt

Content-Key: 3759181954

Url: https://administrator.de/contentid/3759181954

Ausgedruckt am: 06.10.2022 um 23:10 Uhr

Mitglied: unbelanglos
unbelanglos 26.08.2022 um 16:26:09 Uhr
Goto Top
SAN-Zertifikat oder Wildcard ist das Stichwort.
https://en.wikipedia.org/wiki/Subject_Alternative_Name
Mitglied: 3714160434
3714160434 26.08.2022 aktualisiert um 16:50:29 Uhr
Goto Top
Zitat von @unbelanglos:

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.

Mitglied: beidermachtvongreyscull
beidermachtvongreyscull 26.08.2022 um 21:41:58 Uhr
Goto Top
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!
Mitglied: ukulele-7
ukulele-7 29.08.2022 um 10:29:30 Uhr
Goto Top
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.
Mitglied: Dani
Dani 29.08.2022 um 11:58:51 Uhr
Goto Top
@beidermachtvongreyscull
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. face-sad

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
Mitglied: ukulele-7
ukulele-7 29.08.2022 um 12:02:15 Uhr
Goto Top
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.
Mitglied: ukulele-7
ukulele-7 31.08.2022 um 09:26:22 Uhr
Goto Top
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
Mitglied: 3714160434
3714160434 31.08.2022 aktualisiert um 09:48:47 Uhr
Goto Top
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

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 ...