您好,
您描述的情境在 AD FS 环境中确实常见:Token-Signing 凭证自动轮转后,若某些 SAML Relying Party Trust 没有设定动态 Federation Metadata URL,而是使用静态 XML,便会因为仍依赖旧凭证而导致验证失败。 解决方式就是导出目前生效的主要 Token-Signing 公钥凭证,并更新这些 static RPT。
在 PowerShell 中,您可以透过 AD FS 模块来精准取得目前 Active 且 Primary 的 Token-Signing 凭证。 以下是一个标准化的脚本范例:
PowerShell
# 匯入 AD FS 模組
Import-Module ADFS
# 取得目前主要的 Token-Signing 憑證
$cert = Get-AdfsCertificate -CertificateType Token-Signing | Where-Object { $_.IsPrimary -eq $true -and $_.IsActive -eq $true }
# 將公鑰憑證匯出為 .cer 檔案(不含私鑰)
Export-Certificate -Cert $cert.Certificate -FilePath "C:\Temp\TokenSigning.cer"
# 驗證輸出
Write-Output "Exported Primary Token-Signing certificate to C:\Temp\TokenSigning.cer"
这样会产生一个标准的 .cer 文件,您可以提供给第三方厂商更新他们的 static RPT。
若要直接更新本机的 static RPT,您可以使用 Set-AdfsRelyingPartyTrust 搭配 -SigningCertificateRevocationCheck None 或 -SignatureAlgorithm 等参数来重新指定凭证。 不过在大多数情况下,第三方应用程序需要您提供 .cer 文件,而不是直接在 AD FS 内部更新。
如果厂商要求以字符串形式提供公钥,您可以将证书转换为 Base64:
PowerShell
$bytes = $cert.Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.Convert]::ToBase64String($bytes) | Out-File "C:\Temp\TokenSigning_Base64.txt"
这样就能产生一个符合常见 SAML Metadata 格式的字符串,方便嵌入到他们的配置文件中。
总结来说,最佳实务是:使用 Get-AdfsCertificate 抓取 Primary + Active 凭证,透过 Export-Certificate 导出 .cer,再依需求提供给 static RPT 或第三方。 这样能确保凭证轮转后,所有依赖方都能正确验证 SAML Assertion。
多米克配音。