Auto-Acceleration in SharePoint Online
Published Mar 15 2018 04:30 PM 9,744 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.



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