Jump to content

Garant

Members
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Garant

  • Rank
    Newbie
  1. Aktuell habe ich mit meinen ca. 25 Benutzern keine Bauchschmerzen was die verfügbare Bandbreite und die Performance der Maschine angeht. Geht mir hier wirklich nur um den Vergleich, da ich davon ausgehe, dass es hier sicherlich einige gibt, die das Produkt mit vielen weiteren Benutzern einsetzen. In den aktuellen Zeiten ist die Frage nach solchen Möglichkeiten höher denn je.....
  2. Die ERP-Software ist Telnetbasierend, da sehe ich eher weniger ein Problem. Die Session Hosts sind in unseren Fällen die Büro-Arbeitsplätze der Mitarbeiter, auf die wir die Mitarbeiter via RDG zugreifen lassen.
  3. Guten Morgen, vor einiger Zeit hatte ich ja eine technische Rückfrage zur Bereitstellung des RD-Gateways. Das läuft nun auch gut mit knapp 25 Benutzern. Gibt es von euch Erfahrungswerte bis wie viele Personen so ein RD-Gateway stabil und flüssig läuft? Ich weiß, hängt natürlich stark vond er Umgebung und deren Tätigkeiten ab. Wir machen hier allerdings nur Office- und ERP-Software.
  4. 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ß
  5. 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.
  6. 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?
  7. 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.
  8. 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?
  9. 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?
  10. 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.
  11. 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.
  12. 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ß
×
×
  • Create New...