Zertifikatsproblem mit RDS

[THC 0]

Liebe Fachleute,

 

ich beisse mit gerade die Zähne an einem Zertifikatsproblem aus.

 

Ausgangssituation:

 

2 Domänencontroller Windows Server 2016, einer davon (SRV11) betreibt die interne Zertifizierungsstelle.

Dann 2 RDS-Hosts (SRV18, SRV19) auch Windows Server2016 - SRV18 ist Sitzungshost, macht den Verbindungsbroker (VB) und WebAccess für RDP - SRV19 ist Lizenzserver und auch Sitzungshost.

 

IM DNS gibt es einen Eintrag RDS, der auf SRV18 und SRV19 verweist (Round Robin).

 

Die Bereitstellung ist mit einem Zertifikat der internen Zertifizierungsstelle ausgestattet (für die drei Bereiche VB Serverauthentfizierung, VB RDP-Verschlüsselung und Web Access) das Zertifikat ist als vertrauenswürdig eingestuft.

Das Zertifikat ist ausgestellt auf den Eintrag im DNS - also auf RDS.meineDomain.local

 

Wenn ich nun mit einen Client, der nicht Mitglied der Domäne ist, über VPN per RDP eine Verbindung zu RDS.meineDomain.local aufbaue, erhalte ich nach Eingabe von Benutzer und Passwort abwechselnd unterschiedliche Zertifikatsmeldungen:

- Einmal die Meldung zum Zertifikat RDS.meineDomain.local, "Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden". - Verbindungsaufbau klappt dann trotzdem und ich lande dann z.B. auf SRV19

- und bei der nächsten Verbindung dann die Meldung zum selbst ausgestellten Zertifikatdes SRV19  - SRV19.meineDomain.local, "Das Zertifikat stammt nicht von einer vertrauenswürdigen Zertifizierungsstelle." - Verbindung klappt auch hier und ich lande dann auch auf SRV19 oder auch SRV18 - je nachdem, welcher mir dann vom VB zugewiesen wird.

 

Die unterschiedlichen Zertifikatsmeldungen ergeben sich offensichtlich aus der Verteilung des Zugriffs aus dem DNS: lande ich mit der Anfrage bei SRV18 bekomme ich das Zertifikat RDS.meineDomain.local, lande ich bei SRV19, bekomme ich dessen selbst ausgestelltes Zertifikat.

 

Aber warum?

 

Auf beiden Servern SRV18 und SRV19 ist das Zertifikat RDS.meineDomain.local im lokalen Zertifaktsspeicher "Eigene Zertifikate" und "Remotedesktop" hinterlegt. Zusätzlich liegt dort jeweils auch das Zertifikat der internen CA und ein selbst ausgestelltes Zertifikat des jeweiligen Servers.

 

SRV18 zeigt mir das Zertifikat des DNS-Eintrages RDS.meineDomain.local, SRV19 offenbar immer sein selbst signiertes Zertifikat - selbst wenn ich es lösche und alle Caches lösche und den IIS von SRV18 resete.

 

Kann mir jemand dieses Verhalten plausibel erklären? Wo mache ich etwas falsch?

 

Darüber hinaus bringe ich den externen Client auch nicht dazu, einem oder beiden Zertifikaten zu vertrauen - und wenn ich sie noch so oft in den Zertifikatsspeicher installiere.

 

Entschuldigt den langen Text - ich hoffe ich konnte mein Problem deutlich machen. Für Rückfragen stehe ich gerne zur Verfügung - besten Dank im Voraus!

 

MfG Thomas

 

 

 

 

[testperson 1.711]

Hi,

 

in kurz: Verzichte auf DNS Round Robin.

 

 

 

Gruß

Jan

bearbeitet 19. Februar 2018 von testperson

[THC 0]

Danke Jan,

 

wenn ich die beiden angeführten Threads richtig interpretiere, meinst du, ich sollte als Broker einen dedizierten (anderen) Server einsetzen, der nicht auch Sitzungshost ist und im DNS dann explizit auf diesen einen mit RDS.meineDomain.local = VerbindungsbrokerIP verweisen und damit RoundRobin vermeiden? Und damit löst sich auch das Zertfikatsproblem?

 

Hmm - muss ich mal schauen, ob ich die Verbindungsbrokerrolle einfach so woanders hin umgedreht bekomme - ich probiere es mal - und berichte dann - danke!

 

MfG Thomas

[testperson 1.711]

Ich würde dir, wie in den anderen Beiträgen, zu einem dedizierten Broker raten. _Müssen_ tust du nicht.

Ansonsten zitiere ich mich mal aus einem der beiden Beiträge:

Zitat

Erstelle mal eine RDP Datei mit dem Broker (bei dir also TS01.<Domäne>.<tld>) als Ziel und speichere diese ab. Öffne die Datei z.B. mit Notepad und passe folgende Einträge an bzw. füge diese hinzu:

use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.<RDS COLLECTION NAME>

Bei dir wäre es dann aber SRV18 anstelle von TS01.

[THC 0]

Damit bekomme ich keine Verbindung (das erwartete Zertifikat RDS.meinDomain.local wird aber präsentiert) Fehlermeldung ist beigefügt. Wie genau ist RDS COLLECTION NAME anzugeben? - ich habe nur den Namen angegeben - keine Serverbezeichnung dabei - reicht das?

 

Danke im Voraus für deine Geduld.

 

MfG Thomas

 

[testperson 1.711]

Da kommt lediglich der Name der Sammlung rein. Als Zielcomputer wird der Broker genutzt?

[THC 0]

Ja - FQDN des Brokers.

 

Edit: Der gleiche Fehler taucht auch auf, wenn ich das direkt in der registry versenke, also mit:

 

DefaultTsvUrl"="tsv://MS Terminal Services Plugin.1.OfficeCollection

 

 

Edit erneut: Manchmal ist man auch schon belämmert - wenn ich in der registry nun denn den richtigen Namen für den Platzhalter angebe, klappts auch mit dem Nachbarn - sorry.

 

Nun verbindet sich der Client brav nacheinander immer mit dem jeweils nächsten freien Host und ich bekomme jedes mal das Zertifikat der Bereitstellung präsentiert -allerdings mit dem Fehler - siehe unten:

 

 

Bekomme ich das mit einem internen Zertifikat gelöst? Oder brauche ich da was von einer externen CA?

 

Besten Dank schon mal für deine Hilfe!

 

MfG Thomas

bearbeitet 19. Februar 2018 von THC

[zahni 554]

Die Meldung  sagt doch alles. Es ist  eine CRL und/oder  ein Online Responder konfiguriert. Die Quellen sind  nicht erreichbar.

[THC 0]

Mensch, zahni! Endlich mal ein wirklich hilfreicher Post! Wird man eigentlich Expert Member weil man sich besonders eng an sein Motto hält ?

 

Wenn ich den Pfad für die Sperrprüfung direkt in Explorer einfüge, erreiche ich die Sperrliste aber....

 

 

 

 

Allerdings kann ich irgendwie in der Zertifizierungsstelle den HTTP-Pfad nicht richtig veröffentlichen, das ist ausgegraut - irgendwas fehlt da noch - hast du da vielleicht einen Tip aus deinem Fundus, was ich falsch mache bzw. anders machen muss? Danke im Voraus - Thomas

 

 

 

 

[tesso 375]

Von wann ist die Sperrliste?

Ich vermute sie ist abgelaufen.

[Dr.Melzer 191]

vor 2 Stunden schrieb THC:

Wird man eigentlich Expert Member weil man sich besonders eng an sein Motto hält ?

Was meinst du damit?

[testperson 1.711]

Am 19.2.2018 um 17:02 schrieb THC:

Bekomme ich das mit einem internen Zertifikat gelöst? Oder brauche ich da was von einer externen CA?

Das geht auch mit einem Zertifikat deiner eigenen CA. Ich würde bei sowas aber immer von einer externen CA signieren lassen.

Wo liegen die Sperrlisten? Auf einem IIS? Dann wirst du den Delta-CRL Download noch erlauben müssen: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd379478(v=ws.10)

 

Beim verwalten der Pfade solltest du einfach den "Hinzufügen" Button wählen und dort dann den Ort angeben, wo die CRLs abgerufen werden können (Und die CRLs dort natürlich auch veröffentlichen).

Am 19.2.2018 um 17:02 schrieb THC:

Ja - FQDN des Brokers.

 

Edit: Der gleiche Fehler taucht auch auf, wenn ich das direkt in der registry versenke, also mit:

 

DefaultTsvUrl"="tsv://MS Terminal Services Plugin.1.OfficeCollection

 

 

Edit erneut: Manchmal ist man auch schon belämmert - wenn ich in der registry nun denn den richtigen Namen für den Platzhalter angebe, klappts auch mit dem Nachbarn - sorry.

Das ist, wie im anderen Thread beschrieben, nur ein Workaroun für alte Clients. Du solltest die RDP entsprechend richtig konfigurieren und verteilen. Zur Not eine über RDWeb generieren.

 

P.S.: Evtl. solltest du deine Server / Domänen / etc. Namen in den Screenshots anonymisieren.

bearbeitet 21. Februar 2018 von testperson