9191329637

Mar 30, 2024 at 18:08:29 (UTC)

2017

Exchange-Server 2019 Multi-Domain Setup

Schönen Abend zusammen!

Ich habe mal eine Frage bzw. ich bräuchte vielleicht ein paar Antworten auf mein Problem.
Ich habe für mich und meine Familie einen Exchange-Server 2019 auf einem Windows Server 2022 installiert.

Dieser Server soll Mail-Server für 5 Domains sein.
Ich fange jetzt erstmal mit dem Aufbau an:

Ich habe mir einen Server im Internet gemietet. Der Server hat eine statische IPv4-Adresse. Der Reverse DNS-Eintrag ist auf mailserver.domain.de gesetzt.

Alle Anfragen auf die IP kommen auf eine Sophos XG Firewall an. Die Ports 80 und 443 sind per NAT auf einen weiteren Host geleitet, auf dem ein Docker Container mit NGINX Proxy Manager läuft. Der Proxy Manager kümmert sich in erster Linie um die SSL-Zertifikate, welche mit Let's Encrypt erstellt werden. Der Exchange-Server ist damit erreichbar mit mail.domain.de, autodiscover.domain.de und outlook.domain.de (und dasselbe für die anderen Domains (mail.domain2.de, autodiscover.domain2.de und outlook.domain2.de, etc.))

DNS Einträge sind A-Records mit der IP der Sophos Firewall.

Der Domaincontroller verwendet die Anmeldedomäne domain.local. Der Exchange-Server hat daher den FQDN srv-Exchange.domain.local.

Versand der Mails funktioniert so weit, auch mit DKIM Signatur.
Ich kann die Mail Clients auf dem Smartphone (Apple Mail und Google Mail) auch anlegen.
Leider funktioniert die Verbindung mit Outlook Desktop nicht. Ich habe testweise auch mal Spark getestet. Spark unterstützt ja kein ActiveSync, daher funktionierte hier vermutlich die Verbindung auch nicht...

Zur Info: Wenn ich das ECP aus meinem LAN öffne (Per VPN), dann bekomme ich eine Meldung das, dass Zertifikat falsch ist. (Der Exchange verwendet ja die eigenen Zertifikate, die bei der Installation erstellt wurden).

Ich habe daher mal mit dem Remotetest Tool von Microsoft die ActiveSync Funktion getestet... Der Test lief leider auf einen Fehler:

Die Antwort „HTTP 401 Nicht autorisiert“ wurde vom Unknown-Remoteserver empfangen. Dies ist in der Regel die Folge eines falschen Benutzernamens oder Kennworts. Wenn Sie sich bei einem Office 365-Dienst anmelden möchten, stellen Sie sicher, dass Sie Ihren vollständigen Benutzerprinzipalnamen verwenden.
HTTP-Antwortkopfzeilen:
Connection: keep-alive
request-id: 95471cba-9c4f-4eb0-9789-2533cbd10864
X-OWA-Version: 15.2.1544.4
Content-Length: 0
Date: Sat, 30 Mar 2024 17:57:49 GMT
Server: openresty
WWW-Authenticate: Basic realm="autodiscover.domain.de"  
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
X-FEServer: SRV-EXCHANGE
Strict-Transport-Security: max-age=63072000;includeSubDomains; preload

Der Fehler macht aber keinen Sinn, da ich den Benutzernamen und das Kennwort so auch bei den Smartphones verwendet habe...

Ich stecke bei dem ganzen Zertifikat und Exchange-Geschichte noch nicht so tief drin, vielleicht hat da jemand bisschen mehr Erfahrung und kann da etwas Licht ins Dunkle bringen

Danke!

Please also mark the comments that contributed to the solution of the article

Content-Key: 73815487338

Url: https://administrator.de/contentid/73815487338

Printed on: April 30, 2024 at 10:04 o'clock

7 Comments

Latest comment

Moin...

du hast ein zertifikat problem, sind interne und externe url gleich?
ist autodiscover auch in deinem zertifikataufgeführt?
was ist das für ein zertifikat?

Frank

Moin,

Ich habe für mich und meine Familie einen Exchange-Server 2019 auf einem Windows Server 2022 installiert.

du kommst zu rechten Zeit... in dem Fall sind es nun 17.001...
https://www.msxfaq.de/exchange/update/bsi-csw-nr-2024-223455-1032.htm
https://asichel.de/2024/03/27/exchange-server-administratoren-und-untern ...
https://www.borncity.com/blog/2024/03/27/bsi-warnung-mind-17-000-exchang ...

Der Domaincontroller verwendet die Anmeldedomäne domain.local. Der Exchange-Server hat daher den FQDN srv-Exchange.domain.local.

Wieso als TLD .local? Ist gar nicht mehr Best Practices von Microsoft. Seitens ICANN wird es wohl auf TLD .internal hinauslaufen: https://itp.cdn.icann.org/en/files/root-system/identification-tld-privat ...

Ich stecke bei dem ganzen Zertifikat und Exchange-Geschichte noch nicht so tief drin

Was veranlasst dich deshalb einen Exchange Server zu betreiben? Das wird früher oder später ein Problem werden. Das ist kein Spielzeug sondern eine komplexe Anwendung. Welche dauerhafte Pflege und Aufmerksamkeit benötigt. Nein, es ist kein Selbstläufer.

Die Ports 80 und 443 sind per NAT auf einen weiteren Host geleitet, auf dem ein Docker Container mit NGINX Proxy Manager läuft. Der Proxy Manager kümmert sich in erster Linie um die SSL-Zertifikate, welche mit Let's Encrypt erstellt werden. Der Exchange-Server ist damit erreichbar mit mail.domain.de,

Das könnte dein Problem sein. Wird zwischen NPM und Exchange über HTTPS kommuniziert? Ist dem so, so schlägt die Exchange Extended Protection zu. Denn hierfür muss auf den Proxy und Exchange-Server das selbe (gleicher Fingerabdruck) verwendet werden.

Gruß,
Dani

Hallo ihr beiden!

...sind interne und externe url gleich?

Nein, die hatte ich auf die gleiche URL gezogen. Ich habe diese erstmal wieder auf zwei verschiedene URLs gestellt, da es hier keinen positiven Effekt gab. Wie mache ich das denn hier aber mit den verschiedenen Domains? Ich kann ja nicht mehrere Domains für die Verzeichnisse angeben.

ist autodiscover auch in deinem zertifikataufgeführt?
was ist das für ein zertifikat?

Das Zertifikat ist ein Wildcard-Zertifikat, welches von NPM erstellt wird. Das Wildcard-Zertifikat ist auf dem Exchange-Server gar nicht vorhanden und wird nicht verwendet. Mir ist noch keine Lösung untergekommen, wie ich das Wildcard-Zertifikat aus der Datenbank von NPM automatisiert in den Exchange-Server importieren kann.

du kommst zu rechten Zeit... in dem Fall sind es nun 17.001...

Gelesen hatte ich das auch. Es nützt nur leider nichts, ich habe auch versucht Mailcow zu nutzen. Leider konnte ich mich mit dem System nicht so anfreunden. Exchange und Exchange Online kenne ich von der Arbeit, daher hab ich mich für das System entschieden. Ich werde dann schauen, wie ich den Exchange noch absichern kann, aber erstmal muss es laufen...

Hat einfach den Hintergrund, dass ich mich mit dem Thema weiter beschäftigen kann, da dies Thema in meiner Ausbildung ein bisschen kurz gekommen ist. Dazu benötigen wir aus diversen Gründen personalisierte Mail-Adressen und mit der "Mailkuh" konnten wir nicht alles so richtig abbilden... Dazu kommt das ich weiterhin gerne Veeam als Backup Lösung für die Mails einsetzen möchte, und Veeam 365 Backup meines Wissens nach keine Postfächer von der Mailkuh sichern kann...

Und über die Wartung brauchst du dir keinen Kopf machen, ich bin sogut wie jeden Tag auf meinen Servern unterwegs und installiere die Updates

Dann wird das vermutlich der Grund sein...

Ich habe das EAC jetzt wenigstens aus dem Internet nicht erreichbar gemacht... Sollte dadurch ja etwas mehr abgesichert sein.

Moin...

Das Wildcard-Zertifikat ist auf dem Exchange-Server gar nicht vorhanden und wird nicht verwendet. Mir ist noch keine Lösung untergekommen, wie ich das Wildcard-Zertifikat aus der Datenbank von NPM automatisiert in den Exchange-Server importieren kann.

na dann besorge doch ein ordentliches zertifikat, wo ist das Problem?

Nein, die hatte ich auf die gleiche URL gezogen. Ich habe diese erstmal wieder auf zwei verschiedene URLs gestellt, da es hier keinen positiven Effekt gab.

ohne splittdns und Zertifikat im Exchange wird das auch nix!

Wie mache ich das denn hier aber mit den verschiedenen Domains? Ich kann ja nicht mehrere Domains für die Verzeichnisse angeben.

deine frage sagt mir, du hast nicht mal ansatzweise verstanden wie der Exchange funktioniert- du hast nicht mal Bücher darüber gelesen! du solltest erstmal offline bleiben mit dem Exchange!

Und über die Wartung brauchst du dir keinen Kopf machen, ich bin sogut wie jeden Tag auf meinen Servern unterwegs und installiere die Updates

und du glaubst, das ist alles, was du wissen und machen musst?
Frank

Moin,

Nein, die hatte ich auf die gleiche URL gezogen. Ich habe diese erstmal wieder auf zwei verschiedene URLs gestellt, da es hier keinen positiven Effekt gab.

Es funktioniert natürlich auch, wenn die interne und externe URL nicht identisch ist. Allerdings gibt es hier weit aus mehr zu beachten als bei einem klassischen Split-DNS. Das SSL-Zertifikat, welches für die interne URL verwendet wird, kann natürlich entweder Self-Signed oder von einer privaten PKI bzw. CA stammen. Wichtig hierbei ist, dass der NPM die Services auf dem Exchange Server auch mit dem internen FQDN anspricht. Damit das aber funktioniert, muss das Zertifikat der ausstellenden PKI auf dem Linux Server manuell zur der Liste der Root CAs aufgenommen werden.

Wie mache ich das denn hier aber mit den verschiedenen Domains? Ich kann ja nicht mehrere Domains für die Verzeichnisse angeben.

eine deiner Domain muss führend sein. Sprich diese ist in der Regel die System/Service Domain. Da wird gerne auch mal ein neutraler Name in der E-Mail Welt dafür genommen.

Mir ist noch keine Lösung untergekommen, wie ich das Wildcard-Zertifikat aus der Datenbank von NPM automatisiert in den Exchange-Server importieren kann.

Mir ist auch keine Lösung wie deine unter die Augen gekommen. In der Regel wird hier ein gekauftes Zertifikat mit einer Laufzeit von 12 Monaten eingesetzt. Weil WAF, weil AD FS, weil WAP, weil Exchange Extended Protection, etc.

Es nützt nur leider nichts, ich habe auch versucht Mailcow zu nutzen. Leider konnte ich mich mit dem System nicht so anfreunden.

Da muss man doch ehrlich zu sicher selber sein. Sprich für einen produktiven Betrieb die Postfächer hosten lassen und gerne parallel eine interne Spielwiese aufbauen und das Wissen aneignen.

Exchange und Exchange Online kenne ich von der Arbeit, daher hab ich mich für das System entschieden.

Was sind den beruflich gesehen deine Berührungspunkte mit eurem Exchange Server?

Hat einfach den Hintergrund, dass ich mich mit dem Thema weiter beschäftigen kann, da dies Thema in meiner Ausbildung ein bisschen kurz gekommen ist.

Wie gesagt eine Spielwiese ausbauen, welche überhaupt keine Kontakt zur Außenwelt hat. Das geht früher oder später schief.

Und über die Wartung brauchst du dir keinen Kopf machen, ich bin sogut wie jeden Tag auf meinen Servern unterwegs und installiere die Updates

Du meinst also die 17.001 und ein Server sind gefährdet, weil keine Microsoft Update installiert sind? Für ein gewissen Prozentsatz ist das sicherlich richtig. Aber der Großteil ist einfach nicht den gegenwärtigen Vorgaben konfiguriert und es fehlen einfach Sicherheitsmerkale (AD FS + WAP, WAF, MFA, etc.).

Dazu kommt das ich weiterhin gerne Veeam als Backup Lösung für die Mails einsetzen möchte, und Veeam 365 Backup meines Wissens nach keine Postfächer von der Mailkuh sichern kann...

Ja gut, die Windows Welt mit der Linux Welt zu koppeln (Mailcow + Veam 365) war noch nie eine gute Idee und sind Äpfel und Birnen. Es gibt natürlich auch in der Linux Welt entsprechende Lösungen. Damit muss man sich auseinandersetzen.

Ich habe das EAC jetzt wenigstens aus dem Internet nicht erreichbar gemacht... Sollte dadurch ja etwas mehr abgesichert sein.

Sollte? Das Wort gibt es in der IT nicht. Weshalb nicht die Schotten dicht bis du dein Wissen aufgebaut hast. Denn OWA, AS, Outlook Anywhere und sogar SMTP (Port 25) bilden eine immer noch große Angriffsfläche. Wobei OWA vermutlich durch die Sperre von ECP (je nach dem wie du es konfiguriert hast) nicht mehr funktioniert.

Gruß,
Dani

Moin...

Alternativ kannst du ja auch für die Externen Clients ein VPN nutzen!
SMTP ausgehend wäre sowiso nur möglich mit fester IP und Reversmapping!
eingehend kannst du ja einen POP conector etc nutzen...

Frank

German Question Exchange Server E-Mail Outlook Mail Windows Server

Hotly discussed

End of availability for classic Teams clientDani - 2 Comments

Developer diary: Release 6.1admtech