j.c.v. 10 Geschrieben 10. April 2008 Melden Teilen Geschrieben 10. April 2008 Hallo zusammen, ich habe ein kleines Problem mit der Veröffentlichung einer Website mit dem ISA-Server. Ausgangssituation: Internes Netzwerk mit einem IIS-Server (6.0), Internetzugang über einen ISA-Server (2006), der über ein eigenes Interface zu einer H/W-Firewall routet. Internes Netzwerk 172.16.X.X, externe IP dynamisch, "meinefirma.dyndns.org". Nun möchte ich den Server "server.meinefirma.dyndns.org" veröffentlichen, und nach Möglichkeit den Zugang auch nach ADS-Benutzern filtern. Eins vorweg: Die "manuelle" Freigabe auf Port 80 mit IP des Servers funktioniert (via "Freigabe eines nicht-Web Servers" im ISA, mit manueller Angabe von Port 80), der Server ist also dann extern erreichbar. Die "Rahmenbedingungen" stimmen also. Nun möchte ich aber den Server mit dem Assistenten für Websites benutzen, u.a. um eine Benutzerauthentifizierung gegen die ADS durchzuführen. Ich habe den Assistenten nunmehr mindestens 20x getestet, ich habe aber nicht einmal eine externe Erreichbarkeit möglich machen können (auch nicht mit Herabsetzung aller Sicherheitsfunktionen). Konkretes Szenario: Interner Server "server.meinefirma.local" soll via "meinefirma.dyndns.org" erreichbar sein, aber (vorzugsweise) nur für Benutzer der Gruppe "XXX" innerhalb der ADS "meinefirma.local". Selbst wenn ich alle Autehntifizierung im Assistenten weg lasse, funktioniert es nicht, die Protokollierung liefert ein "Verweigert" entsprechend der Standardregel (externe IP -> localhost des ISAs), wie gesagt, manuell funktioniert es, nur ohne die Möglichkeit der Benutzerauthentifizierung. Mein Ziel ist es also, den Server "server.meinefirma.local" als "meinefirma.dyndns.org" auf Port 80 zu veröffentlichen, wobei zuvor Benutzerdaten (aus einer Gruppe "XXX" der ADS der internen Domämne) abgefragt werden. Leider habe ich es bisher nicht einmal geschafft, dies mit dem Assistenten OHNE Authentifizierung zu realisieren, manuell (s.o.) aber sehr wohl. Ich hoffe auf eure Tipps und bedanke mich im Vorraus. Schöne Grüße, Jan Zitieren Link zu diesem Kommentar
twiki 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Hallo, die "alte" Regel hast Du aber gelöscht,oder? Wir hatten das Problem das sich ein anderes Programm (in dem Fall der IIS -> Standardwebsite) sich zusätzlich auf Port 80 gebunden hat und dadurch keine weiter Regel mehr funktioniert hat! Gruss twiki Zitieren Link zu diesem Kommentar
j.c.v. 10 Geschrieben 11. April 2008 Autor Melden Teilen Geschrieben 11. April 2008 Hmmm, welche "alte" Regel? Ich habe in der Firewallrichtlinie keine andere eingehende http-Regel. Eine extra Netzwerkregel muss ich doch nicht erstellen, oder? Wie gesagt, folgender Weg geht: Neue Firewallregel ->Nicht-Webserver-Protokolle veröffentlichen ->Server-IP eingeben ->Neues Protokoll (z.B. "Test"), Port80, TCP, eingehend ->Fertig. Dann ist der Server veröffentlicht. Aber ich möchte ja nun den Assistenten benutzen, damit ich auch mit der Authentifizierung arbeiten kann. Hier aber nach wie vor kein Erfolg. Eine Regel mit dem Assistenten wird quasi gar nicht berücksichtigt. In der Protokollierung wird der Zugriff immer nach Standardregel (s.o.) verweigert... Hat noch jemand eine Idee? Das muss doch gehen... Schöne Grüße, Jan Zitieren Link zu diesem Kommentar
twiki 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Hallo, unter Toolbox -> Netzwerkobjekte -> Weblistener würde ich einen Neuen Listener anlegen, da der bei dem Assistenten eh abgefragt wird. Damit sollte das eigentlich funktionieren. Zumindest funktioniert es bei uns :confused: Gruss twiki Zitieren Link zu diesem Kommentar
j.c.v. 10 Geschrieben 11. April 2008 Autor Melden Teilen Geschrieben 11. April 2008 Ja, hab ich auch schon x-mal gemacht, aber auch in der einfachsten Konfiguration (HTTP ohne SSL, keine Authentifizierung, etc.) gehts leider nicht. Die Regel wird einfach immer übergangen (bzw. ist demnach lt. ISA nicht zutreffend)... Grüsse, Jan Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Was ist der Sinn dahinter? Sollen die User von innen und außen über den gleichen Namen auf die Site zugreifen können?` Nebenbei bemerkt: Für den Zugriff von außen solltest Du ohnehin imho über SSL nachdenken; da ja der Zugriff beschränkt werden soll, müssen die User sich authentifizieren und diese Daten sollten tunlichst nicht im Klartext durchs Internet übertragen werden. Christoph Zitieren Link zu diesem Kommentar
twiki 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Hallo, hast Du das ganze mal mit einem anderen Port versucht (zu Testzwecken)? Gruss twiki Zitieren Link zu diesem Kommentar
j.c.v. 10 Geschrieben 11. April 2008 Autor Melden Teilen Geschrieben 11. April 2008 Hallo Christoph, ja - es wird irgendwann auch auf SSL hinauslaufen, im Moment möchte ich es aber erstmal grundsätzlich zum laufen kriegen. Zum Sinn: Der Webserver wird zu 95% intern genutzt, einige Benutzer sollen aber selten auch einmal von außen zugreifen. Deshalb auch nur die recht halbherzige Lösung mit dyndns etc. Ich brauche also eine ganz einfache Veröffentlichung (wie sie manuell ja auch geht, s.o.) MIT Benutzerauthentifizierung gegen die ADS. Für letzteres brauche ich den Assistenten, aber was ich da auch mache, es will einfach nicht laufen - die Regel greift nie. Nochmal zum Fehler in der Protokollierung: Da steht VERWEIGERT aufgrund STANDARDREGEL, von <EXTERNE IP> (die ist übrigens richtig) nach LOKALER HOST. Letzteres finde ich etwas seltsam, wenn ich den Webserver manuell freigebe steht da ZUGELASSEN von <EXTERNE IP> nach <IP DES WEBSERVERS>. Ich hoffe es hat noch jemand einen Tipp für mich, wie ich das zum Laufen kriege - irgendwo hab ich da noch nen Wurm drin... Danke und schöne Grüße, Jan Zitieren Link zu diesem Kommentar
j.c.v. 10 Geschrieben 11. April 2008 Autor Melden Teilen Geschrieben 11. April 2008 @twiki: nein, habe ich nicht. Ist ja relativ aufwendig (Firewall, ISA und IIS umstellen) und mit der manuellen Freigabe auf Port 80 (s.o.) gehts ja. Es sei denn, es gibt da ein Problem mit dem Listener (der bei manuell ja nicht genutzt wird)... ?!? :suspect: Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Poste doch hier mal, Step by Step, welche Angaben du im Assistenten für die Web-Veröffentlichung gemacht hast und wie der HTTP-Listener konfiguriert ist. Am besten machst Du auch noch Angaben, wie der Webserver konfiguriert ist. So schwer kann das eigentlich nicht sein mit dem Assistenten. Damit der Server auch von innen erreichbar ist, könntest Du Split-DNS einsetzen (also intern auch eine Zone deinefirma.dyndns.org konfigurieren und da einen A Record mit der IP deines Servers erstellen). Diese IP sollte direkt, also nicht über Proxy, ansprechbar sein. der bei manuell ja nicht genutzt wird Du meinst, für Server-Veröffentlichungs-Regeln? Korrekt, da wird kein Listener genutzt, sondern nur bei Web-Veröffentlichungsregeln (einschließlich Sharepoint und Exchange Publishing-Regeln, die ja letztendlich auch nur aufgebohrte Assistenten für Web-Publishing sind). Christoph Zitieren Link zu diesem Kommentar
j.c.v. 10 Geschrieben 11. April 2008 Autor Melden Teilen Geschrieben 11. April 2008 Hallo Zusammen, ich habe den Fehler gefunden.... Auf dem ISA läuft noch ein WSUS auf Port 80... (Wie dumm - mein Fehler :( ) Bei der Serververöffentlichung ist das wohl egal, dann wird die Anfrage wohl vor dem WSUS "weggeschnappt" und weitergeleitet. (Daher bin ich erst gar nicht auf die Idee gekommen, das da was stört) Nur der Listener kann dann natürlich nicht an port 80 binden.... Ich frage mich nun, was ich da mache.... Den Wsus auf einen anderen Port legen will ich nicht so gerne, da das an sich so ganz gut läuft. Kann man sich das nicht vielleicht noch anders zusammenbasteln? Erste Idee: Von der FW Port80 auf Port XXXX am ISA weiterleiten. Den Listener auf XXXX und die Regel geht dann wieder auf 80 des Webservers.... Könnte das wohl klappen oder irgendwelche anderen Ideen? Aber ersteinmal vielen Dank! Schöne Grüße, Jan Zitieren Link zu diesem Kommentar
twiki 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Hallo, meine Rede! :D Deine Idee sollte funktionieren (daher war meine Frage ob man zu Testzwecken einen anderen Port nehmen kann). Gruss twiki Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Aha, gut dass Du das mal erwähnst ;) Andere Dienste auf dem ISA sind grundsätzlich keine gute Idee... Ihr solltet eher überlegen, den WSUS auf einen anderen Server zu migrieren. Christoph Zitieren Link zu diesem Kommentar
j.c.v. 10 Geschrieben 11. April 2008 Autor Melden Teilen Geschrieben 11. April 2008 Sooo, ja - es läuft jetzt erstmal so im Groben. Dann werd ich mich jetzt mal dran setzen, dass etwas sicherer zu machen ;) . Ich danke euch erst mal recht herzlich für eure Hilfe! Jan @Christoph: Ich weiß, dass das nicht so optimal ist. Bei der Einrichtung habe ich auch schon Bedenken geäußert, aufgrund von x Gründen musste das dann aber so sein. Das WSUS ist aber auch das einzige, was da noch drauf läuft. Außerdem steht der ISA ja nicht direkt "an der Front" sondern hinter einem Security Gateway... Im ganzen nicht schön - muss ich im Moment aber mit leben... Aber mal ne andere Frage dazu: Kann man einen WSUS "schnell und einfach" migrieren, ohne alles neu Aufzusetzen? Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 11. April 2008 Melden Teilen Geschrieben 11. April 2008 Ist das eine Migration von WSUS 3 nach WSUS 3 auf einem anderen Server? Oder von WSUS 2 nach WSUS 3? Links: Microsoft Corporation Moving a WSUS server « Something witty, part deux Christoph Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.