Exchange 2016: Zertifikate konfigurieren (Teil 3)

Dies ist der letzte Teil der Beitragsserie “Zertifikate konfigurieren” für Exchange Server 2013 und Exchange 2016. Die vorherigen Teile finden sich hier:

Hinweis: Auch dieser Teil baut auf Teil 1 und Teil 2 auf, also bitte unbedingt vorher die ersten beiden Teile lesen.

In diesem Teil geht es um zwei Themen, zum einen die Anbindung weiterer E-Mails Domänen und zum anderen die Punkte die zu beachten sind , wenn eine interne Zertifizierungsstelle anstatt öffentlicher Zertifikate genutzt wird.

Anbindung weiterer E-Mail Domänen

Um es direkt vorweg zu nehmen: Für das Anbinden weiterer E-Mail Domänen, muss das Zertifikat nicht geändert werden.

In Teil 2 wurde das folgende Zertifikat für Exchange Server ausgestellt und nutzbar gemacht:

image

Als Namen wurden mail.frankysweb.de für die Exchange Benutzerschnittstellen (OWA, ActiveSync, EWS, MAPI) eingetragen und für Autodiscover der Name autodiscover.frankysweb.de. Als E-Mail Domain wird entsprechend @frankysweb.de verwendet.

Nehmen wir mal an, dass neben frankysweb.de und auch firma.de als E-Mail Domain genutzt werden soll. Wie hier zu sehen, gibt es jetzt einen Benutzer mit der E-Mail Adresse hans@firma.de:

image

firma.de ist dann natürlich auch als akzeptierte Domain angelegt:

image

Um die Domain firma.de entsprechend auch per Autodiscover erreichbar zu machen sind nur Änderungen am DNS des Hosters und am internen DNS nötig.

Anpassung interner DNS Server

Am internen DNS Server, also normalerweise auf dem Domain Controller, wird eine weitere DNS Zone erstellt:

image

Als Typ wird wieder “Primäre Zone” ausgewählt:

image

Die Zone wird auf allen DNS Server ausgeführt:

image

Als Zonenname wird “firma.de” angegeben:

image

Dynamische Updates können deaktiviert werden:

image

Nachdem der Assistent abgeschlossen wurde, gibt es nun eine DNS-Zone mit dem Namen “firma.de”:

image

Achtung: Hierbei handelt es sich jetzt um eine DNS-Split Brain Konfiguration. Das heißt konkret, der DNS Server ist jetzt für interne Rechner, die den internen DNS Server nutzen für die Zone firma.de authorativ. Versuchen jetzt interne Clients beispielsweise www.firma.de aufzurufen, wird der interne DNS Server mit NXDOMAIN (non existent Domain, gibts nicht) antworten. Der Hintergrund ist einfach: Der Domain Controller geht davon aus, das er der Chef für firma.de ist, da die Zone firma.de wie oben zu sehen keine Einträge enthält (Beispielsweise www) antwortet er mit “Gibt’s nicht”:

image

Wenn es sich bei www.firma.de nun um einen Webserver beim Hoster handelt der die Firmenwebsite hostet, dann muss dieser Server entsprechend intern bekannt gemacht werden. Nehmen wir an, der Webserver des Hosters hat die IP 12.34.12.34, dann wird nun ein HOST-A Eintrag in der Zone firma.de angelegt:

image

Nachdem der Eintrag angelegt wurde, ist auch www.firma.de zu erreichen:

image

Auf diese Weise müssen nun alle externen Server eingetragen werden, beispielsweise shop.firma.de, portal.firma.de oder was es sonst noch geben mag.

Wenn alle externen Ressourcen eingetragen wurden, kann ein Autodiscover Eintrag angelegt werden. Bei dem Autodiscover Eintrag handelt es sich um einen SRV-Record, dieser kann über “Weitere neue Einträge” angelegt werden:

image

Im Assistenten muss “Dienstidentifizierung (SRV)” ausgewählt werden:

image

Für den SRV-Record gelten folgende Werte:

  • Dienst: _autodiscover
  • Protokoll: _tcp
  • Portnummer: 443
  • Host: autodiscover.FRANKYSWEB.de

 

image

Hinweis: Die Unterstriche müssen mit eingegeben werden!

So sieht es nach dem Anlegen des Eintrags aus:

Zertifikate

Vereinfacht gesagt haben wir jetzt einen Verweis angelegt, der Outlook mitteilt, dass Autodiscover für firma.de unter autodiscover.frankysweb.de zu erreichen ist. Da autodiscover.frankysweb.de auf dem Zertifikat vorhanden ist, wird Outlook das Zertifikat als gültig akzeptieren.

Auf diese Art und Weise lassen sich beliebige Domains anbinden. Das Zertifikat muss nicht mehr angefasst werden.

Anpassung externer DNS (Hoster)

Die Änderung, wie oben beschrieben, ist für das interne LAN. Damit auch Outlook Anywhere funktioniert, muss ebenfalls ein SRV-Record beim Hoster angelegt werden. Da sich hier die Einrichtung wieder von Hoster zu Hoster unterscheidet, gibt es hier nur ein Beispiel für Strato. Als Beispiel dient hier die Domain “exchange-tools.de” (Denken wir uns einfach exchange-tools.de ist firma.de):

Wenn vorhanden, muss zunächst die Hoster eigene Autodiscover Funktion abgeschaltet werden:

image

Danach kann in den DNS Einstellungen ein SRV-Record angelegt werden:

image

Für den SRV-Record sind die gleichen Einstellungen wie für den internen DNS vorzunehmen:

image

  • Service: _autodiscover
  • Protokoll: _tcp
  • Port: 443
  • Ziel: autodiscover.FRANKYSWEB.de

 

Das war schon alles. Jetzt können Tests folgen.

Outlook Anywhere (Client nicht Mitglied im Active Directory)

Wie eingangs erwähnt, habe ich einen Benutzer “Hans” mit der E-Mail Adresse hans@firma.de angelegt. Wenn Hans nun Outlook auf einem PC nutzen möchte, der NICHT Mitglied des Active Directory ist, dann läuft die Einrichtung wie folgt ab:

Hans startet Outlook beispielsweise im Home Office:

image

Hans möchte ein E-Mail Konto einrichten:

image

Hans trägt seinen Namen, E-Mail Adresse und sein Passwort des ActiveDirectory Benutzerkontos ein:

image

Bei der Konfiguration wird Hans jetzt nach seinem Benutzernamen und Kennwort gefragt, in dem Fall ist es normal:

  • Der Benutzername ist nicht hans@firma.de sondern hans@frankysweb.local, Nur die E-Mail Adresse ist hans@firma.de:
  • image
  • Outlook kann keine Anmeldeinformationen durchreichen, denn der PC befindet sich nicht im ActiveDirectory und Hans ist ein lokaler Benutzer
  • Hans muss also seine Anmeldedaten angeben und wird daher gefragt:

Konfiguration von Zertifikaten

Hans muss seine Active Directory Daten angeben:

image

Hans ist glücklich, ohne Zertifikatswarnungen:

image

Die Outlook Verbindung läuft nun wie für alle anderen Benutzer gegen den Server mail.frankysweb.de:

image

Da ein SRV Record gefunden wurde, funktioniert auch Autodiscover problemlos:

image

Outlook innerhalb des Active Directory

Zum Vergleich hier noch einmal die Einrichtung von Outlook wenn Hans einen PC nutzt der Mitglied des Active Directory ist und Hans sich mit seinem Benutzerkonto angemeldet hat:

image

Name und E-Mail Adresse wird automatisch ausgefüllt, das Passwort Feld existiert nicht:

image

Direkte Anmeldung an Exchange, ohne Abfrage von Benutzername und Kennwort und selbstverständlich ohne Zertifikatsfehler:

image

Auch hier laufen die Verbindungen gegen mail.frankysweb.de

image

Autodiscover funktioniert ebenfalls ohne Probleme:

image

Nutzung einer internen Zertifizierungsstelle

Die Einrichtung einer eigenen Zertifizierungsstelle habe ich hier bereits detailliert beschrieben und das HowTo ist ebenfalls für Exchange 2016 gültig, daher spare ich mir an dieser Stelle noch einmal die Konfiguration zu beschreiben:

https://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/

Es gibt allerdings ein paar Punkte zu beachten:

Im oben angegebenen Artikel wird eine interne Zertifizierungsstelle eingerichtet, diese Zertifizierungsstelle generiert sich das Zertifikat selbst. Die Zertifizierungsstelle verfügt also über ein selbst ausgestelltes Zertifikat. Hier ist wieder der Vergleich mit dem Ausweis und der Behörde: Die Zertifizierungsstelle behauptet sie wäre ein Staat/Behörde und stellt entsprechende Ausweise (Zertifikate) aus. Die Frage ist nun wer akzeptiert die Ausweise und die Behörde? Innerhalb des Aktive Directory wird das Zertifikat der Zertifizierungsstelle per Gruppenrichtlinie automatisch verteilt, somit sehen alle Active Directory Mitglieder die Zertifizierungsstelle als vertrauensvolle Behörde an. Alle Clients die nicht Mitglied es Active Directory sind (Smartphones, ggf. HomeOffice, etc) kennen die Behörde nicht und sehen sie daher auch als nicht vertrauenswürdig an, die Ausweise sind damit ebenfalls nicht vertrauenswürdig: Zertifikatsfehler.

Entweder man sorgt nun dafür, dass das Zertifikat der Zertifizierungsstelle auf allen Clients installiert wird, was bei Clients ausserhalb des Active Directory (PCs im HomeOffice, Smartphones, Notebooks, etc) ziemlich viel Arbeit machen kann, oder man investiert direkt ein bisschen Geld in ein entsprechendes Zertifikat einer öffentlichen Zertifizierungsstelle. Ich würde zum öffentlichen Zertifikat raten.

Wer die interne Zertifizierungsstelle auch auf Clients vertrauenswürdig machen möchte, muss das Stammzertifizierungsstellenzertifikat seiner eignen Zertifizierungsstelle auf den Clients installieren.

Installation des Stammzertifizierungsstellenzertifikats unter Windows

Das Stammzertifizierungsstellenzertifikat befindet sich auf der Zertifizierungsstelle im folgenden Ordner:

C:\Windows\System32\CertSrv\CertEnroll

image

Dieses Zertifikat muss nun auf allen Clients installiert werden:

image

Das Zertifikat sollte im Speicher für den Computer installiert werden, damit es nicht für jeden Benutzer einzeln installiert werden muss:

image

Das Zertifikat wird im Zertifikatsspeicher “Vertrauenswürdige Stammzertifizierungsstellen” installiert.

image

Hinweis: Das Zertifikat des Exchange Servers welches von dieser Zertifizierungsstelle ausgestellt wurde, muss NICHT installiert werden. Alle Zertifikate die von der installierten Zertifizierungsstelle ausgestellt werden, werden akzeptiert. Sofern natürlich die Namen und das Ablaufdatum stimmen.

Übrigens: Firefox bringt seinen eignen Zertifikatsspeicher mit und greift nicht auf den Windows Zertifikatsspeicher zu. Hier muss das Zertifikat gesondert importiert werden.

9 Replies to “Exchange 2016: Zertifikate konfigurieren (Teil 3)”

  1. Anstelle von „firma.de“ als interne Zone anzulegen kann man auch „_tcp.firma.de“ als interne Zone anlegen. Das spart das Anlegen und Pflegen der externen Adressen wie „www.firma.de“. Das Anlegen des „_autodiscover“-SRV-Records ist über die GUI etwas tricky. Man muss, obwohl man schon innerhalb von „_tcp“ ist, dennoch „_tcp“ und „_autodiscover“ eintippen, genau wie im Screenshot oben.

  2. Hallo, vielen Dank für diese tolle(n) Anleitung(en)!

    Ich habe bisher alles erfolgreich nachvollziehen können, stocke jetzt aber bei dem Schritt der Zertifikatinstallation auf dem Exchange.
    Da ich mir ein Wildcard-SSL-Zertifikat besorgt habe für meine Domain, kann ich vom Exchange heraus jetzt natürlich keine CSR erstellen – denn wer soll mir dafür ein Zertifikat ausstellen – ich habe ja ein Zertifikat. Gibt es hier auch eine Trick wie man solch ein Zertifikat importieren kann?

    Danke und weiter so!
    Daniel

  3. Hi Daniel,

    du kannst das vorhandene Zertifikat direkt in der GUI importieren und brauchst es dann nur noch den Diensten zuweisen. Die URLs musst du natürlich trotzdem konfigurieren.
    Gruß, Frank

  4. Hallo Frank,

    tolles „HowTo“ (alle 3 Artikel). Ich habe bei mir je einen Server 2016 als DC und als Exchange Server aufgesetzt und eine Domäne angelegt. Dann Exchange 2016 CU5 installiert und nach verschiedensten Artikeln aus Deinem Blog konfiguriert.

    DNS, Autodiscover usw. funktioniert hervorragend, Ich habe eine feste IP und habe mir ein SSL-Zertifikat der vorgeschlagenen Zertifizierungsstelle gekauft und auf dem Exchange nach Deiner Anleitung eingebunden.

    Auf meinem Notebook habe ich Outlook 2016 per Mapi over HTTP per Autodiscover eingerichtet und der Zugriff auf mein Exchange-Konto funktioniert ebenfalls. Auch OWA klappt sowohl intern als auch extern.

    So weit so gut. Was ich aber partout nicht hinbekomme, ist die Anbindung meines iPhones und meines iPads.

    Wenn ich auf den Geräten einen neuen Account einrichte und „Exchange“ wähle, dann werde ich nach der email-Adresse gefragt. Ich gabe diese ein und das iPhone/iPad sollte anhand des Domainnamens per Autodiscover den Exchange finden. Nachdem ich weiter gedrückt habe, soll ich das Passwort eingeben. Wenn ich das dann gemacht habe, dauert es ziemlich lange und dann werden alle Parameter wie z.B. Server, Benutzer usw. abgefragt.

    Das zeigt mir, daß Autodiscover nicht funktioniert hat.

    Wenn ich also nun alle Daten manuell eingebe und „Weiter“ drücke, dann erscheinen hinter allen Einträgen blaue Haken und der Account ist angelegt. Scheinbar klappt die Kommunikation mit dem Exchange.

    Wenn ich aber die Apple-Mail-App starte und auf den Account gehe, dann bekomme ich die Fehlermeldung: „E-Mails können nicht empfangen werden. Die Verbindung mit dem Server ist fehlgeschlagen“.

    Hast Du, oder ein Mitleser, eine Idee, woran das liegen könnte?

    Gruß
    Christoph

  5. Hallo,

    noch eine Ergänzung:

    Ich habe den „MS Remote Connectivity Analyzer“ mal durchlaufen lassen. Und der sagte mir, daß das Intermediate-Zertifikat fehlt.
    Ich habe von Geotrust eins mitbekommen, aber nicht installiert, da Frank dieses auch nicht beschrieben hatte.
    Scheinbar muß das installiert werden…. Wenn ja, wie?

    Vielen Dank im voraus

    MfG
    Christoph

  6. Hi Christoph,
    das Intermediate Zertifikate kannst du in den Zertifikatsspeicher „Zwischenzertifizierungsstellen“ des Exchange Servers ablegen. Somit wird es dann auch durch den IIS Server ausgeliefert, dies wird jedoch nicht dein Problem mit ActiveSync lösen, kann es sein, dass du versuchst mit einem Konto welches Domain Admin Rechte hat eine ActiveSync Verbindung herzustellen? Wenn ja, dann schau mal hier:
    https://www.frankysweb.de/exchange-2010-sp1-ereignis-1053-im-event-log-msexchange-activesync/
    Gruß, Frank

  7. Hallo Frank,

    jepp, gerade herausgefunden. Vielen Dank für den Hinweis.

    Mein Benutzerkonto war Mitglied der Domänen-Admins. Die Mitgliedschaft habe ich aufgelöst. Danach ging es immer noch nicht. Ich mußte in meinem Benutzerkonto unter Sicherheit noch die Vererbung „nach unten“ einschalten.

    Nun geht’s :-).

    Bzgl. des Intermediate-Zertifikats bin ich auch weiter. Ich habe eine Sophos UTM 9.4 im Einsatz und habe als Webserver den Exchange definiert. Dann noch einen virtuellen Webserver, der auf Port 443 hört und dieses an den Webserver weiterleitet. Da wird scheinbar etwas verschluckt.

    Wenn ich eine DNAT-Regel definiere, daß Port 443 direkt an den Exchange weitergeleitet wird, dann kommt die Fehlermeldung nicht mehr. Da muß ich mal schauen, was da klemmt.

    Oder hast Du dazu auch schon eine Lösung ;-) ?

    Gruß
    Christoph

    Vielen Dank dafür.

  8. Hallo Frank,

    so, habe Deine Erläuterungen zur Sophos gefunden und so umgesetzt. Der Fehler mit den Intermediate-Zertifikaten über die WAF ist nun weg ;-). Auch der MS Connectivity Analyzer läuft fast sauber durch. Er meckert die autodiscover.xml an, aber nicht als „roten“ Fehler sondern als Hinweis.

    Ich habe aber noch ein kleines Problem. OWA von intern überhaupt kein Problem. Wenn ich allerdings von extern (iPhone) die Webseite https://mail.klahn.net aufrufe, dann kommt folgende Fehlermeldung:
    „Request blocked
    The web application firewall has blocked access to / for the following reason:
    No signature found“

    Die gleiche Meldung sehe ich im Live-Protokoll der UTM bei den virtuellen Webservern.

    Hättest Du da eine Idee?

    Gruß
    Christoph

  9. Hallo Frank,

    so, auch hier gehts nun. Ich hatte einen Fehler in den Entry Urls bei der Firewall-Regel für die Webservices gehabt.

    Besten Dank für alles.

    Gruß
    Christoph

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.