📄 Article
Azure AD Connect: Complete Administration and Troubleshooting Guide
Azure AD Connect is the bridge between your on-premises Active Directory and Azure Active Directory. For any organisation running a hybrid Microsoft 365 deployment, understanding how it works — and how to troubleshoot it — is fundamental to keeping identities in sync and authentication functioning correctly.
🔐 What is Azure AD Connect?
💡 Overview
Azure AD Connect synchronises user identities, groups, and contacts from your on-premises Active Directory to Azure AD. It is the critical component that makes hybrid Microsoft 365 scenarios work — enabling single sign-on, password sync, and unified identity across cloud and on-premises environments.
📋 Prerequisites for Installing Azure AD Connect
⚠️ Before You Install
- A Windows Server (2016 or later) to host Azure AD Connect — not a domain controller for production deployments
- .NET Framework 4.7.1+ and PowerShell installed on the server
- A service account with permissions to read/write to on-premises AD (or use the built-in Azure AD Connector account created during setup)
- A Global Administrator account in Azure AD to complete the cloud-side configuration during setup
- SQL Server — the built-in SQL Server 2019 Express LocalDB is used automatically for under ~100,000 objects; a full SQL Server instance is required beyond that
- Correct TLS 1.2 connectivity outbound to Azure AD endpoints (ports 80/443)
- UPN suffixes on-premises should match a verified domain in Azure AD wherever possible, to avoid sign-in issues
🔄 Critical Synchronisation Concepts
Hard Match vs Soft Match
| Type | How It Works | When Used |
|---|---|---|
| Hard Match | Uses the immutable sourceAnchor identifier set on first synchronisation |
Default method — most reliable |
| Soft Match | Uses attribute-based matching (email address, UPN) when hard match fails | Recovery method for orphaned users |
⚠️ Hard Match Warning
The sourceAnchor cannot be changed once set without breaking synchronisation. Never reinstall Azure AD Connect without proper planning, and never change the sourceAnchor attribute in production.
Password Hash Synchronisation (PHS)
💡 How PHS Works
- Encrypts on-premises password hashes and sends them to Azure AD
- Users can sign in to cloud services with the same password as on-premises
- Password changes sync within 0–2 minutes (delta sync detects the change)
- If a cloud user changes their password in Azure AD, it does NOT sync back to on-premises AD
Pass-Through Authentication (PTA)
💡 How PTA Works
- Password is never sent to the cloud — authentication is validated in real-time against on-premises AD
- More secure for organisations with strict compliance requirements
- Requires additional PTA agent installation on on-premises servers
- More complex infrastructure than PHS — requires highly available on-premises agents
🔏 Authentication Strength & Legacy Authentication
💡 Authentication Strength
Authentication strength is a Conditional Access control that lets you require specific combinations of authentication methods — not just “MFA yes/no” but which methods count. For example, you can require phishing-resistant MFA (FIDO2 security key, Windows Hello for Business, certificate-based auth) for admins, while allowing any MFA method for regular users. It gives far more granular control than the older “require MFA” grant control alone.
⚠️ Legacy Authentication
Legacy authentication refers to protocols that don’t support modern authentication (OAuth 2.0) — POP, IMAP, SMTP AUTH, and older Office desktop clients using Basic Authentication. These protocols can’t enforce MFA or Conditional Access, making them the most common vector for password-spray attacks. Microsoft has been disabling Basic Authentication for Exchange Online by default; best practice is to block legacy authentication entirely via a Conditional Access policy and force all clients onto modern authentication.
🏗️ Scaling Azure AD Connect for Large Organisations
✅ Sizing Guide
- Up to 100,000 users: A single server is typically sufficient — minimum 8 GB RAM, 2 CPU cores
- 100,000+ users: Deploy a staging mode server alongside the active server for high availability
💡 High Availability Setup
- Server 1 (Active): Actively syncs to Azure AD — exports changes to the cloud
- Server 2 (Staging): Imports from on-premises AD but does NOT export to Azure AD. Promoted immediately if Server 1 fails
🛠️ Troubleshooting Synchronisation Issues
1
Object Not Syncing to Azure AD
Check these common causes in order before running advanced diagnostics.
⚠️ Common Root Causes
- Organisational Unit (OU) is excluded from the sync scope
- User account is disabled in on-premises AD
- Duplicate email address exists in the directory
- Invalid characters in the UPN (e.g. spaces, unsupported symbols)
- Incorrect scoping rules or attribute filtering applied
PowerShell — Azure AD Connect
Import-Module ADSync # Check sync errors Get-ADSyncConnectorRunStatus # View sync errors in detail Get-ADSyncConnector | Get-ADSyncConnectorStatistics # Search for specific user in metaverse Search-ADSyncDirectoryObjects -ConnectorName "yourdomain.com" -DN "CN=John Smith,OU=Users,DC=yourdomain,DC=com"
2
Force a Delta or Full Sync
After making changes to attributes, OUs, or permissions, trigger a sync cycle manually to test the fix without waiting for the scheduled run.
PowerShell — Azure AD Connect
Import-Module ADSync # Run a Delta sync (recommended — processes only changes) Start-ADSyncSyncCycle -PolicyType Delta # Run a Full sync (use only when needed — processes all objects) Start-ADSyncSyncCycle -PolicyType Initial
3
Hard Match Failure After Reinstall
This occurs when Azure AD Connect is reinstalled without preserving the sourceAnchor, causing objects to be treated as new users instead of matching existing cloud accounts.
⚠️ Prevention Is Critical
- Never reinstall Azure AD Connect without proper planning and backup
- Never change the
sourceAnchorattribute on any object - Always deploy a staging mode server so failover never requires a fresh install
- Export and back up your Azure AD Connect configuration regularly
PowerShell — Export Configuration Backup
Import-Module ADSync # Export current Azure AD Connect configuration Get-ADSyncGlobalSettings | Export-Clixml -Path "C:\Backup\AADConnect-Config.xml" # Check staging mode status (Get-ADSyncScheduler).StagingModeEnabled
💡 Best Practices & Recommendations
- Always deploy a staging mode server for high availability — never rely on a single Azure AD Connect server in production
- Monitor sync health regularly — set up alerts in Azure AD Connect Health for sync failures and latency
- Implement a proper OU structure and scoping — only sync OUs that contain cloud-enabled users
- Test all updates in staging mode before applying to the active server
- Keep Azure AD Connect updated monthly — Microsoft releases regular updates with bug fixes and security patches
- Set service account passwords to never expire or use managed service accounts to prevent credential-related sync failures
🎓 Common Interview Questions
Q: What is the difference between hard match and soft match in Active Directory synchronisation?
Hard match uses the immutable
sourceAnchor identifier set on first synchronisation — it is the most reliable method and cannot change without breaking sync. Soft match uses attribute-based matching (email address or UPN) when hard match fails, and is used as a recovery method when users become orphaned after a reinstall or migration.Q: What is the difference between Password Hash Synchronisation and Pass-Through Authentication?
PHS sends an encrypted copy of the on-premises password hash to Azure AD, so authentication happens in the cloud — simple to set up, resilient (no dependency on on-premises servers being online), and password changes sync within 0–2 minutes. PTA never sends the password hash to the cloud at all; every sign-in is validated in real time against on-premises AD via a lightweight PTA agent. PTA is preferred where compliance requires passwords to never leave on-premises, but it needs highly available agents since authentication fails if all agents are down. PHS is the simpler, more resilient default for most organisations.
Q: What happens when a cloud user changes their password in Azure AD with PHS enabled?
The password change is stored in Azure AD only and does NOT sync back to on-premises Active Directory. PHS is a one-way sync — from on-premises to cloud. If the user later changes their password on-premises, that new hash will sync to Azure AD within 0–2 minutes, overwriting the cloud-only password.
Q: How many Azure AD Connect servers are required for an environment with 100,000+ users?
One active server is typically sufficient for the sync workload. However, a second server running in staging mode should always be deployed on a separate machine for high availability. The staging server can be promoted to active within minutes if the primary fails, ensuring minimal sync downtime.
Q: How do you troubleshoot an object that is not syncing to Azure AD?
Check in this order: (1) Confirm the OU containing the user is included in sync scope. (2) Verify the user account is enabled in on-premises AD. (3) Check for duplicate email addresses. (4) Use Synchronisation Service Manager to search for the user in the metaverse and review any errors. (5) Review sync errors in the Azure AD Portal under Entra ID → Users → Sync Errors.
Q: What is staging mode in Azure AD Connect?
Staging mode is a configuration where the Azure AD Connect server imports data from on-premises AD and builds the connector space and metaverse, but does not export any changes to Azure AD. It acts as a warm standby that can be promoted to active at any time, providing high availability without the risk of duplicate exports.
Q: What are the prerequisites for installing Azure AD Connect?
A Windows Server 2016+ host (not a production domain controller), .NET Framework 4.7.1+, a service account with appropriate on-premises AD permissions (or the auto-created connector account), a Global Administrator account in Azure AD to complete cloud-side setup, SQL Server (LocalDB is used automatically under ~100,000 objects, full SQL Server required above that), outbound TLS 1.2 connectivity to Azure AD endpoints, and ideally UPN suffixes on-premises that match a verified Azure AD domain.
Q: What is authentication strength and legacy authentication?
Authentication strength is a Conditional Access control that specifies which combination of authentication methods must be used to satisfy a policy — for example requiring phishing-resistant methods like FIDO2 or Windows Hello for Business for admins, rather than just “any MFA.” Legacy authentication refers to older protocols (POP, IMAP, SMTP AUTH, Basic Auth in older Office clients) that predate modern authentication and can’t enforce MFA or Conditional Access — making them a major attack vector. Best practice is to block legacy authentication entirely via Conditional Access and require modern auth for all clients.
📚 References & Further Reading
- 🔗 Azure AD Connect prerequisites and installation — Microsoft Learn
- 🔗 Implement Password Hash Synchronisation — Microsoft Learn
- 🔗 Conditional Access authentication strength — Microsoft Learn