Moving from Federated to Managed Authentication in Azure AD

After dealing with the challenges of maintaining ADFS infrastructure and token signing certificate management, I decided to evaluate moving from federated authentication to managed authentication in Azure AD. This transition would eliminate the dependency on on-premises ADFS servers while still maintaining secure user authentication through cloud-based identity management.

Understanding the Difference: Federated vs Managed

Federated Authentication

Federated domain means that you have set up a federation between your on-premises environment and Azure AD. In this case all user authentication happens on-premises. When a user logs into Azure or Microsoft 365, their authentication request is forwarded to the on-premises AD FS server.

Managed Authentication

A Managed domain, on the other hand, is a domain that is managed by Azure AD and uses Azure AD for authentication. With managed authentication, Azure AD becomes responsible for user authentication, either through Password Hash Synchronization (PHS) or Pass-Through Authentication (PTA).

Pros and Cons Comparison

Aspect	Federated Authentication	Managed Authentication
Infrastructure Complexity	High - Requires ADFS servers, WAP, load balancers, certificates	Low - Cloud-based, minimal on-premises infrastructure
Maintenance Overhead	High - Certificate management, server patching, high availability setup	Low - Microsoft manages infrastructure
Authentication Location	On-premises Active Directory	Azure AD (cloud)
Password Storage	Passwords remain on-premises only	Password hashes synchronized to cloud (PHS) or validated on-premises (PTA)
Single Sign-On (SSO)	Supported with seamless integration	Supported with Azure AD seamless SSO
Customization	High - Custom claims, advanced authentication policies	Limited - Standard Azure AD features
High Availability	Requires redundant ADFS infrastructure	Built-in Azure AD global redundancy
Internet Dependency	Required for external access to federation services	Required for authentication
Cost	High - Server licensing, infrastructure, management	Lower - Reduced infrastructure costs
Security Posture	Federated domain provides a substantial roadblock to threat actors	Good - Modern threat protection, conditional access
User Enumeration Resistance	Setting the domain to federated prevents account enumeration	Vulnerable to account enumeration attacks
Disaster Recovery	Complex - Requires ADFS infrastructure recovery	Simple - Cloud-based resilience
Legacy Application Support	Excellent - Full claims-based authentication	Good - May require application updates

Known Issues and Considerations When Switching

Authentication Timing

When you migrate from federated to cloud authentication, the process to convert the domain from federated to managed may take up to 60 minutes. During this process, users might not be prompted for credentials for any new logins to Microsoft Entra admin center or other browser based applications.

Processing Time for Large Organizations

The process can take approximately 5,000 users per hour, and it can take up to 2 hours for the domain conversion from federated to standard plus an additional hour for every 2000 users.

Based on these Microsoft-documented processing rates, here are estimated conversion times for larger organizations, these are estimated values for illustration purposes

Organization Size	Processing Time	Maintenance Window
5,000 users	1-2 hours	3-4 hours
10,000 users	2-3 hours	4-5 hours
15,000 users	3-4 hours	5-6 hours
20,000 users	4-5 hours	6-7 hours
30,000 users	6-7 hours	8-9 hours

Note: During this process, users might not be prompted for credentials for any new logins to Microsoft Entra admin center or other browser based applications protected with Microsoft Entra ID, so factor this into your user communication strategy.

Password Management

When converting from federated to managed authentication, users will need temporary passwords unless Password Hash Synchronization was already enabled and synchronized.

Application Compatibility

Modern authentication clients (Office 2016 and Office 2013, iOS, and Android apps) use a valid refresh token to obtain new access tokens for continued access to resources instead of returning to AD FS. These clients are immune to any password prompts resulting from the domain conversion process.

Prerequisites Before Converting

1. Enable and Verify Password Hash Synchronization

Before converting to managed authentication, I needed to ensure Password Hash Synchronization was enabled and all passwords were synchronized. Here's how to check and enable this:

Check if Password Hash Synchronization is Already Enabled

Run these PowerShell commands on your Azure AD Connect server:

# Import the ADSync module
Import-Module ADSync

# Check current sync scheduler settings
Get-ADSyncScheduler

# Check Azure AD Connect features to see if Password Hash Sync is enabled
Get-ADSyncAADCompanyFeature

The Get-ADSyncAADCompanyFeature command will show you all enabled features. Look for:

PasswordHashSync: True (indicates Password Hash Synchronization is enabled)

Note : If Password Hash sync is not enabled you can find those instructions at the end of this article before the conclusion, if it is enabled then continue to step 2.

Step 2 : Backup Current Federation Configuration (Critical Step)

Before making any changes, you must backup your current federation configuration. This backup is essential for rollback scenarios:

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

# Backup current federation configuration to a file
$federationConfig = Get-MgDomainFederationConfiguration -DomainId "bythepowerofgreyskull.com"
$federationConfig | ConvertTo-Json -Depth 10 | Out-File 
-FilePath "C:\Backup\FederationConfig_$(Get-Date -Format 'yyyyMMdd_HHmmss').json"

# Also display the configuration for immediate reference
$federationConfig | Format-List

# Save the configuration to variables for potential immediate rollback
Write-Host "=== FEDERATION CONFIGURATION BACKUP ===" -ForegroundColor Green
Write-Host "Save these values for rollback purposes:" -ForegroundColor Yellow
Write-Host "Domain: yourdomain.com" -ForegroundColor White
Write-Host "DisplayName: $($federationConfig.DisplayName)" -ForegroundColor White
Write-Host "IssuerUri: $($federationConfig.IssuerUri)" -ForegroundColor White
Write-Host "PassiveSignInUri: $($federationConfig.PassiveSignInUri)" -ForegroundColor White
Write-Host "ActiveSignInUri: $($federationConfig.ActiveSignInUri)" -ForegroundColor White
Write-Host "SignOutUri: $($federationConfig.SignOutUri)" -ForegroundColor White
Write-Host "MetadataExchangeUri: $($federationConfig.MetadataExchangeUri)" 
-ForegroundColor White
Write-Host "PreferredAuthenticationProtocol: 
$($federationConfig.PreferredAuthenticationProtocol)" -ForegroundColor White
Write-Host "FederatedIdpMfaBehavior: $($federationConfig.FederatedIdpMfaBehavior)" 
-ForegroundColor White
Write-Host "IsSignedAuthenticationRequestRequired: 
$($federationConfig.IsSignedAuthenticationRequestRequired)" -ForegroundColor White
Write-Host "================================================" -ForegroundColor Green

Important: Store this backup file securely and ensure it's accessible during any potential rollback scenarios. The rollback process detailed later in this guide references this saved configuration.

Step 3 : Switching from Federated to Managed

With your federation configuration safely backed up, proceed with the conversion:

# Check current domain authentication type
Get-MgDomain -DomainId "bythepowerofgreyskull.com" | Select-Object AuthenticationType

# Convert domain to managed authentication
Update-MgDomain -DomainId "bythepowerofgreyskull.com.com" -BodyParameter @{
    AuthenticationType = "Managed"
}

# Verify the conversion
Get-MgDomain -DomainId "bythepowerofgreyskull.com" | Format-List AuthenticationType

ADFS Infrastructure Considerations

Warning: Consider planning cutover of domains during off-business hours in case of rollback requirements. The ADFS infrastructure should remain operational for a period after conversion to ensure all authentication tokens have expired and been renewed.

Token Expiration Timeline:

Access tokens typically expire within 1 hour
Refresh tokens can remain valid for up to 90 days (depending on configuration)
Modern authentication clients continue to function without extra configuration during the transition

Warning: Keep ADFS servers running for at least 90 days after conversion to ensure all refresh tokens have expired and been reissued by Azure AD.

Rollback Planning (hopefully not required)

The rollback process should include converting managed domains to federated domains by using the New-MgDomainFederationConfiguration cmdlet. Critical: You must have saved your original federation configuration before converting to managed authentication (see the backup step in the Conversion Commands section above).

# Rollback command (if needed) - restore original federation configuration
# Use the federation configuration backed up during the conversion process

# Step 1: Load your saved federation configuration
$backupFile = "C:\Backup\FederationConfig_YYYYMMDD_HHMMSS.json" 
$originalConfig = Get-Content $backupFile | ConvertFrom-Json

# Step 2: Convert domain back to federated authentication
Update-MgDomain -DomainId "bythepowerofgreyskull.com" -BodyParameter @{
    AuthenticationType = "Federated"
}

# Step 3: Recreate the complete federation configuration using your backed-up settings
$federationConfig = @{
    DisplayName = $originalConfig.DisplayName
    IssuerUri = $originalConfig.IssuerUri
    PassiveSignInUri = $originalConfig.PassiveSignInUri
    ActiveSignInUri = $originalConfig.ActiveSignInUri
    SignOutUri = $originalConfig.SignOutUri
    MetadataExchangeUri = $originalConfig.MetadataExchangeUri
    SigningCertificate = $originalConfig.SigningCertificate
    NextSigningCertificate = $originalConfig.NextSigningCertificate
    PreferredAuthenticationProtocol = $originalConfig.PreferredAuthenticationProtocol
    FederatedIdpMfaBehavior = $originalConfig.FederatedIdpMfaBehavior
    IsSignedAuthenticationRequestRequired = 
    $originalConfig.IsSignedAuthenticationRequestRequired
}

New-MgDomainFederationConfiguration -DomainId "bythepowerofgreyskull.com" 
-BodyParameter $federationConfig

# Step 4: Verify the rollback
Get-MgDomainFederationConfiguration -DomainId "bythepowerofgreyskull.com" | Format-List

Important Rollback Notes:

You must have your original ADFS infrastructure still operational
All federation certificates must still be valid
Reference the backup file created during the backup step earlier in the guide
Test the rollback procedure in a non-production environment first
Ensure the backup file path matches your actual saved configuration file

Enable Password Hash Synchronization (if not already enabled)

If Password Hash Synchronization is not enabled, enable it through the Azure AD Connect wizard:

# Check current connectors
Get-ADSyncConnector

# The output will show your AD and Azure AD connectors, for example:
# Type        Name
# ----        ----
# AD          bear.local
# Extensible2 bearmagic.onmicrosoft.com - AAD

Then run the Azure AD Connect configuration wizard:

Start Azure AD Connect from the Start menu
Select "Configure"
Choose "Customize synchronization options"
Enter your Azure AD global administrator credentials
On the "Optional features" page, ensure "Password hash synchronization" is checked
Complete the wizard configuration

Force a Full Password Synchronization

Warning : Only follow this if password has sync is NOT enabled do you follow this if enabled already.

After enabling Password Hash Synchronization, force a full sync to ensure all passwords are synchronized:

# Get your connector names (case-sensitive)
$adConnector = "yourdomain.local"  # Replace with your AD connector name
$aadConnector = "yourtenant.onmicrosoft.com - AAD"  # Replace with your Azure AD connector

# Import the ADSync module
Import-Module ADSync

# Create a ForceFullPasswordSync parameter
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter 
"Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c

# Disable and re-enable password sync to force full synchronization
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector 
-TargetConnector $aadConnector -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector 
-TargetConnector $aadConnector -Enable $true

# Trigger a delta sync to process the changes
Start-ADSyncSyncCycle -PolicyType Delta

Verify Password Synchronization Status

After the full sync completes, verify that passwords are being synchronized:

# Check the sync cycle status
Get-ADSyncScheduler

# Run password sync diagnostics again
Invoke-ADSyncDiagnostics -PasswordSync

# Check for recent password sync heartbeat (should show recent timestamp)
# Monitor the Application Event Log on the Azure AD Connect server for Event ID 654
# This heartbeat event should appear every 30 minutes when password sync is working

Important Notes:

Password synchronization occurs every 2 minutes for password changes
A heartbeat event (Event ID 654) appears every 30 minutes in the Application log when password sync is healthy
If no passwords have changed recently, you may not see immediate sync activity, but the heartbeat should still be present
The full password sync process can take time for large organizations (approximately 5,000 users per hour)

Conclusion

The move from federated to managed authentication represents a significant simplification of identity infrastructure while maintaining security and user experience. The key to success lies in thorough preparation, particularly ensuring Password Hash Synchronization is working correctly before the conversion.

While federated authentication offers certain security advantages, such as resistance to user enumeration attacks, the operational benefits of managed authentication—including reduced infrastructure complexity, lower maintenance overhead, and improved disaster recovery capabilities—often outweigh these considerations for many organizations.

The conversion process itself is straightforward using Microsoft Graph PowerShell, but the planning and preparation phases are critical for a smooth transition. Keeping ADFS infrastructure operational for 90 days post-conversion ensures a safety net for any unexpected issues while allowing all existing authentication tokens to naturally expire and be renewed by Azure AD.

Moving from Federated to Managed Authentication in Azure AD

Check if Password Hash Synchronization is Already Enabled

Force a Full Password SynchronizationWarning : Only follow this if password has sync is NOT enabled do you follow this if enabled already.

نموذج الاتصال

Force a Full Password Synchronization

Warning : Only follow this if password has sync is NOT enabled do you follow this if enabled already.