DEV Community: Merényi Mónika

Understanding Entra Connect Sync Architecture: A Deep Dive - Part 3

Merényi Mónika — Sun, 16 Feb 2025 19:13:09 +0000

Introduction

Continuing our journey to better understand Entra Connect Sync let's see everything in action!

Start your DC1 server created in this post , login.

Make sure that the Microsoft Azure AD Sync service is running:

Start the Syncrhonization Service

Check what steps are included in the Delta Sync

To make it clean and easy to follow, let's clear the previous Operations if you have one:

Now you can manually start a Delta Sync with PowerShell:

_Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta _

Delta Sync only syncronizes the changed data, while the Initial Sync syncronizes all data from the connected data sources.

In the Operation Tab you can see the steps involved in the Delta Syc:

Delta Import from the local Active Directory - CD to CS
Delta Import from Entra ID (shown as AAD) - CD to CS
Delta Synchronization from Entra ID (shown as AAD) - CS to MV
Delta Synchronization from Active Directory - CS to MW
Export to Entra ID (shown as AAD) - MW to CS
Export to Active Directory - MW to CS

! Disable the sync scheduler now to make sure it won't automatically start a Delta Sync after you create a new user:

Set-ADSyncScheduler -SyncCycleEnabled $false

Create a new user in AD

Active Directory Users and Computers

Users » right click » New » User

Name him:

Check if the object exists in the Connector Space

Connector Space tab » Right click on your CS connected to Active Directory » Search

Click Search and order the list by the Object type

No "New User" object here.

Start a Delta Import

To start a Delta Import right click on the Connector Space connected to the AD » Run » Delta Import

Check the Synchronization Statistics: 1 added item, our new user is replicated to the Connector Space.

This process of bringing in a new object from a connected data source into the Connector Space is called provisioning (from the perspective of the Connector Space)

If you search again in the Connector Space you will find the replica of the New User there.

Check the object in the Metaverse. Since it hasn't been synchronized to the Metaverse yet, it should not be visible.

Metaverse Search Tab » Search

Our new user is not here.

Run a Delta Import from Entra ID (shows as AAD).
No updates from Entra ID.

Now let's run a Delta Synchronization on the local AD Connector Space to project our new user object to the Metaverse.

Right click on the Connector Space connected to the local AD » Run » Delta Syncrhonization

You can see the Synchronization Statistics: there is one new projection.

During the Inbound Synchronization step, if the object does not yet exist in the metaverse, it is projected into the metaverse.

Projection refers to the creation of a new object in the metaverse when there is no existing matching object.

If you search the Metaverse now you will find our new object.

Do the Delta Syncronization on the Connector Space connected to the Entra ID (AAD).
There will be no changes comming from Entra ID.

Now check the object in the Connector Space connected to Entra ID (AAD). Search the Connector Space and organize the result by the Object Type.

By clicking the Properties of the new user (with the Display name blank) you can see it is flagged as "Pending Export".

**Now let's do an Export on the Connector Space connected to Entra ID (AAD) **to export the newly created object to the cloud.

Source

Right click on the Connector Space connected to the AAD » Run » Export

After in finish successfully you can see there is 1 added item.

Check if you can find the new object in the Connector Space connected to Entra ID (AAD).

Search Connector Space:

You can see there is a new item with the Display name field blank.
(if you don't see the Display Name column click on Column Settings... and add it)

We are waiting for confirmation from Entra ID that the export was successful. Since this hasn't happened yet, the status shows "Awaiting Export Confirmation."

Check the properties of the object:

If you check your users in Entra ID you can already see the newly added user:

Let's get the confirmation from Entra ID (AAD)
Run a Full Import on the Connector Space connected to Entra ID (AAD)

Check the new user again, now the object will show it's display name:

Even if you do a Delta Sync with PowerShell you still see the new object as Awaiting Export Confirmation after the Delta Sync successfully finished.

To try this create a new user like "Delta New User" and run a Delta Sync manually ( Start-ADSyncSyncCycle -PolicyType Delta ).
Check the object in the Connector Space connected to the Entra ID (AAD). It shows as Awaiting Export Confirmation.

The "Awaiting Export Confirmation" status means that the Sync Engine has successfully exported the new user object to Entra ID but has not yet received confirmation that Entra ID processed the change.

The Sync process (exporting the change from AD to Entra ID) is asynchronous, meaning changes are sent to Entra ID, but the system waits for confirmation that they have been processed. Once Entra ID acknowledges the export, the status will update, and the object will be fully synchronized.
Until then, the object remains in this state, indicating the process is not yet complete.
Confirmation will occur during the next Sync Cycle or can be triggered manually by initiating an Import (full or delta) from Entra ID, as demonstrated in the example.

Understanding Entra Connect Sync Architecture: A Deep Dive - Part 2

Merényi Mónika — Sat, 15 Feb 2025 17:47:23 +0000

Introduction

In Part 1, we explored the core components of Microsoft Entra Connect Sync—Connectors, the Connector Space, and the Metaverse—which form the foundation of identity synchronization. But how does data actually move through the system? How does Entra Connect Sync ensure changes in your on-premises Active Directory (AD) are reflected in Microsoft Entra ID?

In Part 2, we’ll dive deep into the synchronization process, exploring how sync objects interact and move identity data through the system.

Let's begin!

We already discussed Sync Engine in the previous post, but here is a recap:

Sync Engine

The Sync Engine is a system that synchronizes identity data across different sources, such as a company’s HR database, Active Directory, and cloud services. It acts as a middleman, ensuring that changes made in one system—like adding a new employee to HR records—are reflected in other connected systems.

And let's dig deeper:

To manage this synchronization, the Sync Engine uses objects, which are digital representations of users, devices, or groups from various sources.

Every object in the sync engine must have a globally unique identifier (GUID), to make sure there are no duplicates and to track relationships between objects.

Types of Objects in the Sync Engine

For recap: Connector Space is where identity data from external systems (like Active Directory, HR databases, or cloud services) is temporarily stored before being processed and synchronized with the metaverse.

Objects in the Connector Space include:

1. Staging Object

This is the most important type.

A staging object is a temporary copy of an object from a connected data source, stored in the connector space before synchronization.

It stores key attributes and operational data needed for synchronization.

Key Characteristics of Staging Objects

Each staging object has a GUID (globally unique identifier) and a distinguished name for identification.
It always includes an object type to define its nature (e.g., user, group, device).
Staging objects from an imported data source always have an anchor attribute (a unique key that remains constant for an object).
NOTE: Newly provisioned objects (created by the sync engine) do not yet have an anchor attribute until they exist in the connected data
source.

Check one user for example in Synchronization Service Manager:

Synchronization Service Manager » Connectors » your local AD connector - Right click » Search Connector Space

Role of Staging Objects in Sync

They store identity attributes(such as name, email, group memberships).

They track operational status for synchronization.

The sync engine does not apply changes immediately. Instead, it stages changes in the connector space before they are processed.

This is where the "pending import" and "pending export" flags come in.

Pending Import

The sync engine has received new or updated data from a connected data source, but it has not yet processed that data.

Example:

A user in your on-premises Active Directory (AD) changes their name.

The user object in the connector space is updated with the new name address, but it has not yet been written to the metaverse.

Until the sync engine applies this change, the object is flagged as "pending import."

Source of the picture

Pending Export

The sync engine has processed a change and is ready to send it to a connected system, but it has not yet been applied.

Example:

The sync engine determines that a new employee needs to be provisioned in Microsoft Entra ID (Azure AD).
It creates an export object in the connector space to send this new identity to Entra ID.
However, until the sync engine successfully exports the object, it is flagged as "pending export."

Source of the picture

Import Object → Created when sync engine detects an object in a connected data source and stages it in the connector space.

Export Object → Created when an update needs to be sent from the sync engine to a connected data source.

Why is this important?

These flags help the sync engine track unprocessed changes, ensuring that:
✅ Only necessary updates are applied.
✅ No redundant or conflicting changes occur.
✅ Data remains consistent across connected systems.

2. Placeholder

Placeholders are temporary objects in the Sync Engine used to preserve the structure of hierarchical systems like Active Directory. For example, if a user is imported but their manager’s record isn’t available yet, a placeholder is created to represent the missing manager. Once the manager’s record is imported, the placeholder is replaced by the actual object.

3. Disjoined Objects (Disconnector Objects)

These are staging objects in the Connector Space that are not linked to any object in the metaverse.
They exist in the Sync Engine but don’t yet affect synchronization.

An object becomes disjoined if, for example, it fails to meet synchronization criteria.

Source

Object in the metaverse:

Metaverse object:

A metaverse object represents a consolidated view of identity data aggregated from one or more connector space objects (imported from connected data sources).

Automatic Creation & Deletion:

Metaverse objects cannot be manually created or deleted.
They are automatically generated when a connector space object is linked to the metaverse.
If all linked connector space objects are deleted or disconnected, the sync engine automatically removes the corresponding metaverse object.

Attribute Flow & Synchronization:

The metaverse object maintains the most up-to-date identity information through attribute flow, where changes from the connector space are synchronized into the metaverse.

One-to-Many Relationship:

A metaverse object can be linked to multiple connector space objects (from different connected data sources).
However, a connector space object can be linked to only one metaverse object.

Joined objects

When a staging object in the Connector Space is linked to a metaverse object, it becomes a joined object.

This allows data to flow between the metaverse and the external system.

Source

Summary

Objects in the Connector Space → Staging Objects, Placeholders, Disjoined Objects.
Objects in the Metaverse → Unified identity objects.
Objects linked between both → Joined Objects (Connector Objects).

A little illustration that I created shows everything we discussed so far.

Objects from a connected data source are temporarily stored in the Connector Space as staging objects.

Import objects exist in the Connector Space for the on-premises Active Directory (AD).
Export objects exist in the Connector Space for Microsoft Entra ID.
The synchronization process follows these steps:

Inbound Synchronization: The object is first synchronized from the Connector Space to the metaverse, governed by inbound synchronization rules (ISR).

Outbound Synchronization: The object is then synchronized from the metaverse to the target Connector Space as an export object, following outbound synchronization rules (OSR).

This ensures that identity data flows correctly between systems while maintaining consistency across environments.

In the next part we will se everything in action.

Understanding Entra Connect Sync Architecture: A Deep Dive - Part 1

Merényi Mónika — Fri, 14 Feb 2025 17:45:59 +0000

Introduction

In today's cloud-driven world, identity synchronization is the backbone of seamless user access across hybrid environments. Microsoft Entra Connect Sync plays a crucial role in ensuring that on-premises directories and Microsoft Entra ID remain in sync.

But how does it really work under the hood? What components make up this synchronization engine? And how do sync rules define the flow of identities?

In this deep-dive series, we'll unravel Entra Connect Sync Architecture, breaking down:
✅ Core components of Entra Connect Sync
✅ Data flow and processing in synchronization
✅ Connectors, metaverse, and rules engine
✅ How synchronization rules shape identity lifecycle management

This first post focuses on understanding the architecture before we explore the intricacies of sync rules in future articles.

In my first post I quickly run over the basic architecture of Entra Connect, and we used it in real life, but I haven't really explained how it works in details.

I believe it will be valuable for many to explore the design and grasp the fundamental concepts.

What is Entra Connect Sync?

Entra Connect Sync bridges your on-premises Active Directory with Microsoft Entra ID by synchronizing user identities to the cloud. The data flow is fully customizable using sync rules, allowing you to control how information is synced. This ensures seamless authentication across your hybrid environment.

This topic explains how key features of the Microsoft Entra Connect Sync service work.

Sync Engine Overview

The sync engine gathers and manages identity data from multiple sources, such as Active Directory or SQL Server, creating a unified view of identities.
Any system that structures data in a database-like format and supports standard data-access methods can be a data source. These synchronized data sources are known as connected directories (CD) or connected data sources.

Connectors

The sync engine interacts with connected data sources through modules called Connectors. Each data source has a specific Connector that translates operations into a format the source understands.

Connectors use API calls to read and write identity data between the sync engine and the data source.
Custom Connectors can also be created using the extensible connectivity framework for additional integration options.

Connectors are installed on the machine that is running Entra Connect Sync.
They enable communication without requiring specialized agents by using remote system protocols. This approach reduces both deployment time and risk, particularly when integrating with critical applications and systems.

The connector handles all import and export operations, freeing developers from having to understand the native connection methods of each system.

Imports and exports are scheduled, meaning changes in the system do not automatically sync to the connected data source. Additionally, developers can create custom connectors to integrate with virtually any data source.

The default synchronization schedule for Microsoft Entra Connect Sync is set to run every 30 minutes. This means that the sync engine checks for updates and performs imports or exports at 30-minute intervals.

We will talk about imports and exports a little bit later.

Connector Space

Each connected date source is represented as a filtered subset of objects and attributes in its own Connector Space. The identity data is temporarily stored, and this design allows the sync engine to operate locally, reducing the need to interact with the remote system during the sycn process. It ensures that the data is properly mapped and syncronized before it is moved to its final destination.

The sync engine uses the connector space to determine what has changed in the connected data source and to stage incoming changes.

Metaverse

The metaverse is a central repository that consolidates identity data, acting as a unified view of identities from one or more connected data sources.
It stores and organizes identity objects and their attributes, ensuring they are mapped correctly and synchronized across systems.

The metaverse manages attribute flow, which is the process of transferring and transforming data based on predefined attribute mappings.

Attribute flow between the connector space and the metaverse is governed by synchronization rules, which define one-way data movement per rule. However, multiple rules can run in the same sync cycle, allowing bidirectional updates in different stages of synchronization.

Even with a single data source, the metaverse plays a key role in ensuring data is structured properly and updated efficiently without re-evaluating connections every time.

Here you can see how multiple data sources would use the metaverse:

Sync Engine Identity Management Process

The sync engine ensures identity updates between connected data sources through three main processes: Import, Synchronization, and Export.

Import

The sync engine retrieves the identity data from the connected data source and stages it in the connector space. It detects changes and marks them as pending import for processing. Staging objects in the connector space ensures only modified data is synchronized, improving efficiency.

Synchronization

This process updates the metaverse with new or changed data from the connector space (inbound syncronization) and propagates updates back from metaverse to the connector space (outbound synchronization).
New objects maybe created (projected), linked to existing records (join), or updated as needed.

Export

Changes staged in the connector space as pending export are sent to the connected data source. Since the sync engine doesn’t maintain a persistent connection, it verifies changes by re-importing data to confirm successful updates.

Note: Sync engine does not maintain a live, continuous connection to external systems. Instead, it imports data on a scheduled basis to verify changes and confirm that exports were applied correctly.

Synchronization rules

Inbound and outbound syncronization both controlled by synchronization rules.

Inbound Synchronization Rules (ISR)

They define how the data flows from connector space to the metaverse.
They determine whether objects should be joined, projected (creating new objects) ** , or **updated and specify which attributes should be mapped to the metaverse.

Outbound Synchronization Rules (OSR)

Define how data flows from the metaverse to the connector space. They determine whether changes in the metaverse should be applied to connected data sources, including updating attributes, provisioned(creating new objects), or **deprovisioning* (disconnecting/deleting) objects.

In summary: new objects may be projected into the metaverse (projection), linked to existing records (join), or updated as needed. If a metaverse object needs to be created in a connected data source, it is provisioned into the corresponding connector space.

In Part 2, we’ll see more about the objects created in each space!

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

Merényi Mónika — Thu, 06 Feb 2025 11:44:33 +0000

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.

8. Connect with the user account synced from AD

Firt we need to install an extension to the VM. For this go to your VM » Settings » Extensions + applications » Add

Install the Azure AD based Windows Login Extension:

Go back to your VM » Security » Identity
Enable the System Assigned Managed Identity, this allows the VM to authenticate with Entra ID.
SAVE.

Add one of the Virtual Machine Administrator Login role to the user you selected for this test.

Access Control (IAM) » Add »» Virtual Machine Administrator Login

Select the user and assign the role.

Next steps:

Add your user as a remote desktop users:
_net localgroup "remote desktop users" /add "cloudup1@neontiger12.com"
_

In your client VM check if RDP is enabled.
Settings » System » Remote Desktop

Check the Select Require devices to use Network Level Authentication to connect option.

Log out from the machine.
Lookup the RPD file you downloaded for the client and make a copy of it, edit the copy and add following line at the end:

enablecredsspsupport:i:1

After login check the status of the PRT, now you should see it as Yes.

Open Edge and enter: https://myapps.microsoft.com/neontiger12.com
Change your domain address accordingly.

Myapps portal should available without the asking the user to login.

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

Merényi Mónika — Wed, 22 Jan 2025 22:34:07 +0000

Introduction

Part 1.SSO and PRT introduction

Before creating our new device, let's discuss:

What is Single Sign-On (SSO)?

SSO is an authentication method that lets users sign-in to multiple applications and systems with a single set of login credentials. Authenticate once and access all the connected resources seamlessly.

Advantages:

Convenient for the user: they don't have to remember separate credentials for different applications.
Security: centralized management of authentication, if a user left the company all it's related access will be revoked. Users don't use the same password multiple times.
Efficiency: reduces the time needed for login. Reduces the number of tickets for the password reset.

Key Protocols Used in SSO

Two key protocol is used for SSO in the cloud.

1. SAML (Security Assertion Markup Language)

Open source standard to securely exchange authentication and authorization information between an Identity Provider (IdP) and a Service Provider (SP).
It uses an XML SAML assertion (security token) to provide the access to the service.

2. OpenID Connect (OIDC)

Built on top of Oauth2.0. Provides authentication by verifying the user's identity and issue an ID token.
ID token: Json web token (JWT) has claims about the user (like username, email, authorization status..)

How to decide which one to use?

Choose OIDC if you're working with modern, cloud-native apps or APIs that require lightweight communication and JSON support.

Opt for SAML if you're integrating with legacy applications or enterprise systems already using SAML.

Quick mention about the on-premise authentication protocols used for SSO:

Kerberos
A network authentication protocol that uses tickets to allow nodes to prove their identity in a secure manner.
Commonly used for SSO in Windows environments.

WS-Federation
Enables SSO by allowing trust relationships between security domains to federate identity.
Commonly used for legacy systems for federated identity management.
Example: Using Microsoft Entra ID to authenticate to SharePoint on-premises.

SSO options:

Active Directory Federation Service:
Used for federated domains
Seamless Single Sign-on:
Uses a combination of Kerberos and SAML for authentication.
Used in legacy Win 7 and 8.1.

3. Primary Refresh Token
Json web token issued for Win10 , Server 2016 and above, iOS, Android to enable SSO.
For Entra ID joined **or **hybrid joined device the PRT is issued when the user logs in.
For Entra ID registered device the PRT is issued when a user adds a secondary work/school account or enable "Allow my organization to manage this device" when signing in to a web application:

An Entra-joined machine is typically a corporate-owned device used in cloud-first scenarios where there is no on-premises infrastructure. Users sign in using their Microsoft Entra ID credentials, and the device is managed through Intune.

An Entra hybrid joined device is joined to the on-premise domain registered to Entra ID.It is typically corporate-owned and relies on the on-premises Active Directory for authentication. These devices can be managed using Group Policy, SCCM, or Intune.

An Entra-registered device is typically a BYOD (Bring Your Own Device) where users sign in with local or personal credentials rather than an organizational account. These devices can be managed using Intune or Microsoft Endpoint Manager (MEM).

Primary Refresh Token

Key terms

Cloud Authentication Provider - CloudAP:

Handle the authentication process during login.
Verify user credentials.

Entra CloudAP Plugin (CloudAP Plugin):

Built on the CloudAP framework.
Request the PRT.
Cache the PRT for seamless access.

Entra WAM plugin:

Enable SSO for application that rely on Entra ID for authentication.
Allow the use of existing credentials.

DSREG:

Entra component on a Windows 10 (and above) machine that handles device registrations. ! We will use dsreg command line tool a lot for checking status and troubleshooting.

What is in the PRT?

Device ID:

Identify the device to which the PRT is issued.
The deviceID claim is part of the tokens issued using the PRT.
It helps enforce Conditional Access policies by checking the device's state or compliance.
Tokens include this claim to ensure secure and policy-compliant access.

Session ID:

Encrypted symmetric key, generated by Entra authentication service, issued as part of the PRT.
Securely transferred to the clients machine and stored in the TPM.
Acts as a proof of possession when issuing for tokens.
(No one can extract it from the TPM)
Rotated if the key is older than 30 days.

How PRT is issued

PRT is issued only to Entra registered devices (joined, hybrid joined, registered).
During the registration process DSREG creates two asymetric key pairs:

Device Key (dkpub/dkpriv): Key associated with a registered device, used to verify the device's identity to Microsoft Entra ID and other services.
Transport Key (tkpub/tkpriv): Encrypts data during its transfer, ensuring secure communication between the client and the server.

The private keys are bound to the machine TPM (if has one) and the public is sent to Entra ID during the registration process.

How PRT is used

During user login the Entra CloudAP plugin request the PRT from Entra ID and caches it for seamless (or offline) use.

The WAM Plugin is used when the user tries to access an application.
Request access and refresh token to application using WAM plugin. Enables SSO by injecting the PRT into the browser request.
Browser SSO is supported on Microsoft Edge, Chrome (via Windows 10 Accounts), and Mozilla Firefox v91+ (with the Firefox Windows SSO setting).

For Entra ID registered devices the whole process is handled by the WAM plugin because there is no Windows login.

Lifespan of the PRT

The PRT is valid for 14 days and it is continuously renewed on active device.

Now, we know everything about SSO and PRT. We will try this out in the next post!

Deploying and Configuring a Hybrid Identity Lab Using Bicep - Part 2: Authentication options (PHS, PTA)

Merényi Mónika — Mon, 20 Jan 2025 21:10:39 +0000

Introduction

In this second part of our lab exercise, we shift focus to exploring authentication methods, discussing Password hash sync and Pass-through authentication in detail. These features are essential for improving user experience and enhancing security in hybrid identity environments.

This post assumes you’re familiar with basic security concepts like hashing and encryption. Don’t worry. I’ll explain everything in a clear and simple way! 😊

Goal

By the end of this exercise, you will:

Configure multiple authentication methods in Entra ID (Password Hash Sync, Pass-through Authentication).

Let's jump right in! :)

Recap what we have so far:

We deployed a virtual network and a server including all of its necessary components like network interface card, static private IP address (10.1.1.5). The server acts as a Domain Controller and a DNS server. We successfully synchronized users from on-premise to Entra ID.

Discussing the authentication options

While we value the on-premises data source, the focus is shifting towards leveraging the cloud to reduce reliance on on-premises resources.

One way to achieve this is by enabling Password Hash Synchronization (PHS). With PHS, authentication is handled by Entra ID, which uses a securely stored hash of the on-premises password hash to validate sign-in requests.

This approach allows users to continue using their familiar AD passwords, but authentication is managed entirely by Entra ID rather than the on-premises Active Directory. This shift enhances reliability, reduces dependency on on-premise infrastructure, and supports cloud-first strategies while providing a good user experience by eliminating the need to remember separate credentials. This also reduces helpdesk costs by minimizing the volume of password reset requests.

Are you ready to dig a little bit deeper in this topic?

How PHS works?

Active Directory domain service stores the user's password in a hash format. The hash is a result of a one-way mathematical function, there is no way to revert back to the original plain text.

On the DC passwords are stored as NT hashes, which are based on MD4 algorithm. You are right if you ask: isn't it weak? Indeed, MD4 is considered as a weak hash algorithm by modern standards, however it is used to ensure compatibility with older systems.

Don't worry. The process implement security features for the data in transit between the AD and the PHS agent on the Entra Connect Sync server. Entra Connect Sync agent will make sure the hash is secure enough to meet modern standards.

1. Sync:
Every 2 minutes the PHS agent queries the AD DC for the password hash, it uses a standard replication protocol called MS-DRSR.

The MS-DRSR (Directory Replication Service Remote Protocol) is an RPC(Remote Procedure Call) protocol that facilitates replication and management of Active Directory data between Domain Controllers.

2. Secure the hash before sending:
The DC creates a key from the MD5 hash of the RPC session key and a salt.
Encryption key = MD5# session key + a salt.
The password hash is encrypted with this key.

Salt is simply an added security mechanism, making the hash unique even if the passwords are the same.

3. Data transmit:
DC sends the encrypted hash, and the salt separately (the salt itself is not encrypted) to the PHS agent over RPC (Remote Procedure Call).

4. Decryption:
**The synchronization agent uses the MD5 hash of the RPC session key combined with the salt to generate the decryption key. This key is then used to decrypt the encrypted MD4 password hash sent by the DC.

Just for fun: the decryption key is generated by the MD5CryptoServiceProvider which is .NET framework that provides a managed implementation of the MD5 hash algorithm.

If you worried about the MD4 not being secure enough you can relax :).
Entra Connect Sync makes sure the password hash is secure even by the strictest security standards. Let’s explore how it achieves this level of protection.

5. Making the hash secure:

a. Expanding the size of the hash from 16 bytes to 64 bytes.
b. The agent adds a 10 byte per-user salt to further protect the hash.
c. The 64 bytes hash and the 10 bytes user specific salt is combined and put through the Password-Based Key Derivation Function 2 (PBKDF2)
PBKDF2 applies the HMAC-SHA256 hashing algorithm 1,000 times to the input. This computational effort makes the hash much more resistant to attacks.
HMAC (Hash-based Message Authentication Code) with SHA-256 is a strong hashing algorithm used to generate a final 32-byte hash.

6. Sending to Entra ID:
The final 32 byte hash is sent to Entra ID over a secure TLS connection along with the user-specific salt and the iteration count.

7. Authentication:
When a user attempts to authenticate, their password undergoes the same hashing process. If the resulting hash matches the securely stored value, the user is successfully authenticated.

The user might have to enter their corporate credentials when authenticating to Entra ID even if they already authenticated on-prem. However, the "Keep me signed in" option creates a session cookie that allows users to stay signed in for up to 180 days.
The session cookies also follow corporate security policies, adding an assurance of security.

Additionally, you can minimize password prompts by configuring Microsoft Entra join or Microsoft Entra hybrid join devices. These configurations enable automatic sign-ins for users on their corporate devices when connected to the corporate network.

I hope this diagram I created helps you understand the process better, as it provides an overview about what is happening.

Checking the PHS status

If you remember we enabled PHS when we setup the Connect Sync:

We can, however, still enable or disable this option with Entra Connect Sync:

Configure sync options in Entra Connect:

Configure synchronization options:

Authenticate and go to Optional features:

Confirmation and troubleshooting

Let's check the status of the sync in Entra ID:

In the portal go to Entra ID » Microsoft Entra Connect » Connect Sync

You can see that the PHS is enabled.

Use the following command-line tool to validate sync status:

Invoke-ADSyncDiagnostics -PasswordSync

Let's review the output:

AAD Tenant - calcio15gmail.onmicrosoft.com
Password Hash Synchronization cloud configuration is enabled

» this means that the PHS is enabled on the Entra side. No issue here.

AD Connector - neontiger.local
Password Hash Synchronization is enabled
Latest Password Hash Synchronization heartbeat is detected at: 01/19/2025 16:33:28 UTC

» this means that the PHS is enabled on the AD side. It shows the latest heartbeat. No issue here.

Check the time of the latest sync:

Last successful attempt to synchronize passwords from this directory partition started at: 1/19/2025 4:5
1:29 PM UTC and ended at: 1/19/2025 4:51:29 PM UTC

Only Use Preferred Domain Controllers: False

Verify the connectivity to the domain:

Checking connectivity to the domain...
Domain "neontiger.local" is reachable

Let's assume you want to troubleshoot the PHS issue for one particular user.

At the end on the output it ask you:

Did you find Password Hash Sync General Diagnostics helpful? [y/n]: y

Your answer, yes or no it doesn't matter :).

The next question is:

Would you like to diagnose single object issues? [y/n]: y

Yes, you would like :).

Copy the distinguished name from: Users and Computers » Users » right click on the user » Properties » Attribute Editor » distinguishedName

Paste it:

Please enter AD connector space object Distinguished Name: CN=CloudUp1,CN=Users,DC=neontiger,DC=local

Check the output:

The object is available in the AD connector space - neontiger.local
The object is a connector, it has a link to the metaverse
The object is synced to the AAD connector space

» Here you can verify the status of the object in the connector space.

We would like to see this output at the end:

_Password hash is synchronized successfully _

NOTE:
You can run the Invoke-ADSyncDiagnostics cmdlet without any parameter and navigate through the different diagnostic options.
Feel free to explore it! :)

If that wasn't enough, then run this script that might further help you with the troubleshooting process:

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-password-hash-synchronization#get-the-status-of-password-sync-settings

Here is a comprehensive guide from Microsoft in case you face any issue here:

https://learn.microsoft.com/en-gb/entra/identity/hybrid/connect/tshoot-connect-password-hash-synchronization

This setup now should allow your users to sign-in to cloud applications with their on-premise password.

To verify this quickly, go to DC1 and select a user from your on-premises Active Directory. Use their credentials to sign in to office.com. Voilà, your user signed in to a cloud application without creating a username/password in that application.

Keep in mind that you set the default password for these users in the users.ps1 script. If you haven’t changed it since, you should already know what it is. 😊

Next up, we'll explore the Pass-through authentication as an alternate sign-in option.

Pass-through authentication (PTA)

Pass-through authentication (PTA) allows users to authenticate to cloud applications using their Active Directory (AD) credentials. However, in this case, the authentication is handled by the on-premises Active Directory rather than Entra ID.
This option is ideal for organisation that want to keep authentication processes within their own infrastructure for compliance or control reasons.

Note: only AD synced users can authenticate with this method.

How PTA works

Components involved in the PTA authentication:

Microsoft Entra Security Token Service (STS):
Stateless service used to handle sign-in requests and issue security tokens to browsers, clients, or services.

Azure Service Bus:
Azure Service Bus is a cloud-based messaging service enabling communication between applications and services. It offers features like message queues and publish-subscribe topics to decouple applications.
Publish-subscribe topics allow multiple publishers (any application, service, or component, whether on-premises or cloud-based) to send messages to a central topic, which subscribers can receive based on their filtering rules, ensuring efficient and scalable communication.

Microsoft Entra Connect Authentication Agent:
The on-premise component responsible for listening and responding to the password validation requests.

Azure SQL Database:
Holds authentication agents information including their metadata and encryption key.

Windows Server AD:
On-prem AD, where the user account and their associated password is stored.

Install and register authentication agents

You can enable PTA two ways:

When you first setup Entra Connect Sync:

Choose Pass-through authentication as a Sign-in option instead of Password Hash Sync.

Modify the Sign-in option with the Entra Connect Sync wizard

More on these options when we enable PTA in our environment.

The authentication agent is installed and registered with Entra ID when you enable PTA.

The preparation of the authentication agent involves three main phases:

Installation
Registration
Initialization

Now, let's uncover each phase in details.

Installation

For the installation and registration process you need a user with either Hybrid Identity Administrator or a Global Admin.

Two methods available to install the agent:

Enabling Pass-Through Authentication (PTA) with Entra Connect:
This method integrates the authentication agent during the Entra Connect setup process.

Standalone Installation:
You can also install the authentication agent separately by downloading the installer and configuring it manually.

Agent registration:

After installation, the agent registers with Entra ID.
Entra then issues a certificate, facilitating secure communication between the agent and Entra ID. This process also binds the authentication agent to the tenant, ensuring Entra recognizes which agent is authorized to handle password validation requests.
This procedure must be repeated for each agent you register.

Let's see it in detail:

During setup, the Hybrid Identity Administrator (or Global Admin) authenticates to Entra ID. In the sign-in process the authentication agent receives an access token allowing it to act on behalf of the user.
The authentication agent generates an RSA 2048-bit public-private key pair. The private key is securely stored on the on-premises server where the agent resides.

Note:
As of now, RSA 2048-bit encryption is still in use. However, recent guidelines recommend upgrading to more secure encryption by the end of 2025. Stay tuned for Microsoft announcements to see if any action is needed from your side.

The authentication agent sends a registration request to Entra ID over HTTPS, including the components:

The access token
The public key
A Certificate Signing Request (CSR) applying for the digital identity certificate

Entra verifies the request:
Is come from an authorized user?
The access token is valid?
The root CA in Entra ID signs the digital identity certificate, which is used exclusively for the PTA feature. The certificate's subject is the tenant ID, ensuring it can only be used with your tenant.
Entra ID stores the public key in an Azure SQL database, which is accessible only by Entra.
The on-premise server stores the certificate in the Windows certificate store (CERT_SYSTEM_STORE_LOCAL_MACHINE).

Initialization:

The authentication agent send a secure request to Entra ID to start the process.
Over port 443.
Entra provides an access key for a unique Service Bus queue linked to your tenant.
The agent establishes a secure (HTTPS)connection to this queue.

If you have multiple authentication agents, the initialization process ensures that the agents connects to the same Service Bus queue.

Now, we will dive into how the actual sign-in requests are handled.

PTA Sign-in requests:

When a user tries to access an application like Outlook Web App and is not signed in, the app redirects the browser to the Entra ID sign-in page. The Entra STS service then responds with the sign-in page.
User enters his/her credentials.
Entra STS encrypts the password with the public key of the registered authentication agents (retrieved from Azure SQL Databese) producing one encrypted password for each registered authentication agent.
In the next step, the Entra STS places the encrypted password into the Service Bus queue specific to your tenant.
During the initialization phase, the authentication agent configured a persistent connection to the Service Bus queue, allowing it to retrieve password validation requests.
The authentication agent decrypts the password with it's private key.
The authentication agent validate the username/password with AD DS.
The result is retrieved from AD DS is either success, username/password incorrect, or password expired.

Here is a diagram explaining the PTA sign-in process:

Transmitting passwords between servers needs strong security measures. We'll talk about these measures in the next section.

PTA security capabilities

Secure multi-tented architecture:

Even though Entra is built on a shared infrastructure, each tenant's data and sign-in requests are completely isolated from one another, ensuring the organization's data remains secure and private.

On-premises passwords are not stored in the cloud

The connection from the authentication agents is outbound only:
The agent initiates a connection to Entra ID and retrieves password validation requests by making an outbound connection to the Service Bus queue.
This makes sure that only outbound ports (80, 443) required:

443 for all authenticated communications.
80 to download certificate revocation lists (CRLs)

Passwords used are encrypted in the cloud before sending it to the on-premise infrastructure using a secure HTTPS channel.

Works with Entra features for protecting the identity:

Conditional access policies
MFA
Block legacy authentication
Smart lockout

Important considerations:

Since this solution relies on the on-premise infrastructure configure more than one server hosting authentication agent for high reliability.
Treat them as Tier 0 systems:
Tier 0 systems are the most critical assets in the organisation. These systems are highly privileged, must be strictly managed and protected.

Now, that you are equipped with the necessary understanding about the PTA let's configure it in our environment!

As already mentioned, you can enable PTA two ways:

When you first setup Entra Connect Sync:

Choose Pass-through authentication as a Sign-in option instead of Password Hash Sync.

Check out the note there:
Microsoft recommends that the user performing the Pass-through Authentication (PTA) setup should be a cloud-only user. This is crucial because, once Pass-through Authentication is enabled, hybrid users will be unable to sign in if there is a service disruption to the on-premises Active Directory.

To avoid being locked out, ensure you have cloud only account that can manage sign-in options (and Entra).

Modify the Sign-in option with the Entra Connect Sync wizard

Click Configure in Entra Connect Sync.

Choose Change user sign-in.

Authenticate with your Hybrid Identity Admin or Global admin user.

Change the Sign-in to Pass-through authentication.

Click Next.

Now the Entra Connect Sync will install and initialize the authentication agent.

Click Configure and wait for the wizard to complete the task.

Password hash synchronization (PHS) is enabled, as shown. It is a good practice to enable PHS even if you are using Pass-through Authentication (PTA). This is because Microsoft continuously monitors the dark web for leaked credentials and can notify you if any of your users' credentials are compromised.

You can also use Password hash sync as a fallback option in case PTA experiences issues (e.g., connectivity or service outages with the on-premises agent).

If you want to disable, run the wizard again and change the settings in Customize synchronization options. Disable Password hash sync.

Check if the PTA is enabled correctly:

Here's another useful troubleshooting technique using the Invoke-ADSyncDiagnostics cmdlet:

We'll create a log file that displays the status of the synchronization process.

Run the cmdlet, enter: 3 and wait for the result. The log file will open in Internet Explorer.

The log file will provide a comprehensive overview for every aspect of Entra Connect Sync. Look for the Microsoft.UserSignIn.SignOnMethod:

Check it in Entra portal:

Entra ID » Microsoft Entra Connect » Connect Sync:

You can see it is Enabled.

Click on the Pass-through authentication to check the status.

The recommendation emphasise the importance of having multiple (at least 3) authentication agent for high availability.

This is the end of this lab and overview of the different authentication options.
Still there are a lot to discuss.
In the next session we will discuss and enable SSO.

Deploying and Configuring a Hybrid Identity Lab Using Bicep - Part 1: Active Directory Setup and Sync

Merényi Mónika — Wed, 15 Jan 2025 15:29:56 +0000

Introduction

Setting up a hybrid identity lab is a fantastic way to dive into the world of modern identity and access management. Since there's so much to cover in this exciting field, it’s best to break it down into smaller, bite-sized chunks. That way, you can tackle each piece one at a time and have fun while building your skills without feeling overwhelmed!

Part 1: Configuring Active Directory and Entra Connect Sync

In this first part, we’ll set up on-premises Active Directory (AD) and configure Entra Connect (formerly AAD Connect) to sync user identities with Entra ID. This critical step enables hybrid identity, allowing seamless access to on-premises and cloud resources with a single identity.

Objectives of Part 1:

Set up an On-Premises Active Directory Domain Services (AD DS) environment.
Install and configure Microsoft Entra Connect Sync.
Sync users from on-premises AD to Entra ID.
Verify the sync between on-premises AD and Entra ID.

We’ll cover:

Deploying resources using a Bicep template.
Syncing on-prem users to Entra ID with Entra Connect.

By the end of this lab, you’ll have a functional hybrid identity setup to experiment with.

Prerequisites

Before starting, ensure you have:

Azure Subscription: Active and with P1 license.
You can do this lab practice with Free subscription as well, just with limitations. Free license does not allow you to create custom domain for example.

Setup custom domain in your tenant:
https://learn.microsoft.com/en-us/entra/fundamentals/add-custom-domain

Cloud user with Global Admin rights

Get the Bicep files from here: https://github.com/neontiger12/EntraConnect

Install Visual Studio Code: use VS Code to modify the bicep files.

Lab setup

All the resources will be deployed in the West Europe region.

The virtual network details:

VNet Name: VirtualNetwork01
IP Address Space for VNet: 10.1.0.0/16
**Subnet Name: **Subnet01
Subnet IP Address Range: 10.1.1.0/24

Domain Controller - Server

Virtual machine name: DC1
Static private address: 10.1.1.5

What is Bicep and Why Use It?

Bicep is a domain-specific language (DSL) for deploying Azure resources. It simplifies the process of defining infrastructure as code (IaC), making templates easier to read, write, and maintain compared to traditional JSON ARM templates.

Here’s why we’re using Bicep in this lab:

It allows for declarative infrastructure: You specify what you want, and Azure takes care about the how to do it.
It provides a modular approach: Resources like the VNet and server can be managed independently.
It’s easier to write and manage: Bicep is more human-readable, which reduces errors and accelerates deployment.

For those new to Bicep, stay tuned! I’ll explain the templates step-by-step in a future post to help you build and customize your own deployments.

A quick run through the files:

The configurations for the client and server are split into separate modules to make the Bicep file more organized and readable:

Network Module: Manages networking resources like the VNet and subnets.
Server Module: Handles server settings like VM size, OS, and network interfaces.
This modular approach improves readability, reusability, and simplifies management.

The main Bicep file acts as the central point that ties everything together. It references the network and server modules, passing in the required parameters and ensuring all resources are deployed in a coordinated way. This keeps the structure clean and easy to maintain.

1 - Setup the environment for the Bicep template

Install Azure CLI: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli
Login to your Azure account:
az login
https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli-interactively
Install the bicep extension in Visual Studio Code (if you would like to modify the Bicep files)
We are using the terminal of the VS Code for easier access. Make sure you are running the commands from the directory where you store the bicep files.

2 - Deploying the Virtual Network

This guide explains how to deploy a Windows Server hosting Active Directory Domain Services (AD DS) using Bicep. We'll separate the deployment into two resource groups:

Resource Group for the Virtual Network (VNet): Shared between the server and client.
Resource Group for the Server: Hosts the Windows Server for AD DS.

The first step is to deploy the VNet, which will connect the AD server and the client machine.

We need to create a separate resource group for this.
For example the name of the vnet is "Vnet", the location is Westeurope.

az group create --name Vnet --location westeurope

Check the deployment result.You should see 'Succeeded'.

Now, we are deploying the Vnet resource:

az deployment group create --resource-group VNet --template-file vnet.bicep

After the deployment check the provisioning state, it should be "Succeeded"

Now that the network is set up, we’re ready to deploy the Domain Controller (DC)!

3 - Deploy the Server for the Domain Controller

Create the resource group first:

az group create --name DC_RG --location westeurope

After the successfully creating the resource group lets deploy the server!

az deployment group create --resource-group DC_RG --template-file main-server.bicep

You will be asked to provide the admin username and password:

After a couple of minutes the deployment should be ready.

provisioningState": "Succeeded"

Go to the Azure portal check the VM you just created and click Connect:

Download the RDP file and open it to remotely connect.

Since we enabled port 3389 you should not face any issue connecting.

We are ready to setup the Domain Controller and the DNS service on the server.

4 - Configure the DC and DNS service

Open the ADDS.ps1 with PowerShell ISE and Replace placeholder values yourdomain.local, yourdomain, and P@ssw0rd! representing your environment:

Run the script. The server will restart once the installation finishes.

Reconnect and check the Server Manager. You should see the ADDS and the DNS configured.

Now it is time to create users!

Modify the placeholders for user prefix, domain and password to match your environment.

After running the script check the created new users:

If you check the domain you see that we used a non-routable domain: neontiger.local for this example. This is good for internal use, however we need to ensure we can synchronise our newly created users to Entra ID.

For synchronisation, Entra ID requires that at least one domain is routable and verified in your Azure tenant.

Entra ID uses User Principal Names (UPNs) to identify users.
If your UPN suffix is @neontiger.local, Entra ID will not accept it because it's non-routable.

A routable, verified domain (like neontiger12.com in this example) is required for UPNs to sync properly with Entra ID.

Add your custom domain name to Active Directory Domains and Trust:

right click on Active Directory Domains and Trust and click Properties

Don't forget to click Apply and then OK.

If you check your user's property again you should see the new domain available:

Let's fix the UPN for the users!

Microsoft's IdFix tool helps you to prepare your AD for the synchronisation. It identifies and fix issues, like the non-routable UPNs.
Download and install the tool.

IDfix
https://github.com/microsoft/idfix/tree/master/MSIs

Run the Query.
The result will show the issue with the UPN:

Open the UPN_update.ps1 with PowerShell ISE and replace the relevant parameters to represent your current local and the new routable domain.
Run the script to update the UPN of the users.

Run the IdFix query again to confirm that the script has resolved the issue.
Now the Cloudup users should disappeared from the list.

There is one tiny problem left with my admin user: the DisplayName attribute is empty. Fix it by adding some value to that:

Users are ready, now let's do the connect to Entra ID!

5 - Connect to Entra ID

Fix the TLS 1.2
Entra ID Connect requires TLS 1.2. You can enable it on your server by running the following script (tls.ps1) from:
https://github.com/neontiger12/EntraConnect/tree/main/powershell-scripts

Download and install the Entra Connect Sync:

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Accept the terms and conditions and click Continue.

Choose Customise, leave the next page as default and click Install.

Choosing a Customized Entra Connect setup allows you to tailor synchronization options to your specific needs, such as filtering which organizational units (OUs) or attributes to sync, or enabling password writeback.

User Sign-In

The Sign On method is Password Hash Syncronization.

Click Next.

Connect to Microsoft Entra ID

Use your Global Admin user to connect.

You might face this issue with the sign-in:

Add the required sites to the Trusted sites.

Still after adding all of those site you can see this error message:

To fix this open Internet Options from the Control Panel: Network and Internet » Internet Options. Lower the security level of the Trusted sites.

Note: Avoid simply searching for "Internet Options" to fix this issue, as you may encounter permission-related restrictions.

Try to sign in again, this time it should work.

Connect your directories

Click Add Directory and configure a new domain admin:

When it is ready, click Next.

*Microsoft Entra Sign-in configuration
*

Tick the box next to Continue without matching all UPN suffixes to verified domain.

It's okay to continue setting up Entra Connect without matching all UPN suffixes to a verified domain, as the local domain in Active Directory will still function internally, and this setup is sufficient for our lab environment.

Domain and OU filtering

For this lab we sync all domains and OUs. Click Next.

Uniquely identify your users

Leave everything as default. We let Azure to use the mS-DS-Consistency GUID as a sourceAnchor.

The mS-DS-Conistency GUID is an attribute that uniquely identifies a user both in Active Directory and in Entra. Often leveraged as the sourceAnchor. It ensures that even if a user changes their name, the attribute remains the same, preventing the creation of a new user in Entra ID; instead, it simply updates the user's details (e.g., last name)
The sourceAnchor (also called immutableId) is an attribute that uniquely identifies an object in both on-premises Active Directory and Microsoft Entra ID. It is a Base64 encoded representation of the mS-DS-Consistency GUID.

Click Next.

Filter users and devices

Leave as default. Filtering is out of scope for this lab.
Click Next.

Optional features

Enable Password writeback as we will need this for the Self service password reset.

Ready to configure

Install.
Configuring may take a while. Maybe it is time to grab a cup of coffee :).

Once the setup is complete, you should see the 'Configuration Complete' window. The synchronisation started, wait a few minutes and check the newly added users in Entra ID.

The On-premise sync enabled is set to yes for these users.
If you check the properties for the user you can see all the attributes that were sync from AD.
You cannot change these because from Entra's prospective the on-prem AD is the source of truth.

The usage location is a good example for an attribute that you can set in Entra. This attribute can effect licensing options.

Look at the On-premises immutable ID for CloudUser1:

Now check this attribute in the Active Directory Users and Computers.
To see this option in properties we need to enable the advanced features:

Enable Advanced Features under the View menu.
Right-click the user account and select Properties.
Go to the Attribute Editor tab.
Find mS-DS-ConsistencyGUID in the list of attributes.

You might face the same issue as me, the mS-DS-ConsistencyGUID attribute is empty.

Let's fix that by initiating a sync cycle.

There is a handy PowerShell command to do it.

First install the ADSyncTools:

Install-Module -Name ADSyncTools

Reopen PowerShell ISE.

Import the module:

Import-Module -Name ADSync

Initiate a sync cycle:

Start-ADSyncSyncCycle -PolicyType Delta

The result we expecting is "Success".

Delta sync handels only changes made since the last sync to keep Entra ID updated efficiently. Initial sync, on the other hand, is the first sync that brings in all objects from on-premises AD to Entra ID. Delta is faster and incremental, while Initial is comprehensive and sets the baseline.

Now, check the attribute again in Active Directory to see if it's populated.

Now it is there however you still not sure if they are the same?
I can understand why you questioning that :).

Open the convert.ps1 script in PowerShell ISE and edit the parameters according the values your user have.
Now run the script and check the result.

Remember, I mentioned in the Uniquely identify section of the Entra Connect setup: the On-premise immutable ID is the Base64 encoded representation of the mS-DS-ConsistencyGUID attribute.
If you decode that you can confirm that those two values are the same! :)

Other way to check the sourceAnchor

You can also check these attributes with the Syncronization Service Manager.
This tool allows you to monitor and manage syncronization, provides detailed logs and information about syncronization cycle. Great to have this for troubleshooting!

Don't get overwhelmed by all those information you see.
Explaining the details about how Entra Connect Sync works deserves a post of their own.
For now it is enough if you understand that the Entra Connect consist of two Connector space: one for your on-prem AD, and one for the Entra ID.

The **connector space **holds a copy of each object and its attributes from a connected data source, helping Entra Connect track changes for proper synchronization.

The Metaverse in Entra Connect is a central database that combines and stores information from all connected data sources, creating a unified view of objects for synchronization with Entra ID.

With that in mind go to the Metaverse Search and click Search on the right hand side.

Right click on CloudUser 1 and click Properties.

The attributes displayed are those relevant to the Metaverse for that specific user. The sourceAnchor (also known as Immutable ID) is used as the unique identifier in Entra ID, while the mS-DS-ConsistencyGUID serves as the unique identifier for the identity in Active Directory.

To check the attributes applicable for the Active Directory go to the Connectors tab and select the connector that is representing your AD. Click properties.

Now you can see the mS-DS-ConsistencyGUID.
Vigilant readers might discover that the mS-DS-ConsistencyGUID is the same as the objectGUID.

This is because the mS-DS-ConsistencyGUID is copied from the objectGUID when Entra Connect first replicates the user.
The objectGUID in Active Directory changes only if the object is deleted and then re-created or if it is moved to a different AD forest. To maintain the link between Active Directory and Entra ID, we use an immutable ID that consistently represents the identity, even if other attributes change.

In the Syncronization Service Manager you can see the status of the import/export shown as "success".

Feel free to explore the Service Manager a bit more if you have time—it’s a great tool for understanding the sync process.

In the next part we will cover Entra Connect Health to further monitor our synchronization process.

Further study

For a more in-depth understanding of Entra Connect, check out this YouTube video by John Savill's Technical Training:
What is the link between Azure AD (AAD) and AD users?. It provides an excellent walkthrough and complements the concepts covered here.

DEV Community: Merényi Mónika

Understanding Entra Connect Sync Architecture: A Deep Dive - Part 3

Introduction

Understanding Entra Connect Sync Architecture: A Deep Dive - Part 2

Introduction

Sync Engine

Types of Objects in the Sync Engine

Objects in the Connector Space include:

1. Staging Object

2. Placeholder

3. Disjoined Objects (Disconnector Objects)

Object in the metaverse:

Metaverse object:

Summary

Understanding Entra Connect Sync Architecture: A Deep Dive - Part 1

Introduction

What is Entra Connect Sync?

Sync Engine Overview

Connectors

Connector Space

Metaverse

Sync Engine Identity Management Process

Import

Synchronization

Export

Synchronization rules

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

Introduction

Part 2

Deploying the client Virtual Machine

1. Resource group

2. Deploy the VM into the resource group

3. Verify

4. Connect to the machine

5. Add the VM to the domain

6. Add the device to Entra ID

7. Now setup the SSO in DC1

8. Connect with the user account synced from AD

Read more about this topic:

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

Introduction

Part 1.SSO and PRT introduction

What is Single Sign-On (SSO)?

Primary Refresh Token

Deploying and Configuring a Hybrid Identity Lab Using Bicep - Part 2: Authentication options (PHS, PTA)

Introduction

Goal

Recap what we have so far:

Discussing the authentication options

How PHS works?

Checking the PHS status

Confirmation and troubleshooting

Pass-through authentication (PTA)

How PTA works

PTA Sign-in requests:

PTA security capabilities

Important considerations:

Deploying and Configuring a Hybrid Identity Lab Using Bicep - Part 1: Active Directory Setup and Sync

Introduction

Part 1: Configuring Active Directory and Entra Connect Sync

Prerequisites

Lab setup

What is Bicep and Why Use It?

1 - Setup the environment for the Bicep template

2 - Deploying the Virtual Network

3 - Deploy the Server for the Domain Controller

4 - Configure the DC and DNS service

5 - Connect to Entra ID

Further study