1. The Hybrid Identity Challenge

Most organisations today run a mix of on‑premises and cloud services. Microsoft 365 (formerly Office 365) is often the biggest cloud investment. You want users to log into Exchange Online, SharePoint Online, and Teams using their existing corporate AD credentials – no separate cloud passwords, no sync delays, and full control over authentication policies like MFA from your own ADFS.

In this lab we’ll deploy Microsoft Entra Connect (formerly Azure AD Connect) to sync identities from our corp.lab domain to a Microsoft 365 tenant. We’ll configure ADFS as the federated identity provider so that when users sign into a Microsoft 365 service, they are redirected to our ADFS farm for authentication – true hybrid SSO.

2. Pre‑Lab Checklist

• ✅ Functional lab with DC01, ADFS01, and EXCH01 (Parts 3 & 4)
• ✅ A Microsoft 365 trial tenant (sign up at admin.microsoft.com)
• ✅ A new VM AZCONNECT01 for Entra Connect (Windows Server 2022, domain‑joined)
• ✅ A custom domain added and verified in your Microsoft 365 tenant (e.g., corp.lab – you can use the onmicrosoft.com domain for lab, but a custom domain is better)
• ✅ Global Administrator credentials for the tenant

3. Step 1 – Prepare Microsoft 365 Tenant for Federation

Before installing Entra Connect, we need to set the tenant’s authentication domain to federated. We’ll use PowerShell to convert the domain from Managed (cloud auth) to Federated (ADFS).

1. Install the Microsoft Graph PowerShell module on any machine (e.g., AZCONNECT01):

Install-Module Microsoft.Graph -Scope CurrentUser

2. Connect to Graph and set the domain to federated:

Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"
# If using the onmicrosoft.com domain, replace with your actual tenant domain
$domain = "corplab.onmicrosoft.com"   # example
New-MgDomainFederationConfiguration -DomainId $domain `
    -ActiveSignInUri "https://sts.corp.lab/adfs/ls/" `
    -IssuerUri "http://sts.corp.lab/adfs/services/trust" `
    -SigningCertificate (Get-Content "C:\adfs_token_signing.cer" -Raw) `
    -PreferredAuthenticationProtocol "wsFed" `
    -FederationBrandName "Corp Lab ADFS"

After running, the domain will show as Federated in the Microsoft 365 admin center under Settings → Domains.

4. Step 2 – Deploy Entra Connect Server (AZCONNECT01)

1. Create a new VM (or use an existing one), join it to corp.lab.
2. Install the latest Microsoft Entra Connect (download from Microsoft’s site – it’s a small MSI).
3. During installation, choose Customize (not Express).
4. Sign in with your Microsoft 365 Global Admin account when prompted.
5. On the Connect your directories page, select your forest (corp.lab) and choose Create new AD account (Entra Connect will create a service account).
6. On the User sign‑in page, select Federation with AD FS.
7. When asked to specify the ADFS farm, choose Use an existing farm and point to sts.corp.lab. Entra Connect will verify it can reach the federation service.
8. Proceed through the remaining pages, leaving the default OU filtering (sync all users).
9. Start the synchronization.

Once the sync completes, your on‑prem AD users will appear in the Microsoft 365 admin center under Users → Active users (they’ll have “Synced from on‑premises” status).

5. Step 3 – Configure ADFS Relying Party for Microsoft 365

Entra Connect normally creates the Microsoft 365 relying party trust in ADFS automatically. If it didn’t, or if you want to verify it, check ADFS Management console.

Look for a trust named Microsoft Office 365 Identity Platform. If missing, you can create it manually using the federation metadata from Microsoft 365:

# On ADFS01, add the relying party trust from the Microsoft 365 federation metadata URL
Add-AdfsRelyingPartyTrust -Name "Microsoft 365" `
    -MetadataUrl "https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml"

Ensure that the claim rules for this trust issue at least the ImmutableID (derived from the on‑prem AD’s objectGuid) and UPN. Entra Connect should add these automatically; otherwise, you can add a rule to send objectGuid as a claim named http://schemas.xmlsoap.org/ws/2005/05/identity/claims/objectidentifier and UPN as UPN.

6. Step 4 – Test Hybrid SSO

Now the real test – accessing a cloud service with your on‑prem credentials.

1. From a domain‑joined client (or a browser on any lab VM), navigate to https://portal.office.com.
2. Enter the UPN of a synced user (e.g., user@corp.lab or user@corplab.onmicrosoft.com – whichever you federated).
3. Instead of a Microsoft login form, you should be redirected to your ADFS sign‑in page (sts.corp.lab).
4. Authenticate with your AD password. After success, you’ll be redirected back to the Office 365 portal, fully signed in.

That’s hybrid SSO in action. No credentials stored in the cloud; ADFS is the sole authenticator.

7. How It Works Under the Hood

When a user tries to access a Microsoft 365 service (like Outlook on the web), the cloud verifies the domain’s authentication configuration. Since it’s set to Federated, Microsoft Entra ID (the cloud identity service) does not attempt to validate the password. Instead, it sends a WS‑Federation or SAML authentication request back to the browser, pointing to your ADFS endpoint.

ADFS authenticates the user (Kerberos if inside the corporate network, or forms‑based). It then generates a SAML token with the required claims – ImmutableID (which ties the cloud identity to the on‑prem object) and UPN. That token is posted back to Microsoft Entra ID, which validates the signature using the pre‑shared token‑signing certificate. Once validated, Entra ID creates its own session and grants access.

Entra Connect periodically synchronises the user account attributes (like display name, department, group memberships) so they’re available in the cloud, but authentication always stays on‑premises.

8. Troubleshooting Common Pitfalls

• Redirect to ADFS, then error “AADSTS50008: SAML token is invalid”? – The token‑signing certificate may not match what you uploaded to Microsoft 365. Re‑export the token‑signing certificate and update the domain federation settings via Graph or the old MSOnline module.
• Users see a Microsoft login page instead of ADFS? – The domain might not be federated. Run Get-MgDomain and check AuthenticationType. If it says “Managed”, you haven’t set up federation.
• ImmutableID mismatch? – If users already existed in the cloud before sync, the soft‑match may fail. Ensure the on‑prem UPN matches the cloud UPN and that the cloud user isn’t already federated with another source.
• Entra Connect sync errors? – Check the Synchronization Service Manager on AZCONNECT01 for detailed logs.

9. Next Steps 🚀

You’ve just built a complete hybrid identity solution. Now let’s extend federation to a completely different organisation – a partner or subsidiary.

👉 Part 7 – Use‑Case Scenario: B2B Federation with a Partner Organisation
We’ll establish a cross‑forest federation trust so that users from a partner company can access your internal applications using their own corporate credentials. A whole new world of identity collaboration awaits.