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.

Schreibe einen Kommentar

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