If you would like to read the other parts in this article series please go to:
- Managing Certificates in Exchange Server 2013 (Part 1)
- Managing Certificates in Exchange Server 2013 (Part 3)
- Managing Certificates in Exchange Server 2013 (Part 4)
- Managing Certificates in Exchange Server 2013 (Part 5)
- Managing Certificates in Exchange Server 2013 (Part 6)
In the previous article we went over the process of choosing the certificate but for this article we will use a Public one. Now, we need to decide the names that we are going to use in our certificate to support our infrastructure.
We are going to use a simple scenario (Figure 01) that can be made more complex later on (by adding more servers, a DR site, etc.). Our initial scenario has a Domain Controller (BsADC01) and a single Exchange Server 2013 (BsAEX01) while our Active Directory has an FQDN named apatricio.local and the SMTP of the future users will be @AndersonPatricio.info.
So from now on, any time that you see AndersonPatricio.info you should replace it with your external domain name of your lab/environment.
Note:
It is a best practice to avoid a single point of failure which means that 2 (two) Domain Controllers and at least 2 (two) Exchange Servers in a DAG for a production environment.
Figure 01
Note:
If you do not have the Exchange Server 2013 in place yet, you can check this MSExchange.org article. This article gives all the steps required to deploy your server.
We are aware that Exchange Server 2013 comes with a self-signed certificate with the NetBIOS name of the computer and the FQDN. In our scenario the name on the self-signed certificate is:
- BsAEX01
- BsAEX01.apatricio.local
Well, we do know that those names are not going to fly with external clients and to simplify things we will be using only two entries in our future SAN/UC Certificate.
Using just two names, we can address all the requirements for the current environment. We will need a single name for all services (OWA, Outlook Anywhere, OAB, EWS and so forth) and another one for Autodiscover (there are a couple of methods to get that going but we use the easiest one which is creating an A record in DNS).
Our initial suggestion for this environment would be the following names:
- Autodiscover.AndersonPatricio.info
- Webmail.AndersonPatricio.info
The webmail can be replaced for any name that you use to access your OWA, however, the Autodiscover is not going to be used by the clients explicitly and since that one is hard coded in the Outlook discovery process we cannot do anything about it.
Now, that we are aware of the names to add in our new certificate we can start working on the technical side, to prepare our environment to support a Public Certificate and those two names.
In our decision to use just two names (AndersonPatricio.info instead of apatricio.local) you may have noticed that they are external names. The reason for that is that Public CA will not support internal names in the near future. However, such a change requires configuration in the internal DNS by creating a mirror of the Public Zone in our internal network. This configuration is also known as split-brain DNS.
Configuring the split-brain DNS…
Using this technique, we create an internal zone of our public domain name inside our network and after that, all clients will request information only for that zone which means that we must make sure that all records that we have on the internet are added to this new internal zone.
Let’s say you have an IIS in the internal network and you publish your institutional page on that server. The beauty of using split-brain is that when an internal computer goes to www.company.ca the IP used will be the internal one to access the server; when the same client goes to the internet and accesses the same address (www.company.ca) the page displayed will be the same but the IP address of the site will be the public one. The entire process is transparent for computers because the IP is only based on which DNS Server is being used by the client.
In our scenario our Active Directory domain is apatricio.local (and NetBIOS is APATRICIO) and when we open the DNS Server Manager (Figure 02) we have the following zones under Forward Lookup Zones.
Figure 02
Right-click on Forward Lookup Zones and click on New Zone… on the first page of the wizard (Figure 03), leave default settings and click Next.
Figure 03
On the Active Directory Zone Replication Scope page (Figure 04), we can define how this replication will work where the most common options are the first two: the first replicates to all DNS in the forest and the second option replicates to all DNS servers in the Domain. Click Next.
Figure 04
On the Zone Name page (Figure 05), type in the public name that in our case is AndersonPatricio.info and then click Next.
Figure 05
On the Dynamic Update page, by default the Dynamic Update is enabled however, we will restrict this zone to make sure that only manual entries will be entered by selecting Do not allow dynamic updates and then click Next. (Figure 06)
Figure 06
On the final page, just click Finish to complete the wizard and our new zone should be listed under Forward Lookup Zones. Click on View and then Advanced.
Note:
The last step allows the TTL information for any record to be shown in the graphical user interface.
Let’s create our first entry in our split-brain DNS, right-click on the zone that we have just created and click New Host…
In the new window, we are going to add first our webmail host pointing out to the Exchange Server 2013 IP address. We can also define the TTL (by default is 1 hour) and we may have to go back here when we increase the complexity of the environment by adding a DR site or something like that. Then, click Add host. A pop up displaying that the host record was created successfully will be displayed, just click OK (Figure 07).
Figure 07
Okay, we created the main A record for our Exchange Server deployment however, we have a split-brain DNS and any host that your internal users access from your public domain must be created here as well.
Before we go any further, create Autodiscover.AndersonPatricio.info pointing out to our Exchange Server 2013 as well. Even though this entry is not used by authenticated computers, it can be useful for ActiveSync devices in your internal Wi-Fi network and workstations that are not joined to the current Active Directory domain.
Now, you will need some time to complete your new zone however, I would like to point out a few hints before you start creating records. Bear in mind that when internal zone is mentioned we are referring to the split-brain DNS that we have just created that reflects your Public Domain zone.
- A good start before trying to remember what your users are using is to get a list of your Public DNS entries and start going over each entry and accommodating those in your internal zone
- MX records shouldn’t be added to your internal zone
- SPF and TXT records to validate services are not required in your internal DNS
- All internal servers that you published through your firewall to the Internet can have their internal IPs in the internal zone. This way your internal traffic doesn’t have to hit the external interface of your firewall
Time for testing! Just open command prompt and try ping webmail.AndersonPatricio.info and you should be receiving the IP address of your internal Exchange Server. If we go one-step further and try to access https://webmail.AndersonPatricio.info you will hit the server but a certificate error message will be displayed, as shown in Figure 08. Do not worry about the Certificate error at this point as we will tackle it in the upcoming articles of this series.
Figure 08
Managing UPN (User Principal Name)
That is not a requirement, however it can save time in the future when transition to Office365. By default, any new Active Directory will have only the FQDN as UPN (in our case APatricio.local) and the users can use two ways to authenticate which are: APATRICIO\name or name@apatricio.local when their authentication is requested.
However, if an external user using Outlook requires entering a username and password he/she probably will try the e-mail address instead of @apatricio.local. In order to create consistency for end-users we can add a UPN in Active Directory to support the SMTP address (or public domain).
In order to manage UPNs, we need to open Active Directory Domain and Trusts, and right-click on the first item on the left and then Properties. In the new window (Figure 09), type in the SMTP domain that will be used for the users and then click Add and OK.
Note:
Do not add @ in the UPN, it is just the domain name.
Figure 09
When creating a new user in Active Directory Users and Computers or even Exchange Admin Center, make sure that you configure the UPN properly for the user (Figure 10).
Figure 10
Managing Accepted Domains
A key point is that your users must have the domain that you are configuring in the new certificate, otherwise most of the tools that we are going to use will fail (especially when testing the autodiscover component).
In order to configure the SMTP to our end-users, the first step is to create an accepted domain in our Exchange Organization. Logged on Exchange Admin Center, click Mail flow, and then click accepted domains.
Click Add, and on the new page type in the name of the domain (without @) on both fields: Name and Accepted Domain and leave default settings for Authoritative domain and click save. The results will be similar to Figure 11.
Figure 11
Now that Exchange is able to handle traffic for the new domain that we created, we need to stamp the new SMTP address on our users. Click E-mail address policies and we should have just one entry called Default Policy, select it and click Edit, then click email address format and change the SMTP entry on the right side to use the new accepted domain that we have just created which matches our future new certificates. Click Save, where you may be asked to apply the new policy and if that is the case, back to the EAC page, select the Default Policy and hit Apply which is located on the right side, and confirm by clicking Yes when requested.
Figure 12
Now, any new user will receive the @AndersonPatricio.info as primary SMTP.
Conclusion
In this second article of this series, we focused on prerequisites to reduce the number of certificates and complexity in Exchange Server 2013. As part of this process we created a split-brain DNS, UPN configuration (to facilitate the authentication process) and accepted domains.
In the next article, we will be requesting the certificate for our environment and all steps involved with this task.
If you would like to read the other parts in this article series please go to:
