Hybrid identity is the operating model most organizations end up with: on-premises Active Directory (AD) remains authoritative for many identities and legacy workloads, while Microsoft Entra ID (formerly Azure AD) becomes the control plane for cloud access, SaaS, Conditional Access, and modern security features. Azure AD Connect is the Microsoft-supported bridge that synchronizes identities (users, groups, and selected attributes) from AD to Entra ID and, depending on your chosen sign-in method, helps deliver authentication experiences that feel seamless to end users.
This article is a practical, end-to-end how-to for IT administrators and system engineers who need to plan, install, and operate Azure AD Connect in a production hybrid identity environment. It focuses on decisions that materially affect security and reliability—such as password authentication method selection, attribute and OU filtering, source anchor choices, and high availability via staging mode—then connects those decisions to the concrete steps you take during configuration.
Because hybrid identity changes tend to ripple across email, devices, VPN, line-of-business applications, and security policies, the intent here is not only to “get it installed,” but to deploy it in a way that is supportable and safe to evolve.
What Azure AD Connect does in a hybrid identity design
Azure AD Connect is primarily a directory synchronization tool. It reads objects from one or more on-premises AD forests and provisions corresponding objects in Entra ID. Synchronization is performed by the Azure AD Connect sync engine (historically based on Microsoft Identity Manager technology). The sync engine maintains a metaverse (a consolidated view of identity objects) and uses connectors and rules to flow attributes between directories.
In most environments, AD remains the system of record for core identity attributes such as display name, department, manager, and group membership. Azure AD Connect then projects those identities to the cloud for Microsoft 365, SaaS apps, and modern authentication controls. This separation of authority is central: if you treat Entra ID as a writable copy of on-prem identity data (when AD is actually authoritative), you can create conflicts and drift that surface later during migrations, tenant consolidations, or security hardening.
Azure AD Connect is also the place where you choose, for synced users, how authentication will work. That choice is not merely “user experience”—it has architectural implications for dependencies, outage tolerance, incident response, and the scope of your security monitoring.
Choosing the right sign-in method: PHS, PTA, or federation
Before you touch an installer, decide how users will authenticate.
Password Hash Synchronization (PHS) synchronizes a hash of the user’s password hash from AD to Entra ID. Entra ID can then authenticate the user without calling back to on-prem infrastructure. PHS is widely recommended for its simplicity and resilience; it reduces dependency on on-prem availability for cloud sign-ins. It also enables features like Identity Protection risk evaluation without requiring the user’s on-prem password at sign-in time.
Pass-through Authentication (PTA) keeps password validation on-premises. Entra ID receives the username and password, encrypts the request, and sends it to an on-prem PTA agent that validates the credentials against AD. PTA can be a good fit when you want cloud authentication to depend on on-prem policies and immediate password changes without waiting for hash sync, but it introduces an availability dependency on your PTA agents and outbound connectivity.
Federation (commonly AD FS) redirects authentication to a federation service. This is often chosen for advanced requirements such as certain smart card flows, third-party MFA integration (in legacy designs), or complex claim rules. Federation adds the most moving parts and typically the highest operational overhead.
A practical approach in 2026 is: use PHS for most organizations unless a documented requirement forces PTA or federation. Even if you adopt PTA or federation, many enterprises enable PHS as a backup sign-in method (where supported) to improve resilience. Your exact posture should be validated against your security requirements and Microsoft’s current guidance for your scenario.
Planning prerequisites: identity, network, and permissions
Azure AD Connect projects your AD into Entra ID, so planning starts with identity hygiene. The most common production issues aren’t installer problems—they’re data problems: non-routable UPNs, duplicates, stale objects, and inconsistent attributes.
From a permissions standpoint, you need administrative rights in both environments. In AD, you need an account that can read directory data, and depending on features (password writeback, device writeback, Exchange hybrid attributes), you may need additional rights. In Entra ID, you need credentials capable of creating and managing directory objects and configuring sync. Microsoft’s role requirements evolve, but in practice you should plan for a tenant admin role during initial setup, then reduce permissions after deployment to least privilege.
Network planning matters because Azure AD Connect needs stable outbound connectivity to Microsoft endpoints. If you have proxy requirements, TLS interception, or strict egress controls, validate that the server can reach Entra ID endpoints and that authentication flows you choose (especially PTA) can maintain outbound connections.
Finally, decide on the host and placement. Azure AD Connect is typically installed on a dedicated Windows Server member server joined to the domain. While the installer supports deployment on a domain controller in some scenarios, operationally it is cleaner to keep it on a member server to reduce coupling and to simplify patching and role separation.
Preparing Active Directory for hybrid identity
A reliable hybrid identity build starts with AD cleanup and standardization.
Validate UPNs and routable domains
A frequent cause of user confusion and sign-in failures is an on-prem UPN that is not a verified domain in Entra ID. For example, users with user@corp.local in AD will be synced to Entra ID, but they cannot use @corp.local to sign in unless that suffix is verified in the tenant (and .local cannot be verified as a public domain).
In practice, you should align UPN suffixes with a public, verified domain such as user@company.com. This typically involves adding an alternate UPN suffix in AD Domains and Trusts, then updating users.
When planning this change, consider downstream dependencies: legacy apps may use userPrincipalName, email addresses may not match UPN, and some VPN or RADIUS integrations may use UPN. Make the change in phases and communicate clearly.
A targeted PowerShell approach to identify non-routable UPNs:
Get-ADUser -Filter * -Properties UserPrincipalName |
Where-Object { $_.UserPrincipalName -match "@corp\.local$" } |
Select-Object SamAccountName, UserPrincipalName
Ensure uniqueness for key attributes
Azure AD Connect relies on certain attributes being unique for join and match logic. Conflicts can cause sync errors or unexpected merges.
Email-related attributes are common collision points, especially in multi-domain or merged environments. Even if you don’t plan to use mail for sign-in, ensure that proxyAddresses values do not collide across users, contacts, and groups.
Decide what to sync: OUs and object scope
The default “sync everything” posture is rarely ideal. You typically want:
- A clear set of OUs for production users and groups.
- Exclusion of service accounts that should never be used in cloud sign-in.
- Exclusion of test OUs unless you are deliberately syncing a pilot set.
Filtering is both a security control (reducing exposure of internal objects) and an operational control (reducing sync load and mistakes). You’ll apply OU and/or attribute-based filtering later in the configuration.
Plan the source anchor (immutable identifier)
The source anchor is the immutable identifier Azure AD Connect uses to link an on-prem object to its cloud counterpart. Historically, objectGUID was common. Modern guidance often uses ms-DS-ConsistencyGuid because it supports certain migration scenarios more cleanly.
This decision matters most in long-term operations: tenant-to-tenant migrations, forest consolidation, and disaster recovery are easier if you picked a stable source anchor and maintained it correctly. You should avoid changing the source anchor after you have synchronized users unless you have a thoroughly validated migration plan.
Preparing Microsoft Entra ID for directory synchronization
On the tenant side, preparation is simpler but still important.
Verify domains and plan your identity namespace
Before syncing users with UPNs like @company.com, verify company.com in Entra ID and ensure you can control DNS. Align this with your email namespace strategy if you use Microsoft 365.
If you plan to use multiple UPN suffixes (e.g., @company.com and @subsidiary.com), verify all relevant domains before broad sync. This reduces the temptation to sync users with non-sign-in UPNs and “fix it later,” which often becomes an incident.
Confirm licensing and feature dependencies
Azure AD Connect itself does not require premium licensing for basic sync, but downstream features might. Conditional Access, Identity Protection, and some governance features require Entra ID P1/P2. Password writeback is associated with certain licensing requirements depending on feature set and current Microsoft terms. Validate licensing early so you don’t design around a capability you cannot deploy.
Decide the authority boundary
In a standard hybrid design, AD is authoritative for synced users and groups. That means changes to key attributes should be made on-prem, not in Entra ID, to avoid being overwritten by sync. Make this operational rule explicit, and ensure your service desk and identity admins understand which system owns which attributes.
Selecting an Azure AD Connect topology
Topology describes how many forests you sync, how many tenants you target, and how you handle availability.
Single forest, single tenant (most common)
This is the simplest and most supportable model. You install Azure AD Connect on one server (plus an optional staging server), connect it to one AD forest, and sync to one tenant.
Multiple forests to one tenant
Common after mergers or when identity boundaries exist for administrative reasons. Azure AD Connect supports connecting multiple forests to one tenant, but you must be careful with duplicate attributes and user matching. You also need a plan for how users are represented: are they present in one forest only, or do you have resource forests and account forests?
High availability via staging mode
Azure AD Connect does not support active/active sync from multiple servers to the same tenant. The supported high availability model is staging mode, where a second server is configured identically but does not export changes to Entra ID. If the primary server fails, you switch the staging server to active.
Staging mode is not optional in environments where directory sync is mission-critical. It reduces mean time to recovery and gives you a safe place to validate configuration changes.
Real-world scenario 1: mid-sized enterprise moving from AD FS to PHS
Consider a 2,000-user organization running AD FS for historical reasons: an older third-party MFA integration and a desire to keep passwords on-prem. Over time, AD FS becomes an operational burden—certificates, WAP publishing, patching, and intermittent authentication outages.
A pragmatic path is to deploy Azure AD Connect with PHS enabled and run it alongside federation while you validate that cloud authentication meets your requirements. After validation, you can transition domains from federated to managed authentication in Entra ID. This reduces dependencies and simplifies incident response. The key lesson is that Azure AD Connect isn’t just sync; it’s also the enabling step for modernizing the authentication plane.
Installing Azure AD Connect: step-by-step approach
The installation flow is straightforward, but production-grade deployments depend on deliberate choices in the wizard.
Step 1: Provision the server and baseline it
Use a supported Windows Server version and keep it patched. Join it to the domain. Ensure time synchronization is correct (Kerberos and TLS both care). Install required prerequisites if your environment has restrictions, but generally the installer handles dependencies.
Treat this server as identity infrastructure:
- Restrict interactive logon.
- Use privileged access workstations (PAWs) or hardened admin workflows.
- Ensure backups cover system state where appropriate and document rebuild procedures.
Step 2: Obtain the installer and verify integrity
Download Azure AD Connect from Microsoft. In environments with strict change control, record the version deployed and keep the installer package available for audit and rollback planning.
Step 3: Choose Express vs Custom installation
Express settings are fast but assume a basic scenario: single forest, password hash sync, and default sync scope. In production, Custom installation is usually the correct choice because it lets you set OU filtering, choose sign-in method, and confirm source anchor settings.
If your environment truly is simple and you’re piloting, Express can be acceptable. But most administrators who use Express end up re-running configuration soon after.
Step 4: Configure the Entra ID connection
The wizard will prompt for Entra ID credentials with sufficient rights. This establishes the connector and creates or configures the synchronization service account on the cloud side.
At this point, confirm you are in the correct tenant. In multi-tenant admin contexts, tenant mix-ups are a real risk; validate tenant ID and domain list.
Step 5: Configure the AD DS connection and account strategy
You will connect Azure AD Connect to your AD forest. You can use:
- An existing AD account with delegated permissions, or
- An account Azure AD Connect creates for directory replication and required operations.
For least privilege, delegated accounts are attractive, but they require careful documentation and lifecycle management (password rotation, monitoring, and ensuring permissions remain intact). In many organizations, allowing Azure AD Connect to manage its service account is operationally simpler, provided you protect the server and control admin access.
Step 6: Select sign-in method and related options
This is where your earlier planning pays off.
For PHS, confirm you understand that Entra ID receives a hash derived from the on-prem password hash (not the cleartext password). Users will be able to sign in to cloud services even if on-prem authentication is temporarily unavailable.
For PTA, plan multiple PTA agents for availability. The Azure AD Connect server can host an agent, but you should also deploy additional agents on separate servers.
For federation, ensure your federation service is stable and properly published. Azure AD Connect can assist in configuring federation trust in certain configurations, but federation design is broader than the sync tool.
If you enable Seamless SSO, Azure AD Connect will create a computer account in AD (commonly AZUREADSSOACC) and configure Kerberos for integrated sign-in on domain-joined devices. This improves user experience on corporate networks.
Step 7: Configure directory and OU filtering
In the wizard, configure OU-based filtering to include only the OUs you intend to sync. This is an important guardrail.
A pattern that works well is to create a dedicated top-level OU such as OU=CloudSync,DC=company,DC=com and move only eligible users/groups under it. This creates an explicit boundary and simplifies audits.
If you cannot reorganize OUs, use existing structure and document the rationale. Avoid syncing built-in containers, privileged admin accounts, and legacy service accounts unless you have a clear use case.
Step 8: Configure optional features carefully
Optional features should be enabled only when you have a defined need and you understand the impact.
Common options include:
- Password writeback: lets users reset passwords in the cloud (for example via self-service password reset) and write the new password back to on-prem AD. This can reduce helpdesk load but requires careful security controls.
- Group writeback: relevant for certain Exchange hybrid and cloud group scenarios; it affects how groups appear on-prem.
- Device writeback: used in some conditional access and device registration scenarios; validate current Microsoft guidance because device management patterns have shifted with Entra ID Join and Intune.
Each writeback feature changes your authority boundary by allowing some cloud-originated objects or attributes to flow back to AD. When you enable writeback, ensure you have change control, backups, and a rollback plan.
Step 9: Configure sync schedule and staging mode (if applicable)
Azure AD Connect runs sync on a schedule (commonly every 30 minutes in default configurations). In most environments, the default schedule is fine. If you need to tune it, do so for a reason—more frequent sync increases churn and can complicate incident analysis.
If you’re deploying high availability, install a second Azure AD Connect server and enable staging mode on it. The staging server should import and synchronize but not export changes. Keep both servers aligned in configuration.
Step 10: Run the initial synchronization and validate results
After configuration, Azure AD Connect will perform an initial sync. This is where data quality issues show up.
Validation is not just “users exist in the cloud.” Validate:
- UPNs match your intended sign-in format.
- Expected users are present and unexpected users are absent.
- Group membership is correct for key access control groups.
- Attributes required by applications (e.g.,
mail,proxyAddresses,department) are flowing.
For a controlled rollout, start by syncing a pilot OU and validating sign-in and app access before expanding scope.
Validating sync and identity health using built-in tools
Azure AD Connect provides local tools, logs, and UIs that help you understand what the sync engine is doing.
Synchronization Service Manager
The Synchronization Service (often accessed via Synchronization Service Manager) shows connector space, run history, import/export steps, and errors. This is the authoritative place to see whether changes are being imported from AD and exported to Entra ID.
When you see errors such as attribute value conflicts, the run history will usually point you toward the offending object and attribute. Address the root cause in AD wherever AD is authoritative.
Event logs and operational logging
Windows Event Viewer includes logs for Azure AD Connect components. In a mature environment, forward these events to a SIEM so that sync stoppages, authentication agent failures (for PTA), or repeated export errors trigger alerts.
Entra ID portal checks
In the Entra admin center, confirm directory sync status and review sign-in logs. Sign-in logs become particularly important after you enable features like Seamless SSO, Conditional Access, or MFA policies because they help you separate “sync succeeded” from “authentication succeeded.”
Real-world scenario 2: multi-OU environment with service accounts and legacy apps
A manufacturing organization has accumulated years of OU sprawl: production users in several OUs, application service accounts mixed with humans, and legacy apps that depend on specific group naming. They want Microsoft 365 but are concerned about accidentally syncing service accounts and exposing them to password spray risk.
The safest approach is to create a dedicated “cloud-eligible” OU structure and move only human user accounts intended for cloud sign-in into scope. For service accounts required by cloud workloads, create separate managed identities or dedicated accounts with modern controls, then place them in a separate OU with explicit policies. Azure AD Connect’s OU filtering becomes the enforcement mechanism that matches organizational intent.
This scenario highlights why OU filtering is not a cosmetic setting. It is the simplest way to avoid syncing accounts that should never authenticate to cloud services.
Managing attribute flow and avoiding common identity mismatches
Once sync is working, the next set of challenges typically comes from attribute expectations across workloads.
UPN vs email address vs proxyAddresses
In Microsoft 365 environments, email routing depends on proxyAddresses and mail, while sign-in typically uses UPN. They can be the same, but they don’t have to be. Problems arise when administrators assume they are always aligned.
If your org wants user@company.com for sign-in but uses user@brand.com for primary SMTP, document the mapping and ensure helpdesk scripts and onboarding processes set the correct attributes.
The source anchor and hard/soft matching
When you introduce Azure AD Connect into an environment with pre-existing cloud users, you need to ensure the on-prem users match the correct cloud identities. Matching approaches include:
- Soft match: matching based on attributes like UPN or SMTP.
- Hard match: matching using the immutable ID (source anchor) representation.
The mechanics of matching are sensitive and should be planned carefully to avoid accidental merges. If you are onboarding an existing tenant, test matching with a small pilot set, and be prepared to remediate mismatches.
Because matching behavior and supported methods can change with service updates, follow current Microsoft documentation for the precise supported procedure in your situation.
Filtering strategies beyond OUs
In some environments, OU filtering alone is insufficient. Attribute-based filtering (for example, syncing only users with a certain attribute set) can be used, but it is more complex and easier to misconfigure.
If you implement attribute-based filtering, treat it as code: document the rule, peer review changes, and validate in staging mode before exporting.
Seamless SSO: when it helps and what it changes
Seamless SSO allows users on domain-joined machines on the corporate network to sign in to Entra ID-backed services without repeatedly typing passwords. It relies on Kerberos and a special computer account in AD.
Operationally, Seamless SSO reduces password prompts and improves adoption, but it does not replace strong authentication controls. You still need MFA/Conditional Access where appropriate. Seamless SSO is best viewed as a user experience optimization that works within a secure policy framework.
In environments with multiple forests or complex DNS, validate Seamless SSO carefully. Client behavior depends on correct SPNs, browser settings, and network reachability.
Password writeback and self-service password reset (SSPR) considerations
Password writeback is often enabled to support SSPR in a hybrid environment. This can be a major helpdesk cost reducer, but it moves a sensitive operation—password change—into a cloud-triggered workflow.
Security considerations include:
- Ensuring MFA or strong authentication is required for SSPR.
- Monitoring password reset events.
- Verifying that writeback is working reliably before rolling out broadly.
If you enable password writeback, validate it with pilot users across common edge cases: expired passwords, locked-out accounts, and accounts with fine-grained password policies.
High availability with staging mode: build it like you mean to use it
Staging mode is the supported approach to Azure AD Connect high availability. The staging server runs the same configuration and synchronization cycles, but it does not export.
To make staging mode effective, you need more than “a second server installed.” You need an operational playbook:
- How to promote staging to active during an outage.
- How to keep versions aligned (patch both servers in a controlled sequence).
- How to test failover periodically.
A common pattern is to keep the staging server fully updated and to perform configuration changes on staging first, validate results (imports, sync rules, metaverse), and then apply the same change to primary or swap roles.
Real-world scenario 3: regulated environment requiring PTA with multiple agents
A financial services organization has a strict requirement that password validation must remain on-prem and must respect certain on-prem controls and monitoring. They select PTA, but they also have strict uptime requirements for Microsoft 365.
The solution is to deploy multiple PTA agents across separate hosts (and ideally separate fault domains) and to monitor agent health centrally. They also enable PHS as a break-glass backup sign-in method where policy allows, so a temporary PTA outage does not become a full productivity outage.
This scenario demonstrates the trade-off with PTA: you can keep validation on-prem, but you must treat the agent tier as production authentication infrastructure with redundancy, patching, and alerting.
Operational management: change control, monitoring, and safe updates
Once Azure AD Connect is installed and syncing, day-2 operations determine whether it stays healthy.
Treat sync scope changes as high-impact
Adding an OU to sync scope or changing filtering rules can suddenly create thousands of new cloud objects. That can impact licensing, group-based access, and even mail routing if Exchange hybrid is involved.
Use a staging server to preview the effect of scope changes. Validate object counts and ensure you understand what will be exported.
Monitor run history and export errors
Export errors are where most real incidents appear: duplicate attributes, invalid characters, or policy conflicts. Build alerts for repeated failures or sync stoppage.
If you have Azure AD Connect Health (where available and licensed), use it to centralize monitoring for sync and sign-in components.
Patch and upgrade strategy
Azure AD Connect updates include security fixes and compatibility updates for Entra ID changes. Running an outdated build for too long increases risk.
A controlled approach:
- Update the staging server first.
- Validate sync cycles and authentication features.
- Update the primary server.
Document versions and maintain a change log that includes configuration changes (filtering, optional features) and infrastructure changes (certificates, proxy settings).
Practical validation scripts for administrators
While most validation happens in UI tools and the Entra portal, small scripts help confirm your assumptions.
Confirm synced users and key attributes in AD
This snippet checks for users in a target OU and reports their UPN and mail attributes, which are common points of mismatch:
powershell
$ou = "OU=CloudSync,DC=company,DC=com"
Get-ADUser -SearchBase $ou -LDAPFilter "(objectCategory=person)" -Properties userPrincipalName, mail, proxyAddresses |
Select-Object SamAccountName, userPrincipalName, mail, @{n='PrimarySMTP';e={($_.proxyAddresses | Where-Object {$_ -cmatch '^SMTP:'}) -replace '^SMTP:'}} |
Sort-Object SamAccountName
Check domain verification status (conceptual)
Domain verification and tenant checks are usually done via the Entra admin center. If you use automation, prefer Microsoft-supported APIs and modules appropriate for your environment and change control. Because Microsoft’s recommended modules have changed over time (for example, moving from older AzureAD/MSOL modules toward Microsoft Graph), confirm current supported tooling before building automation that you rely on operationally.
Integrating Azure AD Connect with Conditional Access and device identity
Azure AD Connect provides the identity objects that Conditional Access evaluates, but Conditional Access decisions also depend on device state, sign-in risk, and application context.
If your endpoint strategy includes Entra ID Join, Hybrid Entra ID Join, or Intune compliance, ensure you understand how devices appear in Entra ID and how that intersects with synced users. Device identity can become a source of confusion in hybrid environments, especially when devices are reimaged, renamed, or moved between OUs.
A coherent hybrid identity design typically aligns:
- Synced user identity (Azure AD Connect).
- Device registration approach (Hybrid Join vs Entra Join).
- Access controls (Conditional Access, MFA, compliant device requirements).
When these are designed together, user experience improves and policy outcomes become predictable.
Common configuration patterns that scale
As environments grow, certain patterns help keep Azure AD Connect manageable.
Use a clear “cloud-eligible” boundary
Whether that boundary is a dedicated OU, a dedicated forest, or attribute-based filtering, the goal is to avoid ambiguity about what should exist in the cloud. This reduces accidental exposure of privileged accounts and simplifies audits.
Keep identity authoritative sources explicit
Document what is managed on-prem vs in the cloud. For synced identities, assume on-prem is authoritative for most attributes. For cloud-only accounts (break-glass admins, some service principals), Entra ID is authoritative. Mixing these without documentation is where operational confusion starts.
Minimize writeback unless required
Writeback features are powerful, but they also increase coupling between cloud and on-prem. Enable only what you need, and implement monitoring and rollback plans.
Build staging mode into standard operations
Staging mode is not just for disaster recovery. It is a safe platform for change validation. Teams that use staging mode routinely tend to have fewer identity incidents.
Putting it all together: a phased deployment approach
A phased approach keeps risk low and creates measurable checkpoints.
Start with AD cleanup: UPN suffixes, duplicates, and OU structure. Then verify Entra ID domains and confirm your sign-in method choice. Deploy Azure AD Connect using custom settings with a limited pilot OU, validate sign-in and application access, and only then expand scope.
As you expand, introduce operational maturity: staging mode for high availability, monitoring for sync and sign-in health, and documented change control for filtering and optional features. By the time you enable advanced capabilities like password writeback or more complex multi-forest matching, you will have a stable baseline and the observability to detect issues early.