Connecting Your On-Premises Systems to Azure: Managing External Users
Synchronization, Hybrid Authentication, Secure Remote Access, and External Identity
This article covers how users are synchronized to the cloud, how authentication works for modern and legacy applications, how on-prem environments are extended to Azure, and how organizations collaborate securely with external users.
Synchronizing Users to the Cloud
Once Active Directory and Microsoft Entra ID are connected, the next critical decision is how authentication should work. Microsoft provides three primary models, each with very different trade-offs.
Password Hash Synchronization (PHS)
Your on-premises AD converts a password into a cryptographic fingerprint and synchronizes only that fingerprint to the cloud.
How it works
AD hashes the password
The hash is synced to Entra ID
During sign-in, Entra ID hashes the entered password and compares results
Why it is the default recommendation
Users can still log in if on-prem servers or internet links fail
Enables cloud-native protections like leaked credential detection
Minimal infrastructure and fewer moving parts
Syncs frequently, roughly every two minutes
PHS offers the best balance of security, simplicity, and resilience.
Pass-Through Authentication (PTA)
The cloud never stores any version of the password.
How it works
Entra ID receives the login request
It forwards the credentials to a local authentication agent
On-prem AD validates the password
Why organizations choose it
- Compliance rules prohibit password storage in the cloud
The trade-off
- If on-prem connectivity or servers are unavailable, cloud sign-ins fail
PTA prioritizes control, but sacrifices availability.
Federated Authentication (AD FS)
Authentication is fully handled by infrastructure you manage.
How it works
Users are redirected to a company-hosted login page
AD FS validates identity and issues tokens to the cloud
Used when
Smart cards are mandatory
Third-party MFA providers are required
Heavy AD FS investment already exists
Downside
High complexity and operational overhead
Multiple servers, certificates, and load balancers
Federation is powerful, but it is rarely the simplest choice today.
Sync Tools: Entra Connect vs Cloud Sync
Authentication models rely on synchronization tools to move identity data to the cloud.
Entra Connect (Classic)
A full-featured, server-based synchronization engine.
Installed on a dedicated server
Uses SQL for processing
All logic runs on-prem
Capabilities
OU filtering
Password and group write-back
Supports PHS, PTA, and Federation
Best suited for
Complex environments
Exchange hybrid
Advanced filtering and writeback needs
Entra Cloud Sync (Modern)
A lightweight, agent-based approach.
Small agent installed locally
Configuration managed entirely in the Entra portal
Cloud-driven sync logic
Where it excels
Mergers and acquisitions
Multi-forest environments
Fast, low-overhead deployments
Limitations
No pass-through authentication
No group writeback
No integration with Entra Domain Services
Choosing the Right Tool
Need advanced control? Use Entra Connect
Need speed and simplicity? Use Cloud Sync
Need both? They can coexist in the same tenant
Authenticating On-Premises Applications
Most legacy applications still rely on IIS and Windows Authentication.
Windows Integrated Authentication
Uses Kerberos automatically
No login prompts
True Single Sign-On inside the corporate network
Kerberos handles identity silently through tickets rather than passwords.
AD FS as an Authentication Hub
Instead of every application talking directly to Active Directory, AD FS centralizes authentication.
Why it matters
Supports both legacy and modern protocols
Enables MFA and certificate-based auth from one location
Acts as a translation layer between AD and modern apps
Supported protocols include:
SAML and WS-Federation
OAuth 2.0 and OpenID Connect
This makes AD FS a stepping stone toward cloud-based identity.
Extending the Server Environment to Azure
When applications move to Azure, identity is often the hardest problem to solve. There are three main approaches.
VPN or ExpressRoute
Azure is treated like another branch office.
Azure VMs authenticate against on-prem Domain Controllers
Simple concept, full compatibility
Heavily dependent on network reliability
A brief network outage can break authentication.
Domain Controller in Azure (IaaS)
A traditional Domain Controller is deployed as a VM in Azure.
Local authentication in the cloud
More resilient than VPN-only setups
Requires full server management
You gain reliability, but also operational burden.
Microsoft Entra Domain Services
A managed Active Directory service in Azure.
Microsoft operates the domain controllers
Kerberos, NTLM, and LDAP are available
No patching, backups, or HA management required
This is the ideal lift-and-shift solution for legacy apps that cannot be modernized.
Entra Domain Services in Practice
How Identity Flows
User data follows a two-step path:
On-prem AD synchronizes to Entra ID
Entra ID synchronizes to Entra Domain Services
Because Kerberos and NTLM are required, Password Hash Sync must be enabled.
When to Use It
Commercial off-the-shelf applications
LDAP-dependent workloads
Group Policy for Azure VMs
Legacy apps with no modern auth support
Key Limitations
No guest or external user authentication
OU structures do not sync from on-prem
Scoped to the Azure virtual network
It is a compatibility layer, not a global replacement for AD.
Web Application Proxy (WAP) with AD FS
The Role of WAP
Web Application Proxy sits in the DMZ and protects internal web applications.
Acts as a reverse proxy
Terminates internet traffic
Creates a fresh internal connection
Shields backend servers from direct exposure
WAP and AD FS Together
WAP relies on AD FS for authentication.
Typical flow:
User accesses an internal app from the internet
WAP intercepts and redirects to AD FS
AD FS authenticates the user
A token is issued
WAP validates the token and grants access
Kerberos Constrained Delegation (KCD)
KCD enables remote access to legacy apps.
WAP authenticates the user via AD FS
WAP requests a Kerberos ticket on the user’s behalf
The internal app receives the ticket it expects
The app believes the user is local, even when they are remote.
Network Obfuscation
WAP allows external URLs to differ from internal ones, hiding:
Server names
Domain structure
Application paths
Security improves by revealing less.
Identity Federation with External Organizations
What Federation Means
Federation is a trust relationship.
One organization trusts another organization’s identity provider
Authentication is proven using tokens and claims
Passwords never cross boundaries
AD FS and Traditional Federation
AD FS historically enabled:
Cross-company access
SaaS single sign-on
Partner collaboration
Users authenticate at their home organization, and trusted tokens grant access elsewhere.
Federation for Cloud-Hesitant Organizations
Some companies require:
All authentication to stay on-prem
No password presence in the cloud
Federation allows cloud services to be used while keeping identity validation fully local.
Cloud-Native Federation
Modern federation is simpler and cloud-managed.
Trust other Entra tenants
Trust social identity providers
Enable customer and partner access without custom infrastructure
Microsoft Entra Application Proxy
A New Remote Access Model
Application Proxy reverses the traditional approach.
No inbound firewall ports
No public IPs for internal servers
A small connector inside the network establishes outbound connections
This dramatically reduces attack surface.
How Application Proxy Works
User authenticates to Entra ID
MFA and Conditional Access are enforced
The cloud signals the on-prem connector
The connector retrieves data from the internal app
Content is returned securely to the user
Internal networks never accept inbound traffic.
Why It Replaces WAP for Many Organizations
No DMZ infrastructure
Centralized access control
Deep integration with Conditional Access
Ideal replacement for VPNs for web apps
Microsoft Entra External ID (B2B and B2C)
B2B: Partner Collaboration
External users authenticate with their home identity
Guest objects are created for authorization
Permissions are controlled internally
Access is revoked automatically when the external account is disabled
You manage access, not credentials.
B2C: Customer Identity
Separate directory for customers
Massive scale support
Social login integration
Simplified onboarding for public apps
Employees and customers remain cleanly separated.
