Mailflow Exch 2013 -> Exch 2010 func. nicht (primary target ip address responded with 451 5.7.3)

[cleveroo 0]

Hallo Freunde,

 

in der bestehenden Domäne W2k8R2 mit Exch 2010 SP3 habe ich einen weiteren W2k12R2 Exch 2013 Server installiert. (RU9)

(Alle Prerequisites wurde auch installiert)

 

Mailpostfächer befinden sich (noch) am Exch2010, allerdings habe ich zwei Postfächer auf Exch2013 zum Testen angelegt.

Diese zwei Postfächer können sich gegenseitig Mails verschicken/empfangen.

 

Exch2010 funktioniert normal, kann intern und nach extern E-Mails verschicken auch zu den zwei Testpostfächer am Exch 2013. Das funktioniert aber nicht umgekehrt. Der neue Exch2013 kann keine Mails an den Exch2010 versenden. Diese bleiben in seinem Queue hängen mit folgender Fehlermeldung:

 

 

451 4.4.0 Primary target IP address responded with: "454 4.7.0 Temporary authentication failure." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

 

 

Wenn ich die Mails die in der Warteschlange hängen anschaue, die hängen am Default Empfangconnector von dem Exch2013 (Default Exch2013 - HubTransport). Dieser wurde nicht von mir geändert, hat Standardeinstellungen wie z.B.  TLS,Standardauth,Integrierte Win-Auth, Exchange-Serverauth und folgende Berechtigungen: Exch-Server, Legacy-Exch-Server, Exch-Benutzer....

 

 

Genau die selbe Einstellungen hat auch der Empfangsconnector am Exch2010 (Default Exch2010).

 

 

Wieso läuft die Mail-Flow von Exch2013 zu Exch2010 nicht? Was habe ich vergessen?

 

Danke

 

 

++++++ NEU +++++++

 

 

 

 

Ich habe vorübergehend einen AnonymenRelay am Exch2010 ausgeschaltet (hat auch die IP von dem neuen Exch2013 abgedeckt) und einen separaten Empfangsconnector nur für Exch2013 erstellt (Mit Exch-Auth und Exch-Server)

 

Die Mails bleiben weiterhin im Queue vom Exch2013 hängen, aber die Fehlermeldung hat sich geändert:

 

 

4.4.1 error encountered while communicating with primary target ip address 421 4.4.2 Connection dropped due to SocketError ....

 

Im SMTP-Protokoll vom neuen Receive-Connector bekomme ich folgenden Fehler:

TLS negotiation failde with error AlgorithmMismatch

bearbeitet 14. September 2015 von cleveroo

[monstermania 53]

Moin,

hatte ein ähnliches Problem bei der Migration von Exchange 2007 nach 2010.

Konnte keine Mail vom Ex2010 zum Ex2007 senden.

Nach Konfiguration der Konnektoren gemäß der folgenden Anleitung hatte sich das Problem gelöst: http://www.petenetlive.com/KB/Article/0000791.htm

 

Gruß

Dirk

[cleveroo 0]

Danke Dirk,

 

dies alles habe ich schon gemacht....

 

Das Problem besteht weiterhin:

 

TLS negotiation failed with error AlgorithmMismatch

 

Ich werde wahrschl. den Exchange2013 neu aufsetzen müssen (ich probiere mein Glück mit ENGL-Version, ohne CUs).

 

Falls euch noch zu dem Fehler etwas einfällt, gerne!

[NorbertFe 2.039]

Ohne CUs würde ich definitiv nicht empfehlen. Wenn dein Algorithmmismatch stimmen sollte, hast du eventuell an der SSL Konfiguration geschraubt? Welchen Patchstand hat der Exchange 2010?

[cleveroo 0]

@NorbertFe

 

in der Tat habe ich vor einem Jahr an dem Exch2010 Server SSL2 und SSL3 ausgeschaltet und RegKeys für TLS 1.1 und TLS 1.2 eintragen lassen (da diese nicht im Registry von Win2k8R2 vorhanden waren. Das war damals die Reaktion auf die Poodle-Attacke:

 

 

 

#make TSL 1.2 protocol reg keys
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client"

# Enable TLS 1.2 for client and server SCHANNEL communications
new-itemproperty -path     "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" -name "DisabledByDefault" -value 0 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -name "DisabledByDefault" -value 0 -PropertyType "DWord"

# Make and Enable TLS 1.1 for client and server SCHANNEL communications
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" -name "DisabledByDefault" -value 0 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -name "Enabled" -value 1 -PropertyType "DWord"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" -name "DisabledByDefault" -value 0 -PropertyType "DWord"

# Disable SSL 2.0 (PCI Compliance)
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" -name Enabled -value 0 -PropertyType "DWord"


# Disable SSL 3.0 (PCI Compliance)
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0"
md "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server"
new-itemproperty -path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -name Enabled -value 0 -PropertyType "DWord"

 

Was ich nocht nicht gesagt habe,

an dem neuen Exch2013 habe ich gleich nach der Exchange-Installation ein internes SSL-Zertifikat importiert (bestätigt von unserer internen CA) und für SMTP und IIS -Dienste aktiviert. Danach war MailFlow zwischen eigenen 2 Testpostfächer an dem neuen Exc2013 nicht mehr möglich. Genauso kein MailFlow von Exch2010->Exch2013.

Als ich das gesehen habe, habe dieses ZErt entfernt und das Standard-Zert. wieder den diensten SMTP und IIS zugeordnet. Danach ging wieder interner Traffic und Exch2010->Exch2013.....     Mailflow Exch2013->Exch2010 weiterhin nicht...

 

Heute habe ich dieses Standard-Zert wieder mit einem selbstsignierten von Exch2013 ausgetauscht, leider keine Besserung.....

+++++++++++++++++++

 

wie kann ich allgemein testen, ob die SSL-Kommunikation zwischen diesen 2 Servern in Ordnung wäre?

 

 

PS

Exch2010 ist SP3 , RU9 , Enterprise, Deutsch

bearbeitet 15. September 2015 von cleveroo

[testperson 1.680]

Hi,

 

das einfachste zum Anpassen der Protokolle, Cipher-Suites, Schlüssel-Austuasch- sowie Hash-Algorithmen wäre wohl IIS Crypto von Nartac. Einfach auf beiden Server entsprechend gleich konfiguriert ausführen und schon sollten sich die Server auf einen gemeinsamen Nenner einigen.

 

Gruß

Jan

[NorbertFe 2.039]

Würde ich auch empfehlen. Iiscrypto und best practise. Danach jeweils Booten und testen.

[cleveroo 0]

IIS Crypto habe ich installiert und auf beiden Servern mit gleichen Einstellungen durchgeführt und neugestartet.

Aktiviert sind jetzt: SSL3, TLS 1.0, TLS 1.1, TLS 1.2

(SSL3 werde ich später wieder ausschalten, da Sicherheitsrisiko)

 

Alle andere Einstellungen (Ciphers, Hashes, Key...) sind ebenso an beiden Servern AN! (alle)

 

So, Mailflow Exch 2013 (Win2012) -> Exch 2010 (Win2008) geht immer noch nicht. Neu ist allerdings ein Fehler im System Windows-Protokoll am Ziel-Server (Exch 2010 (Win2008))

Ereignis 36874, Schannel
Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

gefolgt von:

Ereignis 36888, Schannel
Es wurde eine schwerwiegende Warnung generiert: 40. Der interne Fehlerstatus lautet:1205

Mailflow  Exch 2010 (Win2008) -> Exch 2013 (Win2012) funktioniert wie gehabt!

 

Es scheint so, dass der Exch2010 Win2008 , Probleme hat, TLS1.2 aufzubauen, und der Exch2013 Win2012 besteht darauf und kommt dann aber nicht mehr durch. Richtig?

 

Hat jemand Ahnung wie könnte man das umgehen/fixen?

 

PS, Danke für IIS Crypto, super Tool! :)

bearbeitet 16. September 2015 von cleveroo

[testperson 1.680]

Hi,

 

wurde mit Ex 2010 SP3 RU10 nicht irgendwas an der TLS (1.2) Kommunikation geändert, was eigentlich schon in RU9 enthalten sein sollte? Evtl. den Exchange 2010 SP3 auf RU10 (oder gleich RU11) updaten.

Welchen Patchstand hat denn der Exchange 2013?

 

Exchange 2013 und TLS1.2: http://www.mcseboard.de/topic/201671-exchange-unterst%C3%BCtzung-f%C3%BCr-tls-12/

 

Gruß

Jan

bearbeitet 16. September 2015 von testperson

[NorbertFe 2.039]

Wieso ssl3 aktiviert? Wurde doch empfohlen und best practise zu klicken.

[cleveroo 0]

So, das Problem gelöst.

In Zwischenzeit habe ich auf dem Exch2010 neuestes RU11 aufgespielt, dies war aber nicht die Lösung.

 

MailFlow Exch2013->Exch2010 läuft erst seit dem ich an den beiden Servern ausschließlich  TLS 1.0 aktiviert habe ( über IIS Crypto )

 

Erst dann haben sie sich "gefunden" und die MailFlow läuft jetzt in alle Richtungen einwandfrei!

 

@Norbert

BestPractice hat nicht geholfen, da waren die Einstellungen zu unterschiedlich (W2k8 und W2k12) und es hat einfach nicht gepasst. Hier habe ich auch ein Workaround im Netz gefunden, wonach man die Reihenfolge von Hash-Chips über Policies bestimmen könnte... Dies habe ich aber weiter nicht verfolgt, da die Lösung mit TLS1.0 ONLY geklappt hat.

 

Ja, das ist nur vorübergehende Lösung, so lange ich nicht mit der Migration fertig bin. Dann wird Exch2010 eh abgeschaltet.

 

Danke an alle!!!

[NorbertFe 2.039]

Da ist gar nix unterschiedlich. Außer evtl du Cipher Suiten und da sind trotzdem genügend Übereinstimmungen. Also das kann's in meinen Augen nicht sein. Aber Hauptsache geht. ;)

[cleveroo 0]

@ Norbert

 

Ich denke, die zwei Server konnten sich nicht einigen über welchen Layer die miteinander reden möchten. Ich kann mir dass nur so vorstellen. Als der "alte" W2k8 Server mit Exch2010 noch TLS1.2 und TLS1.1 an hatte, lief die Kommunikation nicht richtig. Erst alls ich an beiden Seiten NUR TLS 1.0 eingeschaltet habe, dann lief alles wieder.

 

Als Quelle dieses Problems, vermute ich nicht existieren von TLS 1.1 und TLS 1.2 in einer original W2K8 Installation. Diese 2 Standards habe ich irgendwann händisch und nachträglich an dem Server über Registry eingeschaltet (damals als Poodle-Attacke aktuelle war). Und ich glaube, nur "Key in Reg eintragen" war einfach nicht genug um eine fehlerfreie Funktion diesen Layers zu ermöglichen.  Ich kann mir dann auch so vorstellen, dass dies eigentlich nachträglich in einem oder anderem Windows-Update gepacht wurde, da aber in meiner Installation diese Keys schon vorhanden waren, wurde das schlicht "übersprungen"....    Das alleine ist meine Vermutung.....  Aber in der Tatsache liegt bei mir NUR damit zusammen.

 

 

Danke trotzdem, IIS Crypto war ne Entdeckung!