Microsoft has introduced the Staged Rollout functionality to convert the sign-in method for people in your organization from federated authentication to managed authentication. However, there is one slight issue with single sign-on. In this blogpost, I’ll address the issue of having both Seamless Single Sign-on and Federation enabled in Azure AD Connect.

About Staged Rollout

Staged Rollout is a feature that allows organizations to transition the sign-in method for people in the organization based on membership to a group. Without the Staged Rollout feature, this transition is only possible per DNS domain name.

When made members of the group that would convert their sign-in method, people would sign in to Azure AD and Azure AD-integrated applications, services and systems using either password hash synchronization (PHS) or Pass-through Authentication (PTA).

The issue

When people sign in using PHS or PTA, they loose their ability to get access based on single sign-on (SSO) in certain scenarios.

These scenarios include:

1. Not using a hybrid Azure AD-joined device
2. Not using an Azure AD-joined device

In these cases, the Microsoft documentation refers to using the Enable single sign-on option in Azure AD Connect. This option enables the Desktop Single Sign-on feature. When the feature is enabled, people in your organization are allowed to perform Kerberos authentication towards the Azure AD sign-in infrastructure.

The Desktop SSO feature creates a computer object named AZUREADSSOACC in the default Computers container per Active Directory forest that is enabled for Desktop SSO. Its password is specifically used to encrypt the Kerberos tokens that are exchanged.

However, when you have Federation with AD FS configured in Azure AD Connect, you cannot enable the Enable single sign-on option at the same time. The option is greyed-out:

Enabling the Desktop Single Sign-on feature

To enable the Desktop Single Sign-on feature, close the Azure AD Connect configuration wizard and open an elevated Windows PowerShell window. Perform the following lines of Windows PowerShell:

Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1’

New-AzureADSSOAuthenticationContext

A modern authentication prompt appears. Sign-in with an account that has been assigned the Global Administrator and/or the Hybrid Identity Administrator role in the Azure AD tenant.

Enable-AzureADSSOForest

A Windows authentication prompt appears. Sign-in with an account that is a member of the Enterprise Admins group in the Active Directory forest for which you want to enable the Desktop SSO feature. Specify the account name in the sAMAccountName format.

Repeat this step for every Active Directory forest you want to enable the Desktop Single Sign-on feature for.

Enable-AzureADSSO -Enable $true

Checking the Desktop Single Sign-on feature

There are two ways to check the Desktop Single Sign-on feature.

You can run the following line of Windows PowerShell in the same Windows PowerShell session you used to enable the Desktop Single Sign-on feature:

Get-AzureADSSOStatus | ConvertFrom-Json

You can check the existence of the AZUREADSSOACC computer account in the default Computers container in the Active Directory forest.

You can start the Azure AD Connect Configuration wizard and examine the output for the Change Sign-in method task.

Further steps

after the initial configuration of the Desktop Seamless Single Sign-on (DSSO) feature, you’re ready to:

1. Create the process for changing the password for the AZUREADSSOACC computer account on a monthly basis
2. Deploy a Group Policy to place https://autologon.microsoftazuread-sso.com in the Intranet Zone to allow people to actually send Kerberos tokens to the Azure AD Authentication infrastructure
3. Create and assign groups for Staged Roll-out and make people members of these groups.

Have fun!