A little bit of a departure from my (not-so) recent posts, but I am finding more and more that I am working with Microsoft Azure and Office 365, so thought I would share some not so much new, as a lot of this had been written about already, but consolidated knowledge during a recent experience with SharePoint Online.
Recently I was working with a customer on an AD FS 3.0 deployment to allow them to use SharePoint Online in Office 365 as a replacement for their intranet. One of the requirements was that it should function in the same way as the current intranet site. This was basically a legacy Content Management System (CMS) running on Windows Server 2008 R2 with IIS 7.5, and uses Windows Integrated Authentication to authenticate users. Users are not prompted for credentials at all, so the goal was to implement a new intranet proof-of-concept in Office 365 using SharePoint Online with a seamless Single Sign-On (SSO) authentication experience identical to that which users currently have. This should function using both Microsoft Internet Explorer and Google Chrome browsers.
The first part of the solution was to deploy AD FS v3.0 and Azure AD Connect to allow users to authenticate with SharePoint Online using their on-premises credentials. There are a number of good guides on this so I won’t go into the details about this specifically, but once this was up and running I was able to authenticate using my own credentials against the SharePoint Online site. We did have to make some changes to Extended Protection for Authentication (EPA) check and supported UserAgent strings in order for Windows Integrated Authentication to work with Chrome. Details of how to do this can be found over on Jack Stromberg’s blog here.
If you’re are familiar with SharePoint Online, or Office 365 administration in general, the following screen will look familiar:
This is the Microsoft Online login screen, and is basically the gateway to all Office 365 resources. When a user tries to access a SharePoint Online site collection and is not already authenticated with Office 365, the user will be directed to the Microsoft Online login screen. The user then provides their email address initially. At this point something called a Home-realm Discovery is performed. Basically what happens is that the Microsoft Online login screen will use the domain portion of the users email address to determine whether the domain is managed by Office 365, in which case the user will need to provide a password. If the domain is Federated (i.e. not managed by Office 365), the user is re-directed to the Identity Provider (IdP) for the user’s organisation – i.e. AD FS. At this point providing internet security settings within the user’s web browser are correct, they will be authenticated using their logged in credentials.
This is the default experience, and in most cases is adequate. The user just provides an email address, and the rest is automatic. However, for my customer this didn’t quite meet the requirement. They needed this to be completely seamless. So, after a bit of digging around I came across something called Smart Links. These seemed to be pretty well documented, and quite a few people had implemented these successfully. Basically, what we do is construct a URL which is a direct link to our Identity Provider (AD FS Farm internally or AD FS Web Application Proxy (WAP) cluster for external access), which also contains the redirect (wreply parameter) to the resource that we need to access once authenticated. There is a great article here about this here. Without reading the article, it is suggested that a HTTP monitoring tool (Developer Tools in Internet Explorer/Chrome/<insert your favourite browser here>, or Fiddler) be used to capture the URL and then use a Vanity URL hosted by an internal server to perform a redirect to the captured URL. Easy enough…..so I thought.
What I actually discovered whilst trying to implement this in the manner that the article (and almost all others that I could find) was that the URL structure in the article didn’t match that issued using AD FS v3.0. It appears that the format of the URL at some point has changed, making this method redundant. Microsoft alluded to this fact here on the Office 365 community forum. It suggested that this used to work in AD FS v2.x, but doesn’t work in v3.0. So I decided to look for an alternate method. I had a play around with crafting the URL manually in line with what AD FS v2.0 might have produced using the HTTP monitoring method, and I had some success, but it wasn’t quite right. I then stumbled across the O365 Smart Linking Tool by Travis Spencer which can be used to construct the Identity Provider (IdP) authentication URL with redirect parameters. I tested this out with the Vanity URL and redirect, and it worked as expected. The one immediate drawback for my customer was that if, for example, we wanted to email URLs to specific paths within SharePoint (for specific content) we would potentially need several vanity URLs, which wasn’t really scalable. One other issue I found with this method was that although Microsoft have produced their own article here on the subject of Smart Links, in another article here they explain why using them isn’t a good idea – basically is can impact other applications which integrate with SharePoint Online due to a lack of persistent FedAuth cookie on the client. So, at this point it looked as though we were stuck
As a last resort, we decided to engage Microsoft directly (Premier Support – the customer has a subscription!) on the subject of a ‘seamless’ single sign on experience for SharePoint Online specifically, just in case there was something we were missing. Pretty quickly they came back with a feature that I had not heard of…….Auto-acceleration for SharePoint Online.
Effectively what this does is inform SharePoint Online that is should use a pre-defined home-realm, negating the requirement for the Home-realm Discovery. This is used to direct users trying to authenticate to the correct Identity Provider – in our case this being AD FS. The only real requirements here are:
- Single Identity Provider – essentially one ADFS end-point to authenticate all of your users.
- Only works with sites that are accessible internally to the organisation – auto-acceleration does not work for external sites since it isn’t clear where the user can log on to.
After hearing of this feature I had a quick dig around and only managed to uncovered a handful of references to this on the internets, so I am guessing that this isn’t that widely used. In terms of implementation, it’s actually really easy. Up until the middle of 2015 this change had to be requested via Office 365 Support. However now we have a PowerShell cmdlet for this. It really is as simple as running the Set-SPOTenant cmdlet with the correct switches:
Set-SPOTenant -SignInAcceletationDomain “mydomain.com”
That’s it! Following this, if you try and access your site collection, you will no longer be prompted at all for either a username or password. Marvellous!!!
I know this is a long-winded article, but I thought I would go through the entire journey and catalog my experiences. When I was researching this there seemed to be a lot of you having the same issues as myself. I hope this goes some way to helping someone out.