使用 SAML Azure AD 建置身分識別同盟

使用 SAML Azure AD 建置身分識別同盟 是做什麼的？

概觀

身分識別同盟讓使用者可經由一個身分提供者（IdP）驗證後，存取另一個提供者管理的資源，而無需維護各自憑證。本技能涵蓋如何在組織的內部部署 Active Directory（透過 AD FS 或第三方 IdP）與 Microsoft Entra ID（原 Azure AD）之間建立 SAML 2.0 同盟，以及設定第三方 SaaS 應用程式的同盟 SSO。同盟消除了密碼同步的顧慮，並將驗證權限保留在內部部署環境，同時將 SSO 擴展至雲端資源。

使用時機

• 在環境中部署或配置使用 SAML Azure AD 建置身分識別同盟功能時
• 建立符合合規要求的安全控制措施時
• 建置或改善此領域的安全架構時
• 執行需要此實作的安全評估時

先決條件

• 內部部署 Active Directory 網域
• AD FS 2019+ 或第三方 SAML IdP（Okta、Ping 等）
• Microsoft Entra ID 租用戶（建議使用 P1 或 P2 授權）
• Azure AD Connect（如果用於混合身分且以密碼雜湊同步作為備援）
• 適用於同盟端點的公開 TLS 憑證
• 同盟服務名稱的 DNS 記錄

核心概念

同盟模型

模型	驗證權限	使用案例
同盟 (AD FS)	內部部署 AD FS	法規要求將驗證保留在內部部署
受控 (PHS)	Azure AD（使用密碼雜湊同步）	最簡單的雲端驗證，無需 AD FS
受控 (PTA)	內部部署（透過傳遞代理程式）	雲端驗證需對內部部署 AD 進行驗證
第三方同盟	外部 IdP（Okta、Ping）	多 IdP 環境

SAML 同盟架構

使用者 → 雲端應用程式 (SP)
   │
   └── 重新導向至 Azure AD
          │
          ├── Azure AD 檢查同盟網域
          │
          └── 重新導向至內部部署 AD FS
                 │
                 ├── AD FS 對 Active Directory 進行驗證
                 │
                 ├── AD FS 簽發 SAML 權杖
                 │
                 └── 權杖傳回 Azure AD
                        │
                        ├── Azure AD 驗證同盟信任
                        │
                        ├── Azure AD 簽發自己的權杖
                        │
                        └── 使用者取得雲端應用程式的存取權杖

同盟信任元件

元件	說明
權杖簽署憑證	IdP 用來簽署 SAML 判斷提示的 X.509 憑證
同盟中繼資料	描述 IdP 端點和功能的 XML 文件
信賴憑證者信任	AD FS 中為每個 SP（Azure AD）建立的設定
宣告規則	將 AD 屬性轉換為 SAML 宣告
簽發者 URI	IdP 的唯一識別碼（實體 ID）

工作流程

步驟 1：準備 AD FS 基礎架構

# 安裝 AD FS 角色
Install-WindowsFeature ADFS-Federation -IncludeManagementTools

# 設定 AD FS 伺服器陣列
Install-AdfsFarm `
    -CertificateThumbprint $certThumbprint `
    -FederationServiceDisplayName "Corp Federation Service" `
    -FederationServiceName "fs.corp.example.com" `
    -ServiceAccountCredential $gmsaCredential

# 驗證 AD FS 是否正常運作
Get-AdfsProperties | Select-Object HostName, Identifier, FederationPassiveAddress

步驟 2：設定 Azure AD 同盟網域

# 安裝 Microsoft Graph PowerShell 模組
Install-Module Microsoft.Graph -Scope CurrentUser

# 連線至 Microsoft Graph
Connect-MgGraph -Scopes "Domain.ReadWrite.All"

# 將受控網域轉換為同盟網域
# 使用 AD FS 同盟中繼資料 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"
}

# 將同盟設定套用至網域
New-MgDomainFederationConfiguration -DomainId $domainId -BodyParameter $federationConfig

步驟 3：設定 AD FS 宣告規則

# 為 Azure AD 新增信賴憑證者信任
Add-AdfsRelyingPartyTrust `
    -Name "Microsoft Office 365 Identity Platform" `
    -MetadataUrl "https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml"

# 設定宣告規則
$rules = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract AD Attributes"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
   Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory",
   types = ("http://schemas.xmlsoap.org/claims/UPN",
            "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
            "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
            "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"),
   query = ";userPrincipalName,mail,givenName,sn;{0}",
   param = c.Value);

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass Through UPN as NameID"
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
   Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer,
   Value = c.Value,
   ValueType = c.ValueType,
   Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"]
       = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent");
"@

Set-AdfsRelyingPartyTrust `
    -TargetName "Microsoft Office 365 Identity Platform" `
    -IssuanceTransformRules $rules

步驟 4：設定第三方 SaaS 同盟

針對每個支援透過 Azure AD 進行 SAML SSO 的 SaaS 應用程式：

1. 瀏覽至 Microsoft Entra 系統管理中心 > 企業應用程式
2. 從資源庫新增應用程式（或建立自訂 SAML 應用程式）
3. 設定單一登入 > SAML：
   • 識別碼 (實體 ID)：應用程式的實體 ID
   • 回覆 URL (ACS)：應用程式的判斷提示取用者服務 URL
   • 登入 URL：應用程式的登入 URL
4. 對應使用者屬性/宣告：
   • NameID：user.userprincipalname (電子郵件格式)
   • 根據應用程式需求新增其他宣告
5. 下載同盟中繼資料 XML 或憑證
6. 使用 Azure AD 的同盟詳細資料設定 SaaS 應用程式

步驟 5：憑證生命週期管理

AD FS 權杖簽署憑證會過期且必須更新：

# 檢查目前憑證到期日
Get-AdfsCertificate -CertificateType Token-Signing | Select-Object Thumbprint, NotAfter

# AD FS 支援自動換用（預設啟用）
Get-AdfsProperties | Select-Object AutoCertificateRollover

# 如需手動輪替：
# 1. 將新憑證新增為次要憑證
Set-AdfsCertificate -CertificateType Token-Signing -Thumbprint $newThumbprint -IsPrimary $false
# 2. 使用新憑證更新 Azure AD
# 3. 升級為主要憑證
Set-AdfsCertificate -CertificateType Token-Signing -Thumbprint $newThumbprint -IsPrimary $true
# 4. 移除舊憑證
Remove-AdfsCertificate -CertificateType Token-Signing -Thumbprint $oldThumbprint

驗證檢查清單

• AD FS 伺服器陣列已正常運作，且具備有效的 TLS 和權杖簽署憑證
• Azure AD 網域已設定為同盟，並包含正確的中繼資料
• 宣告規則能正確將 AD 屬性轉換為 SAML 判斷提示
• 測試使用者能透過同盟流程進行端到端驗證
• 已在 AD FS 或 Azure AD 條件式存取層級強制執行 MFA
• 已啟用憑證自動換用，或已排程手動輪替
• 同盟中繼資料端點可公開存取
• 已設定智慧鎖定以防止暴力攻擊
• 已在 AD FS 上設定外部網路鎖定原則
• 已針對 AD FS 健康狀態和憑證到期設定監控
• 災難復原：已記錄受管驗證的容錯移轉

參考資料

• Microsoft Entra 同盟文件
• AD FS 設計指南
• 設定 AD FS 以進行 Azure AD 同盟
• SAML 2.0 驗證 - OASIS