Configuring Exchange 2003 HTTP Remote Access
Exchange 2003 introduced a lot of new functionality over its previous incarnations. Amongst the features not found in Exchange 2000 are the mobile HTTP services of Outlook Mobile Access (OMA) and Exchange ActiveSync (EAS). These features were previously offered by a stand-alone server product called Mobile Information Service (MIS), and were ported into Exchange 2003 with the same administrative look and feel as the more familiar Outlook Web Access (OWA). OWA itself got quite a facelift and was given a new feature called Form Based Authentication (FBA) to improve security when OWA is accessed from less than secure PCs.
Problems started to occur when administrators attempted to make all these HTTP features work together, and particularly difficult was the new mobile features of OMA and EAS. Although OMA and EAS did retain some of their quirks from the MIS days, the real culprit for the problems was the management system imposed on them by their elder sibling OWA. When configuration changes were made to OWA these changes were executed with little respect for OMA and EAS with the result that they often stopped working! The most problematic change an administrator could carry out was to enable SSL and OWA’s new Form Based Authentication feature.
FBA requires the ‘Basic Authentication’ method for Web access to the OWA folder /Exchange. FBA also requires SLL to be enabled. The OMA and EAS applications also share this same /Exchange folder, but unfortunately they require it to have ‘Integrated authentication’ without any SSL. To work around this problem IIS Manager could be used to re-established ‘Integrated’ authentication on the /Exchange folder, and SSL could be configured but not demanded: OWA, OMA and EAS would all work together … for a while!
Exchange maintains IIS settings for its HTTP features in the Active Directory and these are edited using the Exchange System Manager (ESM) console. When edits are made in ESM, Exchange applies these settings, and not just the changed ones, to the IIS configuration database known as the Metabase. Fixes could be manually applied using the IIS Management console afterwards, but frustratingly Exchange reapplies its settings over any manual fixes whenever it is restarted!
There have been many documented attempts to cure this problem. A favoured method has been to stop the sharing of the same /Exchange folder between OWA and the mobile features and to place the folder for mobile use out of the scope of Exchange’s IIS configuration mechanism.
This solution works very well, but does require the user to make changes to the registry and doesn’t address similar problems with OWA that can occur when frontend Exchange servers are involved (frontend-backend communications also use ‘Integrated’ authentication without SSL).
The solution detailed in this guide takes a slightly different path by splitting SSL access and non-SSL access between different HTTP virtual servers. This solution doesn’t require tricky registry changes and will also handle frontends without problems should you have them (if you have frontends the instructions here apply to your backend servers).
As a side-effect, the solution here also provides internal OWA users with the choice of non-SSL connection using ‘Integrated’ authentication: ‘Integrated’ authentication will give transparent logons to your internal domain users provided they use Internet Explorer.
Modifying the Default Web Site
We will begin by configuring the original Exchange HTTP configuration for a new role of handling only SSL connections rather than trying to make it handle both SSL and non-SSL traffic.
The following steps will enforce SSL on the Default Web Site and is one configuration that can be carried out using the IIS Management console rather than the ESM console without fear of the changes being automatically over-written by Exchange at a later time.
- Click on Start, then Programs, then Administrative Tools and then select Internet Information Services (IIS) Manager. Expand the server name node and click Web Sites. In the right pane of the console right-click on the Default Web Site. Select Properties in the menu.
- In the Default Web Site Properties dialog box click the Directory Security tab. There are three buttons within the Secure communications frame. This guide presumes you have already created a certificate and installed it on the Default Web Site. If this has been done you can click on the View Certificate button, if not, you will need to use the Server Certificate button to install an existing or new certificate. With a certificate in place click the Edit button in the Secure communications frame.
- In the Secure Communications dialog box put a check in the Require Secure Channel (SSL) and Require 128-bit encryption checkboxes. Click OK to return to the properties page and click Apply.
Note: If the checkbox was already selected and you are very sure that SSL is enforced for the site, you need go no further in this section. It is more likely that you will not be sure SSL is enforced throughout the site, so uncheck the Require Secure Channel (SSL) checkbox. Click OK to return to the properties page and click Apply. Click OK to any Inheritance Overrides dialog boxes (do nothing else with them) and then repeat steps 2 and 3.
- An Inheritance Overrides dialog box will appear warning that some ‘child nodes’ override the settings for “UNCPassword”. Ignore this and click OK.
- A second Inheritance Overrides dialog box may appear, this time warning that some ‘child nodes’ override the settings for “AccessSSLFlags”. Click on the Select All button so that these are all high-lighted then click Exadmin to deselect it. Click OK. This has enabled SSL requirement on all the relevant virtual directories in the Default Web Site.
Note: If any of these Inheritance Overrides dialog boxes do not appear, or are not fully populated with all the ‘nodes’ here, it would mean there isn’t an override and the ‘node’ will inherit the settings you’ve just made anyway. This inheritance process avoids the tedious configuration of each individual virtual directory.
- Still in the Default Web Site Properties dialog box click the Web Site tab, and then click on the Advanced button in the Web site identification frame to open the Advanced Web Site Identification dialog box.
- This site will be blocked from receiving port 80 (non-SSL) connections so remove any entries in the Multiple identities for this Web site frame, then click the entry with no host header listed and click Edit.
- In the Add/Edit Web Site Identification dialog box fill in the Host Header value text box with something invalid. Click OK.
Note: These last two steps assume you only have Exchange installed and IIS isn’t supporting other sites. If this isn’t the case with your setup, you will have to treat these steps a little more carefully to keep these other sites available.
- Back in the Advanced Web Site Identification dialog box, click Add in the Multiple SSL identities for this Web site frame (if you already have a valid entry, you can skip this). Select a valid address (see about DNS below) from the IP address drop-down box and enter 443 in the SSL port text box. Click OK.
- Review settings and then click OK to the Advanced Web Site Identification dialog box and the Default Web Site Properties dialog box.
- Back in the Internet Information Services (IIS) Manager console, right-click on the Default Web Site and select the All Tasks and Save Configuration to a File option in the menu.
Note: The Save Configuration to a File option is found in Windows 2003, not Windows 2000. However, the purpose for this saved configuration is optional, as will be seen later.
- The Save Configuration to a File dialog box will open. Enter a suitable file name and file destination path in the File name and Path text boxes (use the Browse button to find a suitable path if you wish). Click OK. Remember the location of this file for later.
- Close the Internet Information Services (IIS) Manager console.
In addition to these steps the guide assumes you have a local DNS with an entry that points the fully qualified domain name (FQDN) you use to connect to OWA, OMA and EAS to the IP address of your Exchange server. This will be required for any local network OWA users to find your OWA server.
The certificate you configured for the OWA site should also have a common name that matches the FQDN you use. Beware of ‘wildcard’ certificates; some mobile devices and ISA Server publishing rules using ‘SSL-SSL bridging’ will not accept such certificates.
Creating an Additional HTTP Virtual Server for Exchange
The next stage is to configure an Exchange HTTP virtual server to handle non-SSL connections to complement the original Exchange HTTP configuration that is now only handling SSL traffic.
Using the Exchange System Manager console is the recommended way of creating an additional HTTP virtual server and directories for OWA, etc. It is also happens to be the quickest and easiest method too. Configuring this way does not interfere with Exchange’s Active Directry to Metabase configuration mechanism (known as DS2MB) and should support any changes made by service packs in the future without having to repeat the configuration again.
This new virtual server must never be configured with Forms Based Authentication or SSL.
- Click on Start, then Programs, then Microsoft Exchange and then select System Manager. In the left pane of the Exchange System Manager console, expand Servers and then expand your server name. Continue expanding Protocols and finally HTTP. Now right-click on an empty area in the right pane of the console. Select the New and HTTP Virtual Server option in the menu.
- On opened the Properties page for the new virtual server enter Exchange Supporting Virtual Server in the Name box (you could choose your own name).
- Click the Access tab and then click Authentication.
- In the Authentication Methods page remove the checkmark from Basic Authentication to leave only Integrated Windows Authentication enabled. Click OK to this dialog box and the Properties page.
Note: You could leave Basic authentication, but you leave the configuration open to users inadvertently sending passwords over the network in plain-text.
Back in the Exchange System Manager console, right-click on the newly created virtual server then select the New and HTTP Virtual Directory option.
- On the Properties page for the new virtual directory enter Exchange in the Name box and then repeat steps 3 and 4 above to leave only Integrated Windows Authentication enabled.
Note: If you have followed one of the many articles that recommend changing the ExchangeVDir registry setting, the name in the name box should be the name used in that setting (probably ExchDAV or Exchange-oma). You could alternatively undo those ExchangeVDir changes because this solution does not need them.
- Repeat steps 5 and 6 but this time enter Public in the Name box and click the Public Folder option for the Exchange Path.
If you created a virtual directory called something other than Exchange in steps 5 and 6, repeat those steps to create a virtual directory called Exchange as well.
Note: Although this step is recommended, you only need to complete step 7 if you want to support frontend Exchange servers or want to fully support internal OWA users with transparent ‘Integrated’ logon.
- Close the Exchange System Manager console. Click on Start, then Programs, then Administrative Tools and then select Internet Information Services (IIS) Manager. Expand the server name node and click Web Sites. Right-click our new Web site in the right pane of the console. Select the New and Virtual Directory (from file) option in the menus.
- In the Import Configuration dialog box use the Browse button to locate the configuration file created earlier. Click Read File. In the Select a configuration to import box click on Exadmin and then click OK.
Note: Although this step is recommended, you only need to complete steps 8 and 9 if you want to be able to list Public Folders when creating new virtual directories in ESM console. Most would not miss this feature!
- Close the Internet Information Services (IIS) Manager console. The configuration is complete, go ahead and try it!
Enhancing the Configuration
The following are some optional configurations that can enhance your OWA, OMA and EAS arrangements, or supply solutions for special circumstances. Some changes require direct edits of the registry and IIS Metabase and you should be aware of the damage that can be done by incorrectly editing the contents of these important structures: Always back them up before making changes!
Root access for OWA
Typing in an URL of https://exchange.company1.tld/exchange can be a bit tedious and you may prefer just to type https://exchange.company1.tld. You may have found that for the new virtual server you created, OWA is configured for the root of the Web site also. The steps needed to extend root access for OWA in the Default Web Site is very straight-forward.
The Default Web Site and the site we created in the second option above both pointed their root home directories to the c:\inetpub\wwwroot folder (assuming Windows was installed on drive C). If you don’t specify a file in the URL, IIS will try to return default.htm or default.asp or so on in that order: Therefore we need only create a redirection script in this location called default.asp and the job is done.
This is one way to create such a file:
- Click Start and Run on the Exchange server. In the Run dialog box type cmd in the Open box and click OK.
- At the command prompt enter the following commands (the ^Z character is entered by pressing the ‘Z’ key with the ‘Ctrl’ key held down):
copy con default.asp
<%@ Language=VBScript %>
<% Response.Redirect "exchange" %>
Additional SMTP domains
Your organisation may have users who have different SMTP domains in their email addresses. These users cause some concern when deploying OWA, OMA and EAS because the mechanisms used by these features rely on identifying your mailbox by your SMTP address, not your logon name! You will need to take steps to ensure all your users can access OWA, OMA and EAS whatever email address they happen to use.
When you configured addition SMTP domains you will have added them to Recipient Policies using ESM console. Whatever arrangements you have made using Recipient Policies, it is important that all your domains appear in the Default Policy. This should look something like:
The SMTP address in bold is the primary address and is what Exchange considers to be the default SMTP domain for the organisation.
This guide has assumed that everyone has an SMTP address in the default SMTP domain. The default /Exchange virtual directory is configured to find mailboxes in the default domain and you cannot change this. If you have users with an SMTP address in a different domain they would have access problems. However, to access OWA and OMA the solution is fairly simple; give these users a second SMTP address in the default domain. In Active Directory Users and Computers console the properties of a user may look like the following illustration (the default SMTP domain here is company1.tld):
For EAS the solution is a little trickier because the EAS routine for finding your mailbox is different to that used by OWA and OMA. EAS will only check your primary SMTP address when looking for your mailbox and assumes that the SMTP domain for this address will be correct. If this was to happen with the user illustrated in the last figure the process is bound to fail because his primary SMTP address isn’t in the organisation’s default SMTP domain.
Fortunately we can force EAS to look for a user’s address that matches the default SMTP domain, but this will require a registry edit.
- Click Start and Run on the Exchange server. In the Run dialog box type regedit in the Open box and click OK. Navigate through the registry tree and find this subkey:
- Right-click in the right-hand pane and select New, and String Value in the menus. A new value is created. Type SMTPProxy in place of ‘New Value #1’ and press ENTER to rename it.
- Double-click the SMTPProxy value you have just created. In the Value data box, type your default SMTP domain click OK and quit Registry Editor.
If you have a frontend-backend deployment, this registry edit must be made on the frontend servers too.
Integrated Authentication and Internet Explorer
The guide has created a site that is accessible using the ‘Integrated’ authentication method. This method never passes your password in plain-text across the network, which means it is a safe method to use with HTTP when no SSL encryption is in use.
The Microsoft Internet Explorer browser can be configured to pass the credentials you logged onto your computer with to any Web site that requests ‘Integrated’ authentication. This makes the logon transparent (no logon dialog box). While this mechanism is not practical across the Internet, it can prove useful for your OWA users on your local network.
1. In Internet Explorer click on Tools in the menu bar and select Internet Options. Click on the Advanced tab and scroll down to the bottom of the list under Settings. Ensure Enable Integrated Windows Authentication (requires restart) has a check mark next to it.
2. Click on the Security tab. Click the Local Intranet icon and then click Sites.
3. On the Local intranet dialog box click Advanced.
4. Enter the FQDN of your OWA site in the Add this Web site to the zone text box and click Add. Click OK on the dialog boxes to return to the browser. You should restart the browser for the changes to take effect.
The original ‘default’ site will also accept ‘Integrated’ authentication using HTTPS provided you have not enabled FBA which only allows ‘Basic’ authentication. Users who can’t use ‘Integrated’ authentication will be forced to use this HTTPS only site (including any ISA Servers you have publishing OWA, OMA and EAS).
Integrated Authentication and Kerberos
Integrated authentication takes two forms in a Windows 2000/2003 networks: Kerberos and NTLM. The Kerberos method is preferred over NTLM so you should take steps to ensure it is used by your internal OWA users.
The first step is to explicitly configure the Web site to always ‘negotiate’ the ‘Integrated’ authentication methods: Kerberos will always be attempted first when this is done, but it will fall back to NTLM when not possible. For this configuration you need the Identifier for the Web site we created. This number (always ‘1’ for the Default Web Site) is displayed in a column in IIS Management console and can be seen on some of the illustrations above. If the column isn’t visible use the View and Add/Remove Columns menu item in the console. The identifier is invariably ‘100’ if you used the ESM console to create the site.
- Click Start and Run on the Exchange server. In the Run dialog box type cmd in the Open box and click OK.
- At the command prompt enter the following commands (replace ‘100’ with your site’s identifier, and use the drive letter where Windows is installed if that isn’t drive C):
cscript adsutil.vbs set w3svc/100/NTAuthenticationProviders "Negotiate,NTLM"
For Kerberos to work the client must obtain what is known as a service ticket for the service it is attempting to access. The client requests a ticket by specifying the service principle name (SPN) for the service in question, which is made up of a service-class followed by the hostname. If your OWA user is attempting to access a site called exchange.company1.tld their client will request a service ticket for the SPN HTTP/exchange.company1.tld from whichever security principle is registered with that SPN (your Exchange server we hope).
The world of SPNs is usually pre-configured and out of sight and you need take no notice of this horrid little lesson provided your Exchange server has the same name as the FQDN in the URL you connect to the Exchange sites with. If not then assume an SPN called something like HTTP/exchange.company1.tld doesn’t exist!
Creating SPNs requires the Support Tools to have been installed on the computer you are going to run the following commands from. You can install the Support Tools from the \Support\Tools folder of your Windows 2003 Server distribution disc.
- Click Start and Run on a domain computer with the Support Tools installed. In the Run dialog box type cmd in the Open box and click OK.
- At the command prompt enter the following commands (replace FQDN here with your site’s FQDN, and the server name ‘exchange2003’ with your OWA server’s NetBIOS name):
setspn –A HTTP/exchange.company1.tld exchange2003
Specifying Host Headers
The guide has so far shown how to create an addition virtual server to pick up all non-SSL communications with the server: This should be the only arrangement you will need. However, you may, for whatever reason, wish to specify the host headers that the virtual server configured in this guide will service.
This is quite advanced, but is mentioned here because the necessary configuration using host headers isn’t entirely straight-forward. You will need an entry for the fully qualified domain name (FQDN) you use to connect to OWA, OMA and EAS plus one for the Exchange server’s NetBIOS name. The latter entry is essential if you want to use OMA, Exchange frontends and also the public folder listings in ESM console. If you use more than one FQDN for OWA, OMA and EAS, you must include these FQDNs too.
- Click on Start, then Programs, then Microsoft Exchange and then select System Manager. In the left pane of the Exchange System Manager console, expand Servers and then expand your server name. Continue expanding Protocols and finally HTTP. Right-click on the newly created virtual server appearing in the right-hand pane and select the Properties option.
- Click the Advanced button alongside the IP address text box. In the Advanced dialog box use the Add button to create the required entries.
Exchange 2003 SP1 Footnote
This guide has recommended you create an additional HTTP virtual server to deal with non-SSL connections. You may question why it was done this way around; could not the new virtual server handle SSL connections and leave the original for non-SSL only? Done this way there would be less messing about with host-headers and no dirty tricks to create the /Exadmin virtual directory.
The answer is that you would have to create virtual directories for OMA (/OMA) and
Exchange 2003 SP1 fixes the