This is the last part of the article series "Configuring certificates" for Exchange Server 2013 and Exchange 2016. The previous parts can be found here:
Note: This part also builds on part 1 and part 2, so please make sure you read the first two parts first.
This part deals with two topics, on the one hand the connection of further e-mail domains and on the other hand the points to be observed if an internal certification authority is used instead of public certificates.
Connection of further e-mail domains
To get straight to the point: The certificate does not need to be changed to connect additional e-mail domains.
In Part 2, the following certificate was issued and made usable for Exchange Server:
The names entered for the Exchange user interfaces (OWA, ActiveSync, EWS, MAPI) are mail.frankysweb.de and autodiscover.frankysweb.de for autodiscover. Accordingly, @frankysweb.de is used as the e-mail domain.
Let's assume that frankysweb.de and firma.de are to be used as e-mail domains. As you can see here, there is now a user with the e-mail address hans@firma.de:
firma.de is then of course also created as an accepted domain:
To make the domain firma.de accessible via Autodiscover, only changes to the DNS of the hoster and the internal DNS are necessary.
Customization of internal DNS server
Another DNS zone is created on the internal DNS server, i.e. normally on the domain controller:
"Primary zone" is again selected as the type:
The zone is executed on all DNS servers:
The zone name specified is "firma.de":
Dynamic updates can be deactivated:
After the wizard has been completed, there is now a DNS zone with the name "firma.de":
Attention: This is now a DNS split brain configuration. In concrete terms, this means that the DNS server is now authoritative for the firma.de zone for internal computers that use the internal DNS server. If internal clients now try to access www.firma.de, for example, the internal DNS server will respond with NXDOMAIN (non-existent domain, does not exist). The background is simple: The domain controller assumes that it is the boss for firma.de, since the zone firma.de does not contain any entries (e.g. www) as can be seen above, it responds with "Does not exist":
If it is www.firma.de is now a web server at the hoster that hosts the company website, then this server must be made known internally accordingly. Let's assume that the web server of the hoster has the IP 12.34.12.34, then a HOST-A entry is created in the firma.de zone:
Once the entry has been created, www.firma.de can also be accessed:
All external servers must now be entered in this way, for example store.firma.de, portal.firma.de or whatever else there may be.
Once all external resources have been entered, an Autodiscover entry can be created. The Autodiscover entry is an SRV record that can be created via "Other new entries":
In the wizard, "Service identification (SRV)" must be selected:
The following values apply to the SRV record:
- Service: _autodiscover
- Protocol: _tcp
- Port number: 443
- Host: autodiscover.FRANKYSWEB.de
Note: The underscores must also be entered!
This is what it looks like after creating the entry:
Put simply, we have now created a link that tells Outlook that autodiscover for company.com can be reached at autodiscover.frankysweb.com. Since autodiscover.frankysweb.de is present on the certificate, Outlook will accept the certificate as valid.
Any domains can be connected in this way. The certificate no longer needs to be touched.
Customization of external DNS (hoster)
The change described above is for the internal LAN. In order for Outlook Anywhere to work, an SRV record must also be created with the hoster. As the setup differs from hoster to hoster, here is only an example for Strato. The domain "exchange-tools.de" serves as an example here (let's just think of exchange-tools.de as firma.de):
If available, the hoster's own Autodiscover function must first be switched off:
An SRV record can then be created in the DNS settings:
The same settings must be made for the SRV record as for the internal DNS:
- Service: _autodiscover
- Protocol: _tcp
- Port: 443
- Destination: autodiscover.FRANKYSWEB.de
That was all. Now tests can follow.
Outlook Anywhere (client not a member of the Active Directory)
As mentioned at the beginning, I have created a user "Hans" with the e-mail address hans@firma.de. If Hans now wants to use Outlook on a PC that is NOT a member of the Active Directory, the setup is as follows:
Hans starts Outlook in the home office, for example:
Hans would like to set up an e-mail account:
Hans enters his name, e-mail address and password for the ActiveDirectory user account:
During configuration, Hans is now asked for his user name and password, in which case it is normal:
- The user name is not hans@firma.de but hans@frankysweb.local, only the e-mail address is hans@firma.de:
- Outlook cannot pass login information because the PC is not in the ActiveDirectory and Hans is a local user
- Hans must therefore enter his login details and is therefore asked:
Hans must enter his Active Directory data:
Hans is happy, without certificate warnings:
The Outlook connection now runs against the server mail.frankysweb.de as for all other users:
Since an SRV record was found, Autodiscover also works without any problems:
Outlook within the Active Directory
For comparison, here is the setup of Outlook when Hans uses a PC that is a member of the Active Directory and Hans has logged in with his user account:
Name and e-mail address are filled in automatically, the password field does not exist:
Direct logon to Exchange, without requesting a user name and password and of course without certificate errors:
Here, too, the connections run against mail.frankysweb.de
Autodiscover also works without any problems:
Use of an internal certification authority
I have already described how to set up your own certification authority in detail here and the HowTo is also valid for Exchange 2016, so I will not describe the configuration again here:
https://www.frankysweb.de/exchange-2013-san-zertifikat-und-interne-zertifizierungsstelle-ca/
However, there are a few points to bear in mind:
In the article above, an internal certification authority is set up; this certification authority generates the certificate itself. The certification authority therefore has a self-issued certificate. Here again is the comparison with the ID card and the authority: The certification body claims it is a state/authority and issues corresponding ID cards (certificates). The question now is who accepts the ID cards and the authority? Within the Active Directory, the certificate of the certification authority is automatically distributed by group policy, so all Active Directory members see the certification authority as a trusted authority. All clients that are not members of the Active Directory (smartphones, possibly HomeOffice, etc.) do not know the authority and therefore do not see it as trustworthy, the ID cards are therefore also not trustworthy: certificate error.
Either you make sure that the certificate of the certification authority is installed on all clients, which can be quite a lot of work for clients outside the Active Directory (PCs in the home office, smartphones, notebooks, etc.), or you invest a little money directly in a corresponding certificate from a public certification authority. I would recommend the public certificate.
If you also want to make the internal certification authority trustworthy on clients, you must install the root certification authority certificate of your own certification authority on the clients.
Installation of the root certification authority certificate under Windows
The root certification authority certificate is located on the certification authority in the following folder:
C:\Windows\System32\CertSrv\CertEnroll
This certificate must now be installed on all clients:
The certificate should be installed in the memory for the computer so that it does not have to be installed individually for each user:
The certificate is installed in the "Trusted root certification authorities" certificate store.
Note: The Exchange Server certificate issued by this certification authority does NOT have to be installed. All certificates issued by the installed certification authority are accepted. Provided, of course, that the names and expiration dates are correct.
By the way: Firefox has its own certificate store and does not access the Windows certificate store. The certificate must be imported separately here.
Hallo Frank,
leider hat wohl Microsoft im Exchange 2016 Cu23 die Möglichkeit zur Erstellung eines Zertifikat Request entfernt.
Es kann jetzt nur noch ein Selbstsignierten Zertifikat über die Admin Webseite erstellt werden.
Anscheinend geht es jetzt nur noch über die Powershell.
Viele Grüße HD
Hallo Franky,
vielen vielen Dank für deine umfangreichen Artikel. Sie sind für mich in vielen Fällen der Erste Anlaufpunkt bei Fragen/Problemen geworden!
Ich habe einen Kunden der (gegen meine Empfehlung) kein Split-DNS einrichten will, weil er ein sehr kompliziertes DNS-Setup (viele DNS-Zonen etc.) hat. Er behandelt das wie seinen Augapfel…
Nun hatten wir einen mehrstündigen Ausfall des Exchange-Servers und das fehlende Split-DNS erschwert die Fehlersuche extrem – man weiß ja nie, welche Folgen letztendlich diese abweichende Konfiguration haben kann.
Meine Idee war, einen Wildcard A-Record zu setzen, der alle Anfragen zur Zone zum DNS-Server des Hosters schickt und nur die anfragen zum Exchange-Server direkt beantwortet. Nach einigem suchen habe ich einen Artikel dazu gefunden:
https://www.itgeared.com/articles/1037-configuring-wildcard-dns-records/
Im MS-Forum wird auch davon berichtet:
https://social.technet.microsoft.com/forums/windowsserver/en-US/75118b80-1031-46c5-bcde-0377ea01569c/dns-wildcard
An sich raten diese davon aber ab…was hältst du davon?
Hallo,
das Zertifikat im Tutorial beinhaltet ja auch beide Domänen: mail. und autodiscover.
Wenn bei dir für „autodiscover.deinedomain.de“ kein Zertifikat vorliegt, wird es wohl auch immmer eine Warnung geben.
Ich verwende deshalb immer ein Wildcard-Zertifikat (*.deinedomain.de).
Dann sind mit einem Zertifikat alle Subdomänen immer korrekt zertifiziert.
Damit kann man dann auch andere Weiterleitungen absichern, wie z.B. vpn.deinedomäne.de, sophos.deinedomäne.de, usw.
Das erspart einem viel Zertifikats-Wirrwarr.
Gruß,
Andreas
Hallo Andreas,
danke für deine Info aber das Zertifikat selbst ist nicht das Problem, ich habe ein Wildcard.
Das Problem ist das Outlook beim Autodiscover die Umlenken erkennt:
– test@anderedomain.de wird im Outlook eingerichtet
– autodiscover.anderedomain.de (ohne zert) verweisst auf autodiscover.hauptdomain.de (mit wildcart)
Wenn ich dann bestätige, dass mein Autodiscover auf eine andere Domain verweisst,.. dann läuft es ohne Zertifikat Fehler. Der umgelengte FQDN passt dann zum Namen des Zertifikats
Drum sagte ich ja, ich finde die Meldung schon logisch,…
Da sie aber im Artikel keine Erwähnung findet, frage ich mich ob es auch ohne diese Meldung geht.
Hallöle,
erstmal vorweg, die ganze Seite mit all ihren Inhalten ist ein Traum.
Dieser Artikel war sehr Hilfreich und kam mir sehr gelegen, da wir für unseren MSP Hosted Exchange vermeiden wollen, das jede Domain ihr eigenes Zertifikat braucht. Leider hat es noch nicht so ganz geklappt.
Alle Clients kommen nur von Extern, drum hab ich mir die DNS Einträge auf dem internen DC gespart.
Nach dem ich nun beim Hoster alle Standard Einträge gelöscht habe und nur die autodiscover umlenkung drin gelassen habe, klappt dieses zumindest, …
Trotzdem kommt bei der Einrichtung vom Outlook der Sicherheitshinweis, dass autodiscover auf einen anderen fqdn verweist, ob man diesem zustimmen möchte. Dieses Verhalten wurde hier im Artikel nur beschrieben wenn ich bei den virtuellen Verzeichnissen den FQDN für autodiscover anpassen würde, was ich nicht gemacht habe.
Daher bin ich nun verunsichert ob ich was falsch gemacht habe, oder hier in dem sonst perfekten Artikel nur der kleine Hinweis fehlt, dass man bei Nutzung mehrerer Domains mit nur einem Zert. mit dieser kleinen Einschränkung leben muss. Logisch wäre es, wenn es zu umgehen ist, wäre aber noch besser. Danke vorab
Super kompetente und verständliche Hilfe auf dieser http://www.frankysweb.de
DANKE, DANKE, DANKE !!!
Hat mir schon öfter das arbeiten erleichtert!
Hallo,
meine Idee macht aber auch keinen Sinn, da ich ohne VPN keine Mails abholen kann.
Also geh ich intern nicht über den Proxy normalerweise. Der Haken bei „Proxy für lokalen Datenverkehr umgehen“ ist auch überall an den Clients gesetzt.
Gruß Jan
Hallo Frank,
der ExChange wurde von einem anderen EDV-Betreuer eingerichtet. Die Zertifikate dienen nur dem Aufruf über Autodiscover.
Ein Proxy wird nur benötigt für den Mailverkehr nach außerhalb.
Ich schaue gerade in meinem Outlook bei „Informationen“. Dort steht Zugriff auf dieses Konto nur über https://autodiscover.***.de. Liegt der Fehler da? Das Outlook zuerst nach außen geht und dann zurück? Weil es immer über den autodiscover geht?
Gruß Jan
Hallo Frank,
ich habe eine Frage zu den Zertifikaten.
Unser altes SSL-Zertifikat ist abgelaufen. Ich hab anstatt auf Erneuern zu klicken ein neues Erstellt….
Habe die Schritte befolgt und das Zertifikat befindet sich nun auch im ExChange mit dem Status gültig. Das alte abgelaufene Zertifikat habe ich gelöscht. Auch sind die Dienste zugewiesen wie bei dem anderen Zertifikat. Den Standard habe ich auch überschrieben.
Trotzdem meldet mir jeder Outlook Client das das Zertifikat abgelaufen ist. Schaue ich in die Details, wird mir das alte Zertifikat angezeigt (welches ich nicht erneuert habe).
Die Bindungen im IIS habe ich auch kontrolliert und angepasst.
Hast du vielleicht noch eine Idee?
Hallo Jan,
wird dir das neue Zertifikat angezeigt wenn du auf dem Exchange Server https://localhost aufrufst? Kann es sein, dass die Clients die Verbindung über einen Proxy oder Loadbalancer herstellen?
Gruß,
Frank
Ganz herzlichen Dank für dieses ausführliche Lehrmittel, endlich die ganzen Geschichten im Kontext.
Hallo Frank,
sehr schöne Anleitung einer kompletten Exchange Installation und Einrichtung, nicht nur für das Thema Zertifikate. Sehr umfassend und hilfreich, danke dafür.
Ich hab eine Frage zum „Default Frontend“-Empfangsconnector. Das fehlt irgendwie bei Deinen How-tos bzw. passt es gut rein. FQDN für HELO/EHLO sollte am Besten eigentlich auch der MX-Record sein, oder?(mail.domain.tld bzw. mail.frankysweb.de)?
Da dies heisst, dass man die Exchange-Serverauthentifizierung im Connector abschalten muss, empfiehlt sich für den Internetempfang ein neuer Frontend-Connector für anonym und TLS sowie setzen im „Default Frontend“ auf internen IP-Adressbereich?
Hallo Frank,
soeben ist mir selbst aufgefallen, was ich übersehen habe:
In Szenario1 habe ich in der Forward-Lookup-Zone im internen DNS auch einen SRV-Eintrag für Autodiscover gesetzt.
In Szenario2 hatte ich den vergessen.
SRV-Eintrag für Autodiscover in Zone „exchange.szene2.de“ erstellt — Fehler weg!!
Schön, dass wir darüber gesprochen haben. ;-)
Hallo Frank,
erstmal großes Lob für deine Seite!
Hat mir schon wirklich oft weitergeholfen.
Jetzt habe ich hier aber ein Zertifikatsproblem, das ich nicht ganz verstehe:
Ich habe 2 (fast) identische Exchange-Umgebungen:
Szenario1: Exchange 2013 mit SSL-123-Zertifikat von Thawte.
Das Zertifikat läuft auf exchange.szene1.eu (interne Domäne ist „ganzwasanderes.local“)
Hierfür gibt es auch eine Forward-Lookup-Zone im lokalen DNS.
Extern habe ich einen Host A-Eintrag der auf die externe IP-Adresse zeigt.
Für Autodiscover habe ich keine interne DNS-Zone, sondern nur einen SRV-Eintrag beim Provider.
( _autodiscover._tcp IN SRV 0 0 443 exchange.szene1.eu. )
Funktioniert tadellos.
Szenario2: Exchange 2016, [interne Domäne ist „ad.szene2.de“ (da bin ich deiner Empfehlung gefolgt)]
aber ansonsten gleiches Setup:
Zertifikat auf exchange.szene2.de / interne Forward-Lookup-Zone / Host A und SRV extern.
Hier bekomme ich im Outlook nun immer eine Fehlermeldung für „autodiscover.szene2.de“:
„Der Name auf dem Sicherheitszertifikat stimmt nicht mit dem Namen der Webseite überein“
Stimmt natürlich, denn das Zertifikat lautet ja auf exchange.szene2.de – nicht auf autodiscover.szene2.de.
In deinem Beispiel löst du das über die zusätzliche SAN-Domain.
Das wird für die SSL-123-Zertifikate aber nicht angeboten.
Ist in Szenario1 aber auch nicht erforderlich und funktioniert trotzdem.
In Szenario2 kriege ich den Fehler einfach nicht weg.
Was habe ich übersehen??
Vielen Dank im Voraus.
Hallo Frank,
bei meinem Provider kann ich autodiscover nicht deaktivieren und habe mir mit einem CNAME Eintrag geholfen.
D.h. ich habe autodiscover.meine-firma.COM und E-Mail-Adressen mail@meine-firma.DE.
CNAME autodiscover.meine-firma.DE auf autodiscover.meine-firma.COM
Jetzt bräuchte ich wohl doch einen weiteren Namen auf dem Zertifikat damit ich keine Warnung bekomme.
Der naive Versuch die Namen einfach zusätzlich einzutragen ist gescheitert.
Hast Du eine Idee?
Viele Grüße
Erik
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
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
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.
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
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
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
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
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
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.