Jump to content

RDS 2016 - Zugriff auf Anwendung nur aus einem bestimmtem Netzwerk


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Leute,
hätte da mal eine sehr spezielle Frage bzgl. dem Bereitstellen einer Anwendung. Genauer gesagt einer möglichen Zugriffsbeschränkung.

Folgende Situation:

Wir betreiben eine RDS Farm 2016 bestehend aus.
2x Citrix Netscaler MPX 5550 (Loadbalancer)
2x RD-Gateway
2x RD-Web Access
2x RD-Connection Broker (+SQL DB)
1x RD Lizenzserver

Alle Server stehen innerhalb der Domäne.
Das Webinterface ist sowohl aus dem internen Netz, als auch über das Internet zu erreichen.
Wird ein User für eine Anwendung freigeschaltet, sieht er diese im Webinterface und kann diese starten. Sofern er auch Mitglied einer separaten Gruppe ist, darf er die Anwendung auch über das Internet und somit über das RD-Gateway starten.

Nun haben wir zu unserem internen Netz noch ein weiteres, sagen wir mal „Kundennetz“
Wir möchten auf der Farm nun eine Anwendung bereitstellen, die NUR erreichbar/startbar ist aus diesem „Kundennetz“, NICHT über das Internet.
Wie kann man das erreichen?

(Mit der RDS Umgebung inkl. AD kenne ich mich gut aus, alles was den Netscaler betrifft bin ich allerdings nicht so gut informiert!).
Ich hoffe ich konnte alles möglichst verständlich beschreiben.

Im Voraus vielen Dank!

Frage.JPG

Link zu diesem Kommentar

Wenn sich der Benutzer auf einem RDSH befindet, auf dem auch eine andere Software läuft, dann kann diese dennoch ausgeführt werden. Zwar kann er über die Berechtigung nur seine berechtigte RemoteApp öffnen, jedoch bieten viele Programme hier ein "Datei öffnen" an. Dort lässt sich einfach eine CMD oder ein anderes besagtes Programm öffnen.

 

Ein Trennung wirst du nur sauber durch einen anderen RDSH, bzw. eine andere Sammlung hinbekommen.

Link zu diesem Kommentar

Hallo MurdoX,

 

danke für deinen Beitrag. Darum geht es allerdings nicht. Mir ist durchaus klar, dass der User auf dem SessionHost noch weitere Programme starten kann.

 

Aus allen Netzen kommt man aufs Webinterface und sieht seine verfügbaren Anwendungen (A,B,C). Diese sind ja dem User zugeordnet.

Anwendung C darf NICHT starten, wenn man dies über das Internet versucht. Die Anwendung darf NUR aus dem Kunden oder internen-Netz gestartet werden können.

Das ist der Punkt worum es sich dreht.

Link zu diesem Kommentar

Hallo CoNtAcT2000,

 

ich hab in den Punkt schon etwas weiter gedacht. Berechtigungen werden über Gruppenmitgliedschaften (wenn´s sauber konfiguriert wurde) vergeben. Diese sind aber nicht abhängig davon von wo eine Person sich verbindet. Daher wird deine Idee/Anforderung nicht aufgehen. Vielleicht hat ja jemand noch eine Kreative Idee. Mir ist aber nichts bekannt. Es gibt sicher Möglichkeiten Verbindungen aus unterschiedlichen Netzen zu blockieren. Das gibt dann aber Fehlermeldungen, anstatt einer sauberen Lösung.

 

Jetzt setzt meine Nachricht von oben an. Selbst wenn es irgendwie machbar wäre, dann könnte die Software dennoch einfach gestartet werden. Dein Konzept wäre also sehr schnell ausgehebelt. Um das zu umgehen, kannst du eine neue Session mit den jeweiligen RDSH erstellen.

Link zu diesem Kommentar

Hi,

 

eine Option wäre von Microsoft RDS auf Citrix Virtual Apps and Desktops zu schwenken. Ansonsten könnte man da evtl. am Netscaler ansetzen und ggfs. mit dem RDP Proxy und/oder Rewrite- / Responder-Policies den Content vom RD-Web in Richtung Client für Externe bearbeiten.

 

Letzteres dürfte aber sicherlich enorm wartungsintensiv sein.

 

Gruß

Jan

Link zu diesem Kommentar

Du könntest nicht die EXE der Anwendung freigeben, sondern ein Script, welches die Client-IP prüft und die Anwendung nur startet, wenn die Client-IP aus einem internen Netzwerk kommt. Das wäre einigermassen "sauber".

 

Du könntest auch das Web Interface anpassen und gewisse Icons nicht anzeigen lassen je nach Client-IP. Da muss man dann einfach aufpassen bei Updates.

 

Oder, wenn es nicht sehr sicher sein muss: das Web Interface um ein JavaScript ergänzen, welches die Client-IP prüft und bei externen Benutzern das Icon für die Anwendung ausblendet. Das kann dann aber jeder umgehen, der sich ein bisschen mit JavaScript auskennt.

Link zu diesem Kommentar

Danke für eure Ideen.

 

- Icon ausblenden ist mir für die Anwendung nicht sicher genug, bzw. bietet ja so gesehen keine wirkliche Sicherheit/Gewissheit
 

- Script welches die Client IP prüft klingt interessant.
  Allerdings kann ich mir grad aus dem Stehgreif gedanklich nicht vorstellen, wie ich auf dem Session Host an die Client IP komme?
  Kannst du mir hier vielleicht weiter auf die Sprünge helfen wie du das skripten würdest?:hmmm:
 

- Umstieg/Erweiterung auf Citrix geht überhaupt nicht!
Erstens hohe, zusätzliche Kosten und zweitens haben wir vor ca 5 Jahren ein absolutes Desaster mit der Firma Citrix erlebt. Support Total mies, versprechen Dinge, die Ihre Produkte einfach nicht können - geben es aber auch nicht zu. Wir haben damals verdammt viel Geld und Manpower in das Projekt versenkt um nachher mit nichts da zu stehen und alles einzustampfen! Trotz Telefon/Video Support über den ganzen Globus! Eine Lachnummer, was sich Citrix da erlaubt hat! Dann die ganzen Abhängigkeiten, Registry Tweaks bei Version XY und Konstellation xy. Die schaffen es ja nicht einmal eine neue Citrix Receiver Version rauszubringen, wo man davon ausgehen kann, dass sie ohne zu knurren bzw. totalversagen funktioniert!:rolleyes::thumb2:

 

Intern hatten wir jetzt noch die Idee das "Kundennetz" auf die interne Loadbalancer IP des Netscalers umzubiegen. Dann müssten man im Kundennetz aber dafür sorgen, dass das RD-Webinterface nicht mehr über das Internet aufgerufen wird, sondern der Aufruf über das Kundennetz geroutet wird. Dann brauche ich den Usern keine Berechtigungen für das RD-Gateway zu geben und sie könnten dann vom Internet aus die Anwendung nicht starten.:hmmm:

Link zu diesem Kommentar
vor 7 Stunden schrieb CoNtAcT2000:

Allerdings kann ich mir grad aus dem Stehgreif gedanklich nicht vorstellen, wie ich auf dem Session Host an die Client IP komme?
  Kannst du mir hier vielleicht weiter auf die Sprünge helfen wie du das skripten würdest?:hmmm:

Im Event Log steht ein entsprechendes Ereignis. Es soll jedoch auch über eine API gehen:

https://community.spiceworks.com/topic/2147508-powershell-get-client-ip-in-rds

Link zu diesem Kommentar
vor 8 Stunden schrieb CoNtAcT2000:

- Script welches die Client IP prüft klingt interessant.

Du kannst am Netscaler die Client-IP auf mehrere Wege "mitgeben".

 

vor 8 Stunden schrieb CoNtAcT2000:

- Umstieg/Erweiterung auf Citrix geht überhaupt nicht!
Erstens hohe, zusätzliche Kosten und zweitens haben wir vor ca 5 Jahren ein absolutes Desaster mit der Firma Citrix erlebt. Support Total mies, versprechen Dinge, die Ihre Produkte einfach nicht können - geben es aber auch nicht zu. Wir haben damals verdammt viel Geld und Manpower in das Projekt versenkt um nachher mit nichts da zu stehen und alles einzustampfen! Trotz Telefon/Video Support über den ganzen Globus! Eine Lachnummer, was sich Citrix da erlaubt hat! Dann die ganzen Abhängigkeiten, Registry Tweaks bei Version XY und Konstellation xy. Die schaffen es ja nicht einmal eine neue Citrix Receiver Version rauszubringen, wo man davon ausgehen kann, dass sie ohne zu knurren bzw. totalversagen funktioniert!:rolleyes::thumb2:

Das kann ich so alles nicht unterschreiben. Aber möchte auch nicht ausschließen, dass sowas passiert. Kenne ich schließlich auch von anderen Herstelleren. ;)

Bzgl. der Kosten, wie lizenziert ihr das Ganze eigentlich? Im Fall von Citrix müsste das eigentlich CSP sein und da hättet ihr eigentlich ein ganz gutes Support-Level.

Link zu diesem Kommentar

 

 

vor 15 Stunden schrieb mwiederkehr:

Im Event Log steht ein entsprechendes Ereignis. Es soll jedoch auch über eine API gehen:

https://community.spiceworks.com/topic/2147508-powershell-get-client-ip-in-rds

 

vor 14 Stunden schrieb testperson:

Du kannst am Netscaler die Client-IP auf mehrere Wege "mitgeben".

ooookkkaaaaaaayyyyy. Danke euch bieden für den Schubs in diese Richtung, das schaue ich mir dann mal an.
Mit dem Netscaler bräuchte ich mehr Hinweise wie man so was konfiguriert, da fehlt mir das KnowHow im Detail.
 

Allerdings hat man mit der Client IP ja nur ne Lösung, um ggf. die Clients auszusperren, damit habe ich noch nicht erreicht, dass die Clients das Webportal nur über das Kundennetz aufrufen.

Auf den Clients bzw. der Infrastruktur überall das Webportal+Farmnamen umzubiegen ist nicht gerade die schönste Lösung. Aber die Daten dürfen nunmal nicht übers Internet laufen, auch wenns https verschlüsselt ist.
Ideal wäre halt ein zweites Webinterface mit anderer Adresse, welches dann nur von intern/Kundennetz erreichbar ist.
Aber gibt wohl nur die Möglichkeit eine Web-Access-Adresse je Farm zu betreiben?

 

vor 14 Stunden schrieb testperson:

Bzgl. der Kosten, wie lizenziert ihr das Ganze eigentlich?

Im Detail kann ich es dir nicht 100% sagen, da das nicht meine Kernbaustelle ist. Jedenfalls haben wir MS Enterprise Agreement, die TS-Farm läuft virtuell auf nem HyperV Cluster, auf dem dann (glaube ich) die CPU Cores lizensiert werden müssen. Wie gesagt nicht festnageln, ist nicht mein Steckenpferd. Alle "Kunden" sind BMI bezugsberechtigt und dürfen die Lizenzen nutzen. Und dann haben wir halt noch TS-User-Call´s. Soweit meine Infos zu dem Lizenzthema.

 

 

 

 

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...