Zugriff auf RDS-Server mit Clients ohne Domänenmitgliedschaft nicht möglich

Ich hatte bei einem Kunden das Problem, das ein Client in einem Branch-Office (Außenstelle im Ausland) über eine VPN-Verbindung keine Verbindung mit dem “Remote Desktop Services” (RDS) –Server in der Zentrale aufbauen konnte. Der Client hat Windows 7 als Betriebssystem und ist nicht Mitglied der Domäne in der Zentrale. Mit einem Windows XP funktionierte die Verbindung ohne Probleme, wenn man über Windows 7 eine Verbindung versuchte, erschien die folgende Fehlermeldung:

Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden.

Der Verbindungsaufbau wird dann abgebrochen, eine Verbindung ist nicht möglich. Ich habe dann überprüft ob der Sperrlistenverteilungspunkt der PKI (per HTTP) erreichbar ist, dies war der Fall, ich konnte sowohl die Sperrliste als auch die Delta-Sperrliste herunterladen.

Das Problem ist eine Einstellung auf dem (oder den, falls mehrere vorhanden sind) RDS-Server. In der “Konfiguration des Remotedesktop-Sitzungshostserver” unter “Verbindungen” in den “Eigenschaften von RDP-Tcp” gibt es den Punkt “Sicherheitsstufe.

Zugriff-auf-RDS-Server-mit-Nicht-Domaenen-Mitglied-01

In der Info unter der Option sieht man den folgenden Text:

Sie sicherste vom Client unterstützte Stufe wird verwendet. Sofern unterstützt, wird “SSL (TLS 1.0)” verwendet.

Bei einem Windows XP ist die höchste Stufe, die gemeinsam genutzt werden kann, die “RDP-Sicherheitsstufe”. Bei Windows 7 ist die höchste gemeinsam nutzbare Sicherheitsstufe aber die besagte “SSL (TLS 1.0)”-Verschlüsselung. Es ist scheinbar so, das bei dieser Art der Verschlüsselung der Abruf der Sperrliste nicht über HTTP erfolgt (Ob über LDAP weiß ich nicht) und deshalb die Verbindung nicht aufgebaut werden kann. Falls der Abruf über LDAP passieren soll funktioniert dies aufgrund fehlender Domänenzugehörigkeit nicht.

Eine Lösung des Problems ist, das man die Sicherheitsstufe in den Eigenschaften auf “RDP-Sicherheitsstufe” setzt. Danach funktioniert eine Verbindung auch von einem Windows 7 ohne Domänenzugehörigkeit.

Sicherheitstechnisch halte ich das persönlich nicht für kritisch, da ja bereits die Verbindung zwischen den beiden Standorten über eine gesicherte VPN-Strecke aufgebaut wird.

Teilen:

Jan Kappen

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitet seitdem bei der Rachfahl IT-Solutions GmbH & Co. KG. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Im April 2015 wurde Jan Kappen im Bereich "File System Storage" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

9 Kommentare:

  1. Ich habe heute die Umstellung der RDP-Sicherheitsstufe durchgeführt. Folgende Nachteile ergeben sich aus meiner Sicht:
    Wozu habe ich ein Zertifikat, wenn ich es nicht benutze?
    Alle bisher ausgehandelten Verbindungen über SSL werden “v ergessen” und es werden von allen Benutzern die ANmeldedaten erneut angefordert.

  2. Wir reden hier von Clients die nicht Mitglied der Domäne sind, und zweitens von Windows XP. Das Clients keine Mitglieder der Domäne sind ist schon mal nicht toll, da sie dann nicht per GPOs usw kontrolliert werden können. Weiterhin ist Windows XP mittlerweile knapp 9 Jahre alt, das gilt auch zu berücksichtigen. Normalerweise sind die RDS dazu gedacht, das sie mit “gleichwertigen” Client-Betriebssystemen (Vista oder 7) genutzt werden. XP sollte meines Wissens nach ursprünglich erst gar nicht in die Liste der unterstützten Betriebssysteme mit aufgenommen werden bei den Server 2008 R2 RDS…
    Diese Methode wird auch nicht empfohlen, da hier die Sicherheit heruntergesetzt wird. Je nach Art der Umgebung kann es auch sein das der Administrator dieser Vorgehensweise nicht zustimmt und man das Client-Betriebssystem updaten muss, damit der Client erfolgreich eine Verbindung aufbauen kann. Wir haben diese Thematik mit unserem Kunden durchgesprochen, für Ihn war die oben genannte Lösung in Ordnung. Da wir die Zertifikate vor Ort sowieso “nur” mit einer PKI erstellt haben, fallen auch keine unnötigen Kosten für Third-Party-Zertifikate an…

    Gruß,
    Jan

  3. Es gibt von Microsoft einen Patch für Windows 7, der dieses Problem löst. Dann kommt zwar immernoch die Meldung aber es gibt ein zusätzliches Feld “Trotzdem verbinden”. Damit braucht man die Sicherheitsstufe nicht umstellen, muss aber den Patch ausrollen. Der Patch ist nicht frei verfügbar und wird nur auf Anfrage ausgeliefert. Finde ich trotzdem die schönere Lösung.

  4. @Bjoern
    wo ist denn dieser Patch veröffentlicht?

  5. Hallo Carsten,
    kannst du mir den Link für den Patch zukommen lassen?

    vielen Dank
    !

  6. Hallo Martin,

    wir haben bisher noch keinen Link zu dem Patch. Ich werd mich bei Gelegeneheit mal auf die Suche danach begeben…

    Gruß, Jan

  7. Der Patch wäre sehr interessant, da nach einer Umstellung auf die RDP-Sicherheitsstufe keine Remote-Apps mehr funktionieren.

  8. Ich habe eine Lösung für das Problem gefunden und erfolgreich getestet.

    Auf dem Terminalserver ist bei mir ein Zertifikat installiert, welches von einer eigenen Zertifizierungsstelle ausgestellt wurde.
    Der betroffene Client ist nicht der der Domäne des Terminalservers.

    Das Root Zertifikat der Zertifizierungsstelle habe ich bisher immer per Doppelklick und dann unter “Vertrauenswürdige Stammzertifizierungsstellen” installiert.
    Das brachte allerdings bisher keine Abhilfe.

    Die Lösung ist folgende:
    – MMC am betroffenen Client öffnen
    – Zertifikate Snap-In hinzufügen und lokaler Computer (nicht Benutzer) auswählen.
    – das Root Zertifikat unter vertrauenswürdige Zertifizierungsstellen importieren

    Und schon sollte es klappen. Bei mir gings dann.
    Wenn man das Zertifikat per Doppelklick installiert, wird es nur unter dem Benutzer, nicht unter lokaler Computer installiert.

    Ich hoffe, damit ein paar Leuten helfen zu können.

    Grüße

    Lorenz

  9. Bin am selben Problem mit der Sperrprüfung.

    Kann mir bitte jemand den Link zum Patch posten?

    Grüße,
    Bernd

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.