TS-Gateway in der DMZ

[Data1701 10]

Moin,

 

hat schon mal jemand ein TS-Gateway in die DMZ gestellt (Ohne ISA mit Cisco) Frontend und Backendfirewall ??

 

Leider muss das TS-Gateway ja für die RAPs und CAPs mit der Domäne sprechen, außer ich würde lokale Anmeldung konfigurieren, will ich aber nicht.

 

Ich habe was zu dem Thema gefunden, würde aber gerne Eure Erfahrungen hören.

 

TS Gateway Server in DMZ: which tcp ports to open in Firewall : Terminal Services : Windows Server : Microsoft TechNet Forums

 

Also kann sich jemand mitteilen ? Bitte nicht nach dem Motto ich habe einfach alle Ports geöffnet.

 

Die von MS haben zwar in Ihrem Whitepaper schöne Bilder wie das aussehen kann, jedoch geht vom Gateway einfach so ein Pfeil an der Firewall vorbei zu einem AD-Controller. Infos dazu im WP = Null.

 

Könnte Ihr ja selbst mal anschauen:

 

Download details: Windows Server 2008 Step-by-Step Guides

 

Gruß Data

[Data1701 10]

Wollte das Thema nur noch mal am Wochenende nach oben spülen.

 

Gruß Data

[LukasB 10]

Auf die schnelle hab ich z.B. das hier gefunden:

 

Configuring an Intranet Firewall

 

Dort ist aufgelistet welche Ports for AD-Kommunikation benötigt werden. Was mir da aber auf den ersten Blick fehlt ist Port 445 for Direct SMB für die Gruppenrichtlinien.

[Data1701 10]

Merci,

 

GP brauche ich nicht unbedingt. Its eine abgeschottete Domäne. Ich werde jetzt mal einen Schwung Firewallrichtlienen setzen und dann mal die Hitcounter anschauen. Evtl. kann man dann ein paar Ports wieder zu machen.

 

Ich verstehe nicht warum MS sich dazu so in Schweigen hüllt.

 

Gruß Data

[Data1701 10]

Ich wollte das Thema noch einmal reaktieren. Mittlerweile gibt es ein wirklich gutes How-To, was allerdings die Tatsache nicht verbessert, dass ich einen Memberserver in die DMZ stellen muss.

 

http://blogs.msdn.com/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx

 

Gruß Data

[StefanWe 14]

du könntest auch einen RODC in die DMZ stellen, das hätte wenigstens den vorteil, das aufs AD 1. nur gelesen werden darf und 2. nur die Benutzer auf dem RODC gespeichert sind, die sich per Terminalserver anmelden.

[LukasB 10]

du könntest auch einen RODC in die DMZ stellen, das hätte wenigstens den vorteil, das aufs AD 1. nur gelesen werden darf und 2. nur die Benutzer auf dem RODC gespeichert sind, die sich per Terminalserver anmelden.

 

Zweiteres stimmt nicht ganz - User sind alle auf dem RODC. Nur die Passwörter sind nicht zwingend dort.

[Stephan Betken 43]

du könntest auch einen RODC in die DMZ stellen, das hätte wenigstens den vorteil, das aufs AD 1. nur gelesen werden darf und 2. nur die Benutzer auf dem RODC gespeichert sind, die sich per Terminalserver anmelden.

Hm, na vielleicht ist diese Möglichkeit deshalb auch auf der verlinkten Seite als mögliche Lösung aufgeführt.

[Data1701 10]

du könntest auch einen RODC in die DMZ stellen, das hätte wenigstens den vorteil, das aufs AD 1. nur gelesen werden darf und 2. nur die Benutzer auf dem RODC gespeichert sind, die sich per Terminalserver anmelden.

 

Das verbessert die Situation auch nicht. Die Daten des AD müssen ja auch auf den RODC kommen, welchen ja auch in der DMZ steht. Davon abgesehen befinden sich auf einem Memberserver gar keine AD-Daten.

 

Ich verstehe diese ganze Implementierung nicht so ganz. Bei Exchange wurde dazugelernt, da war anfänglich der Front-End Server auch zwingend Domänenmitglied. Seit EDGE-Server ist das nicht mehr nötig.

 

Gruß Data

[LukasB 10]

Ich verstehe diese ganze Implementierung nicht so ganz. Bei Exchange wurde dazugelernt, da war anfänglich der Front-End Server auch zwingend Domänenmitglied. Seit EDGE-Server ist das nicht mehr nötig.

 

Ja, aber für OWA etc. sollte man auch einen ISA benutzen um das ganze zu publishen.

 

Du kannst den RDGW auch ins LAN stellen und via ISA publishen - Problem solved :)

[Data1701 10]

Ja, aber für OWA etc. sollte man auch einen ISA benutzen um das ganze zu publishen.

 

Nur mit dem Unterschied das ISA für OWA den Port 443 fowarded, dass kan ich mit jeder vernüftigen Hardwarefirewall auch.

 

Ist dir bewusst wieviel Ports ein Memberserver so geöffnet haben möchte, so dass er sich mit seiner AD unterhalten kann ? Etliche, siehe mein LINK weiter oben. Also eigentlich völlig unaktzeptabel. Wenn etwas schon Gateway heißt und in die DMZ gestellt werden soll, dann bitte in einer Art bei der mir nicht die Haare ausfallen :rolleyes:.

 

Gruß Data

[LukasB 10]

Nur mit dem Unterschied das ISA für OWA den Port 443 fowarded, dass kan ich mit jeder vernüftigen Hardwarefirewall auch.

 

Dann stell den RDGW ins LAN und Forwarde Port 443 und reg dich nicht auf :)

[nerd 28]

Hi,

 

das Thema steht noch bei mir auf der Testliste - daher mal nur eine Idee, ohne fundiertes Wissen zu dem Thema...

 

Ich hätte jetzt bei einem Aufbau mit einer zweistuffigen Firewall einen Radius Server in der DMZ erwartet - würde das die Sache nicht einfacher machen?

[Stephan Betken 43]

Nur mit dem Unterschied das ISA für OWA den Port 443 fowarded...

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

[Data1701 10]

Dann stell den RDGW ins LAN und Forwarde Port 443 und reg dich nicht auf

 

Dann kann ich Port 80 von meinem Internetantritt forwarden oder den Port 25 für SMTP forwarden....

 

Entschuldingung, aber wofür habe ich den ein zweistufiges Firewallkonzept ?! Wofür gibt es Honeypots ? Ne, sorry, da kommt MS nicht drum herum, sich für diese Implementierung maximal ein ausreichend abzuholen.

 

Ich hätte jetzt bei einem Aufbau mit einer zweistuffigen Firewall einen Radius Server in der DMZ erwartet - würde das die Sache nicht einfacher machen?

 

Bringt nichts, da Du keine Radius-Requests seitens deines TS-GW hinbekommst. Das TS-GW frag über die TS-RAP und TS-CAP immer die AD ab und keinen Radius-Server, außnahme Du baust lokale TS-RAPS und CAPS.

 

Der Memberserver (TS-GW) selbst will natürlich auch noch ein bisschen quatschen und seiner AD mitteilen, dass er auch noch existent ist, sonst stirbt ja irgendwann sein Computerkonto.

 

Daher Domainmember in der DMZ = Immer ganz schlecht !!

 

Gruß Data