Working with one of my colleagues recently, we were tasked with implementing Smart Links to speed up the login processes for a client’s SharePoint Online implementation.
The client was working towards replacing their on-premises implementation of SharePoint and OpenSpaces with SharePoint Online. The issue they faced was that when 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 default Microsoft Online login page. The user then provides their email address and something called home-realm discovery is performed. This is where 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. Although this is the default SharePoint Online experience, it was different to the seamless on-premises SharePoint experience with Windows Integrated Authentication.
After spending a little time working through David Ross’ great blog on the topic, we discovered that due to a change in the URL construct with AD FS 3.0, the Smart Link process is no longer supported by Microsoft and has been replaced with Auto-Acceleration for SharePoint Online. This feature reduces logon prompts for the user by instructing SharePoint Online to use a pre-defined home-realm, rather than perform home-realm discovery, when a user accesses the site and “accelerating” the user through the logon process.
However, there are two caveats for getting Auto-Acceleration to work:

  • You can have multiple domains but there must be a single SSO end-point to authenticate users (AD FS or a 3rd party IdP such as Okta, can be used).
  • Auto-acceleration only works with sites that are accessible internally to the organisation, it will not work for external sites.

There isn’t much documentation around for this feature, however it’s pretty simple:

  1. If you haven’t already, download the SharePoint Online Management Shell
  2. Connect to SharePoint Online using the SPO Management Shell:
    [sourcecode language=”powershell”]
    $adminUPN="[UPN for Office 365 Admin]"
    $orgName="[Your tenant name]"
    $userCredential = Get-Credential -UserName $adminUPN -Message "Type the password."
    Connect-SPOService -Url https://$ -Credential $userCredential [/sourcecode]
  3. Type the command Set-SPOTenant –SignInAccelerationDomain “”
  4. If your IdP supports guest users, you can also run Set-SPOTenant -EnableGuestSignInAcceleration $true
ADFS, Identity and Access Management, Office 365, PowerShell, SharePoint, Uncategorized

Join the conversation! 0 Comments

  1. hi
    if internal fqdn is a.internal and external fqdn is (which is added to office 365 and users login as to sharepoint online), which domain name should be used in the above command?
    also is IdP windows 2012 R2 adfs 3.0 supports guest users?

    • You would need to be using a publicly routable namespace for your AD FS endpoint – so you would need split-brain or pinpoint DNS for your internal AD FS servers ( You would also be using in the Set-SPOTenant cmdlet.

      • Sorry, responding to a 2 year old thread. Wondering if you ever encountered issue with Auto-acceleration for Azure B2B scenario.
        If the partner orgs have ADFS, and AzureAD instance (because of their O365 tenant), and I enable Auto-acceleration on my sharepoint online, their auth seem to be breaking even when I force the login to their IDP with domainhint parameter in the URL.
        BTW, I did not setup Claims provider trust for the partner IDP in my ADFS (IDP). In any case, that is not supported with O365 (is what I read).
        Your insights would be helpful.

Leave a Reply