SAMLとAzure ADによるIDフェデレーション構築 は何をしますか?
概要
IDフェデレーションにより、あるIDプロバイダーで認証されたユーザーが、別のプロバイダーが管理するリソースに、個別の資格情報を維持することなくアクセスできるようになります。このスキルでは、組織のオンプレミスActive Directory(AD FSまたはサードパーティIdP経由)とMicrosoft Entra ID(旧Azure AD)間のSAML 2.0フェデレーションの確立、およびサードパーティSaaSアプリケーション向けのフェデレーションSSOの構成について説明します。フェデレーションにより、パスワード同期に関する懸念が解消され、認証権限をオンプレミスに維持しながら、SSOをクラウドリソースに拡張できます。
使用するタイミング
- 環境にIDフェデレーション(SAML + Azure AD)機能を展開または構成する場合
- コンプライアンス要件に合わせたセキュリティ制御を確立する場合
- このドメインのセキュリティアーキテクチャを構築または改善する場合
- この実装を必要とするセキュリティ評価を実施する場合
前提条件
- オンプレミスのActive Directoryドメイン
- AD FS 2019+、またはサードパーティSAML IdP(Okta、Pingなど)
- Microsoft Entra IDテナント(P1またはP2ライセンス推奨)
- Azure AD Connect(バックアップとしてパスワードハッシュ同期を使用するハイブリッドIDの場合)
- フェデレーションエンドポイント用の公開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ドキュメント |
| 証明書利用者信頼 | 各SP(Azure AD)に対するAD FSの構成 |
| クレームルール | 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アプリケーションに対して:
- Microsoft Entra管理センター > エンタープライズアプリケーションに移動
- ギャラリーからアプリケーションを追加(またはカスタムSAMLを作成)
- シングルサインオン > SAMLを構成:
- 識別子(エンティティID): アプリケーションのエンティティID
- 応答URL (ACS): アプリケーションのアサーションコンシューマサービスURL
- サインオンURL: アプリケーションのログインURL
- ユーザー属性/クレームをマッピング:
- NameID: user.userprincipalname(電子メール形式)
- アプリケーションが必要とする追加のクレーム
- フェデレーションメタデータXMLまたは証明書をダウンロード
- 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アサーションに正しく変換する
- テストユーザーがフェデレーションフロー全体で認証できる
- MFAがAD FSまたはAzure AD条件付きアクセスレベルで強制されている
- 証明書の自動ロールオーバーが有効、または手動ローテーションがスケジュールされている
- フェデレーションメタデータエンドポイントにパブリックアクセス可能
- スマートロックアウトがブルートフォースを防ぐように構成されている
- エクストラネットロックアウトポリシーがAD FSに構成されている
- AD FSの正常性と証明書の有効期限に対する監視が構成されている
- ディザスタリカバリ: マネージド認証フォールバックが文書化されている