Outlook Problem mit Extended Protection an einem Standort

[Squire 261]

Hallo zusammen,

 

folgende Umgebung besteht:

Ein Forest mit mehreren Domänen

Eine Exchange Organisation mit 4 Exchange Servern an mehreren Standorten (1 DAG am Hauptstandort, 1 XCH in China, Maildomain1.com / 1 XCH mit Maildomain2.com). Ein Kemp Loadbalancer Päarchen das die Exchange Server über zwei Service IPs (1x Maildomain1.com und 1x Maildomain2.com) nach außen veröffentlicht. Es gibt Öffentliche Ordner die auf den DAG Servern am Hauptstandort liegen.

Exchange Hybrid Wizard mit klassischer Bereitstellung ist aktiv (wegen Teams Kalender Sync. Das SAN Zertifikat mit allen Namen ist auf allen Servern und auf den Loadbalancern aktiv)  

 

Exchange ist 2019 CU14 mit SU vom März 24 auf allen Servern. 

Bei Maildomain1.com funktioniert alles (intern und extern - Outlook von extern ohne VPN funktioniert)

Bei Maildomain2.com funktioniert intern alles. Outlook ohne VPN von außen verlangt permanent Passwort. In der Verbindungsübersicht sieht man, dass zu den ÖO eine Verbindung zustande kommt, aber nicht zu dem eigentlichen Exchange ...

 

Ich hab schon bei Kemp ein Ticket offen, die haben die Konfiguration des Loadbalancers geprüft und sagen, alles in Ordnung. (Wir verwenden SSL Bridging).

Testweise haben wir für Maildomain2.com einen SSL Bypass eingerichtet - Outlook bringt keine Passwort Prompts und funktioniert.

 

Ich bin im Moment etwas ratlos - der Supportler von Kemp meint, wir sollen ein Ticket bei MS aufmachen ... ich denk aber, dass die Exchangekonfiguration richtig ist, sonst dürfte die Bypass Geschichte nicht funktionieren.

 

Anmerkung: Vor CU14 war die Exteneded Protection nicht aktiv und wir hatten für beide Services entsprechende Let's Encrypt Zertifikate aktiv. Da gab es keinerlei Verbindungsprobleme. Die offiziellen SAN Zertifikate von Geotrust waren schon vorher auf den Exchange eingebunden (wegen Hybrid) ...

Hat hier vielleicht jemand einen Tipp?

 

(Crossport bei Franky)

 

Nachtrag

Wenn die Clients von Maildomain2.com per VPN verbunden sind, ist alles hübsch - da sprechen sie aber auf Grund von SplitDNS direkt mit dem Exchange vor Ort.

Der Supportler von Kemp (eigene Aussage: Er ist kein Exchange Spezialist) hat intern das Ticket eskaliert - aber da ist jetzt seit über einer Woche nix passiert.

 

bearbeitet 23. März von Squire

[NorbertFe 2.034]

Hi,

 

hab jetzt keinen konkreten Vorschlag, aber wenn du die Extended Protection testweise abschaltest, geht es dann?

 

Bye

Norbert

[Squire 261]

Hi Norbert,

 

ja - ging ja vorher ohne Probleme und geht auch mit Protection, wenn der Kemp SSL Bypass spielt und die Acceleration/ReEncryption ausgeschaltet ist. Der Fehler bei der zweiten Maildomain tritt nur auf, wenn der Kemp SSLacc/ReEncrypt macht. Wie schon geschrieben, die Exchange sind identisch installiert. Ich hab einzig die Veröffentlichung am Kemp geändert (von LE auf Geotrust Zertifikat umgestellt). 

 

Schönen Sonntag

Robert