Garant

Okay, vielen Dank. Für alle, die den RDG auch via Apache2 veröffentlichen wollen, poste ich einfach mal meine Konfiguration. Es muss das Modul mod_proxy_msrpc aktiviert sein. Ich habe festgestellt, dass auf den Clientrechnern (Windows 10) noch ein Registry-Hack erzwungen werden muss, wenn eine Verbindung über das Gateway aufgebaut werden soll. Er versucht sich via Kerberos-Ticket bzw. NTLM zu authentifizieren und das geht nicht, da kein Ticket existiert bzw. NTLM nicht über den RP übertragen werden kann. Er springt durch folgenden Hack auf RPC-over-HTTP zurück. [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client] "RDGClientTransport"=dword:00000001 ProxyRequests Off ProxyPreserveHost On SSLProxyEngine On SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off # Die folgende direktive lädt das mod_proxy_msrpc-Modul. OutlookAnywherePassthrough On ProxyPass / https://internal.rdg.server/ ProxyPassReverse / https://internal.rdg.server/ SSLEngine on SSLCertificateFile <Zertifikat> SSLCertificateKeyFile <Schlüssel> SSLCertificateChainFile <CA-Zertifikat> Gruß

Guten Morgen, hast du ein Stichwort, wonach ich suchen kann um das zu konfigurieren? Aktuell werden die Sammlungen nur auf dem jeweiligen Session Host im Webaccess angezeigt.

Eine Frage hätte ich noch, wenn ich nun mehrere Session Hosts habe, kann ich die dort hinterlegten Sammlungen/RemoteApps alle in einem RDWeb anzeigen lassen?

KEMP war auf den Beitrag von testperson bezogen. In Betrieb haben wir aktuell kein KEMP, nur den Apache als Reverse-Proxy, welchen ich auch eigtl. erstmal dafür verwenden möchte.

An 2FA habe ich sowieso schon gedacht. Wir müssen (leider) noch auf Server 2012 R2 zurückgreifen, ich hoffe, dass das noch soweit in Ordnung geht. Gepatched wären die Systeme so oder so. Zusammendfassend gehe ich jetzt mit haproxy/apache/kemp davon aus, dass dieser in der DMZ arbeitet und den RDG sowie Session Host, die im internen Netz stehen, veröffentlicht, korrekt?

Ich hoffe, ich beanspruche euer Know-How nicht zu sehr, jedoch würde ich hier gerne noch einmal nachhaken. Mein/unser Reverse-Proxy steht aktuell auch schon in der DMZ, wie oben beschrieben handelt es sich um einen apache2. Damit könnte ich dann die RDweb-Seite veröffentlichen und den RDP-Gateway? Wie würdet ihr das Sicherheitsrisiko bewerten?

Wie sieht das Konstrukt dann aus? Ich haeng den FBL in die DMZ und veröffentliche darüber einfach die Terminalserver, die bei mir im internen Netzwerk stehen? Einen Reverse-Proxy in Form von Apache habe ich bereits schon für andere Veröffentlichungen (Exchange) im Einsatz.

Danke für die erste Antwort. Ich denke, es kommt drauf an, wie sich der Aufbau der RDS-Farm gestaltet und ob die Konfiguration am Ende über den RDS-Webaccess und das Gateway sicherer ist. Ich hätte noch folgende Möglichkeit, dass ich über die Firewall nach außen ein Webaccess-VPN zur Verfügung stellen kann, wo sich der Benutzer anmeldet und eine RDP-Verbindung im Browser zum Terminalserver aufbauen kann. Allerdings ist das natürlich nicht so komfortabel wie direkter RDP-Zugriff mit der Windows-Anwendung. Die Firewall ist eine FortiGate.

Guten Morgen zusammen, erstmal zu meiner Person. Ich bin Tom und komme aus Bremen. Was wäre der geschickteste Weg einen bzw. zwei Terminalserver von außen und ohne VPN erreichbar zu machen? Über WebAccess kann ich dem Anwender über das Internet ja eine URL zur Verfügung stellen, worüber er Desktops bzw. RemoteApps aufrufen kann. Der Traffic läuft dann über den Gateway zu den Session Hosts. Die Frage ist nun, welche der Komponenten setze ich in einer DMZ ab? WebAccess und Gateway? Oder auch der eigentliche Session Host? Vielleicht kann mir jemand etwas Licht in das Dunkle bringen, bevor ich ohne größeres Vorwissen irgendeine Testumgebung installiere. Gruß