Using Auto Discover with large numbers of accepted domains

Introduction

One of the great benefits of using Subject Alternative Name (SAN) SSL certificates with Exchange is that you’re able to specify additional names on your certificate to cater for your Exchange needs, covering multiple domains.

But what if you’ve got a large number of accepted domains within your organization and don’t want to specify AutoDiscover records for these on your SAN certificate, or you’re regularly adding additional domains? Then you could take a leaf out of Office 365’s book and use a simple technique known as AutoDiscover Redirection to allow you to only need your core names on your SAN certificate.

In this two part article series, we’ll cover the various methods of performing AutoDiscover redirection – IIS, a Load Balancer or TMG, along with how to simplify the DNS changes necessary internally and externally. In this part we’ll quickly example the other options available and look at how to create and configure IIS for redirection.

Our Example Exchange Organization

For the context of this article, we’ll base our problem against a simple Exchange organization, consisting of two multi-role Exchange Servers, a load balancer and a TMG server for external access to the organization:

Figure 1: Example Exchange Organization

Both internally and externally, we’ve got an assortment of clients, using both domain-joined Outlook for Windows, along with Mac Outlook and Tablet Devices. We’re using split-DNS, a method of presenting a single consistent namespace to clients regardless of whether they’ll contact an internal IP address or an external IP address to access our Exchange organization; with internal clients accessing our Load Balancer and external client first accessing our Forefront Threat Management Gateway (TMG) 2010 server which is configured as a reverse proxy within the DMZ. All clients use the following HTTPS namespace to access Exchange Client Access servers:

• mail.exchangelabs.co.uk
• autodiscover.exchangelabs.co.uk

Additionally, we’ve configured a Client Access Array for RPC access, which is also load balanced, with the nameoutlook.exchangelabs.co.uk, which is only configured in the internal side of the split DNS configuration. Therefore we’ve been able to use just two names on our SAN certificate; just mail.exchangelabs.co.uk andautodiscover.exchangelabs.co.uk.

However, recent changes mean that the number of accepted domains used within Exchange has increased and will continue to increase as time goes on, and each of these accepted domains is used for primary email addresses for a proportion of users. So to maintain AutoDiscover functionality across the board, we’ve got a number of practical options:

1. Increase the number of subject alternative names on the certificate by replacing it or requesting the certificate vendor re-issue it, along with the addition of AutoDiscover DNS records for each domain.
2. Add a Service Location DNS record (SRV record) for each new domain, as described in KB12345.
3. Use AutoDiscover Redirection to provide a single point for HTTP redirect to our singleautodiscover.exchangelabs.co.uk HTTPS name.

In an ideal world, the first option is preferred and if the additional domain names are known or small in number it’s a straightforward solution that requires no additional configuration to work. However, if new domain names are added regularly, the organization doesn’t own those domains and just hosts another company’s email, or there’s a large number of additional domains, using this technique isn’t necessarily practical.

The second option, to use SRV records, seems at first glance the easiest– only DNS records are needed to make the AutoDiscover information to clients. There’s one major drawback to using SRV records however – although supported by Outlook, mobile clients such as Tablets and Smartphones have very little support.

This leaves us with option three, which is to use AutoDiscover Redirection. This technique allows the client to lookup the AutoDiscover DNS record as normal, and after attempting (and failing to connect) via HTTPS, the client will attempt to connect via standard HTTP.

Upon connecting via HTTP, a redirect is sent to the client advising it to attempt connection to our single AutoDiscover endpoint, https://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml instead.

Configuring the AutoDiscover redirection web site

To provide AutoDiscover Redirection, we’ll need to configure a HTTP-only web site or web listener on an IP address that’s not already providing HTTPS service. That means we can’t share the same internal or external IP address that Exchange’s HTTP namespaces such as mail.exchangelabs.co.uk and autodiscover.exchangelabs.co.uk already use.

We’ve got a number of options available for providing these services, and the one you choose depends on your environment and what resources you’ve got available:

1. A dedicated IIS website listening on it’s own IP address.
2. A new Virtual Server or Virtual IP address on a Load Balancer providing a simple redirect for all traffic on port 80, listening on an IP address that isn’t already providing HTTPS services.
3. A listener in TMG, again bound to an IP address that doesn’t provide HTTPS services, with a rule set to deny traffic and redirect it.

You might find that a combination of two of these techniques suits you; for example using a load balancer redirect internally and a TMG deny-redirect externally. In this section we’ll cover each one, starting with the IIS method in the first part of this article.

IIS Redirection

The IIS method is straightforward to configure and can be applied to either a local on-premises server, an additional IP address and web site within Exchange or even a Virtual Machine in Windows Azure.

As with all these suggested methods, the key thing we’ll need is to listen on an IP address that’s not being used for SSL traffic; otherwise AutoDiscover will attempt to connect to the SSL site first and likely fail due to certificate errors, and not continue. If it’s a fresh installation of IIS on a new server, this will be the default so further configuration isn’t necessary.

When installing IIS, we don’t need many additional components; if this will be dedicated to AutoDiscover redirection, then we won’t need components such as ASP.NET or Authentication. The key component to select during the installation of IIS is the URL Redirect module:

Figure 2: Selecting the HTTP Redirection IIS role service

After installation and configuration, we’ll then create an AutoDiscover subdirectory within the Default Web Site (or any other web site of your choosing), and then select this in the IIS Management Console, then choose HTTP Redirect:

Figure 3: Configuring HTTP Redirection for the AutoDiscover Virtual Directory

In the HTTP Redirect options, configure the following options:

• Redirect all requests to this destination: Configure this to your AutoDiscover URL, for examplehttps://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml
• Select the following checkboxes:
  • Redirect all requests to exact destination (instead of relative to destination)
  • Only redirect requests to content in this directory (not subdirectories)
• Choose the status code Found (302).

When you’re finished, choose Apply.

Finally, you might want to ensure that only requests to your correct full AutoDiscover DNS names are redirected; for example if this will be a multi-purpose web server then you might host other web sites alongside this one. We can do this by configuring the Bindings within IIS. To access this, right click the website (in our case Default Web Site) and select Edit Bindings:

Figure 4: Configuring Bindings for IIS

For each AutoDiscover DNS name, enter a separate host header entry bound to port 80:

Figure 5: Modifying the Host Header list for IIS

After configuring this optional step, requests to names other than those specified in the site bindings list will fail; so if it’s not strictly required for your environment (for example, you’ve used a dedicated IP address for the site, or even a dedicated server).