When I recently rotated the token signing certificate on my ADFS server, I encountered a familiar challenge that became significantly more complex due to Microsoft's retirement of the MSOnline and AzureAD PowerShell modules. My Server 2012 environment, which previously relied on
Connect-MsolService, could no longer perform this critical federation maintenance task.The Problem
Microsoft announced the retirement of the MSOnline and AzureAD PowerShell modules, with full deprecation taking effect. This left many administrators with older server environments unable to update their federated domain configurations using traditional methods.
The specific issue I faced was:
- ADFS server running on Server 2012 with limited PowerShell capabilities
- New token signing certificate installed and active in ADFS
- Azure AD still configured with the old certificate thumbprint
- Users experiencing authentication failures due to certificate mismatch
- No access to newer PowerShell versions or Microsoft Graph modules on the ADFS server
ADFS Server Configuration - What I Could Do Locally
Despite the limitations with connecting to Azure AD, I was able to perform all the necessary certificate management tasks directly on the ADFS server using the built-in ADFS PowerShell snap-in:
Certificate Rollover Configuration
First, I re-enabled automatic certificate rollover to allow ADFS to manage certificate rotation:
Set-ADFSProperties -AutoCertificateRollover $true
Immediate Certificate Generation
To force the generation of new self-signed certificates immediately (rather than waiting for the scheduled rollover):
Update-AdfsCertificate -Urgent
Important Note: This command causes a brief ADFS service outage as all relying parties must update their configuration to expect the new certificates. I performed this during off-peak hours to minimise user impact - unless you are dealing with a high priority incident in which case you have no choice.
Force activation of new certificates
# Force immediate update to both certificate types
Update-AdfsCertificate -CertificateType Token-Decrypting -Urgent
Update-AdfsCertificate -CertificateType Token-Signing -Urgent
# Optionally disable auto-rollover after setting long-term certificates
Set-ADFSProperties -AutoCertificateRollover $false
The Command That No Longer Works
Previously, the final step would have been straightforward using the MSOnline module:
# This command FAILED due to module deprecation
Connect-MsolService
Update-MsolFederatedDomain -DomainName bythepowerofgreyskull.com -SupportMultipleDomain
This single command failure led to formulating options and long periods of diagnostics and research to find the correct modern syntax, ultimately revealing that the entire MSOnline module infrastructure was no longer functional.
Updating the Azure Federation Metadata
Microsoft Graph is the strategic API platform for all Microsoft 365 and Azure AD operations, so lets get cracking with the update the metadata using Graph API calls.
Step 1: Get the Current Federation Configuration
First, I connected to Microsoft Graph from my admin workstation to retrieve the current federation settings:
# Connect with appropriate permissions
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
# Get current federation configuration to retrieve the InternalDomainFederationId
Get-MgDomainFederationConfiguration -DomainId "bythepowerofgreyskull.com"
This command returned the current federation settings, including the critical InternalDomainFederationId that I would need for the update:
Id : 2943b503d-3515-4afd-2b6a-6ffcf89b8fb2
IssuerUri : http://adfs.bythepowerofgreyskull.com/adfs/services/trust
MetadataExchangeUri : https://adfs.bythepowerofgreyskull/adfs/services/trust/mex
SigningCertificate : [OLD_CERTIFICATE_STRING]
...
Step 2: Extract the New Certificate from ADFS
On my ADFS server, I needed to extract the full certificate content (not just the thumbprint) because Microsoft Graph requires the complete base64-encoded certificate:
# Get the new token signing certificate
$cert = Get-AdfsCertificate -CertificateType Token-Signing |
Where-Object {$_.IsPrimary -eq $true}
# Convert to base64 string format required by Microsoft Graph
$certString = [Convert]::ToBase64String($cert.Certificate.RawData)
# Display the certificate string for use in the update command
Write-Output "New Certificate String:"
Write-Output $certString
Important Note: Microsoft Graph PowerShell requires the full certificate content, not just the thumbprint that was accepted by the legacy MSOnline module.
Step 3: Update the Federation Configuration
Back on my admin workstation with Microsoft Graph PowerShell, I updated the federation configuration with the new certificate:
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
# Define the new certificate (obtained from Step 2)
$newCertificate = "MIICXjCCAcegAwIBAgIQ..." # Full base64 certificate string from ADFS
# Create federation settings with all required parameters
$federationSettings = @{
InternalDomainFederationId = "285b503d-3515-4afd-9b6a-6ffcf87b8fb4" # From Step 1
ActiveSignInUri = "https://adfs.bythepowerofgreyskull.com/adfs/ls/"
FederationBrandName = "Bear Central"
IssuerUri = "http://adfs.bythepowerofgreuskull.com/adfs/services/trust"
MetadataExchangeUri = "https://adfs.bythepowerofgreyskull.com/adfs/services/trust/mex"
NextSigningCertificate = $newCertificate
PassiveSignInUri = "https://adfs.bythepowerofgreyskull.com/adfs/ls/"
SigningCertificate = $newCertificate
}
# Apply the update
Update-MgDomainFederationConfiguration -DomainId "bythepowerofgreyskull.com"
-BodyParameter $federationSettings
The Critical Certificate Format Issue
One of the most significant challenges I encountered was understanding the fundamental difference in how certificates are handled between the legacy and modern PowerShell modules.
What I Initially Tried (Thumbprint Approach)
Coming from the MSOnline module experience, I initially attempted to use the certificate thumbprint, as this was the standard approach with the deprecated commands:
# This was my first attempt - using the thumbprint like in legacy modules
$newThumbprint = "16171CF5BF57A4537CE040DBE6F0A826525C1E1F"
$federationSettings = @{
SigningCertificate = $newThumbprint
NextSigningCertificate = $newThumbprint
# ... other parameters
}
Update-MgDomainFederationConfiguration -DomainId "bythepowerofgreyskull.com"
-BodyParameter $federationSettings
The Error That Revealed the Problem
This approach immediately failed with a specific error that initially seemed cryptic:
Update-MgDomainFederationConfiguration : Invalid value specified for property
'signingCertificate' of resource 'InternalDomainFederation'.
Status: 400 (BadRequest)
ErrorCode: Request_BadRequest
The error message didn't explicitly state that the certificate format was wrong, which led to initial confusion about what exactly was invalid about the thumbprint value.
Full Base64 Certificate Required
After research and testing, I discovered that Microsoft Graph PowerShell requires the complete certificate content in base64 format, not just the identifying thumbprint. Here's the correct approach:
# On the ADFS server - extract the FULL certificate content
$cert = Get-AdfsCertificate -CertificateType Token-Signing | Where-Object
{$_.IsPrimary -eq $true}
$certString = [Convert]::ToBase64String($cert.Certificate.RawData)
# The certificate string looks like this (truncated for display):
# MIICXjCCAcegAwIBAgIQJ8+9Z3v3v3v3v3v3v3v3v3v3v3...
# Instead of just: 16171CF5BF57A4537CE040DBE6F0A826525C1E1FTroubleshooting Common Issues
"Invalid value specified for property 'signingCertificate'" Error
This error typically occurs when providing a certificate thumbprint instead of the full certificate content. Ensure you're using the complete base64-encoded certificate string from Step 2.
Missing InternalDomainFederationId
If you receive prompts for InternalDomainFederationId, run the Get-MgDomainFederationConfiguration command first to retrieve this value from your current configuration.
PowerShell Version Compatibility
Microsoft Graph PowerShell modules require PowerShell 5.1 or PowerShell 7+. They cannot be installed on older PowerShell versions typically found on Server 2012 systems.
Conclusion
The retirement of MSOnline and AzureAD PowerShell modules initially seemed like a significant obstacle for maintaining ADFS federation in older server environments, however from an remote workstation I was able to successfully able to update the token signing certificate and restore user authentication.
This approach provides a sustainable path forward for organizations that need to maintain ADFS federation while transitioning away from deprecated PowerShell modules, even when working with legacy server infrastructure and it worked this last time with the legacy command in 2 years ago.