When migrating to Office 365 users must retain access to Outlook Web Access. While the guides for the OWA access are present, users see themselves being challenged for username and password multiple times. This is even worse when most users are located on Exchange 2007 in a mixed environment.
In order to cope with this problem TMG can be setup to only authenticate users once. Even more, users can also be authenticated already when they are sent to the Office365 OWA site and need to request a token from the ADFS server.
This scenario takes the following into account:
• Users are located on a legacy Exchange 2007 environment
• Users are located on an Exchange 2010 environment
• Users are located on Office 365
Single, dual or tripple URL
While each service has its unique OWA access URL, users can type the URL of the service they are located on, thus Exchange 2007 users use for example legacy.company.org, 2010 users use newmail.company.org and Office 365 users use outlook.com/company.org to access OWA services. While the Exchange 2010 CAS (since SP1) can point users to the right location of their mailbox, this CAS server can be used as a central accesspoint. Thus users would only type in newmail.company.org, login to the system and see a redirection to either Office365 or the Exchange 2007 URL (will be fixed in SP2 so that users are automatically sent to these URL’s without the need to click again). Problem here is that when the user is pointed to the new URL, they are requested to re-enter their credentials.
Dual URL
When users will receive a new OWA URL after being migrated (can be part of the migration notifications sent), users only have an on-premise URL (either 2010 or 2007 depending on where the users are located). This could be the easiest fix when all users are in Exchange 2007 and thus the 2010 CAS servers are only added for co-existence with Office 365. When users are on both systems, TMG comes in to play.
In the above picture users are only located on Exchange 2007 or Office 365. There is no active publishing to the OWA URL of Exchange 2010. When users type in the Exchange 2007 URL they are validated by the TMG server and see their OWA mailbox. When they type the name of the new URL they can be sent to an IIS redirection website that redirects the user using smart-linking. It is even possible to add authentication to this URL to avoid anonymous publishing of sites. In that case the SSO domain can help again. As the user is sent to the federation server as part of the logon process, the user is already authenticated and can open the Office 365 OWA.
Single URL
Within TMG there is an option to specify an SSO domain for a web listener, this option allows users to only validate once on a particular web listener and be authenticated on multiple rules that use this listener. How that authentication takes place does not really matter. After configuring this option the web listener can use multiple webserver publishing rules: one for Exchange 2010, one for Exchange 2007 and one for Office 365 – ADFS access. By combining these rules, the user will be asked once for username/password/token and this session will be applicable for all these services during the session. In order for this to work, the Exchange OWA pages will need to be configured to use Windows Authentication and TMG must be allowed to use Kerberos constrained delegation with protocol transition to the OWA URL SPN’s and/or servers HTTP SPN.
In the above picture, the user experience is displayed for accessing OWA through a single URL. When a user opens the main OWA URL, the request comes in at TMG. TMG will present the user with a forms-based authentication page. The user logs in and the TMG will request a Kerberos ticket for the user to access the Exchange 2010 OWA page. The Exchange 2010 OWA will use integrated authentication, thus access with a Kerberos token is enough to authenticate to the service. When the user’s mailbox is on Exchange 2010, the OWA mailbox is displayed. It could however also be that the mailbox is on Exchange 2007. In that case the user is redirected to the legacy Exchange URL known to the 2010 CAS server. The browser of the user points to the new URL that comes in at the same listener. While the user still has his session open, the forms-based login page will be skipped and TMG will request a new Kerberos ticket on behalf of the user to login to Exchange 2007 OWA. When the user has the mailbox in Office 365 a link will be shown. As soon as the user clicks on the link, it is sent to the Online services OWA access page, which in return will request an ADFS token. The user must receive its token from the on-premise federation service. Thus the user again ends up at the TMG on the same listener, is already authenticated and thus TMG will request a Kerberos ticket for the on-premise federation service.
When users access each URL without prior authentication, the forms-based logon URL will be shown.
TMG Web listener & Rules
In order for the different URL’s, which are published on SSL, to work on a single listener each URL must have its own certificate mapped to a unique IP address, or a SAN/wildcard certificate must be used.
The above figure shows the full configuration of the TMG web listener and rules. Note that the Active ADFS path is also within the same listener but does not require any authentication (see previous blog posts). This is to allow Outlook and ActiveSync to work. There is also a difference between the internal listener and the external listener as internal users are not required to use the forms-based authentication page, but can be authenticated using Kerberos or NTLM challenge. These users (thus on the internal network and pointed to the internal IP of TMG by DNS) can open each OWA without additional prompts for authentication. As integrated authentication is used, SSO is not required and the user will automatically be validated by each accessed URL.