Publishing Exchange 2007 Outlook Autodiscover with 2006 ISA Firewalls

With Major Help from: Jason Jones and Jim Harrison

Last week I told you about how we might be able to use two Web Listeners to publish both the OWA, ActiveSync and Outlook Anywhere and the Outlook Autodiscover sites. At that time I wasn’t sure it would work because of a number of issues that I thought were unresolved, but I can tell you now that I do have a working arrangement and I’ll share that in this article.

Before we get into the details of publishing the Outlook Autodiscover site, I want to take a moment to talk about two alternative approaches, which I’ll cover in the coming weeks.

The first alternative approach is using an SRV record in your public DNS to inform the Outlook Anywhere clients of FQDN and the IP address they can use to contact the Outlook Autodiscover site. If you check the KB article at http://support.microsoft.com/kb/940881, you’ll find that you only need a single FQDN, a single IP address and a single Web Listener to make it work. While the solution that I’ll outline today only requires a single Web Listener, it does require two IP addresses, because we need two certificates with different names, as discussed in last week’s article at http://isaserver.org/tutorials/Web-Listeners-Web-Publishing-Rules.html

The SRV record approach is very good and greatly simplifies the Web Publishing configuration on the ISA Firewall. However, Jim Harrison does warn us that it’s not a panacea:

“The problem is that many applications operating behind CERN, SOCKS or Socket proxies can’t use SRV records.

In other words, it’s a rare case where a proxy-served client will even seek; much less receive the SRV record.”

Therefore, you can’t depend on SRV records to help when the client is behind a proxy device that resolves names on the behalf of the client. The only reason why the Outlook Anywhere client is able to “consume” the SRV record is that after a hotfix is applied to the client, then the client is able to use the SRV record. As you can see, this is a client related problem and since most proxy servers aren’t designed to look for the Outlook Anywhere SRV record, it won’t work with them in the path. That means you can take advantage of the SRV approach only for your external clients that are not located behind a Web or SOCKS proxy device that resolves names on the behalf of the client.

Still, this shouldn’t be a problem for your internal clients who are trying to reach an internal Outlook Autodiscover server, since a split DNS will take care of this issue. The internal part of the DNS will have DNS entries for autodiscover.domain.com and the external part of the split DNS will have DNS SRV entries for the autodiscover URL.

Now, there is a third option, and this option might be the most popular depending on your environment. The third option is to use Kerberos Constrained Delegation for your Web Publishing Rules and create two Web Listeners with two certificates and two IP addresses. What do you get with this configuration? What you get is the ability to log onto Outlook Anywhere without having to enter your IP address each time. The downside, or course, is that you need two IP addresses.

While the SRV record and the Kerberos Constrained Delegation options are interesting and definitely worth knowing about, we need to finish the work we did last week on using two IP addresses, one Web Listener and two certificates to publish the OWA, ActiveSync, Outlook Anywhere and Outlook Autodiscover sites.

We need to do the following:

• Obtain a certificate for the autodiscover.msfirewall.org to bind to the Web Listener and Install the certificate into the ISA Firewall’s machine certificate store
  
• Configure the Web Listener with the new certificate and bind the certificate to a second IP address on the external interface of the ISA Firewall
  
• Configure the Outlook Anywhere Web Publishing Rule to support the autodiscover site
  
• Use the dreaded PowerShell to configure the Autodiscover URL
  
• Configure the Client Access Server Outlook Anywhere Site with the new External URL and Basic Authentication

Obtain a Web Site Certificate for the Autodiscover Site and Install it into the Machine’s Certificate Store

Since we need to use a second FQDN to access the Outlook Autodiscover site, we need a second certificate so that we can create a secure connection to the ISA Firewall. We can use the Web enrollment site to obtain the certificate from the certificate server located on the DC machine we configured in our Exchange 2007 Web Publishing scenario.

When you get to the Web enrollment site, select the Request Certificate link. On the next page of the Web enrollment site, click on the Advanced certificate request link. On the Advanced Certificate Request page, click the Create and submit a request to this CA link. Select the Web Server Certificate Template and in the Name text box enter the autodiscover service FQDN in that text box. In our example we’ll use autodiscover.msfirewall.org. Put a checkmark in the Store certificate in the local computer certificate store checkbox. The CA certificate is already installed on the ISA Firewall because the ISA Firewall is a domain member, and we’re using an enterprise CA.

Click Submit and complete the wizard. Let the wizard install the certificate for you when you reach that step.

Figure 1

Configure the Web Listener with the Autodiscover Certificate and Bind it to a Second IP Address

Not too much to add this week on creating the Web listener, as we did that last week. The following screenshots show the salient aspects of the Web listener that is used for all of our Web Publishing Rules.

On the Networks tab, you can see that the Web listener is listening both on the internal and external interfaces. The external interface has two IP addresses, and the internal interface has a single IP address. The internal listener is used to support internal clients that want to use OWA so that they can benefit from the ISA Firewall’s Forms-based authentication and also the ISA Firewall’s HTTP Security Filter.

Figure 2

On the Connections tab you can see that this Web Listener is configured to listen only for SSL connections.

Figure 3

On the Certificates tab, you can see that the certificate with the common/subject name of owa.msfirewall.org is bound to IP addresses 10.0.0.1 and 192.168.1.71. A certificate with the common/subject name of autodiscover.msfirewall.org is bound to IP address 192.168.1.72. Make sure your public and private DNS entries in your split DNS infrastructure reflect these names and addresses.

Figure 4

On the SSO tab, we’ve set an single sign-on domain for msfirewall.org. This means that when users log on to one server in the msfirewall.org Active Directory domain, they will not need to reauthenticate when they connect to another machine in the same domain.

Figure 5

On the Authentication tab, the HTML Form Authentication option is selected and the ISA Firewall uses Windows (Active Directory) as its Authentication Validation Method, which is an ISA Firewall security best practice, as the ISA Firewall is a domain member.

Figure 6

On the Forms tab, the default form settings are used as defined by the Web Publishing Rule Wizard used to create this Web Publishing Rule. There is no reason to make any changes on this page.

Figure 7

Configure the Outlook Anywhere Web Publishing Rule to Support the Autodiscover Site

We now need to make some changes to the Web Publishing Rule settings to support our autodiscover.msfirewall.org FQDN.

Double click on the Outlook Anywhere Web Publishing Rule and click the Public Name tab. Before, we used owa.msfirewall.org for the public name but now we need to change that to support our Autodiscover service publishing. Use the Remove button to remove the owa.msfirewall.org entry and use the Add button to add the autodiscover.msfirewall.org entry, as seen in the figure below. Click Apply.

Figure 8

Click the Paths tab. On the Paths tab you’ll see the paths that the rule can access on the Client Access Server when the call comes in for autodiscover.msfirewall.org. Note that the Outlook Anywhere client not only accesses the Autodiscover service via autodiscover.msfirewall.org, but also uses the autodiscover.msfirewall.org FQDN to reach the RPC/HTTP proxy, as demonstrated by the fact that this rule can forward to the /rpc/* directory on the Client Access Server.

Figure 9

Click on the Authentication Delegation tab. Before we were using NTLM delegation and it worked fine for the RPC/HTTP connection. However, if you try to use NTLM delegation for publishing both the Autodiscover service and the RPC/HTTP service, you’ll find that the client will be repeatedly access for credentials and will never be able to log on. I don’t know why this is the case, since the default setting on the /Autodiscover/* directory is to support both Basic and Integrated authentication. Maybe the answer lies in the bowels of a PowerShell command, but it beats me as to which of the million commands to use to fix this problem. If you figure it out, let me know.

Change the Method used by ISA Server to authenticate to the published Web server to Basic authentication and then click Apply.

Figure 10

Click on the Bridging tab. Here you’ll see that only the Redirect requests to SSL port is enabled and the default port of TCP port 443 is used. Don’t change this!

Figure 11

Click on the Users tab. Here you’ll see that the default is All Authenticated Users. This is just the default setting. If you want to create a custom group of users that you want to allow RPC/HTTP access to, you can do that here.

Figure 12

Click on the To tab. Notice that we don’t change the entry in the This rule applies to this published site text box. This can be a great source of confusion, because it looks like we’re going all over the place changing the public FQDNs and URLs that we want to use for Autodiscover service site. However, we must use the name owa.msfirewall.org here because that is the common/subject name on the Web site certificate bound to the Client Access Server Web site.

I think one of the major reasons for confusion in this area relates to the user of Subject Alternative Names on the Web site certificate bound to the Client Access Server Web site. The fact is that:

The ISA Firewall cannot consume Subject Alternative Name. Period. No more questions.

Now, I can hear you saying “but Jim Harrison said in his ISA Blog post that the ISA Firewall can act as a client to the published Web site and consume SANs”. The problem with Jim’s argument is that in practice, the ISA Firewall cannot use the SANs presented by the published server because the common/subject name and the first SAN (which is theoretically the only SAN that the ISA Firewall will recognize) must be the same. Since the common/subject name and the first SAN must be the same, the end result in actual practice is that the ISA Firewall cannot use any SANs on the Client Access Server Web site certificate.

For more information on this bug that prevents the ISA Firewall from using SANs, please see Steven Hope’s article.

In the Computer name or IP address text box, make sure to use the IP address or the actual machine name on the internal network there. The easiest way to do this is to use the Browse button and find the name of the Client Access Server on the internal network.

Figure 13

Use the Dreaded PowerShell to Configure the Autodiscover URL

Now you need to drop into the dark caves of the dreaded PowerShell (PowerHell). The reason for this is that we need (I think) to set the URL for the Autodiscover service on the Client Access Server. In order to do that, you need to open the EMS and run the following command:

Set-ClientAccessServer -Identity “EXCH2007CAS” -AutodiscoverServiceInternalURI “https://autodiscover.msfirewall.org/autodiscover/autodiscover.xml”

The figure below shows how I got to waste an hour trying to figure out how to make the various PowerShell commands work to set the Autodiscover URL and check it if was actually configured correctly. Let’s hope, pray and beg that they fix this problem in Exchange 2007 SP1. Like many of you, I find that every time I have to drop into the PowerShell I end up taking over an hour to do a five minute task.

Figure 14

Configure the HOSTS File on the Test Client

In our test environment we need to make sure the external client can resolve our Autodiscover service site. Open the HOSTS file located in the c:\windows\system32\drivers\etc path using Notepad. Enter the IP address that the Autodiscover site is listening on. This is the IP address that you bound the autodiscover.msfirewall.org certificate to. The figure below shows the entries in the HOSTS file for our test client.

Figure 15

In your production environment, these FQDNs would have Host (A) records in your public DNS.

Configure the Client Access Server Outlook Anywhere Site with the new External URL and Basic Authentication

Now we need to go to the Client Access Server and make some changes to support our autodiscover.msfirewall.org FQDN access to both the Autodiscover service and the RPC/HTTP service.

Open the Exchange Management Console, expand Server Configuration and click on Client Access. Double click on the Client Access Server name in the top pane of the middle pane and you’ll see the Properties dialog box for the Client Access Server. Click on the Outlook Anywhere tab. Previously, we had owa.msfirewall.org in the External host name text box. We need to change this (I think) to autodiscover.msfirewall.org and we also need to change the authentication to Basic authentication, as seen in the figure below.

I know that I said in a previous article that we should use NTLM authentication so that we could access some new, but undefined “special features” included with Outlook 2007. I guess we’re going to have to forego those undefined “special features” if we want to use the same rule for our RPC/HTTP and Autodiscover service access.

I also noted in my previous articles that I had no idea if it mattered what we put into these External Host Name text boxes. Jason Jones informs me that we need to put the correct external FQDN in these text boxes or else things won’t work right. That is to say, we need to use the URL that external clients use to access the service in question. I’ll take Jason’s word for this and enter the new FQDN in the text box.

Figure 16

Since we’re at the Exchange Management Console on the Client Access Server, we might as well set the external URL for the Offline Address Book. In the bottom pane of the middle pane, click the Offline Address Book Distribution tab, then double click on the OAB (Default Web Site) entry.

In the OAB (Default Web Site) Properties dialog box, click on the URLs tab. In the External URL text box enter the new FQDN. Before we had owa.msfirewall.org as the FQDN for the External URL. We need to change that to the new FQDN, which is autodiscover.msfirewall.org, as seen in the figure below. Click Apply and then click OK.

Figure 17

I’m not sure we have to do the next step, but it doesn’t hurt. Exchange 2007 has a mysterious and undefined relationship to IIS settings, so we might need to restart IIS in order to get our new settings to work.

Open a command prompt and enter the command:

Iisreset –noforce

And then press ENTER. This will restart IIS and hopefully apply the changes we made in the Exchange Management Console.

Figure 18

By the way, before we set up the client and see if everything works, here’s what my ISA Firewall Rules look like:

Figure 19

Setting Up the Outlook Anywhere Client using Autodiscovery

Now we’re ready to configure the Outlook Profile and test the autodiscovery settings. Click Start and right click on the E-mail icon. Click Properties.

Figure 20

In the Mail Setup dialog box, click the Show Profiles button.

Figure 21

In the Mail dialog box, click the Add button.

Figure 22

In the New Profile dialog box, enter a profile name in the Profile Name text box. In this example we’ll use the name Admin3 and click OK.

Figure 23

On the Auto Account Setup page, enter your user name in the Your Name text box, your e-mail address in the E-mail Address text box, and your password in the Password and Retype Password text boxes. Click Next.

Figure 24

Enter your user name and password in the Connect to dialog box. Make sure to use the domain\username format and click OK.

Figure 25

Yes! It worked. On the Congratulations page you can see that everything works and that the e-mail account is successfully configured to use Microsoft Exchange. Click Finish.

Figure 26

In the Mail dialog box, select the Always use this profile and select the one you just created. In this example, that profile was Admin3. Click OK.

Figure 27

Start Outlook. Yeah! It worked and we are connected to Exchange through the ISA Firewall using the Autodiscovery settings.

Figure 28

If you look at the settings created by the Autodiscover service, you can see it set us up to use autodiscover.msfirewall.org as our proxy server and also configured the msstd: entry for us as well. Nice! It’s almost so good that it’s makes me forget about the traumas of using PowerShell.

Figure 29

Hold down the CTRL key on the keyboard and right click the Outlook icon in the system tray. Click on the Connection Status command in the right click list.

Figure 30

In the figure below you’ll see that we were successful in creating an RPC/HTTP connection, as seen in the Conn column, we’re using HTTPS.

Figure 31

If you want to see what the ISA Firewall log entries look like when Autodiscover works

Figure 32

And for those who are interested, here’s what the Test E-mail AutoConfiguration looks like:

Figure 33

Looks like there’s a lot more for us to learn in order to get a fully functional Exchange Server working with the ISA Firewall. I’ll wait for Exchange Server 2007 SP1 to be released before I attempt to tackle the IMAP4 and POP3 services and autodiscovery for those clients. We still need to get the SMTP “service” working too so that we can confirm that inbound mail can be received and outbound mail can be sent.

Summary

In this article we went through the details of publishing the Autodiscover service included with Exchange 2007. The methods we used in this article involved using two IP addresses on the external interface of the ISA Firewall and bound a different certificate to each IP address. At the beginning of the article we discussed two other methods. One method, that requires only a single IP address uses DNS SRV records to publish the Autodiscover service. The second method, which requires two IP addresses and two certificates and Kerberos Constrained Delegation, enables external RPC/HTTP clients to avoid entering their passwords with each log on by enabling Integrated authentication on the Web listener. I’ll go through the details of both methods in future articles. Thanks! –Tom.