Using AutoDiscover with large numbers of accepted domains (Part 2)

If you would like to read the first part in this article series please go to Using AutoDiscover with large numbers of accepted domains (Part 1).

Introduction

In the first part of this article, we looked at why AutoDiscover Redirection can be useful if you’ve got a growing number of domains, or just a large number of domains and want to maintain great client compatibility for AutoDiscover without having a large number of domain names on your SAN certificate. We also looked at the first method to configure this server-side, by using an IIS website with HTTP redirection configured.

In the final part of this series, we’ll look at the other options available for configuring AutoDiscover redirection, by using a Load Balancer and Forefront TMG. We’ll then look at how to configure the external DNS records, along with internal PinPoint DNS zones that avoid a full split-DNS implementation.

Configuring the AutoDiscover redirection web site continued…

Load Balancer Redirection

Our second method of AutoDiscover Redirection is ideal if you’ve already got a Load Balancer in place, as on most load balancers the configuration required is minimal. For this example, we’ll be using a KEMP load balancer to configure a new Virtual IP address and service bound to port 80 only, and configure it to perform the HTTP redirect.

First, we’ll log in to the KEMP Configuration web interface, then navigate to Virtual Services and choose Add New. Next, we’ll add a new IP address and set the port to listen to, to port 80:

Figure 6: Creating a new Virtual Service for Redirection

Next, after creating the new virtual service, we’ll modify it’s properties to add the AutoDiscover redirect, as shown below:

Figure 7: Configuring Redirection options

The settings that need to be configured are located under the Not Available Redirect Handling section. Similar to the IIS configuration, we’ll configure the settings as follows:

• Error code: 302 Found
• Redirect URL: Your AutoDiscover URL, for example https://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml

After completing these settings, the Load Balancer configuration is complete – we don’t need to add any servers to perform load balancing for, as this redirect is handled within the Load Balancer itself.

We don’t have the fine-grained control available we had with IIS; however it’s a great compromise that can make use of existing hardware already in place.

Forefront Threat Management Gateway Redirection

Our final method of redirection is particularly suitable for clients accessing the Exchange organization via an existing Forefront TMG server or array.

To use this method of redirection, the most important thing we need is an external IP address bound to the TMG server that currently doesn’t listen on HTTPS, port 443. Examples of common scenarios where you’ll find an available address include where a different IP address listens for SMTP traffic, or if you publish HTTP-only services already via TMG.

After assigning an additional IP address to the server (if required), we’ll then need to create a new Listener along with a new Web Publishing Rule, by choosing Publish Web Sites:

Figure 8: Creating a new Web Publishing Rule in TMG

After the Web Publishing Rule Wizard begins, we’ll configure a rule with the following options:

• Deny Traffic
• Publish (or rather, Deny) a path of /AutoDiscover/AutoDiscover.xml
• Accept requests for either:

  • Any Domain Name
  • A specific domain name such as autodiscover.contoso.com that we’ll be redirecting. We’d then add the additional AutoDiscover domains later if required.

• Do not require SSL secured connections with clients.

As part of the wizard, we can also create a new listener, with options as below:

• Web Listener IP address: An IP address bound to the TMG server, that is not currently listening on port 443.
• No authentication configured for the listener.

After configuring the rule, we’ll then edit the properties to configure the redirection, which can be found on the Action tab:

Figure 9: Configuring Redirection within the TMG rule

As with the previous methods, we’ll add in the HTTPS address of our central AutoDiscover instance, for example https://autodiscover.exchangelabs.co.uk/AutoDiscover/AutoDiscover.xml

If you’ve chosen to specify the AutoDiscover domains, you’ll need to add these on the Public Name tab, which in a similar fashion to the IIS Bindings configured earlier for IIS, specify the AutoDiscover names we’ll redirect for additional domains.

Finally, to complete the TMG changes, we’ll choose OK to confirm the new rule changes, then select the Apply button to save and apply the changes to our TMG server or array:

Figure 10: Completing configuration within TMG and applying the new rule

DNS Configuration

The final part of the configuration required is to configure appropriate DNS entries to make the configuration work, both externally and internally as required.

If the IP address of the IIS, Load Balancer or TMG you are using for redirection is the same both externally and internally, then you’ll probably need to only edit the external DNS zone for each of your additional accepted domains. If you use different IP addresses for AutoDiscover redirection is different internally and externally, then you’ll also need to create DNS records internally so that clients connected to your network can find the internal IP address without issue.

External DNS Records

The external DNS records are typically the easiest to configure as you’ll either manage these via a self-service portal, or use an external company to manage them.

For each domain, we’ll need to add a new record named autodiscover. In our example, we’ll create an A record, which is a pointer from the name to the external IP address of our AutoDiscover redirector with the following details:

Table 1

In our DNS control panel, you’ll see how this appears below:

Figure 11: Example external DNS control panel configuration

We’ll then repeat that process for each domain we’re performing AutoDiscover Redirection for.

Internal DNS Records

For the internal DNS records, where required, we have two options available:

• Split DNS
• PinPoint Zones

Split DNS is the method of creating a copy of the external DNS zone for an entire domain, replacing external IP addresses with corresponding internal IP addresses. A PinPoint Zone avoids this complexity by creating a zone just for the fully qualified domain name of the single entry that differs from the external DNS zone. As you can imagine, managing split DNS for a large number of domains is complex, therefore we’ll use PinPoint Zones.

To configure a PinPoint zone, create a new zone on your internal DNS server with the full AutoDiscover name, e.g. autodiscover.stevieg.org:

Figure 12: Creating a new PinPoint zone within Windows DNS Server

After creating the zone, add a single A record, leaving the Name field blank, with the internal IP address used for AutoDiscover redirection:

Figure 13: Configuring the internal IP address for AutoDiscover redirection

Alternatively, if you’ve got the DNSCMD utility installed, you can create an AD-integrated zone using a command similar to below, replacing the DNS Server IP, Domain name and Internal AutoDiscover Redirection IP as appropriate:

dnscmd <DNS Server IP> /zoneadd autodiscover.<Domain> /dsprimary
dnscmd <DNS Server IP> /recordadd autodiscover.<Domain> @ A < AutoDiscover Redirection IP>

Testing the configuration

To test the configuration, we can use the Microsoft Remote Connectivity Analyser available at this URL.

We’ll then attempt to confirm functionality using a test user on each domain that uses AutoDiscover Redirection. You should see successful results similar to the output below:

Figure 14: Remote Connectivity Analyser output showing sucessfull AutoDiscover Redirection

Summary

In this article we’ve explored a straightforward technique to allow for reliable AutoDiscover functionality across a large or growing number of accepted domains within your organization that avoids increasing the number of names on internal certificates. While this technique may not be appropriate for every organization, it’s certainly useful if you need to be able to react quickly to organization changes without losing client functionality.

If you would like to read the first part in this article series please go to Using AutoDiscover with large numbers of accepted domains (Part 1).