Magroll 10 Geschrieben 26. Oktober 2015 Melden Teilen Geschrieben 26. Oktober 2015 (bearbeitet) Hallo zusammen, ich habe ein kleines Problem und drehe mich irgendwie im Kreis, evt. hat ja wer von Euch einen erleuchtenden Hinweis für mich? Szenario (alles Windows 2012 R2): rds01.mydomain.com - Broker und WebAccessserver rds02.mydomain.com - Sessionhost mit installierten Anwendungen rdsfarm.mydomain.com - Farmname im DNS (CNAME für rds01.mydomain.com) und Name des Farmzertifikates auf rds02.mydomain.com Vorweg was wie gewünscht funktioniert: - Wenn ich mich via Remotedesktopverbindung mit rdsfarm.mydomain.com verbinde klappt alles einwandfrei, es kommen keine Zertifikatsfehlermeldungen, rds02 meldet sich mit dem Farmzertifikat, wie gewünscht. - Wenn ich mich auf via Browser auf rdsfarm.mydomain.com/RDWeb anmelde, kommt erstmal keine Fehlermeldung, alles gut. Problem: - Sobald ich jedoch via WebAccess eine Anwendung starte, welche auf rds02.mydomain.com liegt bekomme ich eine Zertifikatsfehlermeldung: Name stimmt nicht überein Angeforderter Remotecomputer: rds02.mydomain.com Name im Zertifikat des Remotecomputers: rdsfarm.mydomain.com - Es scheint also als ob mein WebAccess nicht den Farmnamen anspricht, was in diesem Fall ja aber gewünscht ist. Frage: Wie bekomme ich den Webzugriff so geregelt das die Applikation über den Farmnamen aufgerufen wird? Paralell zu rds02.mydomain.com sollen ja noch weitere RDS Server installiert werden. Danke und Gruß, Mag bearbeitet 26. Oktober 2015 von Magroll Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 26. Oktober 2015 Melden Teilen Geschrieben 26. Oktober 2015 Moin, hast Du die Zertifikate über die Eigenschaften der RDS Bereitstellung eingerichtet? Normalerweise wird das Zertifikat einzelner Session Hosts nicht geprüft. Es wird dem Client nur das Zertifikat des Brokers präsentiert und geprüft. Zitieren Link zu diesem Kommentar
Magroll 10 Geschrieben 27. Oktober 2015 Autor Melden Teilen Geschrieben 27. Oktober 2015 (bearbeitet) Hi Dunkelmann, ich habe das Farmzertifikat in den Bereitstellungseigenschaften der Sammlung konfiguriert. Dort gibt es drei Punkte : - Remotedesktop-Verbindungsbroker - einmaliges Anmelden aktivieren - Remotedesktop-Verbindungsbroker - Veröffentlichung - Web Access für Remotedesktop Bei allen dreien habe ich das Farmzertifikat rdsfarm.mydomain.com hinterlegt. Zudem habe ich auf dem Sessionhost rds02 das Farmzertifikat lokal in den Zertifikatsspeicher hinterlegt (unter Eigene Zertifikate) und den folgenden Befehle ausgeführt: - gci cert:\LocalMachine\My | select FriendlyName, Thumbprint (zur Anzeige des Fingerabdruckes des Farmzertifikates) - wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<Fingerabdruck des Farmzertifikates>" ... Also nach weiterem Testen ergibt sich, das wenn ich die Zertifikate auf dem rds02 mittels - wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<Fingerabdruck des Farmzertifikates / lokalen Hosts>" tausche, (Zertifikate für rdsfarm.mydomain.com und rds02.madomain.com) komme ich via WebAccess ohne Fehler drauf, aber nicht mehr via Remotedesktopverbindung und vice versa... Kann mir jemand sagen, ob der WebAccess nicht über den Brokerdienst geht, sondern sich direkt mit den RDS Hosts verbinden will? Das wäre für mich zur Zeit die einzige mögliche Erklärung, auch wenn ich dann noch nicht weiß, wie ich das Problem lösen könnte, da beide Zugangsmöglichkeiten auf die Farm gewünscht sind. Danke Mag bearbeitet 27. Oktober 2015 von Magroll Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 27. Oktober 2015 Melden Teilen Geschrieben 27. Oktober 2015 Hi Dunkelmann, ich habe das Farmzertifikat in den Bereitstellungseigenschaften der Sammlung konfiguriert. Dort gibt es drei Punkte : - Remotedesktop-Verbindungsbroker - einmaliges Anmelden aktivieren - Remotedesktop-Verbindungsbroker - Veröffentlichung - Web Access für Remotedesktop Bei allen dreien habe ich das Farmzertifikat rdsfarm.mydomain.com hinterlegt. Hast Du auch den Client Access Name für den Broker angepasst? Zudem habe ich auf dem Sessionhost rds02 das Farmzertifikat lokal in den Zertifikatsspeicher hinterlegt (unter Eigene Zertifikate) und den folgenden Befehle ausgeführt: - gci cert:\LocalMachine\My | select FriendlyName, Thumbprint (zur Anzeige des Fingerabdruckes des Farmzertifikates) - wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<Fingerabdruck des Farmzertifikates>" Warum? Kann mir jemand sagen, ob der WebAccess nicht über den Brokerdienst geht, sondern sich direkt mit den RDS Hosts verbinden will? Das wäre für mich zur Zeit die einzige mögliche Erklärung, auch wenn ich dann noch nicht weiß, wie ich das Problem lösen könnte, da beide Zugangsmöglichkeiten auf die Farm gewünscht sind. Danke Mag Aufrufe aus dem WebAccess gehen über den Broker. Gib mal bitte die Ausgabe von 'Get-RDCertificate', 'Get-RDWorkspace' und ein 'certutil -dump' vom fraglichen Zertifikat. Zitieren Link zu diesem Kommentar
Beste Lösung Magroll 10 Geschrieben 28. Oktober 2015 Autor Beste Lösung Melden Teilen Geschrieben 28. Oktober 2015 Hi Dunkelmann, das mit dem Thumbprint habe ich gemacht, damit er lokal auf dem Sessionhost das richtige Zertifikat benutzt (das erstellte Zertifikat für rdsfarm.mydomain.com), was ja auch funktionierte. Standardmäßig hat der Server ja nur sein eigenes für rds02.mydomain.com. Ich habe das Problem jetzt aber endlich behoben :o) Durch die Erstellung eines SAN Zertifikates, welches ich jetzt an den entsprechenden Stellen verwende, antwortet der Sessionhost jetzt mit einem Zertifikat alle in dem Zertifikat eingetragenen Namen, in meinem Fall rds02.mydomain.com und rdsfarm.mydomain.com, dies hat mein Problem gelöst! Bei Interesse siehe : https://www.windowspro.de/wolfgang-sommergut/san-zertifikate-ausstellen-ueber-active-directory-ca Vielen Dank und Gruß, Mag Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.