8
Exchange zertifizieren
Moin Community,
ich habe einen Exchange Server installiert und überlege gerade wie ich diesen zertifizieren soll.
Zu Hause habe ich einen Domain Controller und einen Exchange Server. Meine Heim-PC‘s sind in der Domäne angemeldet. Als Firewall dient ein Sophos UTM.
Der Zugriff von Außen ist einfach:
autodiscover.meinedomain.de
mail.meinedomain.de
meinedomain.de
Alles über Letsencrypt zertifizieren. Die 3 DNS Namen sind von außen auflösbar, bei meinem Domainhoster habe ich die Adressen in seinen DNS gefüttert.
Innerhalb meines Hauses sind alle Clients in der Dömäne und erhalten von der auf dem DC installierten Zertifizierungsstelle ein Zertifikat per GPO zugeteilt, das den internen Namen des Exchange Servers ex01.meinedomain.de vertraut macht.
Läuft soweit, wie es soll.
Nur, wenn mich jetzt meine Eltern mit ihrem Surface besuchen (sie haben ihre E-Mails auch auf meinem Exchange Server gehostet) und in mein WLAN anmelden, erhalten Sie eine Zertifikatswarnung, da ihre Surfaces nicht in der Domäne angemeldet sind.
Die erste Warnung ist, weil Autodiscover zunächst versucht meinedomain.de aufzulösen und damit laut den Sophos Einstellungen auf dem Domain Controller dc01.meinedomain.de landen und nicht mehr auf dem Exchange Server.
Die zweite Warnung ist, weil sie nun nicht mehr per Autodiscover die Adresse mail.meinedomain.de , sondern nun den internen FQDN ex01.meinedomain.de erhalten, den sie nicht kennen und nicht vertrauen.
Wie bekommt man das weg?
Ich kenne nur die Möglichkeit sie nicht in mein Domänennetzwerk zu lassen z.B. ein Gäste WLAN.
Oder ich muss jedem Client, der mein Exchange benutzen will, ein ex01 Zertifikat manuell installieren?
Ich möchte nicht, dass die internen FQDN‘s für ex01 (später evtl ex02 usw) auf dem exteurnen DNS Server meines Domainhosters angemeldet werden, nur um auch ein Letsencrypt Zertifikat zu erhalten. <– oder wäre das gar nicht schlimm?
Oder kann ich an meiner Zertifikatsstrategie was ändern?
Ich habe überlegt dem Exchange die interneren Links genau so einzustellen, wie auch die Externen sind. Ich befürchte jedoch, das geht in dem Moment schief, wenn ich einen zweiten Exchange Server als DAG hinzufügen möchte.
Ich weiß, es ist ein klein wenig oversized für ein privates Netzwerk. Die Lizenzen sind nun mal da und ich spiele mich gerne damit.
Danke Euch und keep rockin
Der Mike
ich habe einen Exchange Server installiert und überlege gerade wie ich diesen zertifizieren soll.
Zu Hause habe ich einen Domain Controller und einen Exchange Server. Meine Heim-PC‘s sind in der Domäne angemeldet. Als Firewall dient ein Sophos UTM.
Der Zugriff von Außen ist einfach:
autodiscover.meinedomain.de
mail.meinedomain.de
meinedomain.de
Alles über Letsencrypt zertifizieren. Die 3 DNS Namen sind von außen auflösbar, bei meinem Domainhoster habe ich die Adressen in seinen DNS gefüttert.
Innerhalb meines Hauses sind alle Clients in der Dömäne und erhalten von der auf dem DC installierten Zertifizierungsstelle ein Zertifikat per GPO zugeteilt, das den internen Namen des Exchange Servers ex01.meinedomain.de vertraut macht.
Läuft soweit, wie es soll.
Nur, wenn mich jetzt meine Eltern mit ihrem Surface besuchen (sie haben ihre E-Mails auch auf meinem Exchange Server gehostet) und in mein WLAN anmelden, erhalten Sie eine Zertifikatswarnung, da ihre Surfaces nicht in der Domäne angemeldet sind.
Die erste Warnung ist, weil Autodiscover zunächst versucht meinedomain.de aufzulösen und damit laut den Sophos Einstellungen auf dem Domain Controller dc01.meinedomain.de landen und nicht mehr auf dem Exchange Server.
Die zweite Warnung ist, weil sie nun nicht mehr per Autodiscover die Adresse mail.meinedomain.de , sondern nun den internen FQDN ex01.meinedomain.de erhalten, den sie nicht kennen und nicht vertrauen.
Wie bekommt man das weg?
Ich kenne nur die Möglichkeit sie nicht in mein Domänennetzwerk zu lassen z.B. ein Gäste WLAN.
Oder ich muss jedem Client, der mein Exchange benutzen will, ein ex01 Zertifikat manuell installieren?
Ich möchte nicht, dass die internen FQDN‘s für ex01 (später evtl ex02 usw) auf dem exteurnen DNS Server meines Domainhosters angemeldet werden, nur um auch ein Letsencrypt Zertifikat zu erhalten. <– oder wäre das gar nicht schlimm?
Oder kann ich an meiner Zertifikatsstrategie was ändern?
Ich habe überlegt dem Exchange die interneren Links genau so einzustellen, wie auch die Externen sind. Ich befürchte jedoch, das geht in dem Moment schief, wenn ich einen zweiten Exchange Server als DAG hinzufügen möchte.
Ich weiß, es ist ein klein wenig oversized für ein privates Netzwerk. Die Lizenzen sind nun mal da und ich spiele mich gerne damit.
Danke Euch und keep rockin
Der Mike
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 443411
Url: https://administrator.de/contentid/443411
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
im Prinzip ganz einfach: interne und externe URLs vom Exchange identisch setzen und im lokalen DNS-Server die jeweiligen Subdomains auf die interne IP-Adresse des Exchange Servers einstellen.
https://docs.microsoft.com/de-de/exchange/plan-and-deploy/post-installat ...
Hier ist sogar ein Skript von colinardo
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Das interne, selbst-signierte Zertifikat was du über GPO verteilst, brauchst du dann nicht mehr.
VG
im Prinzip ganz einfach: interne und externe URLs vom Exchange identisch setzen und im lokalen DNS-Server die jeweiligen Subdomains auf die interne IP-Adresse des Exchange Servers einstellen.
https://docs.microsoft.com/de-de/exchange/plan-and-deploy/post-installat ...
Hier ist sogar ein Skript von colinardo
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Das interne, selbst-signierte Zertifikat was du über GPO verteilst, brauchst du dann nicht mehr.
VG
Danke. Das würde jedoch bedeuten, dass Autodiscover dann erst einmal grundsätzlich in einen Fehler läuft, wenn er https://meinedomain.de/Autodiscover/Autodiscover.xml aufruft, da meinedomain.de intern auf den DC schaut. Ist das OK?
moin...
ist doch prima, dann stell dich die passenden zonen und eintrage im dns ein...
Frank
ist doch prima, dann stell dich die passenden zonen und eintrage im dns ein...
Frank
Ich glaube, ich weiß, was Du meinst, die passenden Zonen in dem Fall wären:
Für die Domainmitglieder muss meinedomain.de auf die IP des dc01 zeigen,
Für die Besucher muss meinedomain.de auf die IP der ex01 zeigen.
Meinst Du das so, dass sie einfach unterschiedliche Antworten vom DNS Server erhalten sollen? In diesem Fall müsste ich die MAC Adressen der Domainkandidaten registrieren, damit die in eine andere Zone kommen, richtig so?
Für die Domainmitglieder muss meinedomain.de auf die IP des dc01 zeigen,
Für die Besucher muss meinedomain.de auf die IP der ex01 zeigen.
Meinst Du das so, dass sie einfach unterschiedliche Antworten vom DNS Server erhalten sollen? In diesem Fall müsste ich die MAC Adressen der Domainkandidaten registrieren, damit die in eine andere Zone kommen, richtig so?
Nein, du machst es viel komplizierter als es ist.
Autodiscover testet verschiedene Optionen aus, um den Exchange Server zu finden und nimmt die Option, die als erste funktioniert.
Wenn autodiscover.domain.tld funktioniert, passt alles. Ein Eintrag für domain.tld ist nicht notwendig.
Noch paar Informationen
https://www.msxfaq.de/exchange/autodiscover/autodiscover_grundlagen.htm
https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementa ...
Autodiscover testet verschiedene Optionen aus, um den Exchange Server zu finden und nimmt die Option, die als erste funktioniert.
Wenn autodiscover.domain.tld funktioniert, passt alles. Ein Eintrag für domain.tld ist nicht notwendig.
- Alle Domains müssen von außen richtig erreichbar sein, also autodiscover.domain.tld und mail.domain.tld muss auf die externe IP-Adresse deines Anschlusses zeigen
- autodiscover.domain.tld und mail.domain.tld muss innerhalb deines Netzwerkes auf die interne IP-Adresse deines Exchange-Servers zeigen. Dazu erstellst du zwei Primäre-Zonen im DNS unter Forward-Lookup Zonen und als A-Record die IP deines Exchange.
- interne und externe URLs identisch setzen mit den Befehlen bzw. Skript von oben. Also einfach alles auf mail.domain.tld setzen
- Es funktioniert dann alles!
Noch paar Informationen
https://www.msxfaq.de/exchange/autodiscover/autodiscover_grundlagen.htm
https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementa ...
Viele Dank an Dich für Deine Geduld.
So hatte ich es anfangs, und auch gestern Abend wieder eingerichtet. Existierende Clients verbinden sich sauber.
Nur beim einrichten eines neuen Outlook Clients hackt es ständig. Es kommt immer die Passwortabfrage von O365 online. Wenn man diese abbricht, dauert es nochmal eine halbe Minute und mit etwas Glück kommt dann die Passwortabfrage vom lokalen Exchange Server. Mit etwas Pech kommt oft nochmal die Passwortabfrage vom O365 und man bricht immer wieder ab. Lösung laut maxfaq und frankysweb ist der Registry Eintrag, bei dem die online Prüfmethode ausgelassen wird. Auch das löschen aller Konten in der Anmeldeinformationsverwaltung bringt nichts.
Ich habe zwar keinen Schmerz damit meiner Familie eine .reg Datei zur Verfügung zu stellen, aber, ich dachte mir, das ist nicht im Sinne des Erfinders und es geht bestimmt auch etwas schöner. In der Arbeit klappt es ja auch mit neuen frischen Clients ohne irgendwas verstellen zu müssen. Und Outlook richtet das Postfach ein innerhalb von wenigen Sekunden ohne zu murren.
Also habe ich mir vorgenommen die erste Prüfmethode von Autodiscover zu ermöglichen, die der Exchange Connectivity Analyzer auch prüft, und das ist https://domain.tld/Autodiscover/Autodiscover.xml
Hat das evtl. noch was mit dem _autodiscover._tcp.domain.tld Eintrag zu tun? Den habe ich testweise auf autodiscover zeigen lassen, aber die Auswirkungen blieben die Gleichen.
So hatte ich es anfangs, und auch gestern Abend wieder eingerichtet. Existierende Clients verbinden sich sauber.
Nur beim einrichten eines neuen Outlook Clients hackt es ständig. Es kommt immer die Passwortabfrage von O365 online. Wenn man diese abbricht, dauert es nochmal eine halbe Minute und mit etwas Glück kommt dann die Passwortabfrage vom lokalen Exchange Server. Mit etwas Pech kommt oft nochmal die Passwortabfrage vom O365 und man bricht immer wieder ab. Lösung laut maxfaq und frankysweb ist der Registry Eintrag, bei dem die online Prüfmethode ausgelassen wird. Auch das löschen aller Konten in der Anmeldeinformationsverwaltung bringt nichts.
Ich habe zwar keinen Schmerz damit meiner Familie eine .reg Datei zur Verfügung zu stellen, aber, ich dachte mir, das ist nicht im Sinne des Erfinders und es geht bestimmt auch etwas schöner. In der Arbeit klappt es ja auch mit neuen frischen Clients ohne irgendwas verstellen zu müssen. Und Outlook richtet das Postfach ein innerhalb von wenigen Sekunden ohne zu murren.
Also habe ich mir vorgenommen die erste Prüfmethode von Autodiscover zu ermöglichen, die der Exchange Connectivity Analyzer auch prüft, und das ist https://domain.tld/Autodiscover/Autodiscover.xml
Hat das evtl. noch was mit dem _autodiscover._tcp.domain.tld Eintrag zu tun? Den habe ich testweise auf autodiscover zeigen lassen, aber die Auswirkungen blieben die Gleichen.
Moin...
wiso 2 exchange server?
Frank
Nur beim einrichten eines neuen Outlook Clients hackt es ständig. Es kommt immer die Passwortabfrage von O365 online.
mit etwas Glück kommt dann die Passwortabfrage vom lokalen Exchange Server.
äh.. was richten wir den wo ein?mit etwas Glück kommt dann die Passwortabfrage vom lokalen Exchange Server.
wiso 2 exchange server?
Frank
Ich habe im Moment nur einen Exchange Server. O365 habe ich nicht. Autodiscover versucht ständig automatisch zu O365 zu verbinden. Das Phänomen ist bekannt, siehe hier
https://www.frankysweb.de/exchange-2016-moegliche-ursachen-fuer-abfrage- ...
https://www.frankysweb.de/exchange-2016-moegliche-ursachen-fuer-abfrage- ...
