Auto-Acceleration in SharePoint Online

Published 03-15-2018 04:30 PM 7,596 Views

Note: This is an earlier blog article that was previously hosted on the SharePoint Online Support blog on MSDN. It, and other articles, are being moved over to this site as part of an ongoing Global Blog effort by the SharePoint Online Support Organization.

Information Technology is often tasked with two opposing goals: increase productivity by giving better and easier access to data; while at the same time, protecting that data from unauthorized access.  This means that services such as SharePoint Online (and Office365 in general) must be able to correctly identify the user requesting the information, authenticate that user, then check that user's authorization to ensure that the user has the correct rights to the information they are requesting.  Add in that these users might be authenticating against different providers and things become complicated.


Users do not enjoy interruptions to their workflow, and authentication prompts are often viewed as needless interruptions. The solution, of course, lies in a Cloud experience that feels as seamless as an on premise.  SharePoint Online allows for some of the most feature rich collaboration experiences currently available.  It allows users across organizations to access shared resources, and collaborate on exciting and impactful work.  In order to enable those experiences, SharePoint has to discover who the person requesting the resource is first.


Currently, when you access a SharePoint Online resource, SharePoint Online expects your browser or app to provide a cookie authenticating you.  If you do not have that cookie, SharePoint will undergo the authentication process.  Your browser session will be sent to and you will be prompted to enter your username and password.  When you complete entering your username, will do what is called a Realm Discovery.  Based on your address, you are sent to the appropriate identity provider.  In cases when you are signing in to your own tenant, you are sent to the identity provider your Office365 admin has configured, such as ADFS, or Azure Active Directory, or another third party Identity Provider that supports the appropriate SAML standards for Office 365.  When an external user is attempting to ask for a resource on your tenant, then the realm discovery routes them to the appropriate identity provider for their user name.


If your identity provider is set up for Single Sign On, this added step of providing your username for realm discovery is an additional hurdle that prevents your users from enjoying a true seamless Single Sign On experience.  Enter Auto-Acceleration for SharePoint Online.  Auto-Acceleration is a feature in SharePoint that aims to remove the realm discovery aspect from the sign on experience.  When it is enabled, you specify the default Identity Provider endpoint for your tenant.  In this configuration, when one of your users accesses a resource that is not shared with external users, rather than landing on Login.MicrosoftOnline.Com, your users will be sent directly to the identity provider.  If you have configured Integrated Windows Authentication on ADFS and the user's client machine is domain joined, they will have a completely seamless single sign on experience; it will be no different than if they were accessing an on premises resource.


For some organizations, the redirect to Azure Active Directory for realm discovery is the key feature.  Unlike, an organizations Azure Active Directory page is customizable for branding, and many customers want to create login experiences that are tailored to their organization.  To enable this functionality, you will enable Auto-acceleration, and then configure your sites to be externally-sharable.


One final note, worth noting because it is a favorite question here in support regarding Auto-Acceleration: If you chose to configure auto-acceleration, your back out plan when filing your change control is to run Set-SPOTenant –SignInAccelerationDomain “”.  This will clear out the feature and things will work normally again.



Valued Contributor

Can you comment on the effect this has for external users?

If I remember correctly from my experience, I had this enabled for our domain (worked superbly) but weeks later I've had some complaints from external users (guests) that were no longer able to login, since they were always redirected to our ADFS server, where they of course were not able to authenticated, since they needed to be authenticated against their Microsoft ID.


Hi @Ivan Unger

By default, when you enable Auto-Acceleration, site collections that are enabled for Guest User Access should continue to present the home realm discovery page. However, if an administrator uses the -enableguestsigninacceleration parameter of the Set-SPOTenant cmdlet, all requests will be routed to the identity provider on record for the domain.  Guest Sign In Acceleration is a very niche edge case where a single endpoint is used for multiple domains and can handle guest user authentication.  This is not common in the service.

I hope this helps, and please feel free to follow up with any other questions you might have.

Frequent Contributor

While definitely a niche situation, I appreciate the knowledge sharing! 

Occasional Visitor

Hi Toby,

I have the same question as Ivan. How do we solve this issue? I am forcing redirect to their IDP using the domainhint parameter in the URL (that starts with However, even after the partner ADFS (guest user's) authenticates it successfully, the user gets the annoying: "AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application..."

So far, the MS Premier support seems to be stumped at this, and just trying to understand where the issue is.

In summary, does enabling auto-acceleration for my domain break the guest login? 

Occasional Contributor

@Toby Bianchi 


We use a 3rd party IDP, specifically BIG-IP APM and have integrated windows authentication and user client machine is domain joined to get the seamless SSO experience. But internal users were still getting prompt in SharePoint to click their username to authenticate.  We turned on Auto Acceleration to prevent the login prompts and also for the site collections with external sharing turned on (EnableGuestSignInAcceleration). We are experiencing this same issue with external guest accounts that cannot get into our SharePoint Online environment. We have an open premier ticket on this and they want us to turn on auto acceleration, but our internal users will be getting the login prompt again. Any idea around this for external users?

@Toby Bianchi , we are planning to enable Auto acceleration for one of our tenant. Could you please do let me know what would be the impact on Guest users if we don't enable this parameter  " enableguestsigninaccelaration"? I believe they should be able to access external sharing site collections in similar way how they access in the past and there won't be any impact.

New Contributor

@Toby Bianchi  We looking for to enable this option and we don't want any changes to external users authentication model (should be able to use their own account to authenticate). What's the best way of doing?

Occasional Visitor

We are experiencing the same. After enabling  EnableGuestSignInAcceleration, Guests are not able to access the site . What is the solution for this?



Apologies for the silence on this. 

@Sreedhar rao : I don't have much insight into that.  I would suspect, from the verbiage, as something OAuth related. I will note that the PG has consistently stated in the past that SmartLinks, that is, hacking URLs to supply information normally communicated through the auth flow, is not technically a supported scenario - it will work, but it isn't designed to work this way.  

@Amiyamohanty670: @Anoop Kv@Raghavender Madhadi@Mark Rioux:

The EnableGuestSignInAcceleration is a very specific niche scenario - it is designed only for those tenants that have IDPs that can handle Authentication for all Guest Users they invite.  If you're not acting as the sole IdP for all users in your tenant, you should not enable this setting.

New Contributor

How does this impact OneDrive and sharing externally?


How does this impact the cloud IdP accounts that wouldnt work with ADFS?


ADFS would only be able to handle our domain, nothing else, no guests, no onmicrosoft.


Do I need to set my primary site intranet as not externally addressable that that auto acceleration works for that, but does not touch the other sites and collections? HOwever, I have service accounts using that needs access to the root site,


If onedrive is setup for external it would not touch it?


as long as you dont set this parameter to true? EnableGuestSignInAcceleration


Please advise how you would recommend setting up our new  sharepoint online that we are leveraging


My understanding is turn on auto-acceleration, turn off external sharing for, but then how do I get to work for such site?


otherwise, I am doing links and passing through whr and wsign1.0 I guess.

Version history
Last update:
‎Dec 27 2018 12:47 PM
Updated by: