Converting a Microsoft 365 Domain from Federated to Managed Using Microsoft Graph (The Right Way)

by

Introduction

Microsoft has officially deprecated legacy PowerShell modules such as MSOL and AzureAD. While these modules may still load in some environments, they are no longer supported, unreliable, and increasingly broken due to backend authentication changes.

The only supported path forward for tenant and domain management today is Microsoft Graph PowerShell — but only if it is installed and executed correctly.

This blog documents a real-world troubleshooting journey while converting a Microsoft 365 domain from Federated to Managed authentication. It includes:

  • What Microsoft documentation suggests
  • What we tried first (and why it failed)
  • Every major error encountered
  • The real root cause (not a backend issue)
  • The final working solution
  • Verified Microsoft Graph commands that actually work

If you’re stuck seeing strange Graph authentication errors or partial results, this post will save you hours.

Scenario Overview

Goal:
Convert a custom Microsoft 365 domain from Federated authentication (ADFS) to Managed authentication (Password Hash Sync / Cloud Auth).

Example domain used in this blog:
domain.com (placeholder — replace with your actual domain)

Why MSOL and AzureAD Are No Longer an Option

Historically, admins used commands like:

Connect-MsolService
Convert-MsolDomainToStandard

Problems with MSOL Today

  • ❌ MSOL uses legacy authentication
  • ❌ Fails with modern tenants
  • ❌ Blocked by Conditional Access
  • ❌ Unsupported by Microsoft
  • ❌ Random errors like:
The HTTP request was forbidden with client authentication scheme 'Negotiate'

Conclusion:
👉 MSOL is dead. Even if it loads, do not use it.

Microsoft’s Current Recommendation

Microsoft officially recommends Microsoft Graph PowerShell with delegated permissions:

  • Domain.ReadWrite.All
  • Directory.AccessAsUser.All

This aligns with Microsoft’s Graph-first strategy.

Step 1 – Verify Password Hash Synchronization (Required)

Before converting a domain, Password Hash Sync must be enabled.

Run on the Azure AD Connect server:

Import-Module ADSync
Get-ADSyncAADCompanyFeature

Expected output:

PasswordHashSync : True

If this is False, stop here and enable Password Hash Sync before proceeding.

Step 2 – Back Up Federation Configuration (Critical)

Always back up the federation configuration before making changes.

Connect-MgGraph -Scopes "Domain.ReadWrite.All","Directory.AccessAsUser.All"

$federationConfig = Get-MgDomainFederationConfiguration -DomainId "domain.com"
$federationConfig | ConvertTo-Json -Depth 10 | Out-File "C:\Backup\FederationConfig.json"

This backup allows rollback if needed.

Step 3 – What We Tried First (And Why It Failed)

Attempt 1: Connect to Microsoft Graph

Connect-MgGraph -Scopes Domain.ReadWrite.All

Error:

Could not load type 'Microsoft.Identity.Client.IMsalSFHttpClientFactory'

Attempt 2: Device Code Authentication

Connect-MgGraph -Scopes Domain.ReadWrite.All -UseDeviceCode

Error:

DeviceCodeCredential authentication failed:
Object reference not set to an instance of an object

Step 4 – Symptoms That Caused Confusion

Even though authentication appeared successful:

Get-MgContext

Returned valid scopes and account info, but every Graph call failed:

Get-MgDomain
Update-MgDomain
Get-MgDomainFederationConfiguration
Invoke-MgGraphRequest

All failed with:

DeviceCodeCredential authentication failed:
Object reference not set to an instance of an object

This looked like a Microsoft backend issue — but it wasn’t.

The Real Root Cause (Important)

This was NOT:

  • ❌ A tenant issue
  • ❌ A domain issue
  • ❌ A Microsoft backend outage

✅ Actual Root Cause

A broken local PowerShell environment:

  • Windows PowerShell 5.1
  • Old .NET Framework
  • Mixed Microsoft.Graph module versions
  • Leftover AzureAD / MSOL assemblies
  • Partial Graph SDK dependency loading

Microsoft Graph requires PowerShell 7+ for full, stable functionality.

The Fix (This Is the Key Part)

Step 1 – Remove All Old Graph & Legacy Modules

Get-Module Microsoft.Graph* -ListAvailable | Uninstall-Module -Force
Get-Module AzureAD* -ListAvailable | Uninstall-Module -Force
Get-Module MSOnline* -ListAvailable | Uninstall-Module -Force

Restart the system.

Step 2 – Install PowerShell 7

Download and install PowerShell 7.x (pwsh):

👉Install PowerShell on Windows – PowerShell | Microsoft Learn

Verify:

$PSVersionTable.PSVersion

Expected:

Major  Minor
7      x

Step 3 – Install Microsoft Graph Cleanly

Run inside PowerShell 7 / windows powershell:

Install-Module microsoft.graph -Scope Allusers -Verbose -Force

Step 4 – Connect to Microsoft Graph (Working)

Connect-MgGraph -Scopes "Domain.ReadWrite.All","User.Read.All"

✅ Authentication succeeds
✅ No hidden dependency failures

Step 5 – Validate Graph Connectivity

Get-MgUser

If users return → Graph is healthy.

Get-MgDomain

Example output:

domain.com                  Federated
sub.domain.com              Federated
tenant.onmicrosoft.com      Managed

Step 6 – Convert Domain from Federated to Managed

Final Working Command

Update-MgDomain -DomainId "domain.com" -AuthenticationType Managed

No password file.
No MSOL.
No ADFS dependency.

Step 7 – Verify Conversion

Get-MgDomain

Expected:

domain.com                  Managed
sub.domain.com              Managed

🎉 Conversion successful.

Step 8 – Blank Sign-In Page After Federation Removal (Correct Root Cause & Fix)

After converting the domain from Federated to Managed, sign-in testing was performed using a user account such as:

user@domain.com

Issue Observed

  • Username is accepted
  • Microsoft sign-in page loads
  • Next screen is blank
    • No password field
    • No MFA prompt
    • No error message
    • No way to proceed

At first glance, this looks like a broken authentication flow.

Why This Happens (Actual Root Cause)

This issue occurs because Microsoft Entra ID does not yet have a valid password hash for the user at the time of sign-in.

This situation typically happens when:

  • The domain was previously Federated (ADFS)
  • Users authenticated only via ADFS
  • Password Hash Synchronization was enabled, but:
    • A full or initial sync had not completed
    • Or the last password sync was stale
  • The domain was switched to Managed before Entra ID had usable password data

So when the user signs in:

Entra ID knows who the user is, but does not yet have how to authenticate them.

Because of this, the authentication UI cannot render:

  • A password box
  • An MFA prompt
  • Or a continuation step

Result: Blank sign-in screen

Important Clarification

This is not caused by:

  • ❌ Microsoft Graph
  • ❌ Conditional Access
  • ❌ MFA misconfiguration
  • ❌ Browser or cache issues
  • ❌ Microsoft backend outage

This is a timing and synchronization issue between Azure AD Connect and Entra ID.

Correct Fix – Run Initial Sync of Azure AD Connect

Instead of forcing password resets, the correct and clean fix is to ensure Entra ID receives password hashes from on-prem Active Directory.

Step 9 Fix (Recommended and Implemented)

1. Run Initial Sync on the Azure AD Connect Server

On the Azure AD Connect server, open PowerShell as Administrator and run:

Start-ADSyncSyncCycle -PolicyType Initial

This forces:

  • Full directory sync
  • Full Password Hash Synchronization

2. Wait for Synchronization to Complete

After running the initial sync:

  • Wait 20–30 minutes
  • Allow password hashes to:
    • Sync from on-prem AD
    • Be processed by Microsoft Entra ID
    • Become available for authentication

This delay is normal and expected.

What Happens After the Sync

Once password hashes are synced:

  • Password field appears correctly
  • MFA prompt is displayed (if configured)
  • Users can sign in normally
  • No password reset is required
  • No user impact beyond the short wait time

Verification Steps

After waiting ~30 minutes:

  1. Browse to: https://login.microsoftonline.com
  2. Enter user@domain.com
  3. Confirm:
    • Password prompt appears
    • MFA works
    • Sign-in completes successfully

Why This Fix Is Better Than Password Resets

MethodImpactRecommended
Force password resetDisrupts users❌ No
Bulk password resetHigh risk❌ No
AAD Connect Initial SyncSeamless✅ Yes

Key Takeaway from Step 9

Domain conversion is instant. Password readiness is not.

Azure AD Connect must complete a successful password hash sync before Managed authentication can work as expected.

High-Level Timeline

T0 ────────────────┬──────────────────┬──────────────────┬──────────────────┬───────────
                   │                  │                  │                  │
Enable Password    Domain switched     Azure AD Connect   Password hashes     Users can
Hash Sync          to Managed          Initial Sync       available in        sign in
(AAD Connect)      (Microsoft Graph)   (Forced)           Entra ID             normally
                   │                  │                  │
                   │                  │                  │
                   │                  │                  └── 20–30 min delay
                   │                  │
                   │                  └── Start-ADSyncSyncCycle -PolicyType Initial
                   │
                   └── Update-MgDomain -AuthenticationType Managed

Detailed Timeline Breakdown

TimeActionResult
T0Password Hash Sync enabledNo immediate user impact
T1Domain converted to ManagedADFS no longer used
T2Users attempt sign-inBlank screen (expected)
T3Initial AAD Connect syncPassword hashes sent
T4 (~30 min)Entra ID processes hashesPassword & MFA prompts appear
T5Normal sign-in restoredMigration complete

Final Lesson Learned

When converting from Federated → Managed authentication:

  1. Enable Password Hash Sync
  2. Convert domain using Microsoft Graph
  3. Run Initial Sync
  4. Wait 30 minutes
  5. Then test user sign-in

!!! THANKS FOR READING !!!

Regards,
HARISH KUMAR

Knowledge is not a finite resource to hoard; it’s a boundless treasure that grows when shared

Leave a Comment