This chapter covers Azure AD Connect and hybrid identity, a critical topic for the AZ-104 exam. Hybrid identity allows organizations to extend their on-premises Active Directory to Azure AD, enabling single sign-on, seamless authentication, and centralized identity management. Approximately 15-20% of exam questions touch identity governance, and understanding Azure AD Connect is essential for configuring synchronization, authentication methods, and writeback capabilities. This chapter provides a deep dive into the components, synchronization process, authentication options, and common misconfigurations you must know for the exam.
Jump to a section
Imagine a large company with two separate phone directories: one in the headquarters (on-premises Active Directory) and one for the remote office (Azure AD). Employees in both directories need to have the same contact information, but changes happen in both places. The company hires a synchronization clerk (Azure AD Connect) who sits between the two offices. The clerk's job is to compare both directories every 30 minutes (the default sync interval) and copy changes from one to the other. If an employee in HQ updates their phone number, the clerk notes the change, checks it against the remote directory, and updates it there. If the remote office adds a new employee, the clerk creates a corresponding entry in HQ's directory. However, the clerk follows strict rules: he never copies passwords directly; instead, he synchronizes a hash of the password (password hash sync) so the remote office can verify logins without ever seeing the actual password. He also has a special rule for writing back changes from the remote office to HQ (device writeback, group writeback). If the clerk is configured to allow users to reset their passwords from the remote office, he writes that change back to HQ (password writeback). The clerk uses a secure, encrypted channel (port 443) and maintains a staging area (Metaverse) where he reconciles differences before applying them. If a conflict arises—for example, both offices update the same employee's phone number at the same time—the clerk uses a predefined rule (source of authority, usually on-premises wins) to decide which change to keep. This entire process ensures both directories stay in sync without manual intervention, and the clerk sends health reports (Azure AD Connect Health) to a monitoring console so administrators can see if any synchronization failed.
What is Azure AD Connect and Why It Exists
Azure AD Connect is Microsoft's primary tool for hybrid identity, integrating on-premises Active Directory (AD) with Azure Active Directory (Azure AD). It enables a unified identity experience where users can access cloud resources (Office 365, Azure, SaaS apps) using their on-premises credentials. Without Azure AD Connect, organizations would need to manage separate identities in the cloud and on-premises, leading to administrative overhead and user frustration. The tool handles synchronization of user objects, groups, contacts, and devices, and supports multiple authentication methods: Password Hash Synchronization (PHS), Pass-through Authentication (PTA), and Federation (e.g., ADFS).
How Azure AD Connect Works Internally
Azure AD Connect uses a synchronization engine that runs on a server (typically on-premises or an Azure VM). The process involves three key stages: import, sync, and export.
#### Import Phase
- The sync engine connects to the on-premises AD domain controller via LDAP (port 389/636) and imports objects from the configured organizational units (OUs).
- It also connects to Azure AD via Microsoft Graph API (port 443) to import existing cloud objects.
- The imported data is stored in a staging area called the Metaverse (MV).
- The default import interval is every 30 minutes, but you can force a full sync using Start-ADSyncSyncCycle -PolicyType Initial.
#### Sync Phase
- The sync engine applies synchronization rules to map on-premises attributes to Azure AD attributes. For example, userPrincipalName in AD maps to userPrincipalName in Azure AD.
- Rules are defined in the synchronization rules editor and include scoping filters (e.g., only sync users from a specific OU) and transformation rules (e.g., set cloudExchangeRecipientDisplayType to 0 for mailboxes).
- The engine resolves conflicts using a source of authority, typically on-premises AD (i.e., on-premises changes always win).
- The sync phase also handles identity matching: objects are linked using the sourceAnchor attribute (immutable in Azure AD), which is derived from the on-premises objectGUID by default. This ensures the same object is not duplicated.
#### Export Phase - Changes are written to Azure AD (or on-premises AD, for writeback scenarios). - Export runs every 30 minutes by default, but you can trigger it manually. - The export uses delta synchronization to minimize traffic; only changed attributes are sent. - The sync engine logs errors (e.g., duplicate UPN, attribute conflicts) in the event log and Azure AD Connect Health.
Key Components, Values, Defaults, and Timers
Synchronization Interval: Default is 30 minutes. You can change it by customizing the scheduler, but Microsoft recommends keeping the default for most environments.
Password Hash Sync (PHS): Synchronizes a hash of the on-premises password to Azure AD every 2 minutes by default. The hash uses SHA256 and is salted. PHS enables automatic password rotation and leaked credential detection.
Pass-through Authentication (PTA): Validates passwords directly against on-premises AD via an agent installed on the sync server. The agent listens on port 443 and forwards authentication requests. Default timeout for PTA is 60 seconds.
Seamless SSO: Uses Kerberos delegation to automatically sign in users on domain-joined devices. It creates a computer account AZUREADSSOACC in on-premises AD.
Writeback: Password writeback requires Azure AD Premium P1 or P2. Device writeback requires a Windows Server 2012 R2+ schema. Group writeback for Microsoft 365 groups requires Azure AD Premium.
sourceAnchor: Default is objectGUID. Must be immutable after initial sync. Changing it requires re-syncing all objects.
Filtering: You can filter by OUs, domains, or attributes (e.g., extensionAttribute15). The default is to sync all OUs.
Staging Mode: When enabled, the server imports and syncs but does not export. Useful for testing.
Configuration and Verification Commands
#### Installation - Download Azure AD Connect from the Microsoft Download Center. - Run the installer and choose Express Settings (for single AD forest with PHS) or Custom Settings. - Custom settings allow you to select authentication method, sync options, and filtering.
#### Common PowerShell Commands
- Get-ADSyncScheduler – Shows current sync schedule.
- Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:30:00 – Changes sync interval (not recommended).
- Start-ADSyncSyncCycle -PolicyType Delta – Triggers a delta sync.
- Start-ADSyncSyncCycle -PolicyType Initial – Triggers a full sync.
- Get-ADSyncConnector – Lists all connectors (on-premises AD, Azure AD).
- Get-ADSyncCSObject -ConnectorName "contoso.com" -DistinguishedName "CN=John Doe,OU=Users,DC=contoso,DC=com" – Shows staging object.
- Get-ADSyncMVObject -DistinguishedName "CN=John Doe,OU=Users,DC=contoso,DC=com" – Shows Metaverse object.
#### Verification in Azure Portal - Go to Azure AD > Users > User settings > Sync status to see if sync is enabled. - Use Azure AD Connect Health to monitor sync errors, performance, and authentication health.
How Azure AD Connect Interacts with Related Technologies
Azure AD Domain Services (AADDS): Requires password hash sync to be enabled. AADDS uses the same hashes to authenticate domain-joined VMs.
Microsoft 365: User objects must be synced to Azure AD before they can be licensed for Exchange Online, SharePoint, etc.
Conditional Access: Requires Azure AD Premium. PHS or PTA must be configured for sign-in risk policies.
Azure AD Application Proxy: Uses Azure AD for pre-authentication; hybrid identity ensures users have the same credentials.
Windows Hello for Business: Hybrid deployment requires either PHS or PTA, and device writeback for on-premises resources.
Install Azure AD Connect Server
Download the Azure AD Connect installer from the Microsoft Download Center. Run it on a Windows Server 2016 or later (2012 R2 is deprecated). The server should be domain-joined and have network access to on-premises domain controllers (port 389/636) and Azure AD (port 443). During installation, you choose between Express and Custom settings. Express uses default options: PHS, sync all OUs, and no filtering. Custom allows you to specify authentication method, sync scope, and writeback features. The installer creates a local account for the sync service and registers the server with Azure AD.
Configure Synchronization Scope
After installation, you can filter which objects are synced. Use the Azure AD Connect wizard or PowerShell to select specific OUs. For example, to sync only the 'Users' OU, uncheck all others. You can also filter by domain or attribute (e.g., sync only users with extensionAttribute15='Cloud'). Filtering reduces sync time and prevents unnecessary objects in Azure AD. Note: If you later add a new OU, you must re-run the wizard to include it. The default is to sync all objects in all domains of the forest.
Enable Password Hash Synchronization
PHS is enabled by default in Express settings. It synchronizes a hash of the on-premises password every 2 minutes. The hash is computed using SHA256 with a random salt per user. This allows users to sign in to Azure AD with their on-premises password. PHS also enables leaked credential detection (Azure AD Identity Protection) and is required for Azure AD Domain Services. You can verify PHS is working by checking the sync status in Azure AD Connect Health or by running a delta sync and checking for password sync events.
Configure Seamless Single Sign-On
Seamless SSO enables automatic sign-in on domain-joined devices. It uses Kerberos delegation: the Azure AD Connect server creates a computer account named AZUREADSSOACC in the on-premises AD. When a user accesses a cloud resource, their browser (or Office client) sends a Kerberos ticket to Azure AD, which validates it. This requires the user's device to be domain-joined and the URL `autologon.microsoftazuread-sso.com` to be in the Intranet zone. You enable Seamless SSO during Azure AD Connect installation or via PowerShell.
Implement Password Writeback
Password writeback allows users to reset their passwords from the cloud (e.g., via SSPR) and have the new password written back to on-premises AD. This requires Azure AD Premium P1 or P2. During Azure AD Connect installation, you must check the 'Password writeback' option. The feature uses a service account created in on-premises AD with the necessary permissions to update passwords. Writeback is near-instant (within seconds) but is subject to the same sync interval for other attributes. You can monitor writeback errors via Azure AD Connect Health.
Enterprise Scenario 1: Large Organization with Multiple Forests
A global company with 50,000 users across three AD forests (Europe, Americas, Asia) uses Azure AD Connect to sync all users to a single Azure AD tenant. They use custom sync rules to map attributes like department and cost center. They filter by OU to sync only active employees (excluding service accounts). Challenge: duplicate UPN conflicts. The sync engine handles this by appending a number (e.g., john.doe@contoso.com and john.doe1@contoso.com). They use Azure AD Connect Health to monitor sync errors and set up alerts for any failures. Performance: sync completes in 15 minutes for 50,000 objects with delta changes. They run a full sync quarterly.
### Scenario 2: Small Business with Pass-through Authentication
A 200-user company uses PTA because they cannot store password hashes in the cloud due to compliance. They install Azure AD Connect on a single server with the PTA agent. The agent forwards authentication requests to on-premises DCs. They also enable Seamless SSO for a better user experience. Common issue: the PTA agent fails if the server goes down. They deploy a second PTA agent on another server for high availability. They monitor agent health via the Azure portal.
### Scenario 3: Hybrid Exchange with Device Writeback
A company uses Exchange Online and on-premises Exchange 2016. They enable device writeback so that devices registered in Azure AD (e.g., Intune-enrolled) are written back to on-premises AD for conditional access. They also enable group writeback to sync Microsoft 365 groups back to on-premises AD for legacy applications. Misconfiguration: they forgot to extend the AD schema for device writeback, causing the sync to fail. They resolved by running adprep /forestprep on the schema master.
What AZ-104 Tests on This Topic
- Objective 1.1: Manage Azure Active Directory (Azure AD) objects. Specifically, configure hybrid identity with Azure AD Connect, including authentication methods (PHS, PTA, Federation), sync options, and writeback. - Common Questions: Which authentication method requires no on-premises infrastructure? (Answer: PHS). Which method supports seamless SSO without federation? (Answer: PTA or PHS with Seamless SSO). What is the default sync interval? (30 minutes). What attribute is used for source anchor? (objectGUID). - Common Wrong Answers: 1. Choosing ADFS as the only method for SSO – but Seamless SSO works with PHS/PTA. 2. Thinking password writeback works without Azure AD Premium – it requires P1 or P2. 3. Believing Azure AD Connect must be installed on a domain controller – it can be on any domain-joined server. 4. Confusing sync interval (30 min) with password sync interval (2 min). - Edge Cases:
If you change the sourceAnchor after initial sync, objects become orphaned. You must re-sync all objects.
Staging mode: server imports and syncs but does not export. Useful for testing before going live.
Soft match vs. hard match: soft match uses UPN or proxyAddresses to link objects; hard match uses sourceAnchor.
Eliminating Wrong Answers: Understand the mechanism. For example, if a question asks for a solution that works without any on-premises server, eliminate ADFS (requires federation server) and PTA (requires agent). PHS is the only one that runs entirely in the cloud after sync.
Azure AD Connect syncs objects every 30 minutes by default; password hashes sync every 2 minutes.
The sourceAnchor attribute is immutable after initial sync; default is objectGUID.
Password Hash Sync enables Azure AD Domain Services and leaked credential detection.
Pass-through Authentication requires at least one agent (two for high availability) and does not store password hashes in the cloud.
Seamless SSO works with both PHS and PTA, using Kerberos delegation via the AZUREADSSOACC computer account.
Password writeback requires Azure AD Premium P1 or P2.
Staging mode allows testing sync without exporting changes to Azure AD.
You can filter sync by OUs, domains, or attributes to reduce sync scope.
These come up on the exam all the time. Here's how to tell them apart.
Password Hash Synchronization (PHS)
Synchronizes password hashes to Azure AD every 2 minutes.
No on-premises agent needed after initial sync.
Supports leaked credential detection and Azure AD Domain Services.
Requires no additional on-premises infrastructure.
Users can sign in even if on-premises DCs are unreachable (using cached hash).
Pass-through Authentication (PTA)
Validates passwords directly against on-premises AD in real time.
Requires PTA agent(s) installed on premises (at least one, two for HA).
Does not store password hashes in the cloud (compliance benefit).
Requires outbound connectivity from agents to Azure AD on port 443.
Users cannot sign in if on-premises DCs are unreachable (unless fallback to PHS is configured).
Mistake
Azure AD Connect must be installed on a domain controller.
Correct
It can be installed on any domain-joined Windows Server, not necessarily a DC. However, it needs network access to DCs for LDAP and to Azure AD for sync.
Mistake
Password Hash Sync sends actual passwords to the cloud.
Correct
PHS synchronizes a hash of the password (SHA256 with salt), not the plaintext password. The hash cannot be reversed.
Mistake
Pass-through Authentication requires opening inbound firewall ports.
Correct
PTA agents only make outbound connections to Azure AD over port 443. No inbound ports are required.
Mistake
All users must be synced from a single OU.
Correct
You can filter by multiple OUs, domains, or attributes. The default syncs all OUs, but you can customize it.
Mistake
Azure AD Connect only syncs users and groups.
Correct
It also syncs contacts, devices (with device writeback), and can sync mailboxes, public folders, and more with Exchange hybrid.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default sync interval is 30 minutes. This means that changes made in on-premises AD will be reflected in Azure AD within 30 minutes (plus propagation time). Password hash sync, however, runs every 2 minutes. You can trigger a manual delta sync with `Start-ADSyncSyncCycle -PolicyType Delta` or a full sync with `-PolicyType Initial`. Changing the interval is possible but not recommended.
Yes, you can choose not to enable password hash sync. However, users must then use a different authentication method: either Pass-through Authentication (PTA) or Federation (ADFS). Without password sync, Azure AD cannot authenticate users directly; it must delegate to on-premises systems. Note that some features like Azure AD Domain Services require password hash sync.
Soft match uses the UPN (userPrincipalName) or proxyAddresses to link an on-premises user to an existing cloud user. Hard match uses the sourceAnchor attribute (usually objectGUID). If a soft match fails (e.g., duplicate UPN), you can force a hard match by setting the sourceAnchor in the cloud object. Hard match is more reliable but requires the cloud object to have the correct sourceAnchor.
Password writeback requires Azure AD Premium P1 or P2. During Azure AD Connect installation, in the Custom Settings, check the 'Password writeback' option. You can also enable it later by re-running the wizard. The feature creates a service account in on-premises AD with permissions to update passwords. Users can then reset their passwords via Azure AD SSPR, and the new password is written back to on-premises AD.
If the sync server fails, synchronization stops. Users can still sign in using cached credentials (for PHS) or via PTA agents (if separate from the sync server). To restore sync, you can reinstall Azure AD Connect on a new server and import the existing configuration from a backup (.json file). It is recommended to have a staging server or at least backup the configuration.
Yes, Azure AD Connect supports syncing multiple forests. You can add additional forests during installation or later via the wizard. Each forest must have connectivity to the sync server. Custom sync rules can handle conflicts (e.g., same UPN in different forests). The sourceAnchor must be unique across forests, so Microsoft recommends using the default objectGUID (which is globally unique).
The sync server needs outbound HTTPS (port 443) to Azure AD. For on-premises AD, it needs LDAP (port 389) or LDAPS (636) for directory synchronization. For PTA, the agents need outbound 443 to Azure AD. For federation, additional ports may be required (e.g., 443 for ADFS). No inbound ports are required for Azure AD Connect itself.
You've just covered Azure AD Connect and Hybrid Identity — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?