Windows Server 2016 Exchange-Server 2019 - Apple Mail kann keinen Sync durchführen

[Phil-DE]

Guten Morgen zusammen,
ich habe folgendes Problem, ich kann mit meinem iPhone nicht mit der Apple Mail auf die E-Mails, Kalender, etc. auf meinem Exchange Server 2019 zugreifen.Zugriff wird hier über Wireguard VPN auf der OPNsense gewährleistet. Ich habe testweise den Exchange per Port-NAT (443) aus dem Internet erreichbar gemacht um VPN Probleme auszuschließen.

Outlook (Desktop und App) können die E-Mails abgreifen und Autodiscover scheint auch zu funktionieren. Wenn ich aber in Apple Mail die Konten hinzufüge (Was auch funktioniert), können die Mails, Kontakte, Kalender nicht abgerufen werden. (Server konnte nicht erreicht werden).

Die URLs in den virtuellen Verzeichnissen sind auf die externen URLs gesetzt und die Zertifikate sind installiert und werden auch im Browser als gültig erkannt (Die Zertifikate sind SAN-Zertifikate von Let's Encrypt). Der Microsoft Remote Analyzer meckert rum das was mit dem Autodiscover nicht stimmt, aber dies kann man ja verneinen da Outlook sich ja verbinden kann. Wenn ich die Serveradresse mitgebe läuft der ActiveSync Test durch.

Fehlermeldung ActiveSync mit Autodiscover Test:

Die Microsoft-Verbindungsuntersuchung konnte keine XML-Antwort von der AutoErmittlung abrufen.Weitere DetailsAusnahmedetails:Nachricht: The operation has timed outTyp: System.Net.WebExceptionStapelüberwachung:at System.Net.HttpWebRequest.GetResponse()at Microsoft.M365.RCA.Services.RcaHttpRequest.GetResponse()

Hat da jemand eine Idee?
Danke!

 

[LasseSamenström]

Hast du testweise dem Iphone eine any rule gegeben?

Laut Fehlermeldung will der sich mit 365 connecten?

Microsoft.M365.RCA.Services.RcaHttpRequest.GetResponse

 

[Evil E-Lex]

Der Microsoft Remote Analyzer meckert rum das was mit dem Autodiscover nicht stimmt, aber dies kann man ja verneinen da Outlook sich ja verbinden kann.

Wenn der ActiveSync-Test mit Autodiscover einen Fehler wirft, dann stimmt die Konfiguration nicht.

 

[xexex]

Der Microsoft Remote Analyzer meckert rum das was mit dem Autodiscover nicht stimmt, aber dies kann man ja verneinen da Outlook sich ja verbinden kann.

Diese Aussage kannst du pauschal gar nicht treffen, da es alleine für Outlook abhängig von Version und Konfiguration des Exchange Servers, mindestens drei verschiedene Varianten gibt, wie es sich mit dem Exchange Server verbindet.

Zunächst einfach mal die Frage, das aktuellste Cumulative Update auf dem Exchange Server eingespielt?
https://www.frankysweb.de/exchange-versionen/

 

[Phil-DE]

Okay, das mit 365 hab ich eben nicht gesehen. Danke für den Tipp! Aber woher kann das wohl kommen?

Das aktuelle Update für Exchange ist installiert. Hab das eben nochmal überprüft…

Da ja momentan NAT alles auf Port 443 auf den Exchange wirft, sollte das ja kein Regel Problem sein, richtig?

Es sind auf dem Exchange auch keine Mobilgeräte deaktiviert. OWA und EAS sind für die Benutzer auch aktiviert.

Ich habe testweise auch mal mit einem Samsung das Konto hinzugefügt. Da funktioniert es ohne Probleme, auch das Autodiscover. Das Problem tritt tatsächlich nur bei Apple auf…

 

[xexex]

Das Problem tritt tatsächlich nur bei Apple auf…

Womit Apple auf jeden Fall ein Problem hat sind selbst signierte Zertifikate, die Frage wäre an dieser Stelle natürlich, ob es sich nicht sogar an Let's Encrypt Zertifikaten stört, was ich aber weniger glaube. Sind die Let's Encrypt Zertifikate an allen relevanten Stellen gebunden?
https://www.frankysweb.de/exchange-...rsion-aber-eine-bessere-alternative-win-acme/

 

[Phil-DE]

Die Zertifikate sind an den entsprechenden Stellen hinterlegt. Da ActiveSync ja über 443 läuft, müsste sonst im Safari das Zertifikat ja als unsicher angezeigt werden, wenn man den Webmailer aufmacht. Oder nicht?

Das Zertifikat wird mit dem ACME Client von der OPNsense erstellt und dann automatisiert auf eine Freigabe auf den Exchange Server kopiert. Dieser konvertiert dann per Powershell Skript das Zertifikat in das PFX Format und spielt dieses danach als neues Exchangezertifikat ein. Das Zertifikat ist ein SAN-Zertifikat welches die Akzeptierten Domänen als Wildcard enthält.

Das der Exchange-Server als FQDN eine .local Domain hat, und das Zertifikat diese nicht beeinhaltet müsste ja eigentlich egal sein da die Clients ja nur mit Public Domains auf diesen zugreifen und die Adressen der virtuellen Verzeichnisse auf die public Domain gelegt sind.

Richtig?

Ergänzung (20. April 2024)

Ich hatte kurzzeitig mal vorübergehend den Exchange über den NGINX Proxy Manager veröffentlicht. Dort war das selbe Zertifikat eingespielt. Hier ging komischerweise dann das ActiveSync, aber Outlook Desktop lief dann nicht. Es konnte sich einfach nicht verbinden.

Aber seitdem ich das NAT direkt auf den Exchange gelegt hab, ist es komischerweise genau andersrum…

 

[konkretor]

Klingt irgendwie nach DNS Problem.

Die Namens Einträge vom Exchange sind nur über den internen DNS erreichbar oder auch irgendwo extern eingetragen?

 

[nubi80]

für die korrekte Funktion müssen folgende URLs erreichbar sein von extern:
Ob hier reines NAT oder ein Reverse Proxy zum Einsatz kommt spielt keine Rolle.

autodiscover.domain.com
outlook.domain.com (Die Subdomain kann auch anders lauten mail. oder extern. oder wuenschdirwas.)

Die Bindung dieser Domains an die entsprechenden virtuellen Directorys muss passen.

Hier der Powershell Skript Auszug zur Konfiguration der internen und externen URLs von Franky.

$servername = "EX2016"
$internalhostname = "outlook.frankysweb.de"
$externalhostname = "outlook.frankysweb.de"
$autodiscoverhostname = "autodiscover.frankysweb.de"
$owainturl = "https://" + "$internalhostname" + "/owa"
$owaexturl = "https://" + "$externalhostname" + "/owa"
$ecpinturl = "https://" + "$internalhostname" + "/ecp"
$ecpexturl = "https://" + "$externalhostname" + "/ecp"
$ewsinturl = "https://" + "$internalhostname" + "/EWS/Exchange.asmx"
$ewsexturl = "https://" + "$externalhostname" + "/EWS/Exchange.asmx"
$easinturl = "https://" + "$internalhostname" + "/Microsoft-Server-ActiveSync"
$easexturl = "https://" + "$externalhostname" + "/Microsoft-Server-ActiveSync"
$oabinturl = "https://" + "$internalhostname" + "/OAB"
$oabexturl = "https://" + "$externalhostname" + "/OAB"
$mapiinturl = "https://" + "$internalhostname" + "/mapi"
$mapiexturl = "https://" + "$externalhostname" + "/mapi"
$aduri = "https://" + "$autodiscoverhostname" + "/Autodiscover/Autodiscover.xml"
Get-OwaVirtualDirectory -Server $servername | Set-OwaVirtualDirectory -internalurl $owainturl -externalurl $owaexturl
Get-EcpVirtualDirectory -server $servername | Set-EcpVirtualDirectory -internalurl $ecpinturl -externalurl $ecpexturl
Get-WebServicesVirtualDirectory -server $servername | Set-WebServicesVirtualDirectory -internalurl $ewsinturl -externalurl $ewsexturl
Get-ActiveSyncVirtualDirectory -Server $servername | Set-ActiveSyncVirtualDirectory -internalurl $easinturl -externalurl $easexturl
Get-OabVirtualDirectory -Server $servername | Set-OabVirtualDirectory -internalurl $oabinturl -externalurl $oabexturl
Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl
Get-OutlookAnywhere -Server $servername | Set-OutlookAnywhere -externalhostname $externalhostname -internalhostname $internalhostname -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'
Get-ClientAccessService $servername | Set-ClientAccessService -AutoDiscoverServiceInternalUri $aduri

Darüber hinaus, aber das wurde bereits erwähnt funktionieren unter iOS keine SelfSigned Zertifikate mehr.
Es müssen offizielle Zertifkate sein von denen auf dem Smartphone oder Tablet entsprechende Root Zertifikate vorhanden sind. Letsencrypt funktioniert in jedem Fall, das habe ich selbst so am laufen.

 

[Phil-DE]

Die Namens Einträge vom Exchange sind nur über den internen DNS erreichbar oder auch irgendwo extern eingetragen?

Die Domainnamen sind aktuell nur extern eingetragen, da die Verbindung von extern erstmal funktionieren soll. Die Domainnamen müssten ja auch richtig sein, wenn bei der Verwendung von Nginx Proxy Manager ActiveSync funktionierte... Ich würde auch wieder auf den Nginx Proxy Manager umstellen, wenn ich dann Outlook Desktop zum Laufen bekomme. Aber ich vermute, es hängt mit dem "Anmeldefenster" zusammen, dass der Proxy Manager dies nicht verarbeiten kann. Ich würde mir dann eine IP-Adresse sparen...

für die korrekte Funktion müssen folgende URLs erreichbar sein von extern:

Die Domains (outlook.domain.de und autodiscover.domain.de) die sind eingetragen und über einen Browser bekomme ich diese auch geöffnet. Mit akzeptierten Zertifikat.

Die virtuellen Verzeichnisse haben bei intern und extern jeweils outlook.domain.de drin stehen. Autodiscover dann natürlich autodiscover.domain.de. Ich hatte das Skript damals auch zum Setzen der Pfad-URLs verwendet.

Im Weiteren verweisen die (outlook.domain1.de und autodiscover.domain1.de) auch auf dieselbe IP-Adresse. Und diese bekommen auch ohne Zertifikatswarnung OWA auf.

Das Exchange-Zertifikat wird im PowerShell Skript mit dem folgenden Befehl ausgetauscht:

Enable-ExchangeCertificate -Thumbprint $certificate.Thumbprint -Services POP,IMAP,SMTP,IIS -Force

Aber das Zertifikat sollte meiner Meinung nach dann an allen relevanten Stellen ausgetauscht werden.

Ergänzung (21. April 2024)

Okay ich habe testweise mal wieder auf den Reverse Proxy gewechselt, jetzt geht ActiveSync wieder... Und Outlook Desktop wieder nicht. (Das Windows Anmeldefenster öffnet sich beim Start von Outlook und es ploppt immer wieder auf, egal wie oft ich das Kennwort dort eingebe)

Ich habe es eben mal wieder zurück auf NAT gestellt...

Ergänzung (21. April 2024)

Ich habe spaßeshalber mal eine Domain activesync.domain.de auf die IP des Reverseproxys zeigen lassen und die URLs für ActiveSync angepasst.

Leider bringt dies auch nichts. Das scheint ja irgendwie, als wenn der Apple Client mit dem Autodiscover nicht zurechtkommt.

 

[xexex]

@Phil-DE
Wenn du viel Langeweile hast, installiere dir auf dem PC mal Fiddler und schaue was welche Seiten bei so einer Anfrage aufgerufen werden und welche Zertifikate angefordert werden.
https://www.telerik.com/fiddler

Ich gehe jetzt einfach mal davon aus, dein Exchange läuft bereits im Mapi über HTTP Modus? Das wäre es dann sonst von mir was Ideen anbetrifft, Exchange war schon immer ein Graus, was On-Prem nur noch in wirklich großen Umgebungen einen Sinn ergibt.

 

[Phil-DE]

Wenn du viel Langeweile hast, installiere dir auf dem PC mal Fiddler und schaue was welche Seiten bei so einer Anfrage aufgerufen werden und welche Zertifikate angefordert werden.

Danke, ich werde mir das mal anschauen... Ich will da endlich mal eine Lösung finden, ich hänge mit dem Problem schon gute 2 - 3 Wochen :I

Ich gehe jetzt einfach mal davon aus, dein Exchange läuft bereits im Mapi über HTTP Modus?

Würde ich sagen, da Outlook Desktop, soweit ich weiß, dies ja verwendet, um die Mails abzugreifen.
Meiner Meinung nach macht es nur keinen Sinn, warum nur Apple damit Probleme hat. Samsung kann damit ja ohne Probleme arbeiten, und die werden sicherlich auch ActiveSync verwenden...

 

[redjack1000]

Hast du mal in das ActiceSync Debuglog geschaut?

Aber ich vermute, es hängt mit dem "Anmeldefenster" zusammen, dass der Proxy Manager dies nicht verarbeiten kann.

Gibt es eventuell gleiche Konten "konto@domain.com" auch noch mal Microsoft in Cloud z.B. für Teams?

CU
redjack

 

[Phil-DE]

Hast du mal in das ActiceSync Debuglog geschaut?

Nein, wo finde ich dies? Auf dem Exchange? Oder auf dem Smartphone?

Gibt es eventuell gleiche Konten "konto@domain.com" auch noch mal Microsoft in Cloud z.B. für Teams?

Ne gibt es nicht

 

[xexex]

Würde ich sagen,

Wie schon weiter oben geschrieben, Outlook kommt mit diversen Verbindungsmöglichkeiten zurecht, damit kann man das gar nicht vergleichen.

https://learn.microsoft.com/de-de/e...over-http/mapi-over-http?view=exchserver-2019

 

[Phil-DE]

Wie schon weiter oben geschrieben, Outlook kommt mit diversen Verbindungsmöglichkeiten zurecht, damit kann man das gar nicht vergleichen.

Okay danke für die Info, wieder was gelernt

 

[redjack1000]

https://learn.microsoft.com/en-us/exchange/troubleshoot/mobile-devices/issues-for-mobile-devices

CU
redjack

 

[Phil-DE]

@redjack1000 ich schau mir deinen Link mal eben an...

Ich habe mal Testweise auf der OPNsense den Caddy Reverseproxy eingerichtet da dieser NTLM Transport anbietet. Outlook bekomme ich auch hier angebunden, nur den Mailclient von Apple nicht.

Da dieser dann die entsprechenden Zertifikate vorhängt, können wir ein Zertifikatsproblem ausschließen, oder?

 

[redjack1000]

Ein ReverseProxy schreibt logfiles, schau doch mal rein, hilft im Normalfall bei der Diagnose.

CU
redjack

 

[Phil-DE]

Ich habe in den Caddy-Logs wohl eine Fehlermeldung gefunden:

"error","ts":"2024-04-21T10:22:48Z","logger":"http.log.error","msg":"local error: tls: no renegotiation","request":{"remote_ip":"Public IP","remote_port":"15741","client_ip":"Public IP","proto":"HTTP/2.0","method":"OPTIONS","host":"outlook.domain.de","uri":"/Microsoft-Server-ActiveSync","headers":{"Authorization":[],"Accept-Language":["de-DE,de;q=0.9"],"X-Ms-Policykey":["2640893232"],"User-Agent":["Apple-iPhone15C2/2105.236"],"Content-Length":["0"],"Accept-Encoding":["gzip, deflate, br"],"Accept":["/"]},"tls":{"resumed":false,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"outlook.domain.de"}},"duration":0.015275914,"status":502,"err_id":"xgvp2dnb8","err_trace":"reverseproxy.statusError (reverseproxy.go:1267)"}