Exchange 2013: Mails bleiben in Warteschlange, Fehler:451 Temporary local problem - please try later

[andrew 15]

hello together

 

Umgebung

> Exchange 2013 R2 Standard: Postfachrolle, Clientzugriffsrolle, virtualisiert auf Hyper-V Server 2012 R2

   hat auf der Sophos UTM Relay Rechte

> Sophos UTM Firewall, filtert Mails ausgehend und eingehend Und: dient als Smarthost

> Windows 8.1 Prof Client mit Outlook 2013

   der angemeldete Benutzer ist in der ADDS Gruppe Mitglied, welche auf der Sophos UTM Firewall ebenfalls Relay Rechte hat

> MX Record zeigt auf fixe IP- Adresse (meine Sophos Firewall)

> Sophos UTM Firewall mit Zertifikat, der Allgemeine lautet des Zertifikats lautet: utm.it-netx.ch

> Exchange 2013 Zertifikat: SAN Zertifikat,

- der Allgemeine Name lautet: outlookanywhere.it-netx.ch (Wenn man das Zertifikat anzeigt, Reiter Allgemein: Ausgestellt für)- Feld "Alternativer Antragstellernamen" Hier habe ich immer den FQDN verwendet, analog des Exchange Dienstes

z.B. sind FQDNs drin wie

- ecp.it-netx.ch

- owa.it-netx.ch

- oab.it-netx.ch

- autodiscover.it-netx.ch

- outlookanywhere.it-netx.ch

- activesync.it-netx.ch

usw. (für jeden Dienst analog diesem Vorgehen)

 

> virtuelle Exchange: die interne und externe URL jeweils so angepasst, dass diese mit den oben soeben erwähnten URLs im SAN Zertifikat übereinstimmen

> Get-ClientAccessServer | FL AutoDiscoverServiceInternalUri

Resultat = AutoDiscoverServiceInternalUri : https://autodiscover.it-netx.ch/Autodiscover/Autodiscover.XML

> in der Exchange 2013 GUI (ECP) unter Punkt Server, Server auswählen, Buton bearbeiten klicken, Punkt Outlook Anywhere bei interner URL und externer URL folgende URL eingetragen: outlookanywhere.it-netx.ch

 

Bemerkung
Danach musste ich den Exchange neu starten, da ansonsten mein Outlook Client nicht mitbekommen hätte, dass der Exchange neu unter outlookanywhere.it-netx.ch erreichbar wäre beziehungsweise ist.

 

Kurz:

Outlook 2013 starten funktioniert ohne jegliche Zertifikatsmeldungen, mit Mails senden und empfangen ist jedoch leider nichts.

 

Ein Blick auf den Exchange Server in die Warteschlange sagt: 451 Temporary local problem - please try later

 

 

 

Kurz zur Geschichte, wie es soweit kommen konnte:

> ursprünglich hatte ich auf der Firewall eine simple NAT Regel erstellt, welche HTTPS Verkehr zur internen IP des Exchange weitergeleitet hat.

> ebenfalls war eine entsprechende Firewall Regel eingerichtet, die den HTTPS Verkehr zur internen IP des Exchange 2013 durchgelassen hatte.

 

In dieser Konstellation, so meinte ich doch, war ich in der Lage, Mails zu empfangen (wurden per MX Records zur Sophos Firewall gesendet, diese hat den Mailverkehr gefiltert und danach dem Exchange intern zugestellt)

 

Dann habe ich angefangen, sowohl auf der

> Sophos UTM Firewall

> wie auch auf dem Exchange 2013 mit Zertifikaten zu "spielen", neue erstellt, getestet usw.

 

Und:

Split DNS einzurichten (anscheinend ist es Best Practics, wenn die interne und externe URL gleich sind, also kommt man um Splitt DNS für mein technisches Verständnis nicht herum!

 

Neu war also nicht nur meine interne it-netx.local Domain auf dem DNS Server eingerichtet, sondern nun auch

it-netx.ch (darin enthalten sind alle A- Records, welche auch in meinem SAN Zertifkat enthalten sind)

 

Grund für diese Umstellung war, dass ich gerade versuche, via meine Sophos UTM Firewall den Dienst WAF (Web Application Firewall) zu testen. In dieser Konstellation könnte ich besser schlafen, weil hiermit das 08:15 Szenario, NAT Regel, Firewall Regel für den Dienst HTTPS (owa) überfällig wird Und: den Exchange vor Angriffen besser schützt

 

 

1. Warum will der Exchange keine Mails mehr nach extern senden?

2. Warum bekommen Leute, welche auf meine Test Mailadresse Mails senden (andre.aegerter@it-netx.ch) irgend einmal die Meldung: sorry, we were unable to deliver your message to the following address: andre.aegerter@it-netx.ch

Message expired for Domain it-netx.ch Remote host said: 451 Temporary local Problem - please try later [bODY]

bearbeitet 20. August 2014 von andrew

[DocData 85]

Für den Empfang und Versand von Mails ist HTTPS, aus Sicht des Exchange-Servers, unnötig. Wichtig ist 25/tcp. Der sollte ein- und ausgehend für den Exchange frei sein.

[NorbertFe 2.041]

Und warum nimmt man ein SAN Zertifikat mit x-Namen? Rein technisch reichen zwei (theoretisch wenn man nur mit autodiscover arbeiten will sogar nur ein) Name. Das wird nicht wirklich übersichtlicher wenn man da mit Namen pro Service arbeitet (jedenfalls, wenn man es ohne guten Grund tut).

 

Bye

Norbert

[RobertWi 81]

Moin,

 

ergänzend: Ich würde das ganze mal ohne die Firewall testen. Es wäre nicht das erste Mal, dass eine Firewall (und Sophos ist dafür bekannt) dazwischen funkt und irgendwas verändert. Grundsätzlich solltest Du im Datenstrom von SMTP und HTTP keinerlei Filterung vornehmen. Das ganze muss 1:1 ohne Prüfung direkt beim Exchange-Server landen.

 

Oder anders: Eine Firewall extra für Exchange bringt kaum Sicherheitsgewinn (im Gegenteil, es kann sogar unsicherer werden), aber viel Komplexität und zusätzliche Fehlerquellen. Du schläfst nicht besser damit, Du tauschst den wichtigen Stress nur gegen überflüssigen aus. ;)

[andrew 15]

Vielen Dank für die Rückmeldungen

 

direkter Versand mit Exchange in das Internet ausgehend funktioniert (Port 25/ TCP) hatte ich ausgehend vergessen zu öffnen, das ging gestern Abend in den späten Abendstunden irgendwie vergessen :-)

 

Mail Empfang, direkt via Exchange eingehend funktioniert ohne SMTP Proxy der Firewall ebenfalls ohne Probleme.

 

Fazit

Muss tatsächlich mal die Sophos UTM Firewall unter die Lupe nehmen und den Fehler suchen :-)

 

 

Betreffend SAN Zertifikat, warum so viele Namen darin enthalten sind:

Weil ich die Funktion Web Application Firewall (WAF = Filter) einsetzen/ teste möchte (Funktion der Sophos UTM Firewall).

 

Hierbei ist gegenüber dem einfachen Port weiterleiten (NAT Regel, Firewall Regel)  der Vorteil, dass spezifisch für OWA, Outlook Anywhere, Active Sync usw. eine gesonderte Filterung vorgenommen werden könnte Und: SQL Injection Attacks, XXS Atacks usw. können hierbei abgewehrt werden, was bei einer normalen Portweiterleitung nicht der Fall ist.

[RobertWi 81]

Hierbei ist gegenüber dem einfachen Port weiterleiten (NAT Regel, Firewall Regel)  der Vorteil, dass spezifisch für OWA, Outlook Anywhere, Active Sync usw. eine gesonderte Filterung vorgenommen werden könnte Und: SQL Injection Attacks, XXS Atacks usw. können hierbei abgewehrt werden, was bei einer normalen Portweiterleitung nicht der Fall ist.

 

Du möchtest da nichts filtern. Es sei denn, Du hast Langweile und willst jeden Tag irgendwelche Merkwürdigkeiten suchen, wo Du erst am Ende daran denkst, dass das der Proxy sein könnte. Die meisten Protokolle sind gar nicht offengelegt, da kann sowieso niemand sinnvoll filtern. Nicht mal das TMG macht eine inhaltliche Filterung. ;)

[NorbertFe 2.041]

Vor allem, weil Sophos/Astaro bis vor kurzem sogar Probleme mit der WAF und MacOS/EWS hatte, die dann nicht extern connecten konnten. ;)

https://www.astaro.org/gateway-products/web-server-security/47844-utm-webserver-protection-ews-2.html

 

Bye

Norbert

[RobertWi 81]

Eben. Wir haben ja nicht ohne Grund zuerst auf die UTM getippt und wieder mal richtig gelegen.

 

Dann würde ich mir zweimal überlegen, ob ich mir diesen Stress mit sehr geringem Nutzen absichtlich ins Haus hole. Es mag Anwendungsbereich geben, da ist ein Reverse Proxy gut - Exchange gehört definitiv nicht dazu.

[NeMiX 76]

Dann würde ich mir zweimal überlegen, ob ich mir diesen Stress mit sehr geringem Nutzen absichtlich ins Haus hole. Es mag Anwendungsbereich geben, da ist ein Reverse Proxy gut - Exchange gehört definitiv nicht dazu.

 

Das Problem dabei ist, dass dir sowas bei jedem Security Audit um die Ohren gehauen wird. Wir sind gerade in der Abnahme für ein Projekt und es gibt seit Montag Diskussionen mit der Auditfirma, das kein Server direkt aus dem Internet erreichbar sein darf/soll. Auch SMTP soll laut Auditor durch ein "anderes Device" (zitat) vorgefiltert werden, bevor es auf die interne Struktur trifft. Das Port 443 direkt auf den Exchange geht auf einer externen IP hat fast zum Herzinfarkt geführt...

Diverse MS KBs, Einträge usw. haben bisher nicht zum Erfolg geführt. Der Kunde steht natürlich in der Mitte und weiß nicht wem er glauben soll bzw. was richtig ist.

[NorbertFe 2.041]

Tja auch die Firmen mit auditauftrag wollen ja Geld verdienen.

[RobertWi 81]

Ich habe mir in so einem Gespräch immer konkret erklären lassen, worin der Sicherheitsgewinn steht. Und dann zeigte sich schnell, ob die Auditoren nur Papier ablesen oder echte Ahnung haben. Das merkt dann auch irgendwann ein Kunde. Und da ein Audit nur ein Bestandsaufnahme ist, habe ich mehrfach erlebt, dass so eine Firewall nach dem Audit im "täglichen Betrieb" eine andere Konfiguration bekommen hat.

 

Das wirklich schlimme dabei, dass die Sicherheit trügerisch oder sogar gefährlich ist. "Warum sollte ich Kennworte regelmäßig ändern oder Sicherheitsupdates installieren, ich habe doch die UTM davor." Und wenn es dann mal knallt merken die Leute, dass sie den Sicherheitsgewinn vollkommen überschätzt haben und in Summe eigentlich unsicherer waren, als vorher.

 

Nicht falsch verstehen: Ich habe nichts gegen eine Firewall bis Layer 4/5 und für alle Ports, die wir nicht für Exchange nutzen (wobei das eigentlich nur die Reaktion auf schlechtes Softwaredesign von Windows ist, echte Linux-Admins lachen uns bei so was aus). Aber die soll die Finger von Port 25/443 und Layer 6/7 lassen. Hier macht sie mehr kaputt, als sie hilft.