Skip Ribbon Commands
Skip to main content
Mark E. Smith's Brain Dump > Posts > Securely Publishing Microsoft Exchange Server With Forefront Unified Access Gateway (UAG) – Part 3
July 16
Securely Publishing Microsoft Exchange Server With Forefront Unified Access Gateway (UAG) – Part 3

Jan 17, 2011
UPDATE: The following support statement was posted on the MS Exchange PG blog site yesterday. Therefore the process (publishing multiple OWA vDir's on any TCP port other than 443) in this blog article is NOT supported by Microsoft. I will update this article with a supported method shortly.
http://msexchangeteam.com/archive/2011/01/17/457664.aspx

In Part 3 of this series we will focus on securely publishing Outlook Web App to the internet via UAG. This particular topic has been covered many times using both ISA and TMG by fellow bloggers. In this article I'm going to add some interesting challenges by adding some real world business requirements.

Requirement 1: The Exchange environment consists of Exchange 2003, 2007, and 2010.
Requirement 2: All users must use a same namespace to access OWA regardless of the version of Exchange on which their mailbox resides.
Requirement 3: All users must have a Single Sign On (SSO) experience.
Requirement 4: Forms Base Authentication must be used for OWA both Internally and Externally.
Requirement 5: The use of redirection i.e. "Your best OWA experience is… click here" to get from one version of OWA to another may not be used.

Now that we have our requirements, let's first address our internal OWA requirements then we'll focus on our External (UAG) OWA tasks. Our single namespace for OWA that users will need to remember is: mail.exchange.capaxglobal.net so, let's look at the steps that OWA uses when you try to access an Exchange 2007 mailbox through OWA 2010.

  1. Exchange 2010 CAS will query AD for an Exchange 2007 CAS server with an ExternalURL property set on the OWA Virtual Directory AND where the ExternalAuthenticationMethods matches the InternalAuthenticationMethods of the Exchange 2010 CAS. If the InternalAuthenticationMethods value for the Exchange 2010 CAS server is Forms Based Authentication then Single Sign On (SSO) will occur for the Exchange 2007 user, otherwise the user will be prompted to authenticate again.
  2. If no CAS is found using criteria 1, Exchange 2010 CAS queries AD for any Exchange 2007 CAS with the ExternalURL set and then sends the Redirection screen to the browser with ExternalURL value.
  3. If no CAS is found using criteria 1 or 2, Exchange 2010 CAS queries AD for any Exchange 2007 CAS with an internalURL value and matching InternalAuthenticationMethods of 2010. If this is found AND the Authentication type is FBA then SSO occurs, otherwise the user will be prompted to authenticate again.
  4. If no CAS is found using criteria 1, 2, or 3, then Exchange 2010 CAS queries AD for any Exchange 2007 CAS with an internalURL value and sends the Redirection screen to the browser with the internalURL value. SSO typically fails here.

Since our internal OWA 2010 authentication is Forms Based Auth and we have a requirement for SSO across all versions of Exchange, we'll configure Exchange using criteria 1. So, let's configure Exchange 2007 using:

Set-OwaVirtualDirectory "E2K7HUBCAS01\owa (Default Web Site)" -ExternalUrl https://legacy.exchange.capaxglobal.net/owa -ExternalAuthenticatioMethods "Basic","Fba" -FormsAuthentication $true -BasicAuthentication $true -WindowsAuthentication $false -DigestAuthentication $false

 Now let's confirm that we can log into our Exchange 2007 mailbox using CAS 2010 with SSO from the inside network:

Great! Single Sign On at the OWA 2010 Authentication Prompt and my Exchange 2007 mailbox is opened. Notice the URL is now legacy.exchange.capaxglobal.net

Now for the easy part – adding SSO to Exchange 2003. If you recall, Exchange 2007 will act as an Exchange 2003 Front End server, so all we really need to do now is to redirect users to the /exchange Virtual Directory on Exchange 2007 CAS to get to Exchange 2003 (ok you might need to re-read that a few times for it to sink in).

So, let's just configure the OWA 2010 Virtual Directory and set the -Exchange2003Url parameter to https://legacy.exchange.capaxglobal.net/exchange but let's examine what happens here. The user gets the OWA 2010 FBA screen, enters his/her credentials. CAS 2010 determines that the user's mailbox is on Exchange 2003 and then sends an HTTP post back to the URL specified in the Exchange2003URL property which, of course is our Exchange 2007 server acting as an Exchange 2003 Front End.

So, after configuring the property, let's test:

Perfect! Our requirements are now met internally. Now let's finish publishing the solution to the Internet via UAG.

Now, it might have occurred to those of you who are familiar with this process using ISA server that ISA can't authenticate to OWA on an internal CAS or Front End server if FBA auth is enabled internally. In short, the recommended approach has (and still is) to use Basic Auth on the internal OWA site(s) and then configure ISA to pass the credentials using 401 Basic Auth to CAS/FE.

But how do we meet our requirements of having FBA internally and UAG/ISA/TMG's need for a 401 Basic Auth?... We'll create another OWA Virtual Directory on CAS just for UAG and configure it for Basic Auth. Then we'll direct UAG traffic to this OWA Virtual Directory and direct internal users to the default FBA OWA Virtual Directory.

So, let's review how we'll accomplish this?

  1. We'll create a new IIS Web Site and configure it to listen for HTTP and HTTPS on TCP 81 and 444 respectively.
  2. We'll then use the same SSL certificate that we're using on our existing IIS site.
  3. Add new OWA and, for Exchange 2010, ECP Virtual Directories.
  4. Configure these Virtual Directories with the proper URL's and Authentication Type.

Since we're publishing OWA 2010, 2007, and 2003 we'll need to do this process both on Exchange 2010 CAS and 2007 CAS. So, rather than walking you through the process manually, I've provided a PowerShell script below.

The Exchange 2010 version:

# Exchange 2010 New IIS Web Site, OWA and ECP Virtual Directory Creation Script
# Let's get some environment variables


$systemroot = gc env:systemroot
$localserver = gc env:computername


# Capture the current OWA and ECP Virtual Directories to some PS objects
$currOWAvDir = Get-OwaVirtualDirectory -Server $localserver
$currECPvDIR = Get-ECPVirtualDirectory -Server $localserver


cd $systemroot\system32\inetsrv\

# Let's create the new IIS web site and bind it to TCP 81 and 444 for HTTP and HTTPS respectively
.\appcmd.exe add site /name:"OWA Basic Auth" /id:12345678 /physicalPath:%SystemDrive%\inetpub\wwwroot /bindings:http/*:81:`,https/*:444:

# Let's require SSL
.\appcmd.exe set config "OWA Basic Auth" /section:access /sslFlags:Ssl`,Ssl128 /commit:apphost


# Caputre the current Cert that's used by Exchange for IIS
$cert = Get-ExchangeCertificate | where {$_.Services -like "*I*"}


# grab its thumbprint
$thumb = $cert.Thumbprint


# Now let's bind that cert to our new website.
netsh.exe http add sslcert ipport=0.0.0.0:444 certhash=$thumb appid=`{ab3c58f7-1234-42e3-bc6e-771d4ce4b201`}


# Now that our website is created, let's create the OWA vDIR in it and set its URL's and auth to basic.
# Then we'll just make sure our default web site (that users will hit) is set to FBA Auth


New-OWAVirtualDirectory -WebSiteName "OWA Basic Auth"
Set-OwaVirtualDirectory "$localserver\owa (OWA Basic Auth)" -InternalUrl $currOWAvDir.InternalURL -ExternalURL $currOWAvDir.ExternalUrl -Exchange2003URL $currOWAvDir.Exchange2003URL -basicAuthentication $true -FormsAuthentication $false -WindowsAuthentication $false

Set-OwaVirtualDirectory "$localserver\owa (Default Web Site)" -basicAuthentication $true -FormsAuthentication $true -WindowsAuthentication $false

New-ECPVirtualDirectory -WebSiteName "OWA Basic Auth"
Set-EcpVirtualDirectory "$localserver\ecp (OWA Basic Auth)" -InternalUrl $currECPVDIR.InternalURL -ExternalURL $currECPVDIR.ExternalUrl -basicAuthentication $true -FormsAuthentication $false -WindowsAuthentication $false


Set-EcpVirtualDirectory "$localserver\ecp (Default Web Site)" -basicAuthentication $true -FormsAuthentication $true -WindowsAuthentication $false

The Exchange 2007 Version 

# Exchange 2007 New IIS Web Site, OWA Vdir Creation Script
# Let's get some environment variables


$systemroot = gc env:systemroot
$localserver = gc env:computername


# Capture the current OWA vDir to a PS objects
$currOWAvDir = Get-OwaVirtualDirectory -Server $localserver


cd $systemroot\system32\inetsrv\

# Let's create the new IIS web site and bind it to TCP 81 and 444 for HTTP and HTTPS respectively
.\appcmd.exe add site /name:"OWA Basic Auth" /id:12345678 /physicalPath:%SystemDrive%\inetpub\wwwroot /bindings:http/*:81:`,https/*:444:


# Let's require SSL
.\appcmd.exe set config "OWA Basic Auth" /section:access /sslFlags:Ssl`,Ssl128 /commit:apphost


# Caputre the current Cert that's used by Exchange for IIS
$cert = Get-ExchangeCertificate | where {$_.Services -like "*I*"}


# grab its thumbprint
$thumb = $cert.Thumbprint


# Now let's bind that cert to our new website.
netsh.exe http add sslcert ipport=0.0.0.0:444 certhash=$thumb appid=`{ab3c58f7-1234-42e3-bc6e-771d4ce4b201`}


New-OWAVirtualDirectory -OwaVersion:Exchange2007 -webSiteName "OWA Basic Auth"
New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType Mailboxes -Name "exchange" -WebSiteName "OWA Basic Auth"
New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType PublicFolders -Name "public" -WebSiteName "OWA Basic Auth"
New-OWAVirtualDirectory -OwaVersion:Exchange2003or2000 -VirtualDirectoryType Exchweb -Name "exchweb" -WebSiteName "OWA Basic Auth"


Get-OwaVirtualDirectory -Identity "$localserver\owa (OWA Basic Auth)" | Set-OwaVirtualDirectory -InternalUrl $currOWAvDir.InternalURL -ExternalURL $currOWAvDir.ExternalUrl -basicAuthentication $true -FormsAuthentication $false -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\owa (Default Web Site)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $true -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\Exchange (OWA Basic Auth)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $false -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\Exchange (Default Web Site)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $true -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\Public (OWA Basic Auth)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $false -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\Public (Default Web Site)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $true -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\Exchweb (OWA Basic Auth)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $false -WindowsAuthentication $false
Get-OwaVirtualDirectory -Identity "$localserver\Exchweb (Default Web Site)" | Set-OwaVirtualDirectory -basicAuthentication $true -FormsAuthentication $true -WindowsAuthentication $false

 

Ok so now that we ran our scripts on both E2010 CAS and E2007 CAS let's review what we now have in IIS and the Shell.

We now have two Web Sites in IIS (Default Web Site) and (OWA Basic Auth) bound to the same IP but listening to TCP 80/443 for the Default Site and TCP 81/444 for the OWA Basic Auth site. The same SSL Cert that we configured for our Default Web Site is bound to our new OWA Basic Auth Site.

The same configuration should now exist on your Exchange 2007 CAS (I'll omit screen grabs to save space).

Now that we have CAS configured properly for UAG and FBA Auth inside, let's publish OWA!

Right click on the ExchangePortal and select Add Application

At the Select Application Wizard select "Web – Microsoft Exchange Server (all versions)"

Select Microsoft Exchange Server 2020, Outlook Web Access

Name the Application "Exchange 2010 Outlook Web App"

At the Endpoint Policy page select the OWA 2010 policies for Upload and Download.

Step 5 asks you whether you want to deploy a single web site or load balancer VIP using the "Configure an application server" option or to "Configure a farm".

I recommend that you configure a farm of application servers EVEN if you have an internal hardware load balancer and ESPECIALLY if you're using Windows Network Load Balancer to balance CAS. The reason is that unless you have configured Layer 7 policies on your Hardware Load balancer and are doing cookie persistency for Outlook Web, you're probably using source IP address persistency. Since all of the external OWA requests hitting your load balancer will have a source IP address of the internal network interface of the UAG server, this would result in all OWA requests being persistent to one CAS server. So my recommendation is to almost always configure a farm of application servers and let UAG do the health checks and load balancing across your CAS servers.

Now let's configure UAG to load balance our CAS servers. Enter the internal FQDN of each real CAS server in this Data Center (AD Site) that UAG will be publishing. Next change the HTTPS port to TCP 444 (Remember this is the TCP port that CAS is listening on for our Basic Auth OWA site). Next, configure the Public Host Name (if it will be different from the main UAG Portal Name that we configured in Part 2 of this series. Note: If the public host name is different from the portal name then it must be a SAN on the certificate. Finally select Cookie-based affinity. Since we're terminating SSL at the UAG server and then re-encrypting when we send it back to CAS UAG server will inspect the OWA cookie and maintain persistency between the browser session and the real CAS server. This is the best way to truly balance OWA traffic and is recommended over source IP address. With Source IP address a single IP address (like an office behind a Hide-NAT device) will all appear to UAG as a single IP address. Therefore all of the OWA sessions in that office will maintain persistency to the same real CAS server on your internal network.

In step 7 we setup our healthchecks. This is the method that UAG server will use to determine if a real CAS server is online and healthy. The options are to ping the server – which isn't ideal because IIS could be down but the server might be up and UAG would send OWA traffic to that server. The recommended way to maintain a health check is to have UAG send and HTTP GET request to the physical server. For the purposes of this series we'll just use the root of the IIS web site "/" and UAG will look for a HTTP 200 status code. If you wanted to really monitor OWA and ensure that its App Pool hadn't crashed you could use:

/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fmail.exchange.capaxglobal.net%2fowa%2f

And replace the principal name on the CAS certificate with yours e.g. mail.exchange.capaxglobal.net

           

In Step 8 we'll configure UAG how to authenticate to the CAS servers using 401 (Basic Auth). Now, you might say to yourself "Hey what's that HTML Form" option? Well, after experimenting with this I've found that *IF* you're only publishing Exchange 2010 then UAG _CAN_ actually authenticate to an Exchange 2010 CAS that has FBA enabled. However, I've been told by Microsoft that this isn't officially supported. Furthermore, in my testing, I found that using HTML form Auth does not properly follow the HTTP postback that Exchange 2010 will send if the user's mailbox is on Exchange 2007 or 2003. Therefore, we'll stick with what does work and what is supported – 401 request (Basic Auth).

Now we'll create the Link that will appear for Outlook Web App in the UAG Portal. The two things that I like to change here is the Portal Name – My Preference is to not make this portal link Exchange version specific, after all we want to simplify the experience for our users and Exchange 2010 will proxy to Exchange 2007 and redirect to Exchange 2003, so let's give our users one button to click for OWA no matter what version of Exchange they're on. Second, you have the option to have UAG open a new browser for OWA. This is a personal preference, but we'll uncheck this and put OWA in the portal frame.

In step 10 you have the option to select what users (based on AD Users and/or Groups) are authorized to access OWA from via the UAG server. For example, you may want to allow all users to access OWA from the internal corporate network, but only allow a sub-set to access OWA from the Internet. You could create a security group in AD called "Internet OWA Users" and then select this group in the UAG Authorization option for the OWA application. For the purposes of this article, we'll authorize all users.

Click next and complete the Application Publishing Wizard.

Now a few optional configuration options before we test.

You may have noticed on the Main ExchangePortal screen that we created there is an option for "Initial Internal Application". Until we added our first application the only option was "Portal". This option allows you to select what internal application will automatically launch when users log into the UAG portal. Since all users in the company use Email and this is a series about publishing Exchange, let's change the initial application to "Exchange 2010 Outlook Web App". Also, let's check the box to use the Portal Frame so we get an idea of what UAG will bring to the OWA experience.

Next, let's change the UAG Portal Logon and allow for users to change their passwords. Under the Trunk Configuration click "Configure"

First let's change the look of the plain UAG portal to the familiar Exchange 2010 OWA look and feel. Again, this is optional and I would encourage you to play with these settings and think beyond Exchange since you may decide to use UAG to publish other applications. Next let's let users to change their passwords and notify them that their passwords will expire (I'll select 12 days for the notification).

NOTE: The ability to change passwords will only work if you properly delegated the change password right in AD that we reviewed in Part 2 of this series.

Finally, I mentioned earlier in this series that not only would we use AD Authentication but we would also configure RSA SecurID. Therefore we're going to select the option to Require users to authenticate to each server (even though we only have Active Directory set as the Authentication server right now). Since we'll assume that our RSA SecurID usernames are the same as our Active Directory usernames, we'll check the box "Authenticate to each server with the same username".

So we're all set to activate our new configuration! Click the gear icon in the UAG Management Console.

Ok it's time for a cup of coffee as this may take a few minutes…

Now we can wait a few moments for UAG to configure and sync the TMG Storage.

On to the test. Open IE and navigate to the UAG Portal FQDN. It will take a little bit longer for the .NET App Pool to spin up on the UAG server upon the first connection but eventually you'll get the logon page:

Notice that the Password prompt displays the name that we used in the Active Directory Authorization Server. This will become more important once we add RSA SecurID Authentication. Ok so let's logon!

The portal will open up and OWA should automatically appear in the portal frame.

           

Now that we've successfully published Exchange 2010, let's publish Exchange 2007 and 2003 and make all three versions co-exist!

We already have our Exchange 2010 application published in our Trunk, now all we need to do is to publish the Exchange 2007 CAS since it will be used for both our Exchange 2007 OWA experience and serve as our Exchange 2003 Front End Server.12

So, open the UAG Management Console, Expand the Exchange Portal trunk and then add a new application to the trunk.

           

I'll skip all of the screen shots since the wizard is the same as Exchange 2010 unless warranted.

Step 1: Select Web, Microsoft Exchange Server (all versions).

Step 2: Choose Exchange Server 2007, Outlook Web Access.

Step 3: Application Name: Exchange 2007/2003 Outlook Web Access.

Step 4: Endpoint Policies: Leave Access and Restricted zone as their defaults and Choose Microsoft OWA 2007 Upload and Download for the respective Upload and Download policies.

Step 5: Configure a Farm of Application Servers.

Step 6: Enter your Exchange 2007 CAS servers. IMPORTANT: In the Public host name, make sure you use the Exchange 2007/2003 namespace. In our example, we're using "legacy".

Step 7: Leave all of the defaults for the Connectivity Verifiers (or see the above step for a more specific method – be careful to update the URLs properly for Exchange 2007).

Step 8: Select the Active Directory Authentication Servers and 401 request as the authentication method that CAS will require from UAG.

Step 9: Use the defaults in the Portal Link (we'll come back to this section after we test the solution).

Step 10: Authorize all users.

Now that we've added the Exchange 2007/2003 application, Activate the configuration and after it's completed, let's test.

First, let's login with our Exchange 2007 test account, and we should automatically be redirected to the OWA 2007 experience.

Now, let's login with our Exchange 2003 mailbox and we should have the same experience. Uh oh – a problem. I see Exchange 2003 but it's not rendering properly.

This is actually a know issue with UAG. To correct it, Edit the Exchange 2007 OWA application Properties, navigate to the Web Settings tab, and check the "Evaluate without enforcement" box. Then Activate the Configuration.

Let's try again with our Exchange 2003 user. Success!

Now, for our final "tweak" to the user experience. You'll notice that in the UAG Trunk portal we have application icons for both Exchange 2010 and Exchange 2007/2003. However, we've configured Exchange 2010 CAS to automatically redirect the user to the proper URL which maps to a UAG application. Therefore there's no need to display the Exchange 2007/2003 Icon to the user. No matter what Exchange version their mailbox resides on, they will be automatically logged into the proper version. So let's remove the icon for OWA 2007/2003 and only give them the OWA 2010 icon.

Highlight the OWA 2007 Application, click Edit, scroll over to the Portal Link tab and uncheck the "Add portal and toolbar link" box. Now reactive the configuration and let's test again.

           

           

No more Exchange 2007/2003 icon – users have one application to click on to get ANY OWA experience. When you migrate their mailbox from 2003 to 2007 or 2010 or from 2007 to 2010 they still follow the same logon process.

Congratulations! We've now successfully published OWA 2010, 2007 and 2003 securely to the Internet using a UAG portal, met our business requirements, and given users a uniform and secure way to access OWA on both the Corporate network and Public Internet. In the next parts of this series we'll publish Exchange ActiveSync, Outlook Anywhere, and add RSA SecurID Authentication to the UAG portal.

Other parts of this series:

 

 

 

Comments

There are no comments for this post.