3.4 Hybrid Authentication Methods & Staged Rollout

Hybrid Authentication Methods & Staged Rollout

Selecting and deploying the appropriate hybrid sign-in architecture is one of the most critical decisions in hybrid identity administration. The sign-in method determines where authentication occurs (in the cloud vs. on-premises), how disaster recovery scenarios are handled when on-premises WAN links fail, how security policies (such as logon hours and leaked credential detection) are enforced, and how seamless single sign-on is delivered to end users.

---

1. Deep Dive: Hybrid Authentication Methods

Microsoft Entra ID supports three primary hybrid authentication methods, each with distinct architectural and operational profiles.

+-----------------------------------------------------------------------------------+
|                      HYBRID AUTHENTICATION ARCHITECTURES                          |
|                                                                                   |
|  [1. PASSWORD HASH SYNC (PHS)]                                                    |
|   User Entry ---> [Microsoft Entra Cloud Auth Engine] (100% Cloud Autonomous)    |
|                   (Authenticates against 1000x SHA-256 Hash of NTLM Hash)         |
|                                                                                   |
|  [2. PASS-THROUGH AUTHENTICATION (PTA)]                                           |
|   User Entry ---> [Entra Service Bus Queue] <=== (Outbound HTTPS Poll) ===        |
|                   [On-Premises PTA Agents] ---> [AD DS Domain Controllers]        |
|                                                                                   |
|  [3. FEDERATION (AD FS)]                                                          |
|   User Entry ---> [Browser Redirect] ---> [Perimeter WAP] ---> [Internal AD FS]   |
|                   (AD FS Validates against AD DS & Issues Signed SAML Token)      |
+-----------------------------------------------------------------------------------+

1. Password Hash Synchronization (PHS):

• Cryptographic Pipeline: Entra Connect reads the user's NTLM password hash from on-premises AD DS via directory replication APIs (Netlogon/DRSUAPI). It expands the 16-byte binary hash to 64 bytes, adds a per-user 10-byte salt, and feeds the result into PBKDF2 using 1,000 iterations of HMAC-SHA256. This generated hash of a hash is transmitted over TLS 443 to Entra ID. The password hash sync process runs every 2 minutes and that frequency cannot be modified — it is independent of the 30-minute directory synchronization cycle.
• Security Impossibility: The resulting cloud hash cannot be reversed into the on-premises NTLM hash or plaintext password. It is mathematically impossible to use the cloud hash to authenticate against on-premises resources.
• Leaked Credentials Detection: Integrates with Microsoft Entra ID Protection. Microsoft compares the user's synced password hashes against billions of exposed credentials found on the dark web and threat intelligence feeds, automatically flagging high-risk accounts.
• Maximum Resilience (Cloud Autonomous): If on-premises domain controllers, WAN connections, or internal data centers go offline, cloud authentication continues uninterrupted.

2. Pass-through Authentication (PTA):

• Mechanism: User authentication requests are submitted to Entra ID, which places them into an encrypted Azure Service Bus queue.
• PTA Agents: Lightweight agents installed on Windows Server domain member servers poll this queue over outbound HTTPS (TCP 443). The agent retrieves the request, calls the Win32 LogonUser API to validate the credentials against on-premises domain controllers in real time, and writes the validation result back to the queue.
• Real-Time Policy Enforcement: Immediately enforces on-premises account lockouts, disabled states, expired passwords, and Active Directory Logon Hours / Workstation Restrictions.
• High Availability Guidance: PTA runs with a single agent, but that agent is a single point of failure for every sign-in. For production, Microsoft recommends a minimum of 3 Authentication Agents on independent servers, and enforces a system limit of 40 agents per tenant. Extra agents give redundancy but not deterministic load balancing; Microsoft benchmarks one agent at 300-400 authentications per second on a 4-core, 16 GB server.

3. Federation with Active Directory Federation Services (AD FS):

• Mechanism: Entra ID redirects the user's browser to the on-premises Web Application Proxy (WAP) in the perimeter network, which forwards to internal AD FS servers. AD FS validates the user against AD DS (supporting smart cards, x509 certificates, or hardware tokens) and issues a cryptographically signed SAML 2.0 or WS-Federation token.
• Operational Overhead & Vulnerability: High infrastructure complexity (load balancers, WAP servers, AD FS servers, public SSL certificates). Single Point of Failure: If the on-premises AD FS farm or WAN link goes down, all cloud sign-ins fail immediately unless fallback mechanisms are configured.

Hybrid Sign-In Method Decision Matrix

2. Seamless Single Sign-On (Seamless SSO)

Microsoft Entra Seamless Single Sign-On (Seamless SSO) automatically signs users in when they are on their corporate devices connected to the corporate network, without prompting for passwords.

+-----------------------------------------------------------------------------------+
|                     SEAMLESS SSO KERBEROS AUTHENTICATION FLOW                     |
|                                                                                   |
|  [1. User Workstation]                                                            |
|      - Accesses https://portal.azure.com                                          |
|      - Entra ID returns HTTP 401 Challenge with SPN:                              |
|        "HTTP/autologon.microsoftazuread-sso.com"                                  |
|                                                                                   |
|  [2. Workstation Requests Kerberos Ticket]                                       |
|      - Sends TGS-REQ to On-Premises Domain Controller                             |
|      - DC generates Kerberos Ticket encrypted with AZUREADSSOACC secret           |
|                                                                                   |
|  [3. Workstation Presents Ticket to Entra ID]                                     |
|      - Entra ID decrypts ticket using shared AZUREADSSOACC key                    |
|      - Entra ID validates identity and issues SAML/OAuth token                    |
+-----------------------------------------------------------------------------------+

The AZUREADSSOACC Computer Account:

When Seamless SSO is enabled in Entra Connect, a computer account named AZUREADSSOACC is created in the on-premises Active Directory domain. Entra Connect shares the Kerberos decryption keys of this computer account securely with Microsoft Entra ID.

Group Policy Configuration:

For client browsers to automatically transmit Kerberos tickets without security prompts, administrators must configure two Group Policy settings under User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page:

1. Site to Zone Assignment List: Add https://autologon.microsoftazuread-sso.com with a value of 1 (Intranet Zone).
2. Allow updates to status bar via script: Set to Enabled for the Intranet Zone.

Crucial Maintenance: Rolling the Kerberos Decryption Key:

To maintain security and prevent Kerberos ticket forging attacks (Golden Ticket), the Kerberos decryption key of AZUREADSSOACC must be rolled over periodically (recommended at least every 30 days).

# Importing the Microsoft Entra Connect SSO PowerShell Module
Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1"

# Connecting to Microsoft Entra ID with Hybrid Identity Administrator Credentials
$creds = Get-Credential
New-AzureADSSOAuthenticationContext -Credentials $creds

# Rolling the Kerberos Decryption Key across all synced forests
Get-AzureADSSOStatus | Update-AzureADSSOForest -OnPremCredentials (Get-Credential)

---

3. Self-Service Password Reset (SSPR) & Password Writeback

Password Writeback is a bi-directional synchronization feature that allows users who reset or change their password in Microsoft Entra ID (via the SSPR portal, MySignIns, or modern auth prompts) to have that new password instantly written back to on-premises AD DS.

+-----------------------------------------------------------------------------------+
|                    SSPR PASSWORD WRITEBACK DATA FLOW                              |
|                                                                                   |
|  [User Resets Password in Cloud] ---> [Microsoft Entra SSPR Service]              |
|                                                  |                                |
|                                    (Encrypted Service Bus Relay)                  |
|                                                  v                                |
|  [On-Premises AD DS] <--- (Netlogon API) <--- [Entra Connect Sync Engine]         |
|   - Enforces AD Password Policies (Length, Complexity, History)                   |
|   - Unlocks Locked User Accounts (if enabled)                                     |
+-----------------------------------------------------------------------------------+

Key Operational Rules for Password Writeback:

• No Inbound Ports Required: Password writeback uses an outbound-initiated encrypted WebSocket connection over TCP port 443 to Azure Service Bus.
• On-Premises Policy Enforcement: When Entra Connect writes the password back to AD DS, on-premises Active Directory password policies (minimum length, complexity, password history, and minimum password age) are fully enforced. If the new password violates on-premises password history, the reset fails in the cloud UI with a descriptive policy error.
• Account Unlock Writeback: SSPR can be configured to simultaneously unlock a locked on-premises AD DS account without requiring the user to wait for lockout duration expiration.

---

4. Staged Rollout: Migrating from Federation to Cloud Auth

Historically, migrating an enterprise domain from Federated (AD FS) authentication to Cloud Authentication (PHS or PTA) was an all-or-nothing cutover. If any issues occurred, all users in the domain were impacted.

Staged Rollout eliminates this risk by allowing administrators to selectively pilot and transition specific groups of users to cloud authentication while the domain remains configured as Federated.

+-----------------------------------------------------------------------------------+
|                   STAGED ROLLOUT MIGRATION ARCHITECTURE                           |
|                                                                                   |
|                          [FEDERATED DOMAIN: CONTOSO.COM]                          |
|                                        |                                          |
|                  +---------------------+---------------------+                    |
|                  |                                           |                    |
|                  v                                           v                    |
|     [USERS IN STAGED ROLLOUT GROUP]               [ALL OTHER DOMAIN USERS]        |
|      - Authenticate via PHS or PTA                 - Authenticate via AD FS / WAP |
|      - Use Seamless SSO                            - Full Federation Prompts      |
|      - Zero impact on federation                   - Legacy Fallback Intact       |
+-----------------------------------------------------------------------------------+

Staged Rollout Capabilities:

• Supported Features: Password Hash Sync, Pass-through Authentication, Seamless SSO, and Certificate-based Authentication (CBA).
• Granular Group Assignment: Cloud-created or synced security groups are assigned to specific Staged Rollout features in the Microsoft Entra Admin Center. When a member of that group initiates login, Entra ID intercepts the request and handles authentication directly via PHS/PTA rather than redirecting the browser to AD FS.
• Seamless Fallback: If a pilot user experiences authentication issues, simply removing the user from the Staged Rollout security group instantly reverts their authentication back to AD FS.

Final Domain Conversion to Managed:

Once all user groups have been validated successfully in Staged Rollout, the administrator converts the domain from Federated to Managed using Microsoft Graph PowerShell:

# Converting an Entra ID domain from Federated to Managed authentication
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
Update-MgDomain -DomainId "contoso.com" -AuthenticationType "Managed"