10
Exchange 2007 OWA verfügbar machen ohne Domain
Hallo zusammen,
wir stehen hier dieses Jahr vor einigen Herausforderungen im Bereich des Webhostings und das Mail Verkehrs und ich bin mir nicht sicher wie wir das anstellen sollen.
Vorhanden:
- Exchange 2007
- Mailabruf über "finger" Befehl von Dienstleister ALT
- Mailversand über Anmeldung bei Dienstleister ALT
- Kein OWA oder externer Mailempfang
Geplant / Gewünscht:
- Exchange 2007 soll bleiben
- Umzug mit Website und Mailversand zu Dienstleister NEU
- Mailabruf und Versand über neuen Dienstleister
- Externen Mailempfang, am besten über OWA möglich machen
Mein Problem ist also das ich hier einen internen Exchange habe der im Prinzip alles über einen Smarthost abwickelt, ich keine feste IP Adresse habe, und ich zukünftig OWA oä. für extern bereitstellen soll.
Wie stelle ich nun den Mailversand sicher und mache gleichzeitiig die Mails von Außen abrufbar?
Meine erste Idee wäre beim neuen Dienstleister eine Subdomain einrichten zu lassen, mit einem gültigen SSL Zertifikat, die dann an die "interne" dnydns Adresse hier weitergeleitet wird. Hier im Router kann ich dann ja den SSL Port an den Exchange weiterleiten.
Oder habt ihr andere, bessere Ideen?
Gruß
wir stehen hier dieses Jahr vor einigen Herausforderungen im Bereich des Webhostings und das Mail Verkehrs und ich bin mir nicht sicher wie wir das anstellen sollen.
Vorhanden:
- Exchange 2007
- Mailabruf über "finger" Befehl von Dienstleister ALT
- Mailversand über Anmeldung bei Dienstleister ALT
- Kein OWA oder externer Mailempfang
Geplant / Gewünscht:
- Exchange 2007 soll bleiben
- Umzug mit Website und Mailversand zu Dienstleister NEU
- Mailabruf und Versand über neuen Dienstleister
- Externen Mailempfang, am besten über OWA möglich machen
Mein Problem ist also das ich hier einen internen Exchange habe der im Prinzip alles über einen Smarthost abwickelt, ich keine feste IP Adresse habe, und ich zukünftig OWA oä. für extern bereitstellen soll.
Wie stelle ich nun den Mailversand sicher und mache gleichzeitiig die Mails von Außen abrufbar?
Meine erste Idee wäre beim neuen Dienstleister eine Subdomain einrichten zu lassen, mit einem gültigen SSL Zertifikat, die dann an die "interne" dnydns Adresse hier weitergeleitet wird. Hier im Router kann ich dann ja den SSL Port an den Exchange weiterleiten.
Oder habt ihr andere, bessere Ideen?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 179873
Url: https://administrator.de/contentid/179873
Ausgedruckt am: 26.11.2024 um 23:11 Uhr
10 Kommentare
Neuester Kommentar
Hi.
Gleich wie bisher. Da euer System nur über eine dynamische IP verfügt, bleibt sowieso nur der Versand über Smart Host über.
Über OWA und Outlook Anywhere
Das wird so nicht klappen. Durch die Weiterleitung wird ja die Echtheit des Zertifikats wieder aufgehoben. Erstelle selbst ein Zertfikat auf die korrekte DynDNS Adresse und importiere es auf den Clients.
LG Günther
Wie stelle ich nun den Mailversand sicher
Gleich wie bisher. Da euer System nur über eine dynamische IP verfügt, bleibt sowieso nur der Versand über Smart Host über.
mache gleichzeitiig die Mails von Außen abrufbar?
Über OWA und Outlook Anywhere
Meine erste Idee wäre beim neuen Dienstleister eine Subdomain einrichten zu lassen, mit einem gültigen SSL Zertifikat
Das wird so nicht klappen. Durch die Weiterleitung wird ja die Echtheit des Zertifikats wieder aufgehoben. Erstelle selbst ein Zertfikat auf die korrekte DynDNS Adresse und importiere es auf den Clients.
LG Günther
Hallo,
danke für deine Antwort. Ich muss das selbst erstellte Zertifikat dann auch im Exchange einbinden, bzw. im IIS, richtig?
Wie ist die Sicherheitsstandard von OWA einzuschätzen? Ich würde nur ungern über diesen Kanal infiltriert werden.
danke für deine Antwort. Ich muss das selbst erstellte Zertifikat dann auch im Exchange einbinden, bzw. im IIS, richtig?
Wie ist die Sicherheitsstandard von OWA einzuschätzen? Ich würde nur ungern über diesen Kanal infiltriert werden.
Hi.
Du erstellst das Zertifikat direkt am Exchange. Es gibt dazu genug gute Anleitungen im Netz.
Seit es eine OWA Version gibt, mit der man arbeiten kann (seit Exchange 2003) gab es keine mir bekannte Sicherheitslücke.
Anders herum. OWA ist sicherere als jeder Browser, jedes PDF Produkt vom roten Riesen und sicherer als jeder Flash Player die auf deinen Servern und Clients installiert sind.
Und eines kannst du auch sicher sein, wenn etwas passiert, dann ist es zumindest verschlüsselt
LG Günther
Ich muss das selbst erstellte Zertifikat dann auch im Exchange einbinden, bzw. im IIS, richtig?
Du erstellst das Zertifikat direkt am Exchange. Es gibt dazu genug gute Anleitungen im Netz.
Wie ist die Sicherheitsstandard von OWA einzuschätzen?
Seit es eine OWA Version gibt, mit der man arbeiten kann (seit Exchange 2003) gab es keine mir bekannte Sicherheitslücke.
Ich würde nur ungern über diesen Kanal infiltriert werden.
Anders herum. OWA ist sicherere als jeder Browser, jedes PDF Produkt vom roten Riesen und sicherer als jeder Flash Player die auf deinen Servern und Clients installiert sind.
Und eines kannst du auch sicher sein, wenn etwas passiert, dann ist es zumindest verschlüsselt
LG Günther
Ok, danke. Es ist also ein gangbarer Weg Port 443 in der Firewall auf den Exchange zu leiten, OWA einzurichten und den Usern die Dyndns Adresse zu geben?
Hi.
Ja. Wenn du natürlich ganz sicher gehen willst, kannst du ja einen Proxy zwischenschalten.
LG Günther
Es ist also ein gangbarer Weg Port 443 in der Firewall auf den Exchange zu leiten
Ja. Wenn du natürlich ganz sicher gehen willst, kannst du ja einen Proxy zwischenschalten.
LG Günther
Hallo,
so habe es nun denke ich soweit intern erst mal eingerichtet. Hab ein Selfsigned Zertifikat vom IIS erstellt und kann nun auch per SSL intern darauf zugreifen.
Aber was ist mit den ganzen anderen Anwendungen? Es ist ja sicherlich möglich die Default SSL Seite nach /owa umzuleiten, aber es sind ja noch einige andere Dinge automatisch eingerichtet.
Unter anderem folgende Dienste:
aspnet_client
Exchweb
Exchange
Exadmin
Public
UnifiedMessaging
Autodiscover
EWS
Wie kann ich sicherstellen das die nicht von extern erreichbar sind? Würde nur ungern etwas vom Internet aus ererichbar machen was nicht unbedingt sein muss.
so habe es nun denke ich soweit intern erst mal eingerichtet. Hab ein Selfsigned Zertifikat vom IIS erstellt und kann nun auch per SSL intern darauf zugreifen.
Aber was ist mit den ganzen anderen Anwendungen? Es ist ja sicherlich möglich die Default SSL Seite nach /owa umzuleiten, aber es sind ja noch einige andere Dinge automatisch eingerichtet.
Unter anderem folgende Dienste:
aspnet_client
Exchweb
Exchange
Exadmin
Public
UnifiedMessaging
Autodiscover
EWS
Wie kann ich sicherstellen das die nicht von extern erreichbar sind? Würde nur ungern etwas vom Internet aus ererichbar machen was nicht unbedingt sein muss.
Hi.
Hast du es schon versucht? Wenn nein, dann maches es
Und ich habe ja geschrieben, wenn du ganz sicher gehen willst, dann schalte einen Proxy dazwischen.
LG Günther
Wie kann ich sicherstellen das die nicht von extern erreichbar sind?
Hast du es schon versucht? Wenn nein, dann maches es
Und ich habe ja geschrieben, wenn du ganz sicher gehen willst, dann schalte einen Proxy dazwischen.
LG Günther
Ich habe eine Umleitung wie folgt eingerichtet http://s1.directupload.net/file/d/2793/9nqg35gi_png.htm
Anscheinend sorgt diese dafür das alle direkten Anfragen mit https:// egal auf welchen Dienst zu /owa umgeleitet werden. Prinzipiell ist das ja eigentlich genau das was ich will, denn einen anderen Dienst als Owa will ich ja nicht nutzen. Der Nachteil ist natürlich das ich nun auch intern lediglich OWA auf dem IIS erreichen kann.
Bevor ich die Umleitung eingerichtet habe tauchte jedesmal eine Abfrage mit Benutzername und Kennwort auf. Wenn ich bspw. /exchweb aufgerufen habe kam eine solche Abfrage.
Ich kenne es von einem größeren Unternehmen wo dann DirectoryListing verboten ist oder einfach eine 404 Meldung erscheint.
Einen Proxy dazwischen schalten wäre eine gute Idee. Nromalerweise verwende ich IPCops mit Squid und Dansguardian. Dort müsste ich dann eine Weiterleitung von *:443 auf https://192.intern/owa einrichten oder?
Edit:
Ich habe nun mal nach Anleitungen zu dem Thema gesucht und auch das ein oder andere dazu gefunden. Beispielsweise folgende: http://www.tanti.org.uk/index.php/blogs/owencampbell/3-tech/3-proxy
Nun habe ich aber folgendes Problem: Wenn ich nun auf meinem Debianserver ein SSL Zertifikat mit allem drum und dran erstelle kann ich dieses nicht beim Exchange Server importieren. Ich erhalte eine Fehlermeldung die mir sagt das ich das Zertifikat nur importieren kann wenn es auch auf demselben Rechner erzeugt habe oder so ähnlich. Die genaue Meldung kann ich aber nach reichen.
Edit2:
Folgende Meldung taucht auf wenn ich die Zertifikatsanforderung abschließen möchte:
Die dieser Zertifikatdatei zugeordnete zertifikatanforderung kann nicht gefunden werden. Zertifikatanforderungen müssen auf dem Computer abgeschlossen werden, auf dem sie erstellt wurden.
Anscheinend sorgt diese dafür das alle direkten Anfragen mit https:// egal auf welchen Dienst zu /owa umgeleitet werden. Prinzipiell ist das ja eigentlich genau das was ich will, denn einen anderen Dienst als Owa will ich ja nicht nutzen. Der Nachteil ist natürlich das ich nun auch intern lediglich OWA auf dem IIS erreichen kann.
Bevor ich die Umleitung eingerichtet habe tauchte jedesmal eine Abfrage mit Benutzername und Kennwort auf. Wenn ich bspw. /exchweb aufgerufen habe kam eine solche Abfrage.
Ich kenne es von einem größeren Unternehmen wo dann DirectoryListing verboten ist oder einfach eine 404 Meldung erscheint.
Einen Proxy dazwischen schalten wäre eine gute Idee. Nromalerweise verwende ich IPCops mit Squid und Dansguardian. Dort müsste ich dann eine Weiterleitung von *:443 auf https://192.intern/owa einrichten oder?
Edit:
Ich habe nun mal nach Anleitungen zu dem Thema gesucht und auch das ein oder andere dazu gefunden. Beispielsweise folgende: http://www.tanti.org.uk/index.php/blogs/owencampbell/3-tech/3-proxy
Nun habe ich aber folgendes Problem: Wenn ich nun auf meinem Debianserver ein SSL Zertifikat mit allem drum und dran erstelle kann ich dieses nicht beim Exchange Server importieren. Ich erhalte eine Fehlermeldung die mir sagt das ich das Zertifikat nur importieren kann wenn es auch auf demselben Rechner erzeugt habe oder so ähnlich. Die genaue Meldung kann ich aber nach reichen.
Edit2:
Folgende Meldung taucht auf wenn ich die Zertifikatsanforderung abschließen möchte:
Die dieser Zertifikatdatei zugeordnete zertifikatanforderung kann nicht gefunden werden. Zertifikatanforderungen müssen auf dem Computer abgeschlossen werden, auf dem sie erstellt wurden.
So habe nun zumindest sauber ein Zertifikat erstellt bekommen, das der IIS auch akzeptiert.
Hier mal in Kurzform wie ich das gemacht habe:
Zuerst die Zertifikatsanforderung (Meinedomain.dyndns.org.csr) im IIS erstellen, dann mit openssl einen server.key (Privater Schlüssel) erstellen und mit der Zertifikatsanforderung (Meinedomain.dyndns.org.csr) ein Zertifikat erstellen.
Dieses Zertifikat mit dem MMC Snappin importieren, den Anzeigenamen ändern. Danach lässt sich das Zertifikat im IIS importieren.
Anschließend muss das Zertifikat noch nach .pfx umgewandelt werden. Andernfalls lässt sich das Zertifikat zwar im IIS importieren, aber es verschwindet sofort wieder aus der Anzeige. Also konvertieren und dann im IIS importieren auswählen https://www.sslshopper.com/ssl-converter.html
Keine Ahnung ob man mit openssl auch direkt eine .pfx Datei erstellen kann, aber so hat es funktioniert.
Hier mal in Kurzform wie ich das gemacht habe:
Zuerst die Zertifikatsanforderung (Meinedomain.dyndns.org.csr) im IIS erstellen, dann mit openssl einen server.key (Privater Schlüssel) erstellen und mit der Zertifikatsanforderung (Meinedomain.dyndns.org.csr) ein Zertifikat erstellen.
#openssl genrsa -out MEINEDOMAIN.dyndns.org.key 2048# openssl x509 -req -days 3650 -in MEINEDOMAIN.dyndns.org.csr -signkey MEINEDOMAIN.dyndns.org.key -out MEINEDOMAIN.dyndns.org.cerDieses Zertifikat mit dem MMC Snappin importieren, den Anzeigenamen ändern. Danach lässt sich das Zertifikat im IIS importieren.
Anschließend muss das Zertifikat noch nach .pfx umgewandelt werden. Andernfalls lässt sich das Zertifikat zwar im IIS importieren, aber es verschwindet sofort wieder aus der Anzeige. Also konvertieren und dann im IIS importieren auswählen https://www.sslshopper.com/ssl-converter.html
Keine Ahnung ob man mit openssl auch direkt eine .pfx Datei erstellen kann, aber so hat es funktioniert.
Hallo nochmal,
ich habe die ganze Sache nun gelöst und anders bewerkstelligt. Ich habe ein selbstsigniertes SSL Zertifikat erstellt und auf einem Debian Server pound eingerichtet. Dieser spielt jetzt den Reverse Proxy für OWA. Allerdings läuft die interne Weiterleitung von pound zu OWA nun ohne SSL. Ich habe es nicht hinbekommen dies verschlüsselt abzuwickeln. Sobald ich dies einstelle bekomme ich immer Timeouts.
Im IIS habe ich nun eine HTTP-Umleitung für die Defaultwebsite auf /owa eingerichtet. Nun müsste eigentlich jede Anfrage auf /owa umgeleitet werden und da ich den IIS sonst weder intern noch extern brauche sollte das doch ok sein oder?
Muss ich sonst noch weitere Sicherheitsvorkehrungen etc. treffen?
ich habe die ganze Sache nun gelöst und anders bewerkstelligt. Ich habe ein selbstsigniertes SSL Zertifikat erstellt und auf einem Debian Server pound eingerichtet. Dieser spielt jetzt den Reverse Proxy für OWA. Allerdings läuft die interne Weiterleitung von pound zu OWA nun ohne SSL. Ich habe es nicht hinbekommen dies verschlüsselt abzuwickeln. Sobald ich dies einstelle bekomme ich immer Timeouts.
Im IIS habe ich nun eine HTTP-Umleitung für die Defaultwebsite auf /owa eingerichtet. Nun müsste eigentlich jede Anfrage auf /owa umgeleitet werden und da ich den IIS sonst weder intern noch extern brauche sollte das doch ok sein oder?
Muss ich sonst noch weitere Sicherheitsvorkehrungen etc. treffen?
