If you would like to read the previous articles in this series please go to:

• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 1)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 2)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 3)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 4)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 5)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 6)

We are almost at the end of our trek on how to publish Exchange 2007 Web services using the ISA Firewall. While I have not answered all the questions that both you and I have on how to publish all the services available on the Exchange Server, at least what we will end up with is a working configuration that enables secure remote access to OWA, RPC/HTTP and Exchange ActiveSync. While this article series will leave questions about how to enable Outlook Autodiscovery and access to network shares through OWA, that does not mean that I will give up on the quest for finding answers. When I do find those answers, you can be sure that I will let you know about them in follow up articles on this series.

In this article we will move our attention away from the servers and the ISA Firewall and look at the clients. I have found that often, ISA Firewall admins will look for problems on their ISA Firewalls when the problems actually exist on the clients. For that reason, it is important that we go through the details of configuring the clients.

In this article we will do the following:

• Export the CA certificate of the CA that issued the ISA Firewall’s Web Listener certificate
• Import the CA certificate into the client machine’s Trusted Root Certification Authorities machine certificate store
• Edit the HOSTS file on the client machine so that we can mimic a public split DNS infrastructure
• Create an Outlook 2007 profile and configure the RPC/HTTP settings
• Start the Outlook 2007 client and confirm that RPC/HTTP is working correctly
• Test the OWA client connectivity
• Test the ActiveSync connectivity

Export the CA certificate of the CA that issued the ISA Firewall’s Web Listener Certificate

In order for the Outlook 2007 RPC/HTTP client to connect to the Web Listener listening for RPC/HTTP connections, we need to install the CA certificate of the CA that issued the Web site certificate that is bound to the Web Listener. If the machine connecting to the RPC/HTTP site is domain member, and you have installed an enterprise CA in your domain, then the CA certificate is automatically added to the client system’s Trust Root Certification Authorities machine certificate store. However, if the machine connecting to the RPC/HTTP site is not a domain member, or if you have not installed an enterprise CA, then you will have to add the certificate manually.

The first thing we need to do is to export the CA certificate to a file. There are many ways we can do this and what I am going to show you is only one way. Start by going to the Client Access Server machine and opening the Internet Information Services (IIS) Manager console.

In the IIS console, right click on the Default Web Site node in the left pane of the console and click the Properties command, as seen in the figure below.

Figure 1

In the Default Web Site Properties dialog box, click the Directory Security tab. On the Directory Security tab, click the View Certificate button.

Figure 2

In the Certificate dialog box, click the Certification Path tab. On the Certificate Path tab, click the CA on top of the list, which in this case is dc.msfirewall.org. Click the View Certificate button.

Figure 3

In the Certificate dialog box, click the Details tab. Click the Copy to File button.

Figure 4

This brings up the Welcome to the Certificate Export Wizard. Click Next.

Figure 5

On the Export File Format page, select the DER encoded binary X.509 (.CER) option. Click Next.

Figure 6

On the File to Export page, enter a path and file name for the exported CA certificate file. In this example, we will enter c:\cacert . The file extension will be added for you automatically. Click Next.

Figure 7

Review the information on the Completing the Certificate Export Wizard page and click Finish.

Figure 8

Click OK in the dialog box indicating that the export was successful.

Figure 9

Open Windows Explorer and locate the cacert.cer file. Copy this file to the client machine.

Figure 10

Import the CA Certificate into the Client Machine’s Trusted Root Certificate Authorities Machine Certificate Store

In a production environment you might copy this file to a file share or even a Web site that allows the users to download the file to their machines. After the users download the file to their machines, they can carry out the following steps required to import the CA certificate file into their local Trusted Root Certification Authorities machine certificate store. Users will need access to administrator privileges to do this, but if they have access to local admin access using Vista UAC, then they will be able to carry out the following procedure.

On the Vista client machine, open an MMC console. When the console is opened, click the File menu and then click the Add/Remove Snap-in command.

Figure 11

In the Add or Remove Snap-ins dialog box, click the Certificates entry and then click the Add button.

Figure 12

On the Certificates snap-in page, select the Computer account option and click Next.

Figure 13

On the Select Computer page, select the Local computer; (the computer this console is running on) option and click Finish.

Figure 14

In the Add or Remove Snap-ins dialog box, you will see the Certificates (Local Computer) entry on the right side of the dialog box. Click OK.

Figure 15

In the MMC console, expand the Trusted Root Certification Authorities node in the left pane of the console and click on Certificates. Right click Certificates, point to All Tasks and click Import.

Figure 16

Click Next on the Welcome to the Certificate Import Wizard page.

Figure 17

On the File to Import page, use the Browse button to locate the CA certificate that was copied to the client machine. In this example you can see that cacert.der has been copied to the desktop of the Vista client computer. Select the file and click Open.

Figure 18

The path and file name now appear in the File name text box. Click Next.

Figure 19

On the Certificate Store wizard page, accept the default option Place all certificates in the following store and accept the default Certificate store, which in this case is Trusted Root Certification Authorities certificate store. Click Next.

Figure 20

Review the information on the Completing the Certificate Import Wizard page and click Finish.

Figure 21

You will be informed that the certificate was installed successfully. Click OK in that dialog box to confirm.

Click on the Trusted Root Certification Authorities\Certificates node and locate the CA certificate. The name of the CA we are using in this example is dc.msfirewall.org and you can find that in the middle pane of the console. Double click the CA certificate. Here you can see on the General tab the common name on the certificate and the validity dates. Click OK in the Certificate dialog box.

Figure 22

Close the MMC console. You do not need to save the console if you do not want to.

Edit the HOSTS File on the Client Computer in Order to Mimic a Split DNS Infrastructure

In a production environment we would deploy a split DNS infrastructure so that both internal and external clients would be able to access the Exchange Web services using the same name. In our test lab, we do not have an external DNS server to host the external zones for our split DNS infrastructure. However, we can mimic this external zone by using a HOSTS file on the client machine. It is important to note that this is only done in the test lab; you would NEVER use a HOSTS file for name resolution on production network clients.

On the Vista client, click the Start button and enter the path c:\windows\system32\drivers\etc\hosts as seen in the figure below and then press ENTER.

Figure 23

In the Open With dialog box, click on the Notepad entry.

Figure 24

In the hosts file, add a line at the end of the list that resolves the name that external users use to connect to the OWA, RPC/HTTP and ActiveSync sites. In our current scenario, we use a single FQDN to reach all three of these sites, which is owa.msfirewall.org. So we enter the following line at the end of the HOSTS file:

192.168.1.71     owa.msfirewall.org

Make sure that you press ENTER at the end of the line or else the HOSTS file will not recognize the enter. Just in case you did not know – all entries into the HOSTS file are automatically added to the client’s DNS cache. You can confirm this by using the following command:

Ipconfig /displaydns

Figure 25

Create an Outlook 2007 Mail Profiles and Configure the RPC/HTTP Settings

We are getting closer! The next step is to create the Outlook 2007 mail profile and configure that profile to use RPC/HTTP. This is a step were ISA Firewall admins often make a mistake. After reading this section, you will never make a mistake again when it comes to configuring the RPC/HTTP client (both Outlook 2003 and Outlook 2007).

Click Start and then right click on the E-mail icon. Click the Properties command.

Figure 26

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

Figure 27

In the Mail dialog box, click the Add button.

Figure 28

In the New Profile dialog box, enter a name for a mail profile. In this example we will name the profile Administrator. Click OK.

Figure 29

On the Auto Account Setup page, put a checkmark in the Manually configure server settings or additional server types checkbox. Notice that I had earlier entered information on this page in an attempt to get autodiscovery to work, but apparently it did not work. There is no Microsoft documentation on how to get this to work with the ISA Firewall, but I will try to figure this out and publish my results in the near future. What I am going to need to do is figure out how the Autodiscovery process works on the wire using NetMon and then find out the protocols and paths that its looking for. It would make sense that the client would use the path owa.msfirewall.org/autodiscovery, given that was the path added by the publishing wizard, but if things always made sense, I would not have a job 🙂

Click Next.

Figure 30

On the Choose E-mail Service page, select the Microsoft Exchange option and click Next.

Figure 31

On the Microsoft Exchange Settings page, enter the name of the mailbox server for this user in the Microsoft Exchange Server text box. Do NOT enter the name of the ISA Firewall and do not enter the name of the Client Access Server. Many people make this mistake and it does not work. You have to enter the name of the user’s mailbox server. In this example, the name of the mailbox server is exch2007mb.msfirewall.org, so we enter that into the text box.

In the User Name text box, enter the name of the user who needs to connect to his mailbox.

Figure 32

Click the More Settings button. You will see an information box telling you that the action cannot be completed. That is fine, just click the OK button.

Figure 33

In the Microsoft Exchange dialog box, click the Cancel button.

Figure 34

In the Microsoft Exchange dialog box, click the Connection tab. On the Connection tab, put a checkmark in the Connect to Microsoft Exchange using HTTP checkbox. Then click the Exchange Proxy Settings button.

Figure 35

On the Microsoft Exchange Proxy Settings page, enter the name on the Website certificate bound to the Web Listener on the ISA Firewall that is listening for incoming connections for the RPC/HTTP clients. In our current example, this name (which is the common/subject name on the certificate) is owa.msfirewall.org, so we will enter that in the Use this URL to connect to my proxy server for Exchange text box.

Put a checkmark in the Only connect to proxy servers that have this principle name on their certificate checkbox. Then enter the same FQDN that you entered for the proxy server address, prefaced by msstd: In this example you would enter:

msstd:owa.msfirewall.org

Put checkmarks in the On fast networks, connect using HTTP first, then connect using TCP/IP and On slow networks, connect using HTTP first, then connect using TCP/IP. Checking both checkboxes insures that the Outlook client will always try RPC/HTTP first before trying to connect using RPC/MAPI connections.

In the Use this authentication when connecting to my proxy server for Exchange drop down list, select the Basic authentication option.

Note that you cannot select any other option than Basic authentication because the Web Listener is configured to fail back to Basic authentication only. This means that users will always need to log on when connecting using RPC/HTTP. This is the price you have to pay for ISA Firewall security and pre-authentication. If you try to bypass this configuration, you will enable the entire Internet to establish anonymous connections to your RPC/HTTP proxy site on the Client Access Server. That is not something I consider a wise security decision and do not come crying to me when you get nailed with a zero-day exploit against the RPC/HTTP proxy just because your users whined about having to log on to Outlook.

Click OK.

Figure 36

Click OK in the Microsoft Exchange dialog box.

Figure 37

Click Next on the Microsoft Exchange Settings page.

Figure 38

Click Finish on the Congratulations! page.

Figure 39

In the Mail dialog box, select the Always use this profile option and then select the profile that you just created. This will allow Outlook to bring up this profile by default so you do not have to choose a profile when you startup Outlook.

Figure 40

Click Start and then click the E-mail Microsoft Office Outlook icon. Enter the user name and password in the Connect to dialog box and click OK.

Figure 41

The first time the user connects to the mailbox he will see the dialog box informing him that the Outlook is being prepared for first use for that profile.

Figure 42

Yay! We successfully connected to the Exchange Server using RPC/HTTP. Notice on the bottom right of the graphic below it says that we are Connected to Microsoft Exchange.

Figure 43

Just to make sure, hold down the CTRL button on the keyboard and then right click the Outlook icon in the system tray and click Connection Status. You will see the Microsoft Exchange Connection Status dialog box appear. In the Conn column you see that HTTPS is being used for the connection.

Figure 44

Now let us see if OWA works. Enter https:/owa.msfirewall.org/owa into the address bar and press ENTER. You will see the ISA Firewall generated log on page as seen in the figure below. Select the This is a private computer option and enter a user name and password. Notice that you can enter either domain\username or [email protected]. In this example, I used [email protected]. Click Log On.

Figure 45

Yay! It worked again. The empty administrator mailbox appears in front of us. It would be cool if we could use the Documents option but I have not figure out how that works yet. But once I do, I will definitely let you know.

Figure 46

We do not have an ActiveSync device to test this with, but we can enter the URL:

https://owa.msfirewall.org/Microsoft-Server-ActiveSync

and it should bring up a 501/505 error. In fact, it did. So it worked again!

Figure 47

Summary

In this seven part series on how to publish Exchange 2007 Web service using the 2006 ISA Firewall we started out the series with a discussion of what a secure design is and what it is not. We then went on to describe the network topology used for our lab design. This lab design was used to demonstrate how to install and configure the Exchange Mailbox and Hub Transport Server, how to install and configure the Client Access Server, and how to configure the ISA Firewall. We went through all the steps, step by step with a screenshot of each step so that you could read the entire article series and see how the procedures were done – you never had to try to imagine what the step might look like or feel lost because there wasn’t a machine close by that would allow you to see what the step might look like.

We ended up with a working configuration that securely published OWA, Outlook RPC/HTTP and Exchange ActiveSync. While we ended up with a working configuration, I wish I could tell you that we had a “fully working” configuration. Two vital pieces are still left out of the puzzle: how to get Outlook Autodiscovery to work and how to get Shared Folders to work over OWA. If and when I figure these things out I will let you know and extend this article series to include the configurations required to make those services work through the ISA Firewall. Thanks! –Tom.

If you would like to read the previous articles in this series please go to:

• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 1)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 2)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 3)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 4)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 5)
• Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 6)