1
RDS Sitzungssammlung 2019 Zertifikate
Hallo Zusammen,
wir bauen derzeit parallel eine neue IT-Infrastruktur auf, unter anderem mit einer RDS-Sitzungssammlung mit 2 RDSH auf Basis von Server 2019. Die Sammlung besteht schematisch aus folgenden Servern:
1 Broker
1 Lizenzserver
1 RD Web /RD Gateway Server
2 RDSH
Die Sammlung ist soweit konfiguriert und es funktioniert der Zugriff auf die Farm - allerdings mit den Default-Zertifikaten. Wenn ich mich in RDWeb anmelde und die vorkonfigurierte RDP-Datei zum Zugriff auf die Sammlung verwende, funktioniert der Zugriff, allerdings logischerweise mit Zertifikatsfehler. Die vorkonfigurierte RDP Datei greift auf den FQDN des Brokers zu.
Das AD ist nach dem Schema ad.firma.de benannt, die Server haben also z. B. die Namen Broker.ad.firma.de.
Muss ich nun ein Zertifikat (z. B. Wildcard) mit *.ad.firma.de verwenden, damit intern keine Zertifikatfehler mehr kommen (Das Zertifikat den beiden RDSHs zuweisen sowie dem Broker) und für den RD Web / RD Gateway Zugriff von außen nochmal ein zweites mit der externen Domain z. B. rdgw.kunde.de? Oder verwendet man von extern dann den FQDN rdgw.ad.kunde.de, damit ich keine 2 Zertifikate benötige, sondern nur mit dem Wildcard arbeiten kann? Im Web hab ich immer viel mit .local Domains gefunden und internen Microsoft PKIs, ich möchte aber mit offiziellen Zertifikaten arbeiten.
Als zweite Frage, was ich auch nicht recherchieren konnte ist, wie der Zugriff auf die Farm bei 2019 im Best Practice geplant ist. Die DNS Round Robin Einträge sollen wohl nicht mehr verwendet werden, stattdessen die vorkonfigurierte RDP Datei aus dem RD Web.
wir bauen derzeit parallel eine neue IT-Infrastruktur auf, unter anderem mit einer RDS-Sitzungssammlung mit 2 RDSH auf Basis von Server 2019. Die Sammlung besteht schematisch aus folgenden Servern:
1 Broker
1 Lizenzserver
1 RD Web /RD Gateway Server
2 RDSH
Die Sammlung ist soweit konfiguriert und es funktioniert der Zugriff auf die Farm - allerdings mit den Default-Zertifikaten. Wenn ich mich in RDWeb anmelde und die vorkonfigurierte RDP-Datei zum Zugriff auf die Sammlung verwende, funktioniert der Zugriff, allerdings logischerweise mit Zertifikatsfehler. Die vorkonfigurierte RDP Datei greift auf den FQDN des Brokers zu.
Das AD ist nach dem Schema ad.firma.de benannt, die Server haben also z. B. die Namen Broker.ad.firma.de.
Muss ich nun ein Zertifikat (z. B. Wildcard) mit *.ad.firma.de verwenden, damit intern keine Zertifikatfehler mehr kommen (Das Zertifikat den beiden RDSHs zuweisen sowie dem Broker) und für den RD Web / RD Gateway Zugriff von außen nochmal ein zweites mit der externen Domain z. B. rdgw.kunde.de? Oder verwendet man von extern dann den FQDN rdgw.ad.kunde.de, damit ich keine 2 Zertifikate benötige, sondern nur mit dem Wildcard arbeiten kann? Im Web hab ich immer viel mit .local Domains gefunden und internen Microsoft PKIs, ich möchte aber mit offiziellen Zertifikaten arbeiten.
Als zweite Frage, was ich auch nicht recherchieren konnte ist, wie der Zugriff auf die Farm bei 2019 im Best Practice geplant ist. Die DNS Round Robin Einträge sollen wohl nicht mehr verwendet werden, stattdessen die vorkonfigurierte RDP Datei aus dem RD Web.
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: 640471
Url: https://administrator.de/contentid/640471
Ausgedruckt am: 13.11.2024 um 06:11 Uhr
1 Kommentar
Moin,
Oder verwendet man von extern dann den FQDN rdgw.ad.kunde.de, damit ich keine 2 Zertifikate benötige, sondern nur mit dem Wildcard arbeiten kann? Im Web hab ich immer viel mit .local Domains gefunden und internen Microsoft PKIs, ich möchte aber mit offiziellen Zertifikaten arbeiten.
Ein Wildcard Zertfikat deckt immer nur ein Namensraum ab.
Ein solches Zertifikat mit dem Namensraum kunde.de deckt rds.kunde.de ab aber nicht rds.ad.kunde.de.
Ein solches Zertifikat mit dem Namensraum ad.kunde.de deckt rds.ad.kunde.de ab aber nicht rds.test.ad.kunde.de.
Wir erlauben den Zugriff im LAN ausschließlich über RDGW/RDWEB. Der entsprechend Feed ist auf den Clients eingebunden, so dass die Programme bzw. Verknüpfungen im Startmenü des MA auftauchen. Das Schöne dabei ist, dass wenn die Nutzer mit Notebooks zu Hause arbeiten ohne zutun die Anwendungen aufrufen können.
Gruß,
Dani
Muss ich nun ein Zertifikat (z. B. Wildcard) mit *.ad.firma.de verwenden, damit intern keine Zertifikatfehler mehr kommen (Das Zertifikat den beiden RDSHs zuweisen sowie dem Broker) und für den RD Web / RD Gateway Zugriff von außen nochmal ein zweites mit der externen Domain z. B. rdgw.kunde.de?
das hängt davon ab, welche Philosophie du bezüglich DNS verfolgst (Split-DNS oder getrennte Namensräume). Beides hat Vor- und Nachteile in einem Netzwerk. Das hängt auch ein bisschen von IT Design ab. Gerade auf Hinblick, ob das RDGW/RDWEB ausschließlich extern oder auch intern nutzen möchtest. Zwei Namesräume bringen auch eine gewisse Komplextiät mit sich, die es beim Einrichten und Fehlersuche deutlich schwerer machen.Oder verwendet man von extern dann den FQDN rdgw.ad.kunde.de, damit ich keine 2 Zertifikate benötige, sondern nur mit dem Wildcard arbeiten kann? Im Web hab ich immer viel mit .local Domains gefunden und internen Microsoft PKIs, ich möchte aber mit offiziellen Zertifikaten arbeiten.
Ein Wildcard Zertfikat deckt immer nur ein Namensraum ab.
Ein solches Zertifikat mit dem Namensraum kunde.de deckt rds.kunde.de ab aber nicht rds.ad.kunde.de.
Ein solches Zertifikat mit dem Namensraum ad.kunde.de deckt rds.ad.kunde.de ab aber nicht rds.test.ad.kunde.de.
Als zweite Frage, was ich auch nicht recherchieren konnte ist, wie der Zugriff auf die Farm bei 2019 im Best Practice geplant ist. Die DNS Round Robin Einträge sollen wohl nicht mehr verwendet werden, stattdessen die vorkonfigurierte RDP Datei aus dem RD Web.
Round Robin über DNS sollte nach wie vor funktionieren. Best Practice hängt auch ein Stück weit von den Anforderungen an Sicherheit und Clients (Domain Joined oder Workgroup).Wir erlauben den Zugriff im LAN ausschließlich über RDGW/RDWEB. Der entsprechend Feed ist auf den Clients eingebunden, so dass die Programme bzw. Verknüpfungen im Startmenü des MA auftauchen. Das Schöne dabei ist, dass wenn die Nutzer mit Notebooks zu Hause arbeiten ohne zutun die Anwendungen aufrufen können.
Gruß,
Dani
