Merényi Mónika

Posted on Feb 6

Entra ID Hybrid joined: SSO and understanding PRT- Part 2

Introduction

In this exercise, we will focus on enabling Single Sign-On (SSO) for seamless user authentication across cloud and on-premises resources. We will also dive into the details of the Primary Refresh Token (PRT), a critical component of the SSO experience in hybrid identity environments. To test this setup, we’ll deploy a client machine and hybrid join it to Microsoft Entra ID.

Part 2

Let’s apply what we learned in the previous section. In this part, we will create a new client VM and enable SSO. We’ll set up Entra ID-based login for the VM and connect using a user account synced from the on-premises Active Directory.

Before you begin, make sure to start your DC1 virtual machine, as you will need it throughout this exercise.

Deploying the client Virtual Machine

Check my previous post about how to deploy a resource using biceps template:
https://dev.to/neontiger12/deploying-and-configuring-a-hybrid-identity-lab-using-bicep-part-1-active-directory-setup-and-2eo7

You can pull the required files from my Git repository:
https://github.com/neontiger12/EntraConnect

Let's jump straight into the deployment.
We will deploy a Win11 client machine into a new resource group: Hybrid_Client_RG to westeurope.

It will use the same Vnet, subnet as the DC1 deployed in the Deploying and Configuring a Hybrid Identity Lab Using Bicep - Part 1.

1. Resource group

az group create --name Hybrid_Client_RG --location westeurope

2. Deploy the VM into the resource group

az deployment group create --resource-group Hybrid_Client_RG --template-file main-client.bicep

You need to specify the admin username and password.

3. Verify

Wait until the deployment is finished with the provisioning state "Succeeded".
Check the resource also in Azure.

4. Connect to the machine

Connect » Connect » Download RDP file

5. Add the VM to the domain

Search for "domain" » Access work or school account »

Add account: Access » Work or school

Click Join this device to the local Active Directory domain at the bottom of the window.

Add your local domain. Next.

Add your user as an Administrator.

After successfully adding the VM to the domain you will need to restart it.

Give it some time to restart and reconnect.

Note: Since we are not using a static public IP, if the VM was stopped (deallocated), it will be assigned a new IP address upon restart.

After you signed back run the dsregcmd /status command. The dsregcmd command helps you to understand the state of devices in Microsoft Entra ID.

As you can see, our device is domain-joined but not yet Azure AD (Entra ID) joined. The PRT status is also 'No' because we haven’t set up SSO yet.

6. Add the device to Entra ID

Same way like you added the device to the domain go to Accounts » Access work or school » Connect

After successfully authenticated you are all set! :)

You should now see both your domain and Entra ID account:

Let's now check the status again with dsregcmd /status

AzureAdJoined still shows as NO.

Good practice to run the dsregcmd /join command to force the join process.

The dsregcmd /join command is used to manually join a Windows device to Entra ID in a hybrid Azure AD join scenario. It is especially useful when automatic device registration fails or when a device needs to be re-registered.

Now check the status again:

Now the AzureAdJoined is Yes.

7. Now setup the SSO in DC1

Enable SSO and set the sign in option to Password Hash Sync.

Provide Domain Administrator credentials for each Windows Server AD forest that:

Is synced to Microsoft Entra ID using Microsoft Entra Connect.
Contains users for whom you want to enable Seamless SSO.
Once you complete the wizard, Seamless SSO will be enabled for your tenant.

Entra ID » Microsoft Entra Connect » Connect Sync

NOTE:

Seamless SSO creates a computer account named AZUREADSSOACC in each on-premises Windows Server AD forest. To ensure security:

Restrict management to Domain Administrators.

Right click on AZUREADSSOACC » Properties » Security
Make sure only Domain Admins have full control.

Disable Kerberos delegation on the account.
Right click on AZUREADSSOACC » Properties » Delegation
Select "Do not trust this computer for delegation" » Click OK.
Ensure no other accounts have delegation permissions.
Store the account in an Organizational Unit (OU) to prevent accidental deletion and limit access to Domain Administrators.