Auto acceleration and external users - the devil in the detail

Auto acceleration is an Office 365 feature which simplifies the sign-in process for SharePoint Online sites in scenarios where ADFS is used to authenticate users. It works well for internal users and can work for external users, but that is where things get complicated.

Enabling auto acceleration

Enable auto acceleration with simple line of PowerShell, using Set-SPOTenant commandlet.

Set-SPOTenant –SignInAccelerationDomain "opax.io"  

At this point, auto acceleration starts to work for internal users. When they try to access a SharePoint Online site which is not shared to external users (e.g. opax.sharepoint.com/sites/intranet), the sign-in process is accelerated so that they are redirected directly to ADFS for authentication and single sign-on can easily be achieved.

However, when an user tries to access externally shared site (e.g. opax.sharepoint.com/sites/extranet), she is redirected to Azure AD sign-in page and is forced to write her username before being redirected to the company ADFS or, if she is an external user, to login in to her own tenant.

This is annoying for internal users, since they have already learned to like the easy way, but is required to let the external users to authenticate.

Auto acceleration for external users

It is possible to use auto acceleration to external users as well. Use the same commandlet but with different parameters.

Set-SPOTenant -EnableGuestSignInAcceleration $true  

Now all users are directed to company's ADFS for authentication, so it works for everybody. Right?

In a way it does, but not they way you are likely to want it work. In Office 365 support article it is stated that:

... If you want to enable auto-acceleration for externally shared sites, your IdP needs to be capable of supporting these use cases (or at least the ones that you want your guests to use). To support guests in AAD, MSA or other IdP’s, your IdP will need to be capable of returning the user to the AAD login screen for authentication.

One could assume that ADFS would be an IdP that is capable of supporting these use cases. I tried this by configuring Claims Provider Trust between Azure AD and my ADFS, and an Azure AD application. It almost worked: I could redirect the external user to Azure AD, and because of Azure AD application, it actually authenticated the user and returned him to my ADFS which in turn redirected the user back to SharePoint Online, but something broke on the way and the user got the 'Sorry, something went wrong' message.

To solve this I ended up opening two support requests. First one was to find out what went wrong, which turned up a bit more descriptive error "Security token handler is not registered to read the security token." Then I opened another support request for technical guidance how to do the ADFS configuration to get the Claims Provider Trust to work with guest Office 365 users. That one ended up with this statement:

... you cannot configure ADFS Claims Provider Trust to work with guest Office 365 users and this is by design how the product works.

So, that's it then. The devil is that if you want to use auto acceleration with your Office 365 and ADFS configuration, you can't federate the authentication back to to Azure AD. In our case the effect was that auto acceleration can't be turned on for external sites. We try to advice internal users to first log in to an internal site collection, so that they are signed in when they are accessing the externally shared site collections.