Jump to content

Web Listener ISA 2004 http Veröffentlichungsproblem


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

Empfohlene Beiträge

Hallo,

seit kurzem betreibe ich produktiv einen ISA 2004. Auf diesem sind jetzt alle Protokolle und Regeln eingerichtet. Es läuft z. B. OWA mit https vom feinsten, Terminalserver, VPN etc.

 

Nun will ich von unserem Entwicklungsserver für unsere Kunden die Layout Vorschläge freigeben. Also eine ganz einfache http Webfreigabe.

 

Wir verfügen über einen dynamischen DNS-Eintrag und ich habe am DNS eine Zone mit der DynDNS eingerichtet und einen Host der später veröffentlicht werden soll. Also so:

DNS-Zone: dyndns.org

Dann einen Host dazu: devserver

IP: 192.168.1.3

Somit ergibt sich dann der Host: devserver.dyndns.org mit der IP 192.168.1.3

Auf diesem Server befindet sich im IIS ein Verzeichnis mit dem Namen /hardwareattack.

Der Server sollte dann so zu erreichen sein: http://devserver.dyndns.org/hardwareattack.

 

Nun kriege ich aber beim ISA 2004 ein Problem heraus wenn ich eine Webveröffentlichung einrichte. Ich habe bereits für OWA einen Web Listener eingerichtet mit Port 80 und 443 und OWA FormBased Authentication. Wenn ich jetzt einen neuen Web Listener nur für Port 80 gestalte bekomme ich eine Fehlermeldung die besagt, es gibt bereits eine Weblistener und es dürfen keine Überlappungen auftreten.

 

Nun die Frage:

Wie soll das funktionieren mit einem Weblistener. Vorher, also im ISA 2000, gabs ja auch nur einen Weblistener. Dort konnte man ja nur einen anlegen. Jetzt kann ich mehrere anlegen, aber bringt auch wieder nix, wenn ich Überlappungsfehler bekomme.

 

Ich will einfach nur eine stinknormale HTTP Site freigeben. Wieso sollte dann der OWA Listener hinhorchen. Ich benötige kein SSL und keine OWA FormBased Authentication.

 

Vielleicht kann mir hier jemand helfen?

 

Grüsse

Mullfreak

Link zu diesem Kommentar

Hi,

der Artikel bezieht sich auf ISA 2000. Ich benutze seit ca. 4 Wochen ISA 2004. Die Veröffentlichung im 2000er is klar. Da gabs ja nur einen Weblistener für alle Anfragen. Dies ist eben beim ISA 2004 nicht mehr so.

 

Ich hab das Problem gelöst, jedoch noch nicht zu meiner Zufriedenheit. Ich habe einen neuen Weblistener erstellt, der jetzt auf Port 81 lauscht.

 

Somit habe ich den OWA auf Port 80 und die neue Seite auf Port 81.

 

Dies ist deshalb nicht zufriedenstellend, da ich jetzt für jede weitere zu veröffentliche Site einen neuen Port benötige. Ich will das der ISA alle Anfragen auf Port 80 ablauscht und sie dann nach den Hostheadern an die entsprechenden dahinterstehenden Webserver verteilt.

 

Das muss doch auch mit 2004 möglich sein.

 

Grüsse

Mullfreak

Link zu diesem Kommentar

Hi,

die Website laufen auf unterschiedlichen Webserver. OWA z. B. kommt vom DC und unsere Kundenseiten stammen von unserem Entwicklungsserver.

 

Leider bin ich überhaupt kein Freund von Hostheadern. Auf unserem Entwicklungsserver gibts über 100 verschiedene Seiten die alle verschieden aufgelöst werden. Da würde mit der Zeit ein ordentliches Chaos entstehen.

 

Ich bleibe jetzt vorerst bei einer Portänderung und werde das Problem näher betrachten. Vielleicht weiß hier Herr Dr. Rauscher oder Dr. Shinder mehr drüber in den Foren.

 

Grüsse

Mullfreak

Link zu diesem Kommentar
  • 4 Wochen später...

Hallo Mullfreak,

 

schau mal hier unter Punkt 2.2:

http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/OWA_FBA.htm

 

Das dürfte Dein Problem lösen.

 

Habe eine Frage an dich. Mit welchem Template hast Du Dein ISA konfig.? Ich krieg nämlich OWA nicht zum laufen, weder mit http noch mit https (mein Problem siehe http://www.mcseboard.de/showthread.php?t=55712&highlight=isa+2004+owa)

 

grüße

maho

Link zu diesem Kommentar

Hi maho,

 

zu Deinem Tutorial Vorschlag:

 

Das mit Port 443 ist klar. OWA sollte, wenn überhaupt, nur mit 443 laufen. Dann bleibt Port 80 offen. Wenn Du jetzt aber eine Site auf Port 80 veröffentlichen willst, dann brauchst Du einen neuen WebListener. Hast Du aber mehrere Seiten, die veröffentlicht werden sollen, so müsstest Du für jede Site einen neuen WebListener bauen. Das geht aber nicht weil wenn man dann wieder Port 80 wählt, kommt eine Fehlermeldung, die auf eine Überlappung hinweist. Wenn man dann statt 80 Port 81 wählt, funktionierts wieder.

 

Werde es noch weiter testen.

 

Zu Template:

 

Was meinst Du damit. Im Moment benutze ich die FormBasedAuthentication am ISA. Diese funzt astrein und ich habe keine Probleme damit. Geht Dein OWA intern bereits? Stimmt Dein Zertifikat für SSL am Webserver?

 

Schreib nochmal durch. Ich glaube wir können das Problem lösen. Ich kann Dir ja meine Einstellungen sagen, die bei mir laufen.

 

Grüsse

Mullfreak

Link zu diesem Kommentar

Hi Mullfreak,

 

bei der Installation kannst Du zwischen verschiedenen Methoden, Netzwerk-Templates wählen, je nachdem, wie Du Deinen ISA einsetzen willst. z.B gibt es das Template "Edge Firewall" (das ich gewählt habe). Die Templates siehst Du, wenn Du auf Netzwerk klickst und rechts auf Templates.

 

Wo hast Du Deinen ISA platziert? Hat er ein Fuß direkt im Internet und einen in der DMZ? Oder hat Dein ISA nur eine Netzwerkkarte?

Unseren ISA habe ich mit einer Netzwerkkarte und als "Edge Firewall" konfiguriert. Das Template "Single Network Adapter" unterstütz anscheinend kein Firewall Client.

 

Ich habe jetzt zunächst mal SSL weggelassen und nur HTTP konfiguriert, weil das halt doch einfacher ist, als mit den Zertifikaten. Ich möchte zunächst mal einen einfachen Webzugriff aus dem Internet auf den Exchange-Server weiterleiten.

Denn im Moment krieg ich nicht mal das hin... Und wenn das funktioniert, gehe ich als nächstes SSL an.

Hast Du eine Idee? Zunächst würde mich interessieren, ob Du Dein ISA auch nur mit einer Netzwerkarte laufen hast oder ob irgendjemand einen ISA 2004 mit einer Netzwerkkarte und OWA am Laufen hat. ich befürchte, dass es vielleicht mit dieser Netzwerktopologie, wie wir aufgebaut haben, das gar nicht funktioniert.

 

Grüße, maho

Link zu diesem Kommentar

Hi maho,

 

mein ISA hat zwei Netzwerkkarten. Die externe Seite zeigt zu einem stinknormalen Billigrouter und die andere ins interne Netzwerk. So wie es auf dem 2000er war.

 

Kannst Du in Deiner Umgebung mit Deinem ISA Serververöffentlichungen vornehmen? Wenn das geht, dann kannst Du bestimmt auch bei Dir das OWA veröffentlichen.

 

Da ich den 2004er erst seit ca. 6 Wochen einsetze, habe ich die Veröffentlichungen und auch die Zertifizierungen der Server ziemlich an den 2000er angelegt. Im Grunde ist es nicht anderes außer das ich jetzt im 2004 mehrere Weblistener konfigurieren kann, deshalb auch mein oben genanntes Problem.

 

Wie gestaltest Du Deine Veröffentlichung? Besitzt Du eine öffentliche IP oder willst Du es per DynDNS machen? Hast Du vor dem ISA einen Router oder stellst Du eine DialUP am ISA her (vielleicht bei ISDN)? Wenn es eine Produktivumgebung ist, würde ich auf keinen Fall, auch für Testzwecke, Port 80 auf OWA NIE freigeben. OWA an sich ist ja schon die größte Sicherheitslücke in Bezug auf Userverhalten und z. B. Internetcafes. Du mußt ja noch nix freigeben, ich teste immer vorher den Zugriff aus dem internen Netzwerk mit http und https Aufrufen. Wenn das funktioniert ist die Veröffentlichung weniger das Problem. Bei DynDNS baue ich mir eine weitere Active Directory integrierte DNS-Zone die wie die DynDNS-Adresse lautet, z. b. yourdaim.dyndns.org. Somit kann ich dort eigene Hosts anlegen für die jeweiligen Serverzugriffe, für OWA z. B. dann owa.yourdomain.dyndns.org.

oder term.yourdomain.dyndns.org. Bei Zertifikaten spielt das sowieso keine Rolle. Fehlermeldungen bei der Zertifikatsabfrage ist bei DynDNS Standard. Das kann nicht geändert werden. Somit würde ich auf ein öffentliches Zertifikat für den Webserver von einer öffentlichen Zertifizierungsstelle nehmen --> Kosten ca. jährl. 100,-- Euro.

Das ist natürlich die feine Lösung.

 

Warum überhaupt OWA. Ich habe einen zusätzlichen Terminalserver mit Outlook Anwendung. Volle Funktion von Outlook 2003. Viel besser als OWA. Das ganze noch über VPN mit PPTP (einfach zu bauen am ISA) und sicher ist das.

 

Also, schildere nochmal genau Deine Umgebung und dann bauen wirs schnell zusammen.

 

Grüsse

Mullfreak

Link zu diesem Kommentar

Hi Mullfreak,

 

der ISA ist noch nicht produktiv. Die Umgebung sieht so aus: Ich habe eine Firewall mit 3 Beinen. Inside, Outside und DMZ. In der DMZ steht die ISA mit eine Netzwerkkarte. Die Firewall setzt die private Adresse des ISA um in eine öffentliche im Outside.

Ich kann den ISA über das Internet auch erreichen. Nur leitet er meine Webanfragen nicht weiter.

 

Eine VPN-Lösung haben wir schon, User greifen über VPN-Client auf ihre Postfächer zu. Nun sollen die USer auch z.B. aus dem Internetcafe ihre Mails lesen können.

Dazu plane ich letztendlich die Autorisierung am RSA mit SecureID-Card und zusätzlich SSL-Verschlüsselung. So ist das dann, denke ich, ein sicherer Zugang.

 

Aber zunächst mal muss ich den ersten Schritt, die Publishing-Konfig. hinkriegen.

Ich danke Dir für Deine Mithilfe!

 

Die relevanten Einstellungen sehen so aus:

Regel1

- Erlaube von extern Zugriff pber Port HTTP, HTTPS auf local (auf ISA)

-->Zugriff aus dem Internet auf den ISA über die Ports 80, 443 somit möglich

Regel2 (Webpublishing)

- Erlaube HTTP, HTTPS von Überall zu IP-Adresse des Exchange-Server´s im Inside, Weblistener "Web 80"

Weblistener "Web 80":

- Zugriff von "extern" Port 80 und 443 (habe auch schon Zugriff von überall probiert)

 

 

Grüße

maho

Link zu diesem Kommentar

Hi maho,

 

danke für Deine Ausführungen.

 

Eine Firewall mit drei Beinen und in der DMZ den ISA. Der ISA muss Deine Firewall sein. Ansonsten ist TriHomed schon ok. Was ist das für eine Firewall die vor!!! dem ISA steht?

 

- Erlaube von extern Zugriff pber Port HTTP, HTTPS auf local (auf ISA)

-->Zugriff aus dem Internet auf den ISA über die Ports 80, 443 somit möglic

----> ist klar.

 

- Erlaube HTTP, HTTPS von Überall zu IP-Adresse des Exchange-Server´s im Inside, Weblistener "Web 80"

Weblistener "Web 80"

---->verstehe ich nicht. Ist doch das gleiche wie oben. Was bedeutet "von Überall". Wo ist Überall. Wahrscheinlich meinst Du vom internen Netzwerk aus. Wenn alles richtig konfiguriert ist, sprich DNS-Server, ist es egal ob die Adresse intern oder extern aufgerufen wird, sie funktioniert immer. Deshalb gestalte ich bei einer DynDNS-Auflösung eine neue Active Directory integrierte Zone mit dem entsprechenden Namen der DynDNS-Adresse.

 

Schreib nochmal durch wie genau Dein Netzwerk aufgebaut ist. Hast Du eine feste öffentliche IP Adresse --> wichtig!

 

Grüsse

Mullfreak

Link zu diesem Kommentar

Also, jetzt bin ein Schritt weiter!!! Habe eine neue Publishing erstellt (diesmal SSL). Jetzt sehe ich in der Firewall, dass der ISA auf den Exchange-Server im Inside mit Port 443 zugreift. Allerdings wird die initiierte Session gleich wieder vom Exchange-Server "gekillt".

 

Ich vermute, dass mit den Zertifikaten etwas nicht stimmt... Ich bin exakt nach dieser Anleitung vorgegangen:

http://www.isaserver.org./tutorials/2004owafba.html

 

Allerdings kam danach der Kollege nicht mehr in die Eigenschaften der Objekte (z.B. öffentl. Ordner) im Exchange-Management. Folgende Fehlermeldung erscheint:

"the ssl certificate server name is incorrect"

 

Eigentlich brauche ich doch SSL nur zwischen dem Cleint im bösen Internet und dem ISA? Wozu noch zwischen dem ISA und Exchange?

 

Zu unserer Struktur:

Ich habe eine PIX Firewall im Einsatz. Im Inside sind die Workstations, DMZ hat der ISA seinen Platz, Outside ist Internet (habe eine ganze Range an öffentl. IP´s zur Verfügung).

Die Firewall macht also den ISA mit einer festen öffentl. IP im Internet sichbar und gibt das Port 443 zum ISA frei.

--------------------------------------

Juhuuu :) :) :) . Habe gerade eine Regel erstellt, der SSL nur zwischen dem Client im Web und dem ISA macht und schon funktioniert´s :rolleyes:

Im Firewall-Log kann ich sehen, dass der ISA auf den Exchange-Server mit Port 80 zugreift.

 

So, jetzt interessiert mich Deine Meinung. Kann ich das ganze so lassen?

Ich habe kein "sicheres" Zertifikat im Einsatz (Verisign & Co). Ist der Zugang jetzt dadurch unsicherer? Wenn ja, warum? Ich vermute, das ist genauso sicher, nur ist es nicht schön, weil man jedes mal die Abfrage erhält.

 

Grüße, maho

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...