Deploying ADFS for use with Office 365 is intended to give users a single sign-on experience. As anyone who has deployed Office 365 will tell you, you don’t really get true single sign-on. Depending on the type of client you are using, your “single sign-on” experience can vary pretty widely. The Lync and CRM online clients do give users single sign-on, but Outlook does not. Sitting in the middle you have the experience of logging into the Office 365 Portal.
After completing your ADFS setup, logging into the Office 365 portal at http://portal.office.com can be done without users having to enter their passwords, but users are still required to type in their user names. In this article I am going to show you how to create a “smart link” that will allow your users to access the Office 365 portal (or any other Office 365 web services) without having to enter any information for a true single sign-on experience.
The standard “SSO” experience for Office 365 web applications
The problem with the standard “SSO” experience for Office 365 web applications is that your users have to type in their usernames on the Office 365 portal page before the login process can start. In truth, users don’t even really have to type in their usernames, they just need to type in a username that contains the proper realm. For instance, if my username is nathan@mcsmlab.com I can type in a@mcsmlab.com on the Office 365 portal login page and I will still be redirected to my ADFS server for authentication. If I am on a domain joined PC on the internal network and the ADFS server is listed in the trusted zone in Internet Explorer, I will be signed into the Office 365 portal without any further intervention on my part. So why do I need to type in any username at all?
The answer is that the Office 365 portal is doing a realm discovery on the username you enter there so it can identify what address to send you to for ADFS authentication. Since everyone in the same domain will be directed to the same address for ADFS, the portal does not bother looking at anything before the “@” sign. It just looks at the information after the “@”, in this case mcsmlab.com, so that Azure can lookup that domain and find the ADFS information that was configured during ADFS deployment. Once the portal has the proper address for your ADFS server, it redirects your session there and you get a full single sign-on experience from that point forward.
The real SSO experience using a Smart Link
My solution for this problem of having to enter your user name on http://portal.office.com is to create a Smart Link that already contains the realm information for your domain.
The steps for this configuration are fairly straight forward at a high level the step to complete this setup are
Login to your Office 365 portal as normal and capture the URL used by Office 365 for realm discovery.
Edit that URL to contain only the information that applies to all users in your domain
Create a new website that redirects to your edited URL
Let’s take a closer look at each of those steps.
Capture the URL used by Office 365 for realm discovery
The first step in the process is to identify the URL that the Office 365 portal is using for your tenant’s realm discovery. I started by installing a HTTP analyzer tool. There are a number of free tools you can use for this, but I used HTTP Analyzer V7. After installing the tool start a capture and go to http://portal.office.com to login to Office 365 normally. As soon as you enter your username, Office 365 will do the realm discovery and you will be redirected to your ADFS server to be authenticated.
After you are redirected to your ADFS server and authenticated into Office 365 you can stop the capture and find the relevant URL. It will look something like this (the example below has been sanitized so it's not specific to a real tenant)
https://adfs.contoso.com/adfs/ls/?cbcxt=&vv=&username=nathan%40contoso.com&mkt=&lc=1033&wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=MEST%3D0%26LoginOptions%3D2%26wa%3Dwsignin1.0%26rpsnv%3D2%26ct%3D1292977249%26rver%3D6.1.6206.0%26wp%3DMCMBI%26wreply%3Dhttps:%252F%252Fportal.microsoftonline.com%252FDefault.aspx%26lc%3D1033%26id%3D271345%26bk%3D1292977249
Edit that URL to contain only the information that applies to all users in your domain
This is the URL we are going to edit to make the smart link. You'll need to edit this by removing everything up to the "wa" querystring parameter, remove the last QS parameter "bk", and remove the "ct" parameter (up to the 'ver' parameter).
So after editing my URL, I end up with this
Create a new website that redirects to your edited URL
Now that you have your URL, you want to create a friendly URL for your users. http://office365.contoso.com or maybe http://portal.contoso.com Whatever friendly URL you decide on, you want to create an IIS website to publish it. The steps you’ll follow for this is
Create a DNS A record for your friendly URL
Create a new website (http://portal.contso.com) on your IIS server
Create a 302 redirect service on this new website, and use your new smart link as the target address
Ensure that http://portal.contoso.com resolves to the proper IP address both internally and externally
Test http://portal.contoso.com and ensure that you get a true single sign-on experience access the Office 365 portal or any web services off of that portal
Now just tell your users that they can access Office 365 web applications via http://portal.contoso.com