Exchange 2010 SP2: OWA Cross Site Silent Redirection (update of old blog post from May 2011)
So back in May 2011, I explained what the new OWA cross site silent redirection was all about. Since then my Wiki page on the private Exchange Wiki has been updated. Here’s the most recent version.
As many of you know with OWA 2010 RTM and SP1 (and OWA 2007 for that sake), when a user hits a CAS server in the wrong AD site (that is another AD site than where the user’s mailbox is located), the user will be either proxied or redirected to the correct AD site depending on whether an external OWA URL has been specified or not. If no external URL has been specified for the OWA vdir on the CAS servers in the AD site holding the user’s mailbox, the CAS server in the “wrong” AD site will try to proxy the request to a CAS server in the “right” AD site. If the OWA vdir on the CAS servers in the right AD site has been configured with integrated authentication, the users will experience SSO (only be prompted for credentials once).
However, if an external URL has been specified for the OWA vdir on the CAS servers in the AD site where the user’s mailbox is stored, the CAS server in the “wrong” AD site will initiate a redirect instead of a proxy. Let’s say the user hits https://failover.exchangeonline.dk/owa which points to another AD site than where his mailbox is located, he will will be presented a screen similar to the following:
After clicking on the link that points to the right AD site, he will be prompted for credentials once again:
Now although this forces the user to connect to a CAS server in the “right” AD site, it doesn’t provide a real SSO experience.
Exchange 2010 SP2 will improve the redirection experience by offering a mechanism that will let the user experience a cross site redirection SSO if FBA is enabled in both sites and a CAS provides the form. What does that mean? Well, it means that the user will be redirected automatically (will not have to click manually on a link) and not only that, he will also be allowed access to the mailbox without having to authenticate. This won't work however if the form is being generated in front of Exchange, for example, by TMG.
By the way, internally at Microsoft this feature has already been enabled making the login experience for the respective regions much more seamless.
Technology Architect/Writer/MS Vendor
MCM: Exchange Server | MVP: Exchange Architecture