Azure AD Seamless Single Sign-on

The single sign-on (Azure AD Seamless SSO) feature of Azure AD adds extra value to the Azure AD authentication process and provides a better experience for your users by eliminating the need to enter passwords or even usernames whenever you need to authenticate to Azure AD to access various resources.

For on-premises users that need to authenticate with Azure AD to access resources, typically an organisation will enable Password Hash Synchronization or Pass-through Authentication via AD Connect. This allows on-premises users to use the same credentials they use on-premises for access to cloud resources such as Office 365, SaaS, and other web applications protected by Azure AD. The benefits of a single set of credentials are obvious from a user experience perspective, not to mention the reduced chance of users forgetting their passwords and logging calls to the IT helpdesk.

Note: This feature is not available for Microsoft Azure Germany cloud or Microsoft Azure Government cloud.

Seamless SSO provides users with further benefits, making authentication to cloud resources or resources protected by Azure AD easier. For this feature to work, users must be on the corporate network, and using domain-joined devices.

There are also benefits above what has just been mentioned, such as:

  • No additional infrastructure required to setup and configure SSO.
  • It works the same way as any other sign-in that uses Integrated Windows Authentication (IWA).
  • Can be controlled via Group Policy to specify who can use SSO.
  • No requirement for additional licensing to enable Seamless SSO.
  • The feature is simply enabled via AD Connect.
  • All browser-based web applications and Microsoft Office client-side applications that use modern authentication, such as Outlook, are supported on platforms and browsers capable of Kerberos authentication.

Contents:

Supported browsers:


The following browsers are supported with Seamless SSO. Those with an asterisk require further configuration:

  • Windows 10
    • IE, Chrome, Firefox*
  • Windows 8.1
    • IE, Chrome, Firefox*
  • Windows 8
    • IE, Chrome, Firefox*
  • Windows 7
    • IE, Chrome, Firefox*
  • Mac OS X
    • Chrome*, Firefox*, Safari*

Note: Microsoft Edge is not supported. Also, mobile browsers on iOS and Android do not work.

Authentication flow for web browsers:

  1. User accesses a web application from a domain joined device inside the corporate network.
  2. If the user is not already signed in, they are redirected to the Azure AD sign-in page.
  3. User enters their username (the same one that they use on-premises).
  4. Azure AD receives the username and challenges the user’s browser via JavaScript to provide a Kerberos ticket.
  5. The browser requests a ticket from Active Directory for the AZUREADSSOACC computer account (created when enabling single sign-on).
  6. Active Directory returns a Kerberos ticket after locating the computer account. This ticket will be encrypted with the computer account’s secret.
  7. The user’s browser forwards the Kerberos ticket to Azure AD.
  8. Azure AD decrypts the ticket, which includes the user’s identity, using the previously shared key.
  9. Azure AD evaluates the ticket, and signs the user in, or challenges the user for Multi-Factor Authentication for example if Conditional Access policies are in play.
  10. After authentication is complete, access to the application is granted.

Note: If Seamless SSO fails, the user has to manually enter their credentials. Seamless SSO is known as an opportunistic feature.

Authentication flow for modern authentication capable apps:

  1. User accesses Outlook as an example, from a domain joined device inside the corporate network.
  2. If the user has not yet signed in, Outlook retrieves the username for the user from the device’s Windows session and sends the username to Azure AD including retrieving your tenant’s WS-Trust MEX endpoint.
  3. Outlook queries the WS-Trust MEX endpoint to see if IWA is enabled. If so, a Kerberos challenge is issued.
  4. If Outlook can retrieve the Kerberos ticket, it forwards it to Azure AD’s integrated authentication endpoint.
  5. Azure AD decrypts the Kerberos ticket and validates it.
  6. Azure AD then signs the user in and issues a SAML token to Outlook.
  7. Outlook submits the SAML token to Azure AD’s OAuth2 token endpoint.
  8. Azure AD validates the SAML token, and issues to Outlook an access token, a refresh token, and an ID token for the specified resource.
  9. After authentication is complete, access to the application is granted.

Note: If Seamless SSO fails, the user has to manually enter their credentials. Seamless SSO is known as an opportunistic feature.

Requirements to configure Seamless SSO – at a glance:

  • Install and configure AD Connect, and enable either Password Hash Synchronization, or Pass-through Authentication. Guides to configure these methods are mentioned at the beginning of this article.
  • Allow access to *.msappproxy.net over port 443. If DNS whitelisting is not possible, make sure access to the Azure datacentre IP ranges listed here is allowed.
  • Have access to domain administrator credentials for each forest you synchronise to Azure AD via AD Connect, and that contains users you want to have using Seamless SSO.
  • Use Office versions above 16.0.8730.x for a silent sign-on experience with the likes of Outlook, Excel, Word etc.
  • You must enable modern authentication against your tenant for this feature to work for Office 365 services.
  • Users must attempt to log on from domain-joined devices connected to the corporate network. That is either via a wired or wireless connection, or via a remote access connection such as VPN, that gives them direct access to a domain controller in your domain.
  • Group Policy configuration is required for users and/or computers on the domain.
  • Internet Explorer cannot run in Enhanced Protected Mode.
  • Firefox, if used in your organisation, cannot run in private mode.
  • Firefox, if used in your organisation, must have Kerberos manually enabled by:
    1. entering about:config in the address bar,
    2. searching for network.negotiate-auth.trusted-uris,
    3. right-clicking and selecting Modify,
    4. entering https://autologon.microsoftazuread-sso.com in the field,
    5. clicking OK and then re-opening the browser.

Enable and configure Seamless SSO:

To enable Seamless SSO, you must run a Custom installation of AD Connect. Alternatively, you can re-run the wizard after initial configuration and click Change user sign-in, enter global administrator credentials and then select Enable single sign-on -> Next.

Note: The Enable single sign-on option is only available when your sign-on method is set to Password Hash Synchronization or Pass-through authentication.

Click Enter credentials.

Enter on-premises domain administrator credentials and click OK.

Click Next.

Click Configure.

Click Exit.

A computer account will be created in your on-premises directory that is needed for Seamless SSO to work, so do not delete it. Make sure you move this computer to an Organizational Unit that contains your other computer objects.

From the Azure portal, navigating to Azure Active Directory -> Azure AD Connect shows you that Seamless single sign-on is now enabled, and for which domains it is enabled for. Click on the Seamless single sign-on hyperlink.

The domain(s) this feature has been enabled against are listed.

To apply single sign-on to groups of users or computers, some Group Policy work is required. Create a new GPO that is targeted against either computers or users, based on your preference.

Navigate through to (Computer/User) Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page and double-click Site to Zone Assignment List.

Add https://autologon.microsoftazuread-sso.com to the Intranet Zone, by entering the appropriate Value name and Value as below.

Next navigate through to (Computer/User) Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Intranet Zone and double-click Allow updates to status bar via script.

Select Enabled -> OK.

Testing single sign-on:

After a Group Policy refresh, you will be able to test single sign-on to Azure AD following either of the following steps:

  1. From a supported browser running on a corporate device that is connected to the corporate network, browse to https://myapps.microsoft.com
    • Enter your username. You should not be required to enter your password.
  2. From a supported browser running on a corporate device that is connected to the corporate network, browse to https://myapps.microsoft.com/mydomain.com where mydomain.com matches your verified, custom domain which is managed by Azure AD.
    • You should not be required to enter a username or password.

Note: If you wanted to sign in using a different account, you can sign out and choose another account to sign in with.

Configure Kerberos decryption key roll over:


Roll over of the Kerberos decryption key is recommended by Microsoft to be performed at least every 30 days. This reduces risk of the Kerberos decryption key from being leaked. If it was to be leaked, a malicious user could impersonate Azure AD sign-ins for compromised users. Microsoft are working on introducing an automated capability that rolls over keys for you.

To roll over the AZUREADSSOACC computer account’s Kerberos decryption key, you must first download the Azure AD PowerShell module from the PowerShell Gallery. Launch PowerShell as an administrator on a Windows 7 or Windows Server 2008 R2 or higher machine and run command Install-Module MSOnline.

You will be asked if you want to trust the PowerShell Gallery as a repository. Type a and press Enter.

Run command Import-Module .\AzureADSSO.psd1 from the C:\Program Files\Microsoft Azure Active Directory Connect\ directory.

Run New-AzureADSSOAuthenticationContext and enter global administrator credentials of your tenant.

Run Get-AzureADSSOStatus to see which domains in your forest are enabled for Seamless SSO.

Run $creds = Get-Credential and enter domain administrator credentials.

Run Update-AzureADSSOForest -OnPremCredentials $creds, which updates the AZUREADSSOACC computer account’s Kerberos decryption key for this AD forest, and updates it in Azure AD.

If you have multiple forests using Seamless SSO, perform the same steps.


23 Comments

  • Joris

    October 16, 2018

    Hello,

    Thanks for this write up. Helped me in my environment.

    Cheers,

    Joris

    Reply
  • Jatin

    October 24, 2018

    Thats really awesome, thanks for the article.

    Can I share it on my blog: https://webmakers.co.nz

    Reply
    • George Spiers

      October 24, 2018

      Thanks and yes, feel free to share.

      Reply
  • Andreas

    December 1, 2018

    Great article!

    Reply
  • Eric

    January 10, 2019

    Great article.
    I started with O365 first no on prem AD. My understanding is that once an on prem AD is established and AD connect is installed the Azure AD accounts are made never expire and the passwords are synced from on prem. This is working for all but one account, mine. Mine also happens to be a global administrator. Could the fact that I’m a global administrator causing the duplicate UPN error I’m seeing? All the accounts btw have duplicate UPNs why it is complaining about this one I don’t know.

    Reply
    • George Spiers

      January 11, 2019

      Correct but not sure what duplicate UPN error you are seeing. When installing AD Connect and configuring it did you choose the Express option or Advanced? Do the synced users in Azure AD show the correct UPN as their user name?

      Reply
    • Nestori Syynimaa

      September 7, 2019

      Hi Eric,

      Yes, the reason is your admin status. Azure AD Connect does not link AD accounts to Azure AD accounts if Azure AD account has any admin privileges. That is for security reasons, as Azure AD Connect can be used to “hijack” Azure AD users and change their passwords just by adding a user with the same name to local AD.

      You need to make yourself a normal user, run the sync, and return the admin privileges.

      Reply
  • Victor

    April 5, 2019

    Any info on when SSO on mobile browsers will get some love?
    Just turned on SSO for a project we’re launching and could connect on android browers (chrome at least) fine.
    iPhone fails to pass-through etc. and have since found articles mentioning this doesn’t work for them.

    Reply
    • George Spiers

      April 9, 2019

      Haven’t heard. Best to keep an eye on the documentation, but so far it continues to state no support.

      Reply
    • Jean

      November 2, 2019

      Hi, you can use Edge browser that support SSO on mobile devices.

      Reply
  • Thorbjørn Stegelmann

    May 6, 2019

    Cannot install Single Sign-On

    Version 1.3.20 of the Connect is in use.

    From the Trace log: (domain name is changed :-))

    033] [ 1] [INFO ] Check if username is in samAccount format
    [09:22:22.033] [ 1] [INFO ] Username is in samAccount format
    [09:22:22.033] [ 1] [INFO ] desktopsso computer account will be created in .dk
    [09:22:22.033] [ 1] [INFO ] Checking if credentials belong to the forest
    [09:22:22.080] [ 1] [INFO ] ValidateForest: using DC1.mitdomain.dk to validate domain mitdomain.dk
    [09:22:22.080] [ 1] [INFO ] Successfully examined domain Mitdomain.dk GUID:ad3057d1-421f-4567-b228-b20a289c4212 DN:DC=mitdomain,DC=dk
    [09:22:22.080] [ 1] [INFO ] mitdomain.dk\my_account belongs to the forest
    [09:22:22.158] [ 1] [ERROR] GetDesktopSsoComputerAccountDns exception caught: A referral was returned from the server.

    [09:22:22.158] [ 1] [ERROR] An error occurred while locating computer account.

    Reply
  • Jean

    November 2, 2019

    Hi, one question, what are the options for SSO if we are using ADFS and smartcards?

    Thanks for sharing!

    Reply
  • Pingback: Quick wins—single sign-on (SSO) and Multi-Factor Authentication (MFA) – TerabitWeb Blog

  • Pingback: Quick wins—single sign-on (SSO) and Multi-Factor Authentication (MFA) - ThreatsHub Cybersecurity News

  • Pingback: Quick wins—single sign-on (SSO) and Multi-Factor Authentication (MFA) - F1TYM1

  • Pingback: Quick wins—single sign-on (SSO) and Multi-Factor Authentication (MFA) – Computer Security Articles

  • Akram M

    April 20, 2020

    Hi, How does SSO work when you have a cloud based web proxy. Any one have experience with this. As all my client end points leverage a cloud based web proxy for http/s traffic, does it cause any issues and a lesser sso experience or no sso at all?

    Reply
  • Tangiears

    July 21, 2020

    Very good post! Here is a to recreate the computer account: AZUREADSSOACC if it’s missing, without reinstalling AADConnect: https://www.sysadmit.com/2020/07/azureadssoacc-recrear-cuenta.html

    Reply
  • David

    November 6, 2020

    Once you enable SSO in Azure AD connect but before using GPO to assign users or computers, is there any possibility of users seeing any adverse affects?
    Current config is Password Hash but not SSO. I don’t want anything bad to happen when I turn on SSO if I cant configure the GPO right away. Many unexpected fires at where I work. Cant really reserve time to a single thing.
    Thank you

    Reply
  • Federico

    January 9, 2021

    Hi Very good post! i’ve tried to update kerberos decription key followinf yuor post, on prem it seems to work perfectly but when i check on azure, i find the same warning and the key isn’t update. I’ve a single forest .local on prem, is it a problem?

    Reply
  • David Trevor

    August 12, 2021

    Hello George I have a question about the 2nd SSO test scenario. When I open the URL with the domain hint ?whr=domain.com the SSO works once, but the next time it doesn’t log me in automatically, I have to select the username again. If I were to clear the browser cookies the SSO will work for one time again. Is this a bug or why does it happen?

    Reply

Leave a Reply