If you would like to read the other parts in this article series please go to:
Organizations that have deployed or are planning to deploy Exchange 2010 into their Active Directory forest usually want to allow remote and/or mobile users to access their mailbox from outside the corporate network using one or more Exchange protocols/services. More specially, the organization wants to allow users to access their mailbox using Outlook Anywhere (OA), Outlook Web App (OWA) and Exchange ActiveSync (EAS).
However, for security reasons many of these organizations have a security policy that states any remote or mobile users must pre-authenticate against a reverse proxy solution located in the perimeter network before they are permitted access to a service on the internal corporate network. There are several reverse proxy solutions that support pre-authentication for Exchange users but the most popular is without doubt Forefront Threat Management Gateway 2010 (Forefront TMG 2010).
By default, when enabling pre-authentication for OWA 2010 in Forefront TMG 2010, you must change the authentication method on the Internet-facing Exchange CAS servers from forms-based authentication to integrated/basic authentication depending on the authentication delegation that you will set for the listener in Forefront TMG 2010.
For users that connect to their mailbox using OWA the forms-based authentication logon page has become kind of a de-facto standard which means that the organization usually want to enable FBA for both external and internal OWA users. However, this is not the only reason. For instance, if an internal client machine is shared among multiple users that logs on to the client machine using a shared domain user account (think workforce such as clinical researchers, nurses and receptionists etc.) and then authenticate using their own account when accessing a service or application would prefer to be presented with the FBA page when accessing OWA.
In this article, we’ll take a look at how this is accomplished in an Exchange 2010 based messaging environment where Exchange is published to the Internet using Forefront TMG 2010.
Will Duff (Knowledge Engineer in CSS at Microsoft) and Greg Taylor (Senior PM in Exchange CXP team at Microsoft) put together a good blog post that describes the three typical scenarios when it comes to OWA access and provide best practice recommendations for each of these scenarios. However, the steps necessary to enable FBA for external and internal users are missing both from the blog post as well as the Exchange 2010 documentation on TechNet. Because it involves a lot of steps and is somewhat complex to enable FBA for external as well as internal OWA 2010 users, I thought I would share my experience around this topic with you my fellow readers.
Let’s get going shall we?
The lab environment I’ll use to show you how to enable FBA for external and internal OWA 2010 users consists of the following:
- 1 x Windows Server 2008 R2 Active Directory forest (Exchangeonline.dk)
- 2 x datacenters/locations (primary DC and failover DC)
- 2 x AD sites (one in primary DC and one in failover DC)
- 2 x subnets in primary DC ( MAPI network: 192.168.2.0/24 & replication network: 10.10.10.0/24)
- 2 x subnets in failover DC ( MAPI network: 192.168.6.0/24 & replication network: 10.10.11.0/24)
- 4 x Exchange 2010 multi-role servers (two in primary DC and two in failover DC)
- 4 x Domain Controllers (two in primary DC and two in failover DC)
- 2 x Load balancers (one hardware based LB in primary DC and one hardware LB in failover DC)
- 2 x Forefront TMG 2010 stand-alone arrays (one in primary DC and one in failover DC)
In addition, split-DNS for the mail.exchangeonline.dk and failover.exchangeonline.dk namespaces has been, so that it’s the same FQDN that is used to access Exchange services from the external and internal network. It’s also worth mentioning that the two TMG stand-alone arrays are domain-joined. Finally it should be noted that the same SAN certificate is used for all Exchange servers in the forest, which means the Set-OutlookProvider cmdlet has been used to specify the principal name for EXPR.
The topology for the lab environment is depicted in the following diagram:
Figure 1: Topology Diagram of the lab environment
Changing the Authentication Method for OWA & ECP Virtual Directories
Okay so the first thing we want to do is to change the authentication method for the OWA and ECP virtual directory on each of the 4 Exchange 2010 multi-role servers in the environment. As explained, this is necessary in order to configure pre-authentication for OWA and ECP on the Forefront TMG arrays. The reason for this is because you cannot have FBA enabled for both the Exchange 2010 listener on the Forefront TMG arrays and on the Exchange 2010 multi-role servers since this would result in double-authentication.
To change the authentication methods, launch the Exchange 2010 Management Console (EMC), and expand the “Server Configuration” work center node. Select the first Exchange 2010 multi-role server in the result pane followed by opening the property page for the “owa (Default Web Site)” virtual directory.
Figure 2: Opening the property page for the OWA virtual directory
Check the authentication method from FBA to Integrated and/or Basic authentication as shown in Figure 3. Then click “OK” to apply the changes. You’ll receive a warning stating that you also must change the authentication method for the ECP virtual directory.
Whether you should enable basic and/or integrated authentication depends on what type of authentication delegation you plan on configuring on the Forefront TMG 2010 arrays. The authentication method set on the Forefront TMG 2010 arrays must match the authentication set on the Exchange 2010 multi-role servers.
Figure 3: Changing Authentication method for the OWA virtual directory
Now click the “Exchange Control Panel” tab and open the property page for the “ecp (Default Web site)” virtual directory. Again, change the authentication method from FBA to Integrated Windows and Basic authentication as shown in Figure 4 and click “OK” to apply the changes.
Figure 4: Changing Authentication method for the ECP virtual directory
Now do an IIS reset by opening the command prompt and type “IISRESET” followed by pressing “Enter”.
Repeat the above steps for the remaining 3 multi-role servers.
With the authentication settings changed, internal users will now be automatically logged into OWA using the credentials that were used to log on to the client machine (if FQDN used to access OWA is in the browser’s local intranet zone as shown in Figure 5).
Figure 5: FQDN used to access OWA added to the local intranet zone
If the FQDN is not in the local intranet zone or the user is logged on to the client machine using a non-mailbox enabled user account, she will be prompted for credential as shown in Figure 6.
Figure 6: OWA FQDN not added to the local intranet zone or integrated authentication disabled
As mentioned in the introductory, in some scenarios the above behavior isn’t very desirable and the organization instead want all external as well as internal users to be presented with the FBA logon page.
How Do I Enable FBA for External and Internal OWA 2010 Users?
Okay so how can we enable FBA for external and internal OWA 2010 users? Well, there are several ways to accomplish this:
- Have internal users pointed to the internal interface of the Forefront TMG and utilize the forms-based authentication logon page offered by Forefront TMG.
- Deploy Forefront UAG instead of Forefront TMG. Forefront UAG allows you to have FBA enabled on both the Exchange 2010 Client Access Servers and on the Forefront UAG solution itself.
- Publish Exchange 2010 to the Internet using Forefront TMG but do not configure pre-authentication. This way the users need to go through the Forefront TMG solution, but will authenticate directly against the Exchange 2010 Client Access servers.
- Configure an additional OWA and ECP virtual directory on the Exchange 2010 Client Access Servers.
In this article, I’ll show you the last option which if you ask me is the most elegant one. For large corporate enterprises, I don’t like to route traffic out to the Forefront TMG array in the perimeter network and back onto the Exchange multi-role servers after the user has authenticated. Forefront UAG is definitely an option, but there’s a chance Forefront UAG doesn’t match in with the overall expectations set by the corporate enterprise. Having users authenticated directly against the Exchange 2010 Client Access servers’ kind of defeats the purpose of publishing Exchange 2010 using Forefront TMG 2010. Of the primary benefits of publishing Exchange using Forefront TMG is the fact that users can be pre-authenticated before they are permitted access to the Exchange 2010 Client Access servers on the internal corporate network. This is actually a requirement I often see when involved in customer engagements.
Adding an Additional IP Address to Each Exchange 2010 Server
The first step in order to enable FBA for external and internal OWA users is to add an additional IP address to each of the four Exchange 2010 multi-role servers. In the following, I’ll show you how to add an additional IP address to the first Exchange 2010 multi-role server.
You need to use a unique (different) IP address for each Exchange 2010 server.
Open “Network Connections” then open the property page for the PROD network interface. In Figure 7, you also see a REPLICATION interface since these servers participate in a DAG.
Figure 7: Opening the property page for the PROD interface
Now take properties for “Internet Protocol Version 4 (TCP/IPv4)”.
Figure 8: Opening the property page for TCP/IPv4
Figure 9: Clicking Advanced under the General tab
On the IP Settings tab under IP Addresses, click Add and then enter an IP address that isn’t used on the network. Then click Add and OK.
Figure 10: Adding an additional IP address to the PROD interface
It’s highly recommended you install the hotfix mentioned in this Microsoft KB article on all client access servers on which you configure multiple OWA/ECP virtual directories and configure the “skipassource” flag accordingly. If you don’t you most likely will see issues with opening the Exchange Management Console (EMC) and Exchange Management Shell (EMS). The reason for this is because the PowerShell virtual directory has it’s URL configured to point at “http://CAS_server_FQDN/PowerShell” and not to a load balanced FQDN and therefore sometimes will try to access the PowerShell virtual directory under the second web site, where it doesn’t exist.
Okay we have now reached the end of part 1 in this articles series, but you can look forward to part 2 being published in a near future. Until then have fun!
If you would like to read the other parts in this article series please go to: