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:
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:
firma.de ist dann natürlich auch als akzeptierte Domain angelegt:
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:
Als Typ wird wieder “Primäre Zone” ausgewählt:
Die Zone wird auf allen DNS Server ausgeführt:
Als Zonenname wird “firma.de” angegeben:
Dynamische Updates können deaktiviert werden:
Nachdem der Assistent abgeschlossen wurde, gibt es nun eine DNS-Zone mit dem Namen “firma.de”:
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”:
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:
Nachdem der Eintrag angelegt wurde, ist auch www.firma.de zu erreichen:
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:
Im Assistenten muss “Dienstidentifizierung (SRV)” ausgewählt werden:
Für den SRV-Record gelten folgende Werte:
- Dienst: _autodiscover
- Protokoll: _tcp
- Portnummer: 443
- Host: autodiscover.FRANKYSWEB.de
Hinweis: Die Unterstriche müssen mit eingegeben werden!
So sieht es nach dem Anlegen des Eintrags aus:
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:
Danach kann in den DNS Einstellungen ein SRV-Record angelegt werden:
Für den SRV-Record sind die gleichen Einstellungen wie für den internen DNS vorzunehmen:
- 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:
Hans möchte ein E-Mail Konto einrichten:
Hans trägt seinen Namen, E-Mail Adresse und sein Passwort des ActiveDirectory Benutzerkontos ein:
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:
- 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:
Hans muss seine Active Directory Daten angeben:
Hans ist glücklich, ohne Zertifikatswarnungen:
Die Outlook Verbindung läuft nun wie für alle anderen Benutzer gegen den Server mail.frankysweb.de:
Da ein SRV Record gefunden wurde, funktioniert auch Autodiscover problemlos:
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:
Name und E-Mail Adresse wird automatisch ausgefüllt, das Passwort Feld existiert nicht:
Direkte Anmeldung an Exchange, ohne Abfrage von Benutzername und Kennwort und selbstverständlich ohne Zertifikatsfehler:
Auch hier laufen die Verbindungen gegen mail.frankysweb.de
Autodiscover funktioniert ebenfalls ohne Probleme:
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
Dieses Zertifikat muss nun auf allen Clients installiert werden:
Das Zertifikat sollte im Speicher für den Computer installiert werden, damit es nicht für jeden Benutzer einzeln installiert werden muss:
Das Zertifikat wird im Zertifikatsspeicher “Vertrauenswürdige Stammzertifizierungsstellen” installiert.
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.