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.