TS-Gateway in der DMZ

[Data1701 10]

Für was steht denn bei dir die Abkürzung ISA? Den ISA-Server von MS kannst du ja nicht meinen !

 

Meine Aussage bezog sich nicht auf das forwarden als solches, sondern auf die Masse an Ports die eine Memeberserver in der DMZ geöffnet haben will.

 

Gruß Data

[LukasB 10]

Data,

 

Nochmal einfache Frage: Wie veröffentlichst du dein OWA?

 

Veröffentliche doch den TSGW identisch wie OWA!

[Stephan Betken 43]

Meine Aussage bezog sich nicht auf das forwarden als solches, sondern auf die Masse an Ports die eine Memeberserver in der DMZ geöffnet haben will.

Aber genau das ist mit der Veröffentlichung durch den ISA eben nicht der Fall. Dieser ist als Core-Firewall für die Veröffentlichung der benötigten Dienste und Anwendungen prädestiniert. Die benötigten Ports für die Kommunikation mit der Domäne sind nur auf der internen Schnittstelle geöffnet und nicht aus der DMZ erreichbar.

 

Lies dir den von dir geposteten Link noch mal ganz genau durch!

Note: If there is an ISA server already deployed in the perimeter network of your organization, then RD Gateway server can be put in the internal network which reduces the number of ports that need to be opened on the internal firewall (path from perimeter network to internal network) to one.

 

Und bevor wieder Stimmen laut werden, was ein ISA-Server als Member angeht: Debunking the Myth that the ISA Firewall Should Not be a Domain Member

 

...und seiner AD mitteilen, dass er auch noch existent ist, sonst stirbt ja irgendwann sein Computerkonto.

Um welche Windows-Versionen geht es denn hier? :suspect: :confused: :rolleyes:

[Data1701 10]

Ich glaube wir sprechen aneinander vorbei.

 

a. Gateway gehört für mich in die DMZ. Sonst könnte ich auch direkt 3386 forwarden auf die Server die ich benötige.

 

b. OWA wird bei mir gar nicht geforwarded. Zugriff auf eMail etc, geschieht nur über VPN, Konzernrichtlinie

 

c. Die Konzernrichtlinie schreibt auch vor, das jeder Zugriff auf das interne Netz in der DMZ gepuffert werden muss. Das betrifft SMTP, HTTP, FTP, Black-Berry etc.

 

Jede der unter c. genannten Kompenten ist kein Domänenmitglied, übrigens wir sprechen immer von 2008 Meberserver.

 

Dein Vorschlag verstehe ich sehrwohl. Nimm einen ISA-Server und puffere damit die Anfragen. Das ist für mich ein Krücke. Ich muss ja auch keinen ISA-Server in die DMZ packen um SMTP-Anfragen zu puffern oder ?! Das Design der Exchange-EDGE-Komponete erlaubt es ohne den ISA-Server ein max. an Sicherheit zu bekommen. Warum wurde das beim TS-GW nicht ähnlich gemacht, dass ist die Frage die ich mir stelle...

Als Kunde muss ich die "schlechte" Umsetzung durch den Zukauf eines weiteren Produktes kompensieren.

 

Des Weiteren hat TS-GW noch weitere kleine "Bugs", die dieser Komponenete nur ein ausrreichend bescheren.

 

Was passiert, wenn das Passwort in der Domäne abläuft und der User versucht sich über das TS-GW einzuklinken. Die TS-CAP verhindert das, das TS-GW gibt aber keine Möglichkeit zur Änderung des PW.

 

Veröffentlichung der benötigten Dienste und Anwendungen prädestiniert. Die benötigten Ports für die Kommunikation mit der Domäne sind nur auf der internen Schnittstelle geöffnet und nicht aus der DMZ erreichbar.

 

Da muss ich mir keinen Link durchlesen, mir ist schon klar was Du vorhast und wie es funktioniert, sorry das ich das so klar sagen muss.

 

Schaue Dir mal genau die Doku für die Impelementierung des TS-GW an.

 

Download details: TS Gateway Step-By-Step Guide

 

Seite 39, das Schaubild. So sieht es bei uns aus. Der Pfeil vom TS-GW nach inner, geht "neben" der Firewall vorbei. Die Jungs von MS wissen schon warum....

 

Gruß Data

[Stephan Betken 43]

...mir ist schon klar was Du vorhast und wie es funktioniert...

Hmmm...

a. Gateway gehört für mich in die DMZ. Sonst könnte ich auch direkt 3386 forwarden auf die Server die ich benötige.

...zwischen Forwarding von RDP ins interne Netz und Veröffentlichung von Port 443 (über welchen die RDP-Requests getunnelt werden), welches über den ISA läuft und nicht einfach weitergeleitet wird, gibt es doch Unterschiede.

 

Die Jungs von MS wissen schon warum....

Ja? Ich nicht. Erklär es mir.

 

Vielleicht solltest du dir die Geschichte mit der von dir genannten Abbildung nochmals anschauen und dann überlegen, warum z. B. auch Port 3389 von der DMZ ins interne Netz weitergeleitet wird! Könnte ja vielleicht damit zu tun, dass kein ISA eingesetzt wird.

b. OWA wird bei mir gar nicht geforwarded.

Warum denn auch? Würde ich auch nicht unbedingt wollen. Da ist SSL-Bridging eindeutig die bessere Wahl. Beim SSL-Bridging des ISA-Server wird ein SSL-Tunnel zum ISA-Server aufgebaut und dieser stellt eine SSL-Verbindung zum eigentlichen Webserver her und regelt die Zugriffe. Dabei besteht zu keiner Zeit ein direkter Zugriff, so wie dies bei einer Weiterleitung wäre.

Zugriff auf eMail etc, geschieht nur über VPN, Konzernrichtlinie

Und vom VPN sind welche Ports offen?

c. Die Konzernrichtlinie schreibt auch vor, das jeder Zugriff auf das interne Netz in der DMZ gepuffert werden muss. Das betrifft SMTP, HTTP, FTP, Black-Berry etc.

Jede der unter c. genannten Kompenten ist kein Domänenmitglied, übrigens wir sprechen immer von 2008 Meberserver.

Hört sich nach einer Aufgabe für den ISA-Server an.

Ein ISA muss nicht Domainmember sein und kann die genannten Vorgaben erfüllen.

 

Ich hoffe, du verzeihst mir diesen kleinen Seitenhieb, aber wie hast du Memberserver, die nicht in der Domäne sind?

Nimm einen ISA-Server und puffere damit die Anfragen. Das ist für mich ein Krücke. Ich muss ja auch keinen ISA-Server in die DMZ packen um SMTP-Anfragen zu puffern oder ?!

Ein ISA-Server macht ein eigehendes Relay nicht überflüssig. Das hat ja auch nie jemand behauptet.

Das Design der Exchange-EDGE-Komponete erlaubt es ohne den ISA-Server ein max. an Sicherheit zu bekommen.

Wie das? Einen zusätzlich vorgeschalteten SMTP-Anwendungsfilter, der einzelne Befehle nicht zulässt oder die Länge von einzelnen Befehlen einschränkt, um potenzielle Buffer-Overflows zu verhindern würde ich schon als Erhöhung der Sicherheit ansehen. Von daher liegt das Maximum an Sicherheit immer an der eingesetzten Lösung.

Beim Security-Server des EBS laufen übrigens EDGE-Transport und ISA-Server auf derselben Maschine. Der EDGE-Transport wird aber auch über den ISA abgesichert.

 

Also noch mal zusammengefasst:

Du suchst eine Lösung, um Zugriff auf das TS-Gateway ohne Memberserver in der DMZ zu bekommen. Die Lösung dazu hat Lukas dir ja schon genannt. Du kannst sie nutzen oder es lassen.

Wenn du eine bessere Lösung hast, dann nutze sie. Anderenfalls steht es dir natürlich frei, eine bessere Lösung zu entwickeln. Deine Beschwerden zeigen nur, dass du dich nicht mit dem ISA beschäftigt hast (und lieber falsche Annahmen hier einbringst), aber sie helfen dir auch nicht weiter.

Sorry, dass ich das so klar sagen musste.

 

Was genau spricht denn deinerseits gegen die Lösung ISA? Ich möchte dir da nicht reinreden, aber es interessiert mich schon, welche Gründe du hast, eine funktionierende Lösung abzulehnen und es lieber irgendwie anders gelöst haben möchtest.

Wenn man sich etwas mit dem ISA beschäftigt, dann wird man feststellen, dass er deutlich mehr bietet als andere Lösungen derselben Preisklasse. Bei anderen Herstellern muss man schon ein vielfaches an Investitionen einplanen, um nahezu dieselben Features zu bekommen.

[Data1701 10]

Moin,

 

hatte viel um die Ohren und habe dabei irgendwie diesen Thread vergessen.

 

Ich versuche es noch einmal.

 

...zwischen Forwarding von RDP ins interne Netz und Veröffentlichung von Port 443 (über welchen die RDP-Requests getunnelt werden), welches über den ISA läuft und nicht einfach weitergeleitet wird, gibt es doch Unterschiede.

 

Meine Aussage zu 3386 war überspitzt und sollte als solches auch verstanden werden. Sicher eine 443er-Veröffenlichung ist nicht mit dem 3386 forwarding zu vergleichen, nur hätte ich gerne den Port 443 über das Gateway veröffentlicht, ohne einen ISA-Server dafür in die DMZ zu stellen.

Das ist halt was ich von einem "Gateway" erwarte.

 

Und vom VPN sind welche Ports offen?

 

Alle, da die PCs sich ja in meinem virtuellen privaten Netzwerk befinden. Das gilt aber nur für PCs der eigenen Unternehmung die unserer PC-Hygiene unterliegen (WSUS - Antivirenschutz). Fremd-PCs können nur via RDP bzw. RemoteApp rein.

 

Hört sich nach einer Aufgabe für den ISA-Server an.

Ein ISA muss nicht Domainmember sein und kann die genannten Vorgaben erfüllen.

 

Ich hoffe, du verzeihst mir diesen kleinen Seitenhieb, aber wie hast du Memberserver, die nicht in der Domäne sind?

 

Seitenhieb OK ;), natürlich kleiner Tippfehler, Workgroup-Server, KEINE Memberserver.

 

Ja? Ich nicht. Erklär es mir.

 

Vielleicht solltest du dir die Geschichte mit der von dir genannten Abbildung nochmals anschauen und dann überlegen, warum z. B. auch Port 3389 von der DMZ ins interne Netz weitergeleitet wird! Könnte ja vielleicht damit zu tun, dass kein ISA eingesetzt wird.

 

Nun, ich erkläre es gerne, weil man eine "relativ" schlechte Umsetzung nicht noch weiter breitreden möchte. Einfach mal einen Pfeil vom Gateway an der Firewall vorbei ins interne Netz zeichnen und auch sonst seiner Dokumentationspflicht nicht nachkommen. :(

 

Der Port 3389 wird über das Gateway nach innen geleitet, ist ja auch OK, sonst würde das ganze Konstrukt ja nicht funktionieren. Aber die AD-Zugehörigkeit mal eben mit "einem Pfeil" abhandeln ist nicht die feine Art.

 

Wenn du eine bessere Lösung hast, dann nutze sie. Anderenfalls steht es dir natürlich frei, eine bessere Lösung zu entwickeln. Deine Beschwerden zeigen nur, dass du dich nicht mit dem ISA beschäftigt hast (und lieber falsche Annahmen hier einbringst), aber sie helfen dir auch nicht weiter.

 

Also auch wenn ich es mal so klar sagen muss ;), ich habe mich mit dem ISA beschäftigt, so ungefähr seit dem Jahr 2000.....

 

Es geht mir doch auch gar nicht darum, dass ich den ISA schlecht reden will. Das Produkt ist wirklich fein in manchen Bereichen, mit Sicherheit könnte ich auch hier alles damit erschlagen, allerdings muss ich dann wieder Geld in die Hand nehmen für Hard- und Software.

 

Ein Gatewayprodukt gehört in die DMZ und nicht in das interne Netzwerk, sonst muss ich es nicht Gateway nennen. Es ist nun einmal mein Standpunkt, dass ein SSL-Bridging via RDS-Gateway begrüßenswert gewesen wäre und nicht mit einem Zusatz-Produkt wie z.B. ISA. Ein Tunneling der SSL-Anfragen direkt nach innen ist eine Krücke aber keine Lösung.

 

Ich muss mir den Server 2008 R2 noch einmal genauer anschauen, aber ich habe irgendwo gelesen, dass das RDS Gateway unter 2008 R2 kein Memberserver mehr sein muss. Leider finde ich den Link dazu nicht mehr werde ich aber sofort nachliefern wenn ich diesen finde. Leider habe ich noch kein Best Practice für Server 2008 R2 gefunden.

 

Wenn dem dann wirklich so ist, dann spricht dass eigentlich nur dafür, das MS und auch andere Kunden die gleiche Ansicht vertreten wie ich :cool:.

 

Gruß Data

[WolfgangS 10]

Hi

 

Ich muss mir den Server 2008 R2 noch einmal genauer anschauen, aber ich habe irgendwo gelesen, dass das RDS Gateway unter 2008 R2 kein Memberserver mehr sein muss.

 

auch unter 2008 ohne R2 muss das TS GW keineswegs zwingend Mitglied einer Domäne sein. Man hat dann eben keine Möglichkeit mit Domänengruppen in CAPs und RAPs zu arbeiten.

 

Grüße

Wolfgang

[Data1701 10]

Also ist die Lösung noch immer:

 

a. Gateway intern legen

 

b. Auf AD-basierende CAPs und RAPs verzichten.

 

Schade.

 

Gruß Data

[Data1701 10]

Noch einmal einen Nachschlag :-),

 

Durch das Release von Forefront Threat Management Gateway entzerrt sich die Lage etwas.

 

Ich habe mich gegen den ISA in der DMZ immer etwas gewehrt, da ich nicht noch ein Kiste haben wollte, die quasi nur "eine Aufgabe" hat.

 

Das Threat Management Gateway kann ja nun endlich out-of-the-box das, wofür sonst andere Produkte eingesetzt wurden. HTTP Antivirus, Exchange EDGE Server Integration möglich....

 

Da könnte ich mir glatt vorstellen zwei Server in der DMZ zu ersetzen und dann das Threat Management Gateway als Reverser-HTTPS-Proxy zu nutzen.

 

Mal schauen...

 

Trotzdem, wenn ein Produkt den Namen "Gateway" trägt, also Remote Desktop Gateway, dann gehört es eigentlich in die DMZ, nur was nicht ist, ist halt nicht.

 

Gruß Data.

[LukasB 10]

Trotzdem, wenn ein Produkt den Namen "Gateway" trägt, also Remote Desktop Gateway, dann gehört es eigentlich in die DMZ, nur was nicht ist, ist halt nicht.

 

Ich habe hier noch einen älteren PC auf dem Gateway steht. Muss der jetzt auch in die DMZ?

 

Ich finds schon interessant wie du das am Branding festmachen willst ;)

[Data1701 10]

Moin,

 

ich habe mich jetzt mal von Eurer geballten Kompetenz ;) überzeugen lassen und ein TMG 2010 SP1 in die DMZ gestellt. Natürlich KEIN Memberserver.

 

Authentifizierung über LDAP-S für OWA alles fein, aber igendwie haben die TMG Entwickler das RD-Gateway vergessen.

 

Die FBA wird nicht wie bei OWA durch das TMG ersetzt (Geschützt durch TMG) sondern man landet direkt auf der FBA des RD-Gateways... Ist ja noch zu verschmerzen.

 

Allerdings funktioniert KEIN WEB-SSO wenn man das TMG als Workgroup-Member konfiguriert :cry:. WEB-SSO funktioniert nur via Kerberos-Deligierung. Ich kann aber auf dem Computerkonto des TMG dises Einstellungen nicht vornehmen, da ja KEIN Memberserver. Ergo, man muss zweimal Benutzer name und Kennwort angeben.

 

http://www.it-training-grote.de/web/download/isaserver-TMG-rdweb2.pdf

 

Und da wären dann wieder meine zwei Probleme, sicher aber nicht schön.

 

Gruß Data