By now, many of you have seen the articles that discussed Address Book Policies, hosting changes, and the Hybrid Configuration Wizard, but deep down I know you all have been hoping that we would discuss the most sought after feature that we decided to include in Exchange 2010 SP2.
What’s that you say? Yes, I know, Tony said that the “new features in SP2 are unlikely to cause much of a fuss” and that there are not that many new features in SP2 (I believe his exact words were “relative paucity”) in his SP2 announcement article over at Windows IT Pro.
Well, I'm here to set the record straight. There's one killer feature in Exchange 2010 SP2, that's often not mentioned. That's right – it's time to discuss Cross-Site Silent Redirection for Outlook Web App!
Definitions
First, let’s go over some definitions to make sure we are all on the same page.
- Internet-facing Active Directory Site An Active Directory site that contains CAS that have an ExternalURL populated for the associated service (like OWA). Typically this is the primary datacenter/site where Exchange 2010 is deployed.
- Regional Internet-facing Active Directory Site An Active Directory site that contains CAS that have an ExternalURL populated for the associated service (like OWA).
- Non-Internet-facing Active Directory Site An Active Directory site that contains CAS that do not have an ExternalURL populated for the associated service.
- Direct Connect The process where CAS establishes an RPC session with the Mailbox server hosting the mailbox data.
- Proxy The process where a CAS in an Internet-facing Active Directory site proxies incoming requests to a CAS in a Non-Internet-facing Active Directory site (that's located in the same site as the Mailbox server being accessed).
- Redirection The process where an Internet-facing CAS in one Active Directory site redirects the end user to another Internet-facing CAS that resides in the same site as the Mailbox server being accessed.
- Silent Redirection The process by which CAS issues a silent redirect back to the user’s browser, telling the browser to establish a connection to a specified URL.
- Single Sign-On (SSO) Redirection The process by which CAS issues a silent redirect back to the user's browser, telling the browser to submit the request and authentication credentials to a target CAS so that the login experience is seamless.
OWA Connection Process
In order to understand the various proxy and redirection scenarios, it's important to understand the mechanics behind what happens when a user authenticates against a CAS to access OWA as it happens today with Exchange 2010 pre-SP2:
- User accesses OWA URL using web browser.
- User enters credentials.
- CAS authenticates user and retrieves the following information via service discovery request:
- User's mailbox version
- User's mailbox location (Active Directory site), if known
- CAS gathers additional information based on mailbox information so that it can perform the correct operation:
- If mailbox is Exchange 2010 and local, CAS performs direct connect.
- If mailbox is Exchange 2007 and local, CAS retrieves the ExternalURL of an Exchange 2007 CAS (if one isn't defined it'll use the InternalURL) and silently redirects.
- If mailbox is Exchange 2003, CAS retrieves Exchange2003URL and silently redirects.
- If mailbox is not local, CAS retrieves target ExternalURL (if defined) and redirects or proxies if no OWA ExternalURLs are defined in the target Active Directory site.
SP1 OWA Redirection Types
In Exchange 2010 SP1, we changed things slightly which resulted in three types of redirection experience for OWA in the on-premises product:
- Manual Redirection
- Temporary Manual Redirection
- Legacy Silent Redirection
Manual Redirection
Manual redirection enables customers to not have to funnel and proxy all traffic from a central location when there are CAS closer to the user’s mailbox.
Manual redirections are performed when CAS must redirect an OWA request to Exchange 2007 or Exchange 2010 CAS infrastructure that's located in a different Active Directory site. As mentioned previously, in order for a manual redirection to be performed, the target OWA virtual directory must have an ExternalURL. Your users see the following manual redirection message and the ExternalURL of the CAS in the other Active Directory site:
Figure1: Manual redirection when mailbox is located in another Active Directory site
Temporary Manual Redirection
In SP1, we added another redirection type for OWA, known as Temporary Manual Redirection. There are two scenarios where Temporary Manual Redirection comes into play:
-
During a datacenter activation switchback event, there exists the possibility that the user’s web browser still has the incorrect DNS entry cached and thus is pointing to the CAS infrastructure in the Ative Directory site that no longer hosts the mailbox. As a result, the CAS will issue a manual redirect to the correct Active Directory site, but the redirection is to the same URL that the user is currently using. To prevent a ping-pong effect where the user cannot access his mail, CAS will detect if the same session cookie is being returned and if so, will check to see if the target CAS has a FailbackURL value for the OWA virtual directory. If a FailbackURLis specified, then CAS issues a temporary manual redirection page providing the FailbackURL link. If a FailbackURL is not specified, CAS issues an error page asking the user to close all browser sessions and to try again.
Figure 2: Temporary manual redirection upon datacenter activation switchback -
The second scenario is where CAS will issue the temporary manual redirection page when it detects that the local CAS's site matches that of the Mailbox databases's RpcClientAccessServer value, but the database is actually mounted in a different Active Directory site, so CAS issues a temporary redirect with the ExternalURLof the CAS in the site hosting the mounted database.
Figure 3: Temporary manual redirection when mailbox is mounted in another Active Directory site
Legacy Silent Redirection
For Outlook Web Access, Exchange 2010 CAS does not support rendering mailbox data from legacy versions of Exchange. Exchange 2010 CAS does one of four scenarios depending on the target mailbox's version and/or location:
- If the Exchange 2007 mailbox is in the same Active Directory Site as CAS2010, CAS2010 will silently redirect the session to the Exchange 2007 CAS.
- If the Exchange 2007 mailbox is in another Internet-facing Active Directory Site, CAS2010 will manually redirect the user to the Exchange 2007 CAS.
- If the Exchange 2007 mailbox is in a non-Internet-facing Active Directory site, CAS2010 will proxy the connection to the Exchange 2007 CAS.
- If the mailbox is on an Exchange 2003 server, CAS2010 will silently redirect the session to a pre-defined URL.
As indicated above, legacy silent redirection is only used for same-site redirection events between an Exchange 2010 CAS and the legacy infrastructure. When performing the legacy silent redirection, CAS2010 issues a silent redirect back to the user’s browser, telling the browser to establish a connection to legacy CAS2007/FE2003 infrastructure. In order to successfully redirect to the legacy infrastructure, the following must be configured:
- To redirect Exchange 2003 mailboxes, the Exchange 2010 OWA virtual directory must have the Exchange2003URL populated.
- To redirect to an Exchange 2007 CAS, the target Exchange 2007 OWA virtual directory must have the ExternalURL.
Legacy Silent Redirection can also provide a single sign-on experience when Forms-Based Authentication (FBA) is used on the source and destination OWA virtual directories by issuing back to the web browser a hidden FBA form with the fields populated. This hidden form contains the same information as what the user had originally submitted to CAS2010 FBA page (username, password, public/private selector) as well as, a redirect to the target Exchange specific path and query string. As soon as this form is loaded it is immediately submitted to the target URL. The result is the user is automatically authenticated and can access the mailbox data.
What’s wrong with Manual Redirection?
At first glance, you might think, “hey, manual redirection is great, Microsoft” and to some extent you are correct. It is a great feature for the IT organization to control where users access their data (and thus forcing users to utilize the correct network links). But in reality, the experience is not optimal for the end user. In the scenario where the user uses the wrong OWA URL, the user performs the following actions:
- User enters into the web browser the wrong URL.
- User enters credentials and authenticates against CAS (wrong site).
- CAS (wrong site) performs service discovery and determines that it can redirect user to the correct CAS.
- CAS (wrong site) provides the user with a page that contains a link to CAS (correct site).
- User clicks link to access OWA from the correct site.
- User enters credentials and authenticates against CAS (correct site).
It’s this experience where the user is told they used the wrong URL and that he has to enter his credentials twice that are the sub-optimal experiences with manual redirection.
Cross-Site Silent Redirection in Exchange 2010 SP2
To remove this sub-optimal experience (Greg refers to this as a crappy experience, by the way), we've provided a fourth redirection experience for OWA in Exchange 2010 SP2, known as Cross-Site Silent Redirection. As its name implies, Cross-Site Silent Redirection only performs silent redirection for requests that are destined to CAS located in another Active Directory site (within the same Exchange organization) that have an OWA ExternalURL.
A new parameter has been created to support Cross-Site Silent Redirection, CrossSiteRedirectType. This parameter is available on the Set-OWAVirtualDirectory cmdlet and supports two values, Manual and Silent. Cross-Site Silent Redirection is disabled by default (the default value is Manual), meaning that if you currently perform manual redirection between CAS in different Active Directory sites, it will continue after you deploy SP2.
If you want to enable Cross-Site Silent Redirection, set the CrossSiteRedirectType to Silent on the Internet-facing CAS OWA virtual directories:
Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent
We've updated the OWA connection process to support Cross-Site Silent Redirection. The CAS performs the following steps during service discovery:
- Evaluate the mailbox version (either Exchange 2007 or Exchange 2010).
- Check the mailbox's location.
- Obtain the ExternalURL of target CAS.
- Obtain the redirection type on the source CAS.
- If CrossSiteRedirectType=Manual, we issue a manual redirect.
- If CrossSiteRedirectType=Silent, we issue a silent redirect.
- If source and target CAS have FBA enabled, then the source CAS issues a hidden form back to the browser that contains the user’s credentials and FBA settings, along with the redirect URL.
- If FBA is not enabled on source and target, source CAS simply issues a 302 redirect.
That’s right; Cross-Site Silent Redirection can be a SSO experience when the source and target OWA virtual directories leverage Forms-Based Authentication. Customers that only deploy OWA internally can also achieve a SSO experience when the OWA virtual directory authentication mechanism is Windows Integrated Authentication and the OWA namespaces are added to the “Local Intranet” security zone.
When can I not obtain a SSO Experience?
These are the few scenarios where you can't obtain a SSO experience when redirecting between Active Directory sites:
- You use Basic Authentication on the source and target OWA virtual directories.
- You leverage different authentication settings on the source and target OWA virtual directories.
- You leverage a two-factor authentication solution on the source and target OWA virtual directories.
- You leverage a pre-authentication solution (like Microsoft Threat Management Gateway 2010) that uses different web listeners for the source and target OWA namespaces.
- When the local CAS issues a temporary redirection to another CAS in another Active Directory site.
Keep in mind, that while the SSO experience will be unavailable for these scenarios, a 302 redirection (what we refer to as a silent redirection) will still occur.
Cross-Site Silent Redirection reduces the end user dissatisfaction around having to click a link to get to the correct OWA infrastructure, and may in fact remove the need to enter credentials a second time. For those of you that have been using OWA Manual Redirection up to now, I hope you will enable Cross-Site Silent Redirection when you deploy Exchange 2010 SP2!
Principal Program Manager
Exchange Customer Experience