Azure AD SSO Setup for Hybrid Environments
Most organisations migrating to Azure do not start from zero. They have on-premise Active Directory, domain-joined devices, and users who already authenticate against their existing infrastructure. Getting those users seamless access to Azure and Microsoft 365 services without a separate login, while keeping their on-premise access working, is the hybrid identity problem.
Microsoft Entra Connect (formerly Azure AD Connect) is the bridge. It synchronises your on-premise AD to Microsoft Entra ID, enables Hybrid Azure AD Join so domain-joined devices are also registered in Entra, and supports Seamless SSO so users on those devices get authenticated automatically to cloud services using their existing Kerberos session. This guide covers the configuration from first install through to validating that SSO actually works.
Install and configure Microsoft Entra Connect
The server running Entra Connect is a critical piece of infrastructure. Treat it like a domain controller: do not run other workloads on it, restrict local logons to administrators, and apply the same patching rigour you would to a DC. The server needs Windows Server 2016 or later and .NET Framework 4.5.1 or later.
Before running the installer, run the IDFix tool against your on-premise directory. IDFix checks for attribute errors, duplicate values, and invalid characters in UPN suffixes, proxy addresses, and SAM account names that will cause synchronisation errors. Fixing these before the first sync is significantly faster than dealing with them after you have partially synchronised 50,000 objects.
Also enable the Active Directory Recycle Bin in your forest before installation. This simplifies recovery if objects are accidentally deleted during the initial synchronisation.
During installation you will choose between Express Settings (single-forest environments) and Custom Settings (multi-forest or specific authentication requirements). Express is suitable for most deployments. Custom gives you control over exactly which OUs sync and which authentication method is used.
Choosing an authentication method is the most consequential configuration decision in the installation:
Password Hash Synchronisation (PHS) synchronises a hash of the user's password hash to Entra ID every two minutes. Entra ID handles authentication. This is the simplest option, has no on-premise infrastructure dependency for cloud authentication, and includes leaked credential detection via Entra ID Protection. For organisations without specific compliance requirements for on-premise authentication, this is the recommended starting point.
Pass-through Authentication (PTA) validates passwords directly against your on-premise AD through lightweight agents that you deploy on your servers. Passwords never leave your network. On-premise policies (lockout, sign-in hours) apply immediately. This requires at least three agents for reliability. If on-premise is unavailable, cloud authentication fails, which is a genuine risk to weigh.
Federation via AD FS delegates authentication to an on-premise AD FS farm. This supports the most complex scenarios (smart card authentication, third-party MFA, non-standard UPN formats) but requires dedicated server infrastructure and the highest operational overhead. Reserve it for environments with specific needs that PHS and PTA cannot meet. If you do use Federation, enable PHS as a backup authentication method so cloud access survives an AD FS outage.
After installation, the synchronisation cycle runs every 30 minutes by default. A successful initial sync shows users appearing in the Entra ID portal under All Users with source listed as Windows Server AD. On the Connect server, open Synchronisation Service Manager and verify that Import, Synchronisation, and Export steps all show Success status.
Enable Hybrid Azure AD Join
Hybrid Azure AD Join registers your domain-joined Windows devices with Microsoft Entra ID alongside their existing on-premise domain membership. This is what enables PRT-based SSO on Windows 10 and 11 devices, where the user's authentication token covers both on-premise and cloud resources from a single login.
Prerequisites: Entra Connect version 1.1.819.0 or later, Enterprise Administrator credentials for each forest, Hybrid Identity Administrator credentials for the Entra tenant, and supported device operating systems (Windows 10 1809+, Windows 11, Windows Server 2016/2019/2022).
The configuration is done through the Entra Connect wizard: Additional tasks > Configure device options > Configure Hybrid Azure AD join. The wizard configures a Service Connection Point (SCP) in your on-premise AD's Configuration naming context. The SCP tells devices which Entra tenant to register with.
For environments using PHS or PTA, select Azure Active Directory as the authentication service. For federated environments, select AD FS.
If you want to roll out gradually (recommended for large environments), skip the SCP configuration in the wizard and deploy registry keys directly to pilot devices via Group Policy instead. The keys go at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD with your TenantId and TenantName values. This gives you precise control over which devices register before rolling out to the full estate.
After configuration, devices take up to 45 minutes to register. Validate with dsregcmd /status on a domain-joined machine. The output should show both AzureAdJoined: YES and DomainJoined: YES. In the Entra portal, check Devices > All devices and confirm the join type shows Hybrid Azure AD joined.
A common issue: devices not appearing in Entra after the expected time. First check that the OUs containing those computer objects are included in the Entra Connect sync scope. Devices cannot register if they have not been synchronised. Also verify that the following URLs are excluded from SSL/TLS inspection on your proxy or firewall, because TLS interception breaks the client certificate authentication used during device registration:
- https://device.login.microsoftonline.com
- https://enterpriseregistration.windows.net
Configure Seamless SSO
Seamless SSO eliminates the password prompt for users on Hybrid Azure AD joined devices. It works by using the user's existing Kerberos session (obtained at Windows login) to authenticate silently to Entra ID. It is supported for PHS and PTA environments; it does not work with AD FS (federated environments use AD FS itself for SSO).
Enable it in the Entra Connect wizard: Change user sign-in > Enable single sign-on. Enter Domain Administrator credentials for each forest. The wizard creates a computer account named AZUREADSSOACC in each forest. This account holds the Kerberos decryption key used to validate Kerberos tickets during SSO. Protect it accordingly.
Secure the AZUREADSSOACC account immediately after creation. Move it to a dedicated OU protected from accidental deletion. Restrict management access to Domain Admins only. Disable Kerberos delegation on the account. Set the msDS-SupportedEncryptionTypes attribute to use AES256 rather than RC4, which is the default.
Rotate the Kerberos decryption key every 30 days using the Update-AzureADSSOForest PowerShell cmdlet. This is a mandatory maintenance task, not optional. If the key is compromised, an attacker can generate Kerberos tickets to impersonate synchronised users during Entra sign-ins. Monthly rotation limits the exposure window.
After enabling Seamless SSO in the wizard, apply Group Policy to configure browsers to send Kerberos tickets to the Entra authentication endpoint. Add https://autologon.microsoftazuread-sso.com to the Local Intranet zone using the Site to Zone Assignment List policy under User Configuration > Administrative Templates > Windows Components > Internet Explorer. Set the value to 1 (Intranet zone). Also enable Allow updates to status bar via script in the Intranet zone settings.
For Chrome and Edge, add the URL to AuthServerAllowlist if you have customised that setting. For Firefox, configure it in the SPNEGO section of the authentication policy.
Common mistake: adding the URL to Trusted Sites instead of Local Intranet. Trusted Sites does not trigger Kerberos negotiation. Users will get a login prompt rather than silent authentication. If SSO is not working after the Group Policy is applied, check which zone the URL ended up in on the affected machines.
Validate and troubleshoot
Run dsregcmd /status on a domain-joined device after Group Policy has applied. In addition to the join status, check for SSOState: AzureAdPrt: YES, which confirms the Primary Refresh Token is present and SSO is working.
For browser-based validation, navigate to https://myapps.microsoft.com. A user on a correctly configured device should authenticate without being prompted for a password. If a prompt appears, check: Has Group Policy applied on that machine? Is the URL in the correct zone? Is the device showing as Hybrid Azure AD joined?
Error codes and their causes:
| Code | Meaning | Fix |
|---|---|---|
| 81001 | Kerberos ticket too large | Reduce group memberships; large group membership inflates the token |
| 81010 | Ticket expired or invalid | Device must be domain-joined and connected to the corporate network |
| 81011/81013 | User object not found in Entra | Check synchronisation; the user must exist in Entra ID |
| 81012 | User mismatch | Confirm the device login and the Entra sign-in are the same user |
For Kerberos ticket size issues, use klist to inspect current tickets and klist purge to clear the cache and force a fresh ticket request.
Check Azure AD Connect Health in the Entra admin portal daily. Event ID 4 in the Application log on the Connect server confirms successful synchronisation cycles. Review the Synchronisation Service Manager for any errors on the most recent cycle.
Where Critical Cloud comes in
Hybrid identity is foundational infrastructure that touches every user in the organisation. Getting it wrong means authentication failures, productivity impact, and security gaps, and most issues are subtle enough to persist for weeks before anyone diagnoses them. We configure and operate hybrid Azure identity for businesses across financial services, healthcare, and the public sector. As the world's first Powered by Datadog accredited partner, we monitor synchronisation health, authentication failures, and PIM activation patterns as live signals, so identity problems are detected and resolved before they reach your service desk. See how Critical Support works.