How Azure AD Connect Works

December 24th, 2018 | Posted by admin in Azure AD - (0 Comments)

Azure AD Connect is the upgraded version of DirSync which is used to provision the On-Premise Objects into Azure Active Directory. There are many ways that can be used to provision the Objects to Azure AD for Office 365 like,

  • Directory Synchronization (DirSync), Office 365 Portal, Windows PowerShell, or API
  • Microsoft Azure AD Connector for FIM 2010 R2
  • Microsoft Azure Active Directory Sync tool (Azure AD Sync Tool)
  • The New Microsoft Azure AD Connect

We will see how the Azure AD Connect works on this post. Directory Sync or the Azure AD Connect is mainly required for Identity Federation and Exchange Hybrid Deployment. Below the flow diagram of how the Azure AD Connect works

Azure Connect support the below features

How Azure AD Connect works?

Azure AD Connect by default is a one-way Sync which synchronize the On-Premise AD objects to Azure AD. Before looking at the Synchronization Data Flow, we will see what are Management Agents and where AD Connect stores the information

Management Agents

Management Agents in Azure AD Connect control the data flow between a connected data source and the meta directory. DirSync or Azure AD Connect uses two managements agents.

  • Active Directory Connector management agent
  • Microsoft Azure Active Directory management agent

DirSync or Azure AD Connect stores the information in two places:

  1. Connector Space

Connect Space has the Replica of the managed objects in the AD DS and each management agent or connector has its own connector space

  1. Metaverse

Aggregate information about a managed object (that is, User, Group, etc.)

Azure AD Connect Synchronization data flow:

  1. User is imported from On-Premise AD into the Active Directory Connector space
  2. User is projected to the Metaverse
  3. User is provisioned to the Microsoft Azure Active Directory Connector space
  4. User is exported to the Office 365 Admin Web Service

Above explains how the Azure AD Connect synchronize the objects from On-Premise AD to Azure AD. If Exchange Hybrid option is selected which installing/configuring the Azure AD Connect, then below 7 attributed will be written back to On-Premise AD. (Exchange Federation is must for below Objects to write back to On-Premise AD).


Online Archive: Enables customers to archive mail.


Enable Unified Messaging (UM) – Online voice mail: This new attribute is used only for UM-Microsoft Lync Server 2010 integration to indicate to Lync Server 2010 on-premises that the user has voice mail in online services.


Litigation Hold: Enables cloud services to determine which users are under Litigation Hold.

(LegacyExchangeDN as X500)

Enable Mailbox: Offboards an online mailbox back to on-premises Exchange.


Filtering: Writes back on-premises filtering and online safe and blocked sender data from clients.


Forward Sync and Back Sync in Azure AD Connect

It is important to know what is forward sync and back sync in Azure AD Connect.

Forward Sync

It is sync from Azure AD to the Online Application directory services

  • Once the AD Objects from On-Premise synced to Azure AD, Azure AD won’t be directly referred by office 365 online application.
  • Each online application in Office 365 has their own directory service. After an object is changed in Azure AD, further synchronization are constantly running that parse relevant changes and ship them to these services’ directory partitions.
  • Since the Application directory are updating the information from Azure AD, it can cause delay in applications becoming available to newly commissioned accounts or users

Back Sync or write Back

When Exchange Hybrid Configuration feature is enabled while configuring AD Connect, there are certain attributes for the Microsoft Exchange Online service that require reverse propagation to the on-premises environment for Exchange co-existence features to work which is referred as Back Sync.

  • Back-Sync: Data is changed in the Exchange Online partition and then synced back to Azure AD using daemons similar to those used for Forward-sync
  • Write-back: Data is shipped from Azure AD directory, back through Admin Web Service, to DirSync service using bi-directional FIM functionality
  • DirSync updates the local AD DS objects with these updated attributes

I hope this post is informative, please leave your comments if any additional information required.

Your users may user different type of Strong Authentication method on their choice when MFA enabled for them. If you want to take a report on the type of Authentication Method, use the below PowerShell command.

Get-Msoluser -All |select DisplayName,@{N=’Email’;E={$_.UserPrincipalName}},@{n=”MFA_Methods”;e={($_.StrongAuthenticationMethods).MethodType}},@{N=’MFA_Requirements’;E={($_.StrongAuthenticationRequirements).state}} | export-csv C:\Temp\MFA_Strongauth_Dec31.csv –NoTypeInformation

Azure AD Connect Sync the User Profile photo during the initial sync only. Any further changes on the Photo in On-Premise will not Sync / Update to Azure AD.

We need to manually change the photo if any changes required. You can follow the below PowerShell command to change the photo.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Set-UserPhoto “userid” -PictureData ([System.IO.File]::ReadAllBytes(“C:\Temp\userphoto.jpg”))

We saw the Azure AD sign-in options in the last post and here we will see the difference between Federation Authentication, Password Hash Sync Authentication and Pass-through authentication.



Password Hash Sync


ADFS Requirement

ADFS & WAP servers are required

Not Required

Not Required

AD Connect Requirement




AuthN Agent



Yes. Installed on AD Connect server or member server

How it works

Azure AD redirects you to ADFS as the authentication domain configured as federated domain. ADFS server authenticate the user with AD and return a security token to authenticate with Azure AD

AD Connect sync the Hash of the Password Hash in Azure AD and Azure AD accepts both the user name and password validate it with the synced hash.

Azure AD accepts the user name and password and send it On-Premise AuthN agent server which will authenticate with AD and return the successful authentication to Azure AD

Single Sing On (SSO)

Yes, via On-Premise AD credential


Requires seamless SSO enabled

Seamless SSO

Yes, when device connected to AD

Yes, when device connected to AD

Yes, when device connected to AD

Password Remains

In On-Premise

Azure AD

In On-Premise

MFA Support

On-Premise ADFS or through Azure AD

Azure AD

Azure AD

Conditional Access

On-Premise ADFS or through Azure AD

Azure AD

Azure AD

HA for Authentication

Depends on the ADFS infrastructure

Available in azure AD

Depends on AuthN agent deployments

Account lockout in On-Premise

Immediate effect

Still be active in the cloud

Immediate effect

Disable On-Premise AD Account

Reflect when sign-in occurs

Reflect to Azure AD on the next sync cycle

Reflect when sign-in occurs

Authenticates to Azure AD

Security Token from ADFS

User Name & Password

Kerberos Token


  • Password maintained in On-Premise
  • On-Premise MFA
  • On-Premise Conditional Access Support
  • Seamless SSO.
  • Cost effective & Easy to deploy
  • Cloud Authentication & scalability
  • Identity Protection
  • User to remember one password
  • Ability to login cloud service even if AD down.
  • No need of ADFS deployment
  • Cloud Authentication
  • Seamless SSO.
  • Simple deployment of AuthN agent.
  • HA for AuthN agent.
  • Automatic certification roll over


  • Doesn’t provide cloud authentication scalability.
  • Identity Protection required P2 License.
  • SSL requirement.
  • Authentication prompt when switching applications.
  • No granular logon restrictions.
  • Azure AD Premium license required for self-service password reset.
  • HA to be setup On-Premise
  • Password gathered at Azure AD

Above are the difference between the Azure AD authentication options. Hope this is informative. Learn more about the sign-in options

In this post, we are going to discuss the Azure AD sign in option available to access the claims aware application like Office 365. Below are the four sign-in options available when accessing a Microsoft cloud application or any claims aware application integrated with Azure AD. We will see how the sign-in options work in short on this post and a detailed explanation for each authentication in separate post.

  • Federation Authentication
  • Password Hash Synchronization Authentication
  • Pass-through Authentication
  • Seamless SSO (enabled when choosing PHS or PTA)

On the Azure portal under AD Connect, you can see the authentication options.

Federation Authentication:

Most of the Companies preferred to use federated authentication. When the federation sign in option enabled, the domain used for authentication will be configured as federated domain in Azure AD. Below shows the authentication flow for federation sign-in

How it works?

To explain the Federation Sign-in flow, when you access any claims aware application that trusts Azure AD as the STS, the application will redirect you to authenticate with Azure AD, Azure AD prompts you to login with the user name option only and when you enter the user name, the domain validated whether it is a federated domain. Since it is a federated domain, you are redirected to On-Premise ADFS infrastructure, (to WAP server if you are in Internet and to ADFS server if you sign-in from Intranet). ADFS prompts you to enter the user name and password passed and it authenticates with Active Directory. On successful authentication with AD, ADFS send a Security token to User that will be send back to Azure AD for successful authentication.

Note: You need to maintain a ADFS infrastructure to have this federation sign-in option and it is having additional benefits like you use On-Premise MFA server for multifactor authentication.

You can look for below authentication options which won’t cost you much and AD connect server will help you to meet your requirement.

Password Hash Synchronization Authentication:

No need to confuse about the Password Synchronization option, we are not directly synchronizing the password from On-Premise to Azure AD. Only the Hash of the Password hash synchronized with Azure AD using Azure AD connect.

How it works?

When Password Hash Synchronization authentication enabled for the tenant, Hash of the password hash is available in Azure AD after Synchronization. If a user access a Azure Integrated application, user redirected to authenticate with Azure AD, Azure AD prompt the user to enter the credential, both user name and the password will be entered in Azure AD authentication dialogue window and it will be validated against the hash Synced in Azure. If successful, user will be provided security token to the authenticate the service\application. Switching from one application to other, prompts the user to validate the credential when this sign-in option used.

Pass-through Authentication:

If we use the Pass-through authentication, user name the password will be gathered in Azure AD but Passwords validated in On-Premise AD. AuthN Agent configured in AD Connect or any member server supports this Pass through Authentication. Below shows the pass-through authentication flow.

How it works?

When user access any office 365 application, it will redirect the user to Azure AD for authentication, Azure AD prompt the user to enter both the user and password and it will be sent to AuthN agent server in On-Premise using a securing tunnel established when configuring the AuthN agent. AuthN agent component validate the user name and password with Active Directory using a Win32 API call to Active Directory and the successful authentication will be sent back to Azure AD. Azure AD authentication successful and send a security token to access the application, the user will gain access to Application.

Seamless Single Sign-On Authentication:

Seamless SSO works with Password Hash Synchronization and Pass-through authentication. For the seamless SSO to work, the machine has to be domain joined and should have access to AD. Machine authenticates with Azure AD using Kerberos token.

How it works?

When Seamless SSO enabled, new computer object created in AD that holds 2 SPN for authentication with Azure AD. Let us take User access a claims aware application, user will be redirected to Azure AD for authentication, Azure AD instructs the client to do a authentication test to find the client is SSO capable and it will send a unauthorized response and to get a token a token from AD. Client requests a Kerberos token ticket from AD and the same will be send it to Azure AD, Azure AD returns a security token which will sent to application and the authentication will be successful.

If Seamless SSO fails, the other enabled option PTA or PHS will be used for authentication.

I hope this post is informative to you.