Neues SAN-Zertifikat über Active Directory CA zuweisen (RDP)

[TiTux 10]

Hallo,

 

wir betreiben 5 Windows Server 2012 R2 Session Hosts mit einem Connection Broker. Die Session Hosts befinden sich in einer Sammlung und werden über den DNS Namen "rdpfarm.domäne.präfix" angesprochen. Bis jetzt bin ich so vorgegangen:

 

- Auf dem Domänen-Controller die Zertifikatsdienste installiert

- Im Zertifikats MMC Snap-In ein neues Zertifikat angefordert

- Als Vorlage "Webserver" genommen

- Auf der Registerkarte Antragsteller den Typ auf "Allgemeiner Name" geändert un den FQDN "rdpfarm.domäne.präfix" eingetragen

- Unter Alternativer Name den Typ auf "DNS" festgelegt und alle 5 Sessions Hosts mit Ihrem FQDN eingetragen

- Auf der Registerkarte "Privater Schlüssel" den Haken für "exportierbar machen" gesetzt

- Auf der Registerkarte "Erweiterungen" darauf geachtet, dass "Serverauthentifizierung" als Option ausgewählt wurde

- Zertifikat erfolgreich erstellt und anschließend exportiert

 

Auf den ersten Session Host aufgeschaltet. Dort über das Zertifikats Snap-In das neu erstellte Zerti importiert.

Als nächstes muss es ja dem Session Host noch zugewiesen werden. Also die PowerShell geöffnet u. zuerst den Fingerprint ausgelesen:

gci cert:\LocalMachine\My | select FriendlyName, Thumbprint

Diesen kopiert und ans Ende des folgenden wmi Befehls in Anführungsstrichen angefügt:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<Fingerabdruck>"

Hier erhalte ich jedoch den folgenden Fehler:

 

PS C:\> wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="E1FC0D049A
FB6CE7DF7632DA4675ABEA9344B8F2"
Eigenschaften von "\\TS21\root\cimv2\TerminalServices:Win32_TSGeneralSetting.TerminalName="RDP-Tcp"" werden aktualisiert
FEHLER:
Beschreibung = Der Parameter ist ungültig.
PS C:\>

 

 

Wo liegt jetzt mein Fehler? Im Netz habe ich gesucht u. immer wenn der Fehler "invalid Parameter" auftaucht, war entweder das Zerti nicht in den "Eigenen Zertifikaten" auf dem Host

importiert worden oder es wurde nicht darauf geachtet, dass es bei der Zertifikatserstellung "Serverauthentifizierung" sein muss.

 

Ciao

TiTux

[Dunkelmann 96]

Moin,

 

bei einer RDS Bereitstellung unter 2012R2 benötigen die Session Hosts das Zertifikat nicht. Die Clients verbinden sich nicht direkt mit den Session Hosts.

Das Broker Zertifikat wird in den Bereistellungseigenschaften festgelegt.

 

https://ryanmangansitblog.com/2013/03/10/configuring-rds-2012-certificates-and-sso/

 

Wenn dennoch das Zertifikat auf die Hosts verteilt werden soll, kannst Du Dir mal das Skipt anschauen:

https://ryanmangansitblog.com/2014/05/20/rds-2012-rdsh-certificate-deployment-script/

[TiTux 10]

Servus,

 

wir hatten zwei Zertifikate, eines für den Connection Broker, welches noch nicht abgelaufen ist u. das zweite war auf jedem einzelnen Session Host installiert, welches abgelaufen

ist und ich somit die bekannten Zertifikatswarnfenster erhalte. In dem Fenster wird dann auch der entsprechende Session Host genannt, auf den er mich gerade verbinden möchte,

also verstehe ich jetzt nicht, weshalb kein Zertifikat für für die einzelen Hosts nötig wäre?

[Dunkelmann 96]

Was für Clients sind im Einsatz und werden die RDS Sessions bereitgestellt?

 

Wenn der Verbindungsaufbau initial über den Broker läuft, was ab Server 2012 so vorgesehen ist, wird nur das Brokerzertifikat und ggf. das Zertifikat für die Signatur der RemoteApps geprüft. Beim Redirect auf einen Session Host findet am Windows Client keine weitere Prüfung statt.

 

Bei einigen Thin Clients kann es zu einer Meldung kommen. Bspw. muss die Meldung bei Igel einmalig bestätigt werden und erscheint dann nicht mehr.

[TiTux 10]

Es handelt sich um Fat-Clients. Die RDS Sessions werden von einem RD-Verbindungsbroker bereitgestellt, es wurde eine Sammlung erstellt, in der sich die 5 Session Hosts befinden.

Die Lastverteilung finden über DNS statt, hier wurden alle 5 Session Hosts im DNS eingetragen u. verweisen auf den Farmnamen rdpfarm.domäne.suffix

[Dunkelmann 96]

 

Die Lastverteilung finden über DNS statt, hier wurden alle 5 Session Hosts im DNS eingetragen u. verweisen auf den Farmnamen rdpfarm.domäne.suffix

Da haben wir das Problem. DNS RR ist seit Server 2012 obsolet.

Die Kommunikationspfade zwischen Clinet, Broker und Session Host haben sich geändert.

 

Seit 2012 ist vorgesehen, dass die Clinets ihre Verbindungsinformationen über den WebAccess beziehen. Nur der WebAccess kann den Parameter 'SessionCollection' an den Client weitergeben.

Die Verbindung erfolgt auf den Client Access Name des Brokers unter Angabe der Session Collection. Der Broker leitet die Verbindung dann auf einen passenden Host in der angeforderten Collection weiter. Ein elendes Connect&Redirect wie unter 2008R2 und älter gibt es nicht mehr, da der Client gleich auf einen geeigneten Host geleitet wird.

 

Gibt es keinen WebAccess und nur eine Collection, kann am Broker eine Default Collection für den Zugriff eingerichtet werden.

https://ryanmangansitblog.com/2013/03/11/connection-broker-redirection-rds-2012/

Der Artikel bezieht sich zwar auf eine VDI, funktioniert aber auch mit RDS Sessions