How to Join Active Directory or Azure AD Domains: A Complete Guide

 

Joining computers to a domain, whether it's an on-premises Active Directory or an Azure domain (Microsoft Access ID), is the foundation for centralizing identities, enforcing policies, and enabling Single Sign-On. In this guide we have gathered everything you need in one resource: joining options in Windows 10/11, hybrid identity with Microsoft Entra Connect, Azure AD Domain Services, AD FS deployments in Azure, security with conditional access and monitoring, and operational and cost recommendations.

The goal is to help you choose the best path (classic AD DS, Azure AD/Entra ID, Azure AD DS, or AD FS federation), understand how they connect to each other, and execute the correct steps with best practices. You will also see how to prepare UPN and DNS for synchronizations with Microsoft 365, how to scale and make synchronization highly available, and what to check if something goes wrong, without leaving out typical network configurations in Azure.

Domain Join Options in Windows 10 and 11

Today, there are four main scenarios: on-premises AD DS join, Azure AD join (Microsoft Entra ID), hybrid devices (Hybrid Azure AD Join), and managed domain join with Azure AD Domain Services. Each one addresses different needs for identity management, application compatibility, or remote work.

Joining Azure AD from Windows 10/11 is straightforward from the computer itself: Settings > Accounts > Access work or school > Connect > Join this device to Azure Active Directory, sign in with Microsoft ID credentials, restart, and sign back in with your corporate user.

After initial startup, you'll often need to set up MFA and Windows Hello (PIN) to enhance security and facilitate quick logins. From that point on, the PIN will be requested at each logon, complying with the two-factor authentication required by many organizations.

If you are deploying an access agent such as Sophos ZTNA, remember that application servers (RDP, CIFS, SSH, etc.) must belong to the same domain as the agent. First join the computer to Azure AD and then install the agent so that it inherits the correct identity and access paths.

Identity architecture with Microsoft Azure AD

Microsoft Access ID is the cloud-based identity and directory service that centralizes applications, users, and devices, and integrates with on-premises AD DS through synchronization. A typical reference includes: Entra ID tenant, web subnet with application VMs, on-premises AD DS, a server with Microsoft Entra Connect for synchronization, and application VMs with tiering separation.

Common use cases: publish apps web in Azure for remote users, enable self-service (e.g. password reset, with P1/P2 licenses) and operate without VPN/ExpressRoute connectivity between on-prem and Azure Virtual Network if required by design.

In terms of availability, Microsoft Entra is distributed globally with automatic failover between data centers, ensuring access to directory data across multiple geographic locations. This design minimizes interruptions and supports distributed workloads.

Hybrid Identity with Microsoft Entra Connect: Synchronization and SSO

Microsoft Entra Connect synchronizes AD DS identities with Entra ID and allows you to choose the authentication method: password hash synchronization (default), Pass-through Authentication, or federation with AD FS or another IdP. The choice depends on security policies, desired SSO experience, and components already deployed.

• Supported synchronization topologies: A single forest for a single tenant; multiple forests for a single tenant (with identity consolidation); multiple independent forests; multiple Entra directories (with synchronization servers filtering out exclusive object sets); and a staging server for high availability, testing, or migrations.
• Best practices when deploying Entra Connect: Define what to sync, including domains and frequency; filter (by groups, domains, OUs, or attributes) to avoid syncing inactive accounts; and, if there are many objects, consider using the full SQL Server instead of LocalDB and adjust capacity.
• High availability: Use a second server in staging mode to assume the active role if necessary; if you're not using LocalDB, consider SQL clustering for your database (mirroring and AlwaysOn are not supported for Entra Connect), and plan for disaster recovery.

Configuring the user authentication method

Password Hash Synchronization: The default option is simple and sufficient for many organizations; the user authenticates with the same local password, but only a secure hash travels to the cloud.

Pass-through Authentication: If your policy prohibits synchronizing hashes to the cloud, agents validate the password in on-premises AD without storing the hash in Login ID, maintaining SSO.

Federation with AD FS or another provider: If you already have AD FS or a non-Microsoft IdP, you can delegate authentication and SSO to that infrastructure, while maintaining control and advanced customizations.

Synchronizing objects and rules

The default Entra Connect configuration applies rules to User, Contact, Group, Computer, etc. objects, requiring attributes such as sourceAnchor or sAMAccountName, and avoiding reserved prefixes (e.g., Azure AD_ or MSOL_). To modify rules, use the Synchronization Rules Editor installed with the tool.

In addition to filtering by domain/OU, you can implement more complex custom filters to narrow down the synchronized set to what is relevant. This way you improve performance, security and administration costs.

Identity Environment Monitoring and Health

Microsoft Entra Connect Health provides agents to monitor synchronization, AD DS and AD FS, and exposes dashboards in the Azure portal to review health and performance. It is key to detecting incidents before they affect users.

In terms of protection, Identity Protection (P2) applies ML and heuristics to detect login anomalies and risk events (unusual locations, suspicious IPs, compromised devices), generating actionable alerts and reports.

Complement with conditional access to trigger MFA in untrusted locations, restrict by platform/device state, and use static or dynamic group membership in access decisions. This significantly raises your security posture.

Deploying AD FS in Azure: Design, Networking, and High Availability

For organizations opting for federation, deploying AD FS on Azure enables high availability and scale, with geo-redundancy and easy management from the Azure portal. The recommended topology separates AD FS and WAP, uses DMZ for WAP and load balancers (internal for AD FS and public for WAP).

• Network and security: create a virtual network with two subnets (INT and DMZ), apply NSG per subnet with rules like: allow HTTPS 443 from DMZ to INT (e.g. 10.0.1.0/24 > 10.0.0.0/24, priority 1010), deny outbound to Internet except what is necessary (e.g. deny 80 outbound priority 100), and open only what is essential in DMZ for inbound traffic.
• On-prem connectivity: If you need to reach local domain controllers, use S2S VPN, P2S or ExpressRoute (recommended when you are looking for reliability, high latency and security).
• Availability sets: Use at least two VMs per role (AD FS and WAP) in availability sets; leave the default values (2 fault domains, 5 update domains) for uninterrupted maintenance.
• Internal Balancing (ILB) for AD FS: configures a static IP, a backend pool with AD FS servers, and an HTTP health probe to /adfs/probe on port 80; publishes 443 to backend 443 and creates the Federation Service internal DNS record pointing to the ILB.

WAP, public load balancer, and AD FS testing

Web Application Proxy servers are not domain joined and reside in the DMZ, publishing AD FS to the Internet through a public Load Balancer at 443 with the /adfs/probe probe. Assigns DNS label to public IP for friendly resolutions.

• Update DNS: Create an internal A for the federation service (e.g. fs.company.com) to the ILB, and hosts entries in WAP if you need to internally resolve the ILB IP to the federated FQDN.
• Certificates: Use a server certificate with appropriate CN/SAN (Federation Service, Enterprise Registration, wildcard if applicable) and export it in PFX to install it in AD FS and WAP.
• Proof: enable the IdP Initiated page with PowerShell Set-AdfsProperties -EnableIdPInitiatedSignOnPage $true and validate by navigating to https://tu-adfs/adfs/ls/IdpInitiatedSignon.aspx.

AD FS Deployment Template and Typical Parameters

There are templates that orchestrate six machines (two DCs, two AD FS, and two WAPs) and accept parameters for region, accounts, storage, virtual network (existing or new), INT/DMZ subnets, static IPs of VMs and ILB, VM sizes and administrative credentials. Parameters include: Location, StorageAccountType, VirtualNetworkUsage/Name/AddressRange, subnet names and ranges, NIC IPs per VM, ADFSLoadBalancerPrivateIPAddress, name prefixes for each role, VM sizes, and credentials.

This approach accelerates consistent and repeatable deployments, while documenting network and security configurations. Always adjust ranges to avoid overlaps with existing networks.

Azure AD Domain Services: Join a VM to a managed domain

Azure AD Domain Services (AADD DS) offers managed domain join, LDAP, and Kerberos/NTLM in Azure, without setting up your own domain controllers. Useful when you need legacy application support for domain authentication within Azure.

• Requirements: Active subscription, Enter ID tenant (cloud only or synced), managed domain enabled, user account in the managed domain (with synced password hash or SSPR), and Azure Bastion for RDP access without public IPs.
• Processing: Create a Windows Server VM in a subnet capable of communicating with the managed domain subnet (preferably in a separate subnet), with remote ports closed to the Internet (use Bastion), and join the domain from System Properties specifying the FQDN (e.g. aaddscontoso.com).
• Credentials: Use the recommended UPN format (user@domain.onmicrosoft.com or custom), or SAMAccountName if applicable; the account must belong to the managed domain or tenant. Enter ID.
• Problem solving: If it doesn't ask for credentials, the fault is usually connectivity/DNS: check network pairing, ping the FQDN or IPs of the managed domain and flush DNS cache with ipconfig /flushdns.

If you get an error after entering credentials, check that the account belongs to the managed domain, that password synchronization is enabled, and that enough time has passed after a password change for the hash to replicate. To detach, return to WORKGROUP and then delete the VM if you are not continuing with the tutorial.

Prepare on-premises AD and synchronize with Microsoft 365/Azure AD

If you already use Microsoft 365, syncing your on-premises AD with Entra ID unifies cloud and on-prem credentials, with widespread hybrid options. Ensure that your local UPN suffixes are routable (not .local/.test) and match your verified domains in Microsoft 365/Login ID.

Add a UPN suffix in Active Directory Domains and Trusts and update users in ADUC or via PowerShell to change from @domain.local to @domain.com in bulk, for example with: $LocalUsers = Get-ADUser -Filter "UserPrincipalName -like '*domain.local'" -Properties userPrincipalName -ResultSetSize $null y $LocalUsers | foreach {$newUpn = $_.UserPrincipalName.Replace("@domain.local","@domain.com"); $_ | Set-ADUser -UserPrincipalName $newUpn}.

For Office 365, review proxyAddresses (uppercase SMTP for the primary) in the Attribute Editor for each user/group, Enabling the Advanced Features view in ADUC to properly edit the alias collection.

Install Azure AD Connect: official download, choose Custom installation, define login method (PHS, PTA or Federation), connect with global administrator account in Enter ID/M365, add AD forest, select userPrincipalName as login attribute and filter domains/OU if applicable.

Optional features: Password writeback (P1/P2), rule changes, and scheduler; check “Start synchronization upon completion” or trigger it manually when appropriate.

Synchronization Operation: Useful Commands and Configuration Migration

The ADSync PowerShell module allows you to query the scheduler and force cycles: Import-Module ADSync, Get-ADSyncScheduler, Start-ADSyncSyncCycle -PolicyType Delta o Initial, and adjust interval with Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:10:00.

Azure AD Connect configuration is saved in JSON under %ProgramData%\AADConnect; you can export/import it to clone deployments. and also use the script MigrateSettings.ps1 (Tools folder) to migrate from one server to another.

Remember that timing is not a system of backup: Some attributes only exist in the cloud (for example, licenses), and if they are deleted there, they cannot be recovered by synchronizing. For on-premises AD and Microsoft 365 data backup, turn to dedicated solutions.

Requirements and network: Windows Server 2012/2016/2019 with GUI to install Entra Connect, .NET 4.5.1+, PowerShell 3.0+, TLS 1.2 enabled, and TCP 80/443 outbound to Microsoft services; Essentials/Core are not supported for the tool server.

Conditional Access, Security and Government

Complement login with conditional access policies for unexpected sources, non-compliant platforms, or disabled devices, and rely on groups (including dynamic ones) to segment access. This is how you implement Zero Trust with minimal friction.

Identity Protection (P2) adds baseline risk policies that react to anomalous login signals, and Entra reports help diagnose and audit relevant activities.

Connects Connect Health agents to monitor synchronization, AD DS and AD FS, providing metrics and status in the Azure portal, being one of the pillars of efficient management.

Performance, costs and operability (Well-Architected)

• Performance: Entra ID relies on a primary replica and read-only secondary replicas, with eventual consistency and effective scaling, as it is primarily a read operation. Entra Connect scales SQL if you exceed approximately 100.000 objects.
• Costs: Use the Azure calculator to estimate; optimize by limiting synchronization to what's necessary and selecting authentication methods that reduce infrastructure (e.g., without AD FS if not essential).
• Reliability: Consider a second Entra Connect server in Staging for failover, disaster recovery planning, and take care of the databases- Avoid unsupported technologies such as mirroring or AlwaysOn for database synchronization.
• Operability: Entra Connect tools (Console, Synchronization Service Manager, and Rules Editor) allow you to maintain and adjust synchronization with precise control and diagnostics, essential in complex environments or with custom rules.

Integration with Citrix and SAML (SSO with Azure AD)

To publish desktops or applications with Citrix and SSO via Azure AD, integrate Citrix Gateway and StoreFront using SAML 2.0 as an Azure AD IdP, so Azure AD-joined users can easily sign in from myapps.microsoft.com. In Azure AD, create an enterprise app, configure SAML with an identifier and reply URL as /cgi/samlauth, download the signing certificate, copy the login and logout URLs, assign the app to users, and use the SSO URL in shortcuts.

On Citrix Gateway, import the certificate, configure the SAML policy, add the Azure IdP with metadata, and link with StoreFront (ideally over HTTPS), verifying that authentication works correctly and that the trust and STA policies are appropriate. If you use AD FS as an intermediary IdP, remember the CNAME record for federation (for example, enterpriseregistration. ) to resolve the flow in joining to Azure AD, also ensuring the installation of the corresponding root certificate on the computers.

About platforms: Consult resources like Reddit with caution, as their recommendations are not official, and always check them against formal technical documentation before applying changes.

From basic to advanced, this journey covers everything from simple Azure AD joins to hybrid architectures with high availability, federation, and SSO for modern and traditional applications, with sophisticated security controls and robust operations. By planning UPN and DNS properly, properly filtering synchronizations, and implementing security measures like MFA and Conditional Access, identity management in Windows 10/11 and Azure uploads will be efficient, scalable, and easy to maintain.