ISA bridging

[engel.aloisius 10]

hallo zusammen,

ich hoffe, dass ich trotz früher stunde am aschemittwoch hier eine lösung

fürmein problem finde ... folgende ausgangslage:

 

ich habe einen ISA 2004 SP2 als edge-firewall am laufen, der einerseits mein

intranet- und testwebserver veröffentlicht und andererseits das

entwicklerbüro mit internetzugang versorgt. ich wollte jetzt das intranet

über bridging veröffentlichen, damit ich nach außen SSL-verschlüsselt

arbeiten kann, intern den traffic aber unverschlüsselt weiterfahren kann. ich

scheitere aber beim aufsetzen der bridging-rule - bridging funktioniert weder

in sicher-sicher- noch in sicher-unsicher-konfiguration. ich hab eine sichere

verbindung nur mit einem SSL-tunnel durch den ISA direkt auf den webserver

hingebracht - und das is definitiv nicht das was ich will.

 

* DNS und IP-Konfiguration sind in ordnung und funktionieren.

* ich habe am ISA über die MMC/Zertifikate/ISA-computer das zertifikat des

webservers samt privatem schlüssel installiert, es scheint auch in der

ISA-verwaltung auf.

* die einstellungen zur verifizierung der SSL-Zertifikate (certifikate

revokation) sind korrekt (client certificates not revoked ist ein, server

certificates in a forward szenario ist ein, im backward-szenatio aus)

* das importierte server-zertifikat ist ein eigenes zertifikat

 

irgendwie scheints, dass ich mich wo verirrt habe - nur wo? und was hab ich

übersehen? kann mit jemand einen tipp geben? es sollte ja damit getan sein,

dass ich eine webserver-publishing-rule erstelle und die dann online schalte,

oder?

[Christoph35 10]

Kannst Du mal genauer beschreiben, wo es hakt und was nicht funktioniert?

 

Wie hast Du die Publishing Rule definiert, wie den Listener?

 

Christoph

[engel.aloisius 10]

ganz original funktioniert keine einzige variante des bridgings. weder https2https noch https2http. die clients bekommen immer einen dns-fehler bzw. nicht erreichbar: "Fehler: Server oder DNS kann nicht gefunden werden".

 

listener: ich hab schon probiert, den listener auf 80 und 443 horchen zu lassen, oder nur auf 80 oder nur 443; ändert nix, die verbindung kommt trotzdem nicht zustande. aktuell horcht er nur auf 80 UND 443, wobei ich die auf 80 ankommenden auf SSL verbiege und die korrekte fehlermeldung "Error Code: 403 Forbidden. The page must be viewed over a secure channel (Secure Sockets Layer (SSL)). Contact the server administrator. (12211)" erhalte. aber über SSL kommt gleich der fehler (s.o.)

 

rule: ich hab erst mal versucht, die mit den standardwerten zu fahren, schon das ist misslungen ...

allow from anywhere to interne_IP über HTTP/HTTPS traffic mit umbiegung zu HTTPS. der public name ist korrekt DNSiert der path auch. in bridging will ich alles weiter auf port 80 und das für alle user

 

ach ja, vom isa zum webserver funktioniert die verbindung auf 80.

 

damit bleibt mein problem, dass der ISA nach der annahme ein problem hat, den request richtig zu verarbeiten ...

 

hat wer ne idee?

[Christoph35 10]

Hi,

 

ich habe das grad mal getestet.

 

Folgendermaßen habe ich es hinbekommen:

 

1. SSL (Webserver) Zertifikat vom Webserver aus beantragen, auf dem Webserver zunächst mal installieren (in den Computer Zertifikatsspeicher).

Beim Beantragen darauf achten, dass du angibst, dass das Zertifikat in den Computerspeicher kommen soll, und dass es exportierbar ist!

 

2. Zertifikat exportieren und auf dem ISA Server importieren, wieder im Computer-Zert.-Speicher ablegen.

 

3. Zertifikat auf dem Webserver löschen.

 

4. Secure Web Publishing Regel erstellen. Für den Public Name den gleichen Namen eingeben, den du beim Beantragen des Zerts. gewählt hast. SSL-to-HTTP Bridging auswählen.

 

5. Web Listener erstellen, HTTP löschen, SSL auswählen. Das importierte Zertifikat auswählen.

 

6. Ggf. musst Du mit Link-Translation arbeiten.

 

7. DNS muss korrekt konfiguriert sein, d.h. der A record für die Website muß auf das externe Interface des ISA verweisen (split DNS, falls nötig).

 

So, ich hoffe, ich habe nichts vergessen, sonst melde ich mich nochmal.

 

Info zum Thema gibts auch unter http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/digitalcertificates.mspx

 

/edit:

 

Eine Anmerkung sei mir noch erlaubt:

 

SSL to HTTP Bridging wird im allgemeinen nicht verwendet, da Anwender i.d.R. Wert auf End-to-End Verschlüsselung legen, die bei SSL to HTTP Bridging nicht gegeben ist.

 

Christoph

[engel.aloisius 10]

hallo christoph,

danke erstmal für die ausführliche anleitung - aber ich krieg das ding nicht gebacken ... mittlerweile läuft das teil, wenn ich von http2http bridge, aber von https2https bleibt er wieder stecken

Technical Information (for support personnel)

* Error Code: 500 Internal Server Error. Das Token, das der Funktion übergeben wurde, ist ungültig. (-2146893048)

keine ahnung, was da nicht stimmt ... :shock:

[Christoph35 10]

Jetzt ist doch von HTTPS nach HTTPS die Rede?

 

In dem Fall lässt Du Schritt 3 aus, und behältst das Zertifikat auf dem Webserver.

 

Ausserdem braucht der ISA-Server ein Userzertifikat, mit dem er sich gegenüber dem Webserver authentifizieren kann.

 

Müsste aber auch in dem von mir bereits verlinkten Artikel zu finden sein.

 

Wenn Du mal gute Literatur brauchst zum ISA 2004 und dich Englisch nicht schreckt, empfehle ich Dir die ISA 2004 Bibel von Tom Shinder. Da steht das sehr gut drin erklärt:

 

http://www.amazon.de/exec/obidos/ASIN/1931836191/qid=1141253398/sr=1-2/ref=sr_1_10_2/302-6140652-9022408

 

Christoph

[engel.aloisius 10]

danke nochmal für die links ...

nein, es is nicht komplett umgestellt worden von https2http ... obwohls wurscht wäre ;-)

wir haben jetzt mal ein testszenario aufgebaut, um alle eventualitäten durchspielen zu können.

die geschichte läuft mal von http2http, aber sobald https2irgendwas im spiel ist, kommt der fehler "server not found / DNS error"

 

ich bin mittlerweile ziemlich ratlos :shock:

[Christoph35 10]

Ok, ich habe das Buch von Shinder grad vor mir und habe das mal im Abschnitt zum "Secure Web Server Publishing" nachgeschlagen.

 

Ich zitiere mal aus dem Werk, in englisch ...

 

Things break when the common name on the server certificate doesn´t match the name used by the client request. There are two places where things can break in the SSL-to-SSL-bridging scenario:

- If the common name on the certificate used by the ISA server firewall to impersonate the Web site doesn´t match the name (FQDN) used by the Web client on the Internet

- If the common name on the certificate on the Web site doesn´t match the name (FQDN) used by the ISA firewall service to forward the request; the name in the ISA firewall´s request to the published Web server is determined by the entry on the To tab in the Web Publishing rule

...

Warning: You will encounter the dreaded Internal Server Error 500 if there is a mismatch between the name in the request and the name on the certificate.

 

Deshalb habe ich weiter oben in Punkt 4 darauf hingewiesen, dass der Public Name gleich dem Namen sein muss, der beim Beantragen des Zertifikats für die Website verwendet wurde.

 

Also: Zertifikat für http://www.domain.com'>http://www.domain.com beantragt heisst dann, dass als Public Name für die Website ebenfalls http://www.domain.com genutzt werden muss, und dass DNS entsprechend konfiguriert ist.

 

/edit: DNS Thematik:

 

ich habe in meiner Testdomain einen Webserver testsps.ad.testdomain.local, für den ich ein Zertifikat auf den Namen "sps.testdomain.local" beantragt habe. Dieses Zertifikat habe ich exportiert und auf dem ISA importiert und für den Weblistener verwandt.

 

Weiterhin habe ich eine Secure Web Publishing Rule erstellt, in der ich sps.testdomain.local als den Namen eingetragen habe, unter dem der testsps.ad.testdomain.local veröffentlich werden soll.

 

Dann bin ich hingegangen und habe auf dem externen DNS Server (BIND) einen A-record für sps.testdomain.local erstellt, der auf die externe Adresse des ISAs verweist. E voilà, das funktioniert!

 

Das ganze war, wie oben für ein SSL to HTTP Bridging scenario, in dem Client->ISA ssl verschlüsselt ist, und isa->webserver unverschlüsselt, sowie es in Deinem 1. Posting gefordert war.

 

Christoph

[engel.aloisius 10]

Also: Zertifikat für http://www.domain.com'>http://www.domain.com beantragt heisst dann, dass als Public Name für die Website ebenfalls http://www.domain.com genutzt werden muss, und dass DNS entsprechend konfiguriert ist.

 

/edit: DNS Thematik:

 

ich habe in meiner Testdomain einen Webserver testsps.ad.testdomain.local, für den ich ein Zertifikat auf den Namen "sps.testdomain.local" beantragt habe. Dieses Zertifikat habe ich exportiert und auf dem ISA importiert und für den Weblistener verwandt.

 

Weiterhin habe ich eine Secure Web Publishing Rule erstellt, in der ich sps.testdomain.local als den Namen eingetragen habe, unter dem der testsps.ad.testdomain.local veröffentlich werden soll.

 

Dann bin ich hingegangen und habe auf dem externen DNS Server (BIND) einen A-record für sps.testdomain.local erstellt, der auf die externe Adresse des ISAs verweist. E voilà, das funktioniert!

 

 

 

hallo christoph

ich hab einen öffentlichen dns eintrag für die domain test.blabla.net eingerichtet. der a-eintrag zeigt auch auf die öffentliche IP. es kann also kein dns-problem sein, es funktioniert ja auch über http von außen.

das zertifikat ist auf den fqdn ausgestellt test.blabla.net ausgestllt und kommt von meiner internen ca. das root ca liegt ebenfalls im zerifikatsspeicher am isa. die hakerl bei der certificate revokation sind auf ja/ja/nein gesetzt, was ja auch richtig sein sollte.

in der rule, die test.blabla.net heißt, wird unter "public name" auf test.blabla.net gehorcht.

 

jetzt ein ABER: die domain ist auch in der hosts datei hinerlegt, die auf den internen server 10.1.14.6 zeigt. die IP ist auch im To-Tab eingetragen, weil der isa sonst ja im kreis läuft - er muss ja wissen wohin mit der anfrage ... TS meint aber, wenn ich es richtig gelesen habe, dass dort test.blabla.net reingehört oder? oder hab ich da nen knoten im hirn?? ganz falsch kanns ja nicht sein, weil das http-publisching ja funktioniert ... :(

[engel.aloisius 10]

Zusätze:

 

ich bin nach der anleitung von msisafaq.de vorgegangen.

SSL Bridging mit HOSTS Datei

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

 

daszenrtifikat ist auch am webserver gebunden.

 

mir is gerade im log aufgefallen, dass der https-traffic an der publishing-rule vorbeiläuft und von der "default rule" am ende abgeschmettert wird ... da liegt wahrscheinlich der hund begraben.

wie bring ich das jetzt wieder weg ... der listener horcht ja auf 80 und 443 ... ???

 

vom isa kann ich die seite über https://test.blabla.net aber aufrufen ...

[Christoph35 10]

hallo christoph

ich hab einen öffentlichen dns eintrag für die domain test.blabla.net eingerichtet. der a-eintrag zeigt auch auf die öffentliche IP. es kann also kein dns-problem sein, es funktioniert ja auch über http von außen.

das zertifikat ist auf den fqdn ausgestellt test.blabla.net ausgestllt und kommt von meiner internen ca. das root ca liegt ebenfalls im zerifikatsspeicher am isa. die hakerl bei der certificate revokation sind auf ja/ja/nein gesetzt, was ja auch richtig sein sollte.

in der rule, die test.blabla.net heißt, wird unter "public name" auf test.blabla.net gehorcht.

Soweit ist das alles korrekt.

 

jetzt ein ABER: die domain ist auch in der hosts datei hinerlegt, die auf den internen server 10.1.14.6 zeigt.

 

auch noch ok, wenn du mit "die domain" den externen Namen der Website meinst

 

die IP ist auch im To-Tab eingetragen, weil der isa sonst ja im kreis läuft ja funktioniert ... :(

 

Hier liegt der Fehler, denke ich.

 

Bei MSISAFAQ.DE steht auch nicht, dass du die IP als Ziel eingeben sollst, sondern den FQDN der öffentlich erreichbar ist, und auf den das Zertifikat ausgestellt ist.

 

Folgendes Zitat steht etwa zu Anfang der 2. Hälfte des von Dir verlinkten Artikels:

In diesem Schritt müssen Sie Angaben drarüber machen, an welchen Webserver die Anfrage weitergeleitet wird. Normal würden Sie hier den

wirklichen FQDN des Webservers eintragen, da Sie normal ein Zertifikat auf dem Webserver importiert haben, das für diesen ausgestellt ist,

ansonsten würde die SSL-Verbindung fehlschlagen. Auf dem Webserver haben Sie aber das Webserverzertifikat für shop.meinefirma.de importiert, somit müssen Sie auch diesen FQDN als Weiterleitungsserver eintragen. Durch den Eintrag in der HOSTS-Datei wird der Name in die interne IP-Adresse aufgelöst und an den internen Webserver weitergeleitet.

 

Genauso steht es auch bei Shinder.

 

Du hast in der Hosts Datei auf dem ISA ja die IP für den Web-Server eingetragen, also 10.1.14.6. Dann kannst Du als Ziel im To-Tab auch den FQDN angeben.

 

Jetzt musst Du nur noch schauen, weshalb die Regel nicht greift. Es muss alles passen: quelle: anywhere, ziel: muss der externe fqdn sein (test.blabla.net). Protokoll muss stimmen (HTTPS). User Set muss stimmen (all users). Ich geh jetzt einfach mal davon aus, weil es ja via HTTP geht, dass Netzwerkregeln etc. stimmen.

 

Christoph

[engel.aloisius 10]

Jetzt musst Du nur noch schauen, weshalb die Regel nicht greift. Es muss alles passen: quelle: anywhere, ziel: muss der externe fqdn sein (test.blabla.net). Protokoll muss stimmen (HTTPS). User Set muss stimmen (all users). Ich geh jetzt einfach mal davon aus, weil es ja via HTTP geht, dass Netzwerkregeln etc. stimmen.

 

werd mir noch mal die netzwerkregeln ansehen ... quelle, ziel, berechtigungen und protokolle sind aber (meiner meinung) ok, ich verstehe nur nicht, warum die regel den http-traffic nimmt und den https-traffic nicht ...

[Christoph35 10]

Kannst Du mal die genauen Settings der Publishing Rule hier posten? und die Einstellungen des Web-Listeners? Domains kannst Du ja abwandeln.

 

Christoph

[engel.aloisius 10]

Kannst Du mal die genauen Settings der Publishing Rule hier posten? und die Einstellungen des Web-Listeners? Domains kannst Du ja abwandeln.

Christoph

 

 

also die rule:

general: heißt wie das web test.blabla.net und is enabled

action: allow

from: anywhere

to: server "test.blabla.net" mit "forward original header" aktiv und "requests appear to come from the original client" ebenfalls aktiv

traffic: http und https

public name: requests fpr the followin websites "test.blabla.net"

path: /*

bridging: 80 auf 80, 443 auf 443 ohne zertifikat zum authentifizieren

users: all users ohne credential forwarding

 

listener:

heißt wie das web "test.blabla.net"

net: external gebunden auf die öffentliche im dns eingetragene IP

preferences: http und https enables auf den standard-ports mit dem importierten webserver-zenrtifikat, authentication auf integrated

isa.txt

[Christoph35 10]

Hi,

 

ich hatte das, glaub ich, schon mal erwähnt: beim SSL to SSL Bridging braucht der ISA ein Userzertifikat um sich gegenüber dem Webserver zu authentifizieren. Und dieses User-Zertifikat ist dann auf dem Bridging Tab auszuwählen.

 

Leider hab ich das Buch heute nicht zur Hand und kann das genau erst heute nachmittag nachsehen.

 

Christoph