Establish SAML 2.0 identity federation between on-premises Active Directory and Azure AD (Microsoft Entra ID) for seamless cross-domain authentication and SSO to cloud applications.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Establish SAML 2.0 identity federation between on-premises Active Directory and Azure AD (Microsoft Entra ID) for seamless cross-domain authentication and SSO to cloud applications.
Identity federation enables users authenticated by one identity provider to access resources managed by another without maintaining separate credentials. This skill covers establishing SAML 2.0 federation between an organization's on-premises Active Directory (via AD FS or third-party IdP) and Microsoft Entra ID (formerly Azure AD), as well as configuring federated SSO for third-party SaaS applications. Federation eliminates password synchronization concerns and keeps authentication authority on-premises while extending SSO to cloud resources.
When to Use
When deploying or configuring building identity federation with saml azure ad capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation
Common Misconfigurations & Verification
Assertion signature not enforced: the SP/relying party accepts an unsigned or SP-signed-only <saml:Assertion>, enabling signature stripping. Verify the IdP signs the assertion (not just the <Response>) and the SP rejects SignatureMethod=rsa-sha1 and unsigned assertions. Test by replaying a captured assertion with the <ds:Signature> removed — it must fail.
Golden SAML exposure: anyone who can export the AD FS token-signing private key can mint assertions for any user. Confirm the key lives in an HSM/DKM-protected store, alert on Set-AdfsCertificate and event 307/510, and rotate after any DC/AD FS compromise.
Audience/recipient not validated: SP ignores <AudienceRestriction> or Recipient, so a token issued for app A is replayed at app B. Verify each SP pins its own EntityID as the required audience.
NameID and NotOnOrAfter: persistent NameID plus missing NotOnOrAfter/NotBefore checks allow indefinite replay. Confirm short assertion lifetimes and that InResponseTo is bound to a real AuthnRequest.
Verification: pull Get-MgDomainFederationConfiguration -DomainId corp.example.com and confirm signingCertificate, issuerUri, and preferredAuthenticationProtocol=saml match AD FS; decode an assertion with SAML-tracer and confirm signed assertion, correct Audience, and a fresh .
NotOnOrAfter
Prerequisites
On-premises Active Directory domain
AD FS 2019+ or third-party SAML IdP (Okta, Ping, etc.)
Microsoft Entra ID tenant (P1 or P2 license recommended)
Azure AD Connect (if using hybrid identity with password hash sync as backup)
Public TLS certificate for federation endpoint
DNS records for federation service name
Core Concepts
Federation Models
Model
Authentication Authority
Use Case
Federated (AD FS)
On-premises AD FS
Regulatory requirement to keep auth on-prem
Managed (PHS)
Azure AD with password hash sync
Simplest cloud auth, AD FS not needed
Managed (PTA)
On-premises via pass-through agent
Cloud auth validated against on-prem AD
Third-Party Federation
External IdP (Okta, Ping)
Multi-IdP environment
SAML Federation Architecture
User → Cloud App (SP)
│
└── Redirect to Azure AD
│
├── Azure AD checks federated domain
│
└── Redirect to on-premises AD FS
│
├── AD FS authenticates against Active Directory
│
├── AD FS issues SAML token
│
└── Token posted back to Azure AD
│
├── Azure AD validates federation trust
│
├── Azure AD issues its own token
│
└── User receives access token for cloud app
Federation Trust Components
Component
Description
Token-Signing Certificate
X.509 certificate used by IdP to sign SAML assertions
Federation Metadata
XML document describing IdP endpoints and capabilities
Relying Party Trust
Configuration in AD FS for each SP (Azure AD)
Claims Rules
Transform AD attributes into SAML claims
Issuer URI
Unique identifier for the IdP (entity ID)
Workflow
Step 1: Prepare AD FS Infrastructure
# Install AD FS role
Install-WindowsFeature ADFS-Federation -IncludeManagementTools
# Configure AD FS farm
Install-AdfsFarm `
-CertificateThumbprint $certThumbprint `
-FederationServiceDisplayName "Corp Federation Service" `
-FederationServiceName "fs.corp.example.com" `
-ServiceAccountCredential $gmsaCredential
# Verify AD FS is operational
Get-AdfsProperties | Select-Object HostName, Identifier, FederationPassiveAddress
Step 2: Configure Azure AD Federated Domain
# Install Microsoft Graph PowerShell module
Install-Module Microsoft.Graph -Scope CurrentUser
# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Domain.ReadWrite.All"
# Convert managed domain to federated
# Using AD FS federation metadata URL
$domainId = "corp.example.com"
$federationConfig = @{
issuerUri = "http://fs.corp.example.com/adfs/services/trust"
metadataExchangeUri = "https://fs.corp.example.com/adfs/services/trust/mex"
passiveSignInUri = "https://fs.corp.example.com/adfs/ls/"
signOutUri = "https://fs.corp.example.com/adfs/ls/?wa=wsignout1.0"
signingCertificate = $base64Cert
preferredAuthenticationProtocol = "saml"
}
# Apply federation settings to domain
New-MgDomainFederationConfiguration -DomainId $domainId -BodyParameter $federationConfig
