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.

• ✅ 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
• ✅ ADFS token‑signing certificate exported from ADFS01 (from Part 4) – you’ll need this for federation configuration

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 AZCONNECT01 (or any machine with access to both your AD and the internet):

Install-Module Microsoft.Graph -Scope CurrentUser -Force

2. Connect to Graph and set the domain to federated. First, export the ADFS token‑signing certificate as a Base‑64 .CER file (from Part 4) and copy it to AZCONNECT01.

# Connect to Microsoft Graph with Global Admin permissions
Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"

# If using the onmicrosoft.com domain, replace with your actual tenant domain
# Example: contoso.onmicrosoft.com
$domain = "corplab.onmicrosoft.com"   # CHANGE THIS to your tenant domain

# Read the token-signing certificate (must be in Base-64 .CER format)
$certPath = "C:\ADFS_TokenSigning.cer"
$certContent = Get-Content $certPath -Raw

# Configure federation for the domain
New-MgDomainFederationConfiguration -DomainId $domain `
    -ActiveSignInUri "https://sts.corp.lab/adfs/ls/" `
    -IssuerUri "http://sts.corp.lab/adfs/services/trust" `
    -SigningCertificate $certContent `
    -PreferredAuthenticationProtocol "wsFed" `
    -FederationBrandName "Corp Lab ADFS"

PowerShell – Domain federation configuration completed

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

Microsoft 365 Admin Center – Domain status shows Federated

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.

Entra Connect wizard – User sign‑in page with Federation selected

Entra Connect – connecting to existing ADFS farm

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).

Synced users in Microsoft 365 Admin Center

Entra Connect normally creates the Microsoft 365 relying party trust in ADFS automatically. Verify it in 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"

ADFS relying party trust – Microsoft Office 365 Identity Platform

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:

# Add claim rule for ImmutableID (objectGuid → ImmutableID)
$rule = '@RuleName = "ImmutableID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/objectidentifier",
         Value = c.Value);'

Set-AdfsRelyingPartyTrust -TargetName "Microsoft 365" -IssuanceTransformRules $rule

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.

Browser redirect from Office 365 to ADFS login

Office 365 portal after federated login

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

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.

• 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.
• ADFS not reachable from Entra Connect? – Ensure firewall rules allow port 443 from AZCONNECT01 to ADFS01, and that DNS resolution for sts.corp.lab works.

If you need to quickly revert federation to cloud‑managed authentication (or remove the ADFS integration), follow these steps:

9.1 Disable Federation for the Domain

On a machine with the Microsoft Graph PowerShell module installed, run:

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"

# Convert the domain from Federated back to Managed
# Replace with your actual domain
$domain = "corplab.onmicrosoft.com"

Update-MgDomainFederationConfiguration -DomainId $domain `
    -ActiveSignInUri $null `
    -IssuerUri $null `
    -SigningCertificate $null `
    -PreferredAuthenticationProtocol "wsFed" `
    -FederationBrandName $null

Alternatively, use the old MSOnline module (for older tenants):

# Install the module if needed
Install-Module MSOnline -Force
Connect-MsolService

# Convert domain to managed authentication
Set-MsolDomainAuthentication -DomainName $domain -Authentication Managed

9.2 Remove the Relying Party Trust from ADFS

On ADFS01, in PowerShell:

# Remove the Microsoft 365 relying party trust
Remove-AdfsRelyingPartyTrust -TargetName "Microsoft Office 365 Identity Platform" -Confirm:$false

9.3 Uninstall or Pause Entra Connect Sync

On AZCONNECT01, you can open the Entra Connect wizard and choose to Customize → Uninstall or simply stop the sync service:

# Stop the sync service
Stop-Service -Name "ADSync"

# Or disable it from starting automatically
Set-Service -Name "ADSync" -StartupType Disabled

After these steps, users will no longer be redirected to ADFS for Microsoft 365 authentication. They will use cloud authentication (password‑based or password hash sync if configured).