openmind
Goto Top

Exchange 2010 OWA über externe IP-Adresse ansprechen

Hallo liebe Mitglieder,

ich möchte auf einem W2008R2 mit Exchange 2010 den Zugriff auf das OWA über eine externe IP-Adresse ermöglichen.

Der Stand ist:
OWA ist für Port 443 freigeschaltet.

Auf dem Router wird mit einer Portweiterleitung und NAT der externe Port auf den internen 443 weiter gereicht.
Zum Test habe ich die externe Adresse derzeit per NAT ebenfalls auf die interne Routeradresse umsetzen lassen.
Somit kommen die Requests Adresstechnsich vom internen Routerinterface.
Ein grober Blick auf Wireshark bestätigt mir, dass das auch.

Intern kann ich sowohl über den voll qualifizierten Namen als auch über die Server-IP Adresse auf das OWA zugreifen.
Von extern komme ich auch auf die Standard Default Seite mit dem hübschen Willkommensgruß.
Der Datenfluß scheint also soweit zu stimmen.

Nur beim Zugriff auf https://<externe-ip>:<externerPort>/owa kommt nach einiger Wartezeit "Die Seite kann nicht angezeigt werden"
Ein neues selbstsigniertes Zertifikat ist wie hier beschrieben "http://notes.ponderworthy.com/create-new-self-signed-certificate-for-exchange-2010" erstellt, um die externe Adresse des Routers erweitert und zugeordnet.
Das OWA-Verzeichnis ist inzwischen auch schon einmal neu angelegt worden.

Kann mir jemand auf die Sprünge helfen wie ich dem Problem her werden kann?

Die wirklich zahlreichen Beiträge, die zu diesem Thema zu finden sind, haben mich auch nach zwei Tagen Probieren nicht weiter gebracht.
Evtl. habe ich hier ja ein grundsätzliches Verständnisproblem zum Verhalten des IIS bzgl. /OWA ?

Danke und Gruß
Uwe

Content-Key: 255284

Url: https://administrator.de/contentid/255284

Ausgedruckt am: 29.03.2024 um 06:03 Uhr

Mitglied: Criemo
Criemo 19.11.2014 um 15:25:07 Uhr
Goto Top
Hi,
Hast du es denn auch im IIS der Default Web Site in den 443 Bindung zu geordnet?

VG
Criemo
Mitglied: openmind
openmind 19.11.2014 um 15:29:23 Uhr
Goto Top
Hallo Criemo,

danke für den Hinweis.
Wenn du damit das Zertifikat meinst, ja das ist zugeordnet.

Gruß
Uwe
Mitglied: Criemo
Criemo 19.11.2014 aktualisiert um 15:47:05 Uhr
Goto Top
Hallo Openmind,

Schon mal einen Connectivity test gemacht?
einmal in den Exchange Tools

und einmal auf der PS?

Test-OwaConnectivity -URL:https://domain.local/owa -MailboxCredential:(get-credential domain\user)

VG Criemo
Mitglied: openmind
openmind 19.11.2014 um 16:01:35 Uhr
Goto Top
Hallo Criemo,

danke für deine Hilfe.

in der PS bekomme ich in der Tabelle die URL mit Result Erfolgreich angegeben.

Meinst du mit Tools den RemoteVerbindungstest, der auf die MS Website https://testconnectivity.microsoft.com verweist?

Den kann ich leider nicht ausführen, da das Formular die URL nicht als gültig akzeptiert, warum kann ich nicht sagen.
Ich gebe dort "https://externe-ip:externer-port/owa" an. Aber auch willkürliche URL's werden nicht akzeptiert.

Grundsätzlich wird der interne Test vermutlich nichts anderes bringen kann als OK, da dies ja wie oben beschrieben geht
und der externe Zugriff auf die Startseite geht ja auch.

Gruß Uwe
Mitglied: Criemo
Criemo 19.11.2014 um 16:15:29 Uhr
Goto Top
Hi,

okay also irgendwie müssen wir ja dahinter kommen was nun los ist

kannste es mal hiermit Probieren:

http://mxtoolbox.com/


domain eingeben und anschließend auf Find Problems gehen?

VG
Criemo
Mitglied: openmind
openmind 19.11.2014 um 16:28:36 Uhr
Goto Top
Hallo Criemo,

gerne, nur verstehe ich nicht so ganz wie das gehen soll, weil...

extern habe ich einen MX Eintrag der auf den eMail-Server des Providers verweist (Smarthost).
Ich gehe auf den Exchange im LAN aber über die dedizierte externe IP Adresse des Routers.
Intern ist im internen DNS ein MX Eintrag auf den Exchangeserver im LAN mit der lokalen Domäne vorhanden.

Das mxtoolbox.com versucht den MX Eintrag im Internet zu finden, dort findet es zu der externen Domäne auch die Einträge, nur haben diese ja nichts mit dem Exchangeserver zu tun.

Oder verstehe ich dich da falsch?

Gruß Uwe
Mitglied: keine-ahnung
keine-ahnung 19.11.2014 um 16:33:35 Uhr
Goto Top
extern habe ich einen MX Eintrag der auf den eMail-Server des Providers verweist (Smarthost).
Intern ist im internen DNS ein MX Eintrag auf den Exchangeserver im LAN mit der lokalen Domäne vorhanden.

????? Bist Du sicher, das Du weisst, wovon Du schreibst face-wink??

LG, Thomas
Mitglied: openmind
openmind 19.11.2014 um 16:36:02 Uhr
Goto Top
Hallo keine-Ahnung,

danke, sehr hilfreich.

Gruß Uwe
Mitglied: Criemo
Criemo 19.11.2014 um 16:45:54 Uhr
Goto Top
es geht nicht um ds was der Exchange ausspuckt sondern der WebServer also der IIS


hast du es mal mit deinem Handy versucht? komplett außerhalb des internen netzes?
Mitglied: openmind
openmind 19.11.2014 um 16:52:58 Uhr
Goto Top
Hallo Criemo,

wie ich oben geschrieben habe, vermute ich ja auch dort das Problem
und ja ich versuche den externen Zugriff die ganze Zeit von außerhalb.

Von dort komme ich mit "https://externe-ip:externer-port/" auf die Willkommens-Startseite des IIS.
Nur halt nicht auf "https://externe-ip:externer-port//owa".

LG Uwe
Mitglied: Criemo
Criemo 19.11.2014 um 18:25:58 Uhr
Goto Top
Sorry ist vielleicht ne blöde Frage, aber hast du die externe Adresse auch in der Exchange Console hinterlegt?
Mitglied: Criemo
Criemo 19.11.2014 um 18:27:53 Uhr
Goto Top
Hast du die IIs Seiten neu generieren lassen?
Mitglied: goscho
goscho 19.11.2014 aktualisiert um 19:31:47 Uhr
Goto Top
Moin
Zitat von @openmind:
Von dort komme ich mit "https://externe-ip:externer-port/" auf die Willkommens-Startseite des IIS.
Nur halt nicht auf "https://externe-ip:externer-port//owa".

Prinzipiell brauchst du den Port nicht mit anzugeben, da es sich ja um den Standard-Port für HTTPS-Anfragen handelt (443).

Vielleicht ist es nur ein Schreibfehler deinerseits (2 x / vor OWA), aber probiere doch mal https://externe-IP/owa face-wink

Ansonsten solltest du den Fehler im IIS suchen, wie @Criemo es schon schrieb.
Mitglied: Criemo
Criemo 19.11.2014 um 19:40:13 Uhr
Goto Top
@goscho
So wie ich es oben verstanden habe benutzt er von außen einen anderen Port der dann auf 443 geforwarded wird!

VG Criemo
Mitglied: Criemo
Criemo 19.11.2014, aktualisiert am 20.11.2014 um 08:59:00 Uhr
Goto Top
Überprüfe mal ob bei
 Get-OwaVirtualDirectory -Identity "Server\owa (default Web site)" |fl  

Alles richtig angezeigt wird?

Ist das Zertifikat wirklich auf der entsprechenden Bindung hinterlegt?
Mitglied: openmind
openmind 20.11.2014 um 08:52:10 Uhr
Goto Top
Hallo Criemo,

nochmals danke für deine Hilfe.

Zu den letzten Kommentaren:
Ja ist richtig, ich benutze von außen einen anderen Port, der dann auf intern 443 umgesetzt wird; daher die Angabe in der URL.

Get-OwaVirtualDirectory gibt mir drei Spalten aus:
Name: owa (Default Web Site)
Server: <der richtige Servername>
OwaVersion: Exchange2010

Zur Frage ob ich die Die IIS Seite neu generieren lassen habe:
Ich habe den Hinweis in den Foren gefunden gehabt, dass das Virtuelle Directory (dass war glaube nach einem Patch auf einem SBS, oder so) gecrasht sein kann.
Ich habe dieses daraufhin neu erstellt, hatte aber keine Änderung gebracht.
Letztendlich funktioniert es intern ja auch.

Die Bindung des Zertifikates ist auf https hinterlegt.

Zu deiner Frage: "...aber hast du die externe Adresse auch in der Exchange Console hinterlegt?"
Was meinst du bitte damit genauer ?

Was ich nicht verifiziert habe, ist die Aussage, das zu OWA nur der Port 443 benötigt wird, wenn dem nicht so ist, wäre das eine plausible Erklärung warum der IIS die OWA Seite nicht ausliefern kann. Aber dann müsste es doch eigentlich auch dokumentiert sein.

Gruß
Uwe
Mitglied: Criemo
Criemo 20.11.2014 aktualisiert um 09:02:51 Uhr
Goto Top
Hallo Uwe,


Get-OwaVirtualDirectory -Identity "Server\owa (default Web site)" |fl  

eigentlich meinte ich das so sorry.

schaumal bei internal und External Url ob dort die richtige URL hinterlegt ist!

OWA benutzt nur 443. Keine Sorge

VG
Criemo
Mitglied: openmind
openmind 20.11.2014 um 09:08:43 Uhr
Goto Top
Hallo Criemo,

bei InternalURL steht: https://<Servername>.<interneDomäne>.local/owa

bei ExternalURL steht: https://<exterenIP>/owa

So richtig?

Gruß
Uwe
Mitglied: Criemo
Criemo 20.11.2014 um 10:27:30 Uhr
Goto Top
ja eigentlich schon.

wie sieht es denn mit dem Portforwarding aus und deiner NAT regel. weil ich glaube nicht mehr dass es am IIs liegt ich vermute mittlerweile dass es an deiner Firewalleinstellung liegt. Könntest du das nochmal checken und testen. teste mal wenn du kein Forwarding machst sondern denn Port 443 einfach nach außen legst?


VG
Criemo
Mitglied: openmind
openmind 20.11.2014 um 12:15:47 Uhr
Goto Top
Hallo Criemo,

echt Klasse dass du bei der Stange bleibst und mir helfen willst.

Also ich bin da nochmal gedanklich nüchtern rangegangen und habe die Einstellungen geprüft.

Ich sehe im Wireshark einen SSL Vereinbarung und wie dann Daten ausgetauscht werden.
Da verschlüsselt kann ich ja leider nicht reingucken, aber wie gesagt direkt auf die DefaultWebSite bekomme ich die Standard WillkommenSeite.

Wenn ich mich mal von außen durch die installierten virtuellen Verzeichnisse so durchteste, bekomme ich z.B. bei /PowerShell ein Forbidden usw..

Zum weiteren Test habe ich jetzt einfach mal ein virtuelles /Test Verzeichnis im physikalischen wwwroot-Pfad mit einer index.html angelegt, da kann ich dann sofort drauf zugreifen.

Daraufhin bin ich mal in das physikalische Verzeichnis C:\Programme\Microsoft Exch....\V14\ClientAccess\owa gegangen und habe mal dort alles weggesichert und auch eine index.html angelegt und siehe da
... kein Zugriff !

Da passt doch was mit den Zugriffsrechten nicht, oder?

Habe nur leider kein Referenzsystem zum Vergleich übrig.

VG
Uwe
Mitglied: Criemo
Criemo 20.11.2014 um 13:26:00 Uhr
Goto Top
Hi Uwe,
klar bleibe ich da bei der Stange, kann dich ja nicht im regen stehen lassen und außerdem Wurmt mich das selber.

An den rechten kann es eigentlich nicht liegen, weil Intern funktioniert es ja auch ohne Probleme.

Aber überprüfe es mal:

Authentifizierte Benutzer > Lesen
System > Vollzugriff
Administratoren (LokalerServer\LokaleAdminGruppe) > Vollzugriff


Hast du mal versucht extern EWS und ActiveSync auf zu rufen? einfach um aus zu schließen dass es am OWA verzeichnis liegt?!


VG
Criemo

PS: Übrigens html sollte dort nicht gelesen werden können ist ja .Net also wenn müssten es ASPX Dateien sein!
Mitglied: openmind
openmind 20.11.2014 um 14:00:07 Uhr
Goto Top
Hallo Criemo,

Hm...
wenn ich /EWS von innen oder draußen aufrufe, kommt die typische Frage "Laden dieser Website fortsetzen(nicht empfohlen)?"
Danach kommt ein HTTP403: Verboten - Die Website hat die Anzeige dieser Webseite abgelehnt.

Gruß
Uwe
Mitglied: Criemo
Criemo 20.11.2014 um 15:04:01 Uhr
Goto Top
Hallo Uwe,

also wenn solltest du nach dem /EWS auch noch ein /Exchange.aspx dranhängen!

ich denke um mal vorran zu kommen sollten wir jetzt einmal das nachfolgende machen:


Zurücksetzen eines virtuellen Verzeichnisses auf einem Clientzugriffsserver mithilfe der Exchange-Verwaltungskonsole

Bevor Sie dieses Verfahren ausführen können, müssen Ihnen die entsprechenden Berechtigungen zugewiesen werden. Informationen zu den von Ihnen benötigten Berechtigungen finden Sie unter "Zurücksetzen von virtuellen Verzeichnissen auf Clientzugriffsservern" im Thema Clientzugriffsberechtigungen.
Navigieren Sie in der Konsolenstruktur zu Serverkonfiguration > Clientzugriff.
Klicken Sie im Aktionsbereich auf Virtuelles Clientzugriffsverzeichnis zurücksetzen.
Klicken Sie auf der Seite Einführung neben Zurückzusetzendes virtuelles Verzeichnis auf Durchsuchen. Wählen Sie das virtuelle Verzeichnis, das zurückgesetzt werden soll, und klicken Sie auf Weiter. Standardmäßig werden die folgenden virtuellen Clientzugriffsverzeichnisse aufgeführt:
Autodiscover (Standardwebsite)
ecp (Standardwebsite)
EWS (Standardwebsite)
Microsoft-Server-ActiveSync (Standardwebsite)
OAB (Standardwebsite)
owa (Standardwebsite)
Nachdem das Verzeichnis, das zurückgesetzt werden soll, zur Liste unter Zurückzusetzendes virtuelles Verzeichnis hinzugefügt wurde, klicken Sie auf Weiter.
Geben Sie auf der Seite Protokollspeicherort den Pfad und den Dateinamen für die Protokolldatei an, und klicken Sie auf Weiter. Die Protokolldatei umfasst die Einstellungen für das virtuelle Verzeichnis, das zurückgesetzt werden soll. Diese Einstellungen sind möglicherweise nützlich, wenn Sie ein virtuelles Verzeichnis mit denselben Einstellungen wiederherstellen möchten. Die Protokolldatei wird standardmäßig in den Ordner Dokumente auf dem Clientzugriffsserver kopiert.
Klicken Sie auf der Seite Virtuelles Clientzugriffsverzeichnis zurücksetzen auf Zurücksetzen.
Klicken Sie auf der Seite Fertigstellung auf Fertig stellen.
Starten Sie die Internetinformationsdienste (IIS) neu. Sie können die Internetinformationsdienste neu starten, indem Sie an einer Eingabeaufforderung iisreset /noforce ausführen.


Dann können wir uns wenigstens sicher sein, dass es nicht an einem Defekten owa und IIS Config liegt!

VG
Criemo
Mitglied: Criemo
Criemo 20.11.2014 um 15:35:38 Uhr
Goto Top
Hattest du eigentlich auch die Root CA auf deinem Client und dem Server Installiert?


ansonsten schau dir das Tutorial mal an ist zwar für EX2007 aber es sollte im groben dennoch passen!!


VG

Criemo
Mitglied: openmind
openmind 20.11.2014 um 15:45:39 Uhr
Goto Top
Hallo Criemo,

das hatte ich auch schon mal gemacht.
Nun habe ich es aber wiederholt durchgeführt.
Nach dem iireset /noforce ist es das Gleiche wie zuvor.

VG
Uwe
Mitglied: Criemo
Criemo 20.11.2014 um 15:52:03 Uhr
Goto Top
Hallo Uwe,

wie sieht es mit der ROOT CA aus?

ansonsten schau dir das Tutorial mal an ist zwar für EX2007 aber es sollte im groben dennoch passen!!

http://exchangeshell.wordpress.com/2009/09/20/create-ucc-san-private-ca ...


VG
Criemo
Mitglied: openmind
openmind 20.11.2014 um 16:10:06 Uhr
Goto Top
Es gibt derzeit keine authorisierende CA im Netz, bei der ich ein Zertifikat einreichen könnte.
Das verwendete Zertifikat ist ein vom Exchangeserver selbst erstelltes, das dann zwar beim Erstaufruf mangels Verifizierung als bedrohlich angefragt wird, aber nach Bestätigung der Vertrauensstellung bisher keine Probleme bereitet.

Da ein Zertifikat eh bei der Installation des Exchange angelegt wurde, habe ich wie oben erläutert, auf PS-Ebene ein neues mit Aliasen der externen Adressen für den Server gebaut und auch in der Bindung kontrolliert.

Wobei durch die Adress- und Portumsetzung der IIS als anfragende Adresse die interne vom Router bekommt.
Das ist auch der Grund, warum ich so verwundert bin und sich mir der Verdacht aufdrängt, dass der IIS auf der http(s) Ebene zum dem Entschluss kommt, die externe Anfrage zu ignorieren; wenn überhaupt, kann er doch nur dort noch Rückschlüsse auf die ursprüngliche URL ziehen.

Somit drehe ich mich wieder im Kreis und frage mich wie die owa-ASP Seite eigentlich so tickt und an welcher Stelle da ggf. noch eingegriffen werden muss, bzw. welche Einstellung da noch nicht passen könnte.

Die Clients im Netz, die über Outlook zugreifen haben das freilich auch schon mitbekommen und arbeiten aber problemlos mit dem neuen Zertifikat, war also ein weicher Übergang.

VG
Uwe
Mitglied: openmind
openmind 20.11.2014 um 17:17:53 Uhr
Goto Top
Hallo Criemo,

nun kommen wir vielleicht doch ein Stück weiter.

Ich habe einmal die URL aus dem internen Zugriff, wenn ich im Anmeldefenster stehe kopiert und diese dann für den externen Zugriff genommen und die enthaltenen Adressen gepatched.

Und siehe da, es geht !

Das sieht dann wie folgt aus:

https://<externer-ip>:8443/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2f<externe-ip>%2fowa%2f

oder auch mit

https://<externe-ip>:8443/owa/auth/logon.aspx?

Nur mit
https://<externe-ip>:8443/owa
geht es nicht.

Was ist da von mir beim IIS nicht berücksichtigt worden?

VG
Uwe
Mitglied: openmind
openmind 20.11.2014 um 17:20:33 Uhr
Goto Top
Zu früh gefreut,
es kommt zwar das Anmeldefenster, aber nach dem Anmelden wieder Die Seite kann nicht angezeigt werden.

Trotzdem, zeigt das doch schon die Richtung an.

VG
Uwe
Mitglied: Criemo
Criemo 20.11.2014 um 20:17:58 Uhr
Goto Top
Hi Uwe,
Was passiert denn wenn du auf dem Exchange mal https://localhost/owa aufrufst?

Kannst du es mal ohne Port forwarding probieren?

Ich glaube dass es hier der Hase liegt!

Die URL die du da anzeigst? Hast du URL Hardening aktiviert?

Setzt du einen Reverse Proxy ein?

VG
Criemo
Mitglied: openmind
openmind 21.11.2014 um 10:09:28 Uhr
Goto Top
Hallo Criemo,

mit https://localhost/owa funktioniert es auch.

Leider kann ich nicht so weiteres das Forwarding abschalten, da ich nicht auf den Providerrouter keinen direkten Zugriff habe.
Müsste ich in Auftrag geben, ist aber nicht unmöglich.

Nein, einen Proxy habe ich nicht zwischengeschaltet.

Von draußen geht es auf den eben erwähnten Router, der die eingehenden Pakete des betreffenden Ports auf die dahinter liegende Appliance wirft.

Diese ist wieder in meinem Zugriff und setzt den externen Port auf 443 um, sich selber als Absender via NAT ein und leitet die Anfrage an den Exchangeserver.

Das NAT habe ich zuletzt noch hinzugenommen, da ich am Anfang erst ohne angefangen habe und aufgrund des Problems die Möglichkeit ausschließen wollte, dass der Exchange sich an der "fremden" Absenderadresse stört; so kommt für ihn die Anfrage adressseitig quasi von innen.
Der Datenverkehr scheint ja auch soweit zu klappen.

Ein URL Hardening ist an der Stelle nicht eingerichtet, es sei denn, der IIS macht das selber.
Da habe ich aber keine aktive Aktien dran und müsste mir das Thema im IIS auch erstmal anlesen.

VG
Uwe
Mitglied: Criemo
Lösung Criemo 21.11.2014, aktualisiert am 25.11.2014 um 15:04:31 Uhr
Goto Top
Hi Uwe,

ich fasse mal zusammen:

Intern geht der Zugriff
auf dem Localhost geht der Zugriff

Ergo Kein Problem mit OWA bzw IIS

2. Möglichkeiten

entweder liegt es noch an dem externen Zertifikat, welches du verwendest oder aber am Portforwarding bzw. am NAT


VG
Criemo
Mitglied: openmind
openmind 21.11.2014 um 13:13:59 Uhr
Goto Top
Hallo Criemo,

ich werden zusätzlich den Port 443 einrichten lassen, kann man ja später ggf. wieder rausnehmen.

Nächste Woche gehe ich mal vor Ort zwischen Router und Appliance und werde aus dem "Transportnetz" einen Zugriff versuchen.
Vielleicht kommt dann ja mehr Licht ins Dunkel.

Danke für die Unterstützung, ich melde mich wieder und berichte.

Wäre schön, wenn du mich dann ggf. wieder weiter unterstützen könntest.

Schönes WE und VG
Uwe
Mitglied: Criemo
Criemo 21.11.2014 um 13:22:41 Uhr
Goto Top
Hi Uwe,
klar kein Problem ich bin hier face-smile

Schönes WE und Viele Grüße

VG
Mirco
Mitglied: openmind
openmind 25.11.2014 um 15:01:33 Uhr
Goto Top
Hallo Criemo,

am Ende war es so was von trivial.

Es heißt ja Google ist dein Freund naja.. face-smile

Ich bin nach diverser Recherche zu dem Thema über verschiedene Lösungsansätze von TMG und ReverseProxy dem Bock aufgesessen, dass es laut gelesener Aussagen ausreichen soll, einen externen Port auf den internen 43 umzuleiten.( Mit allen Vor- und Nachteilen).

Was aber leider keine Erwähnung fand, ist, dass die ASPX Integration des OWA gleich mal einen URL Redirect macht; dabei geht dann logischerweise bei einer Portumsetzung der externe Quellport verloren; en bekommt das OWA ja nicht mit.

Meine Überlegungen waren zu sehr von der Aussage geprägt, dass es gehen soll und ich Mangels bisheriger Beschäftigung mit dem IIS und OWA zuerst eine falsche Konfiguration etc. vermutete und weil ich mir die URL beim internen Zugriff nicht genau angesehen habe, bin ich da erst viel später darauf gekommen.

Also extern wie intern auf 443 belassen und schon geht es, kein Fehler mehr !

Nun kann noch zu Absicherung ein ReverseProxy dazwischen und es sollte soweit OK sein.

Danke nochmal
und VG
Uwe
Mitglied: Criemo
Criemo 25.11.2014 um 15:21:28 Uhr
Goto Top
Hi Uwe,
wunderbar. das freut mich, dass es funktioniert!
Makiere das Thema bitte als gelöst.

VG
Criemo