Active Directory フェデレーション サービスを保護するためのベスト プラクティス

• 適用対象:

  ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

このドキュメントでは、Active Directory フェデレーション サービス (AD FS) と Web アプリケーション プロキシ (WAP) のセキュリティを考慮した設計と展開のベスト プラクティスについて説明します。 追加のセキュリティ構成、特定のユース ケース、およびセキュリティ要件についての推奨事項が含まれています。

このドキュメントは、AD FS、および Windows Server 2012 R2、2016、および 2019 の WAP に適用されます。 これらの推奨事項は、オンプレミスのネットワークまたは Microsoft Azure などのクラウドでホストされる環境のいずれかに使用できます。

標準の展開トポロジ

オンプレミス環境での展開では、次で構成される標準の展開トポロジをお勧めします。

• 社内ネットワーク上の 1 つ以上の AD FS サーバー
• DMZ またはエクストラネット ネットワーク内の 1 つ以上の Web アプリケーション プロキシ (WAP) サーバー。

各レイヤー、AD FS および WAP では、ハードウェアまたはソフトウェアのロード バランサーがサーバー ファームの前に配置され、トラフィック ルーティングが処理されます。 ファイアウォールは、必要に応じて、ロード バランサーの外部 IP アドレスの前に配置されます。

注意

AD FS には、読み取り専用ドメイン コントローラーではなく、完全に書き込み可能なドメイン コントローラーを機能させる必要があります。 計画されたトポロジに読み取り専用ドメイン コントローラーが含まれている場合は、読み取り専用ドメイン コントローラーを認証に使用できますが、LDAP 要求の処理には書き込み可能なドメイン コントローラーへの接続が必要です。

AD FS サーバーのセキュリティ強化

以下は、AD FS の展開の強化とセキュリティ保護に関するベスト プラクティスと推奨事項の一覧です。

• Active Directory 管理者と AD FS管理者のみが AD FS システムに対する管理者権限を持つようにします。
• すべての AD FS サーバーでローカル Administrators グループのメンバーシップを減らします。
• すべてのクラウド管理者に多要素認証 (MFA) の使用を要求します。
• エージェントによる最小限の管理機能。
• ホスト ファイアウォールを介したネットワーク上のアクセスを制限します。
• AD FS 管理者が管理者ワークステーションを使用して資格情報を保護するようにします。
• 他のサーバーもホストしない上位 OU に AD FS サーバー コンピューター オブジェクトを配置します。
• AD FS サーバーに適用されるすべての GPO は、他のサーバーにも適用されるのではなく、そのサーバーにのみ適用する必要があります。 これにより、GPO の変更による潜在的な特権のエスカレーションが制限されます。
• インストールされている証明書が盗難から保護されていることを確認し (ネットワーク上の共有フォルダに保存しない)、有効期限が切れる前に更新されるカレンダー リマインダーを設定します (証明書の有効期限が切れるとフェデレーション認証が解除されます)。 さらに、AD FS にアタッチされているハードウェア セキュリティ モジュール (HSM) で署名キー/証明書を保護することをお勧めします。
• ログ記録を最高レベルに設定し、AD FS (およびセキュリティ) ログを SIEM に送信して、AD 認証や AzureAD (または同等のもの) と関連付けます。
• 必要のないプロトコルと Windows の機能を削除します。
• AD FS サービス アカウントに長い (>25 文字) 複雑なパスワードを使用します。 グループ管理サービス アカウント (gMSA) をサービス アカウントとして使用することをお勧めします。これは、サービス アカウントのパスワードを自動的に管理することで、時間の時間をかけてサービス アカウントのパスワードを管理する必要がなくなります。
• セキュリティとログ記録の改善のため最新バージョンの AD FS に更新します (常に、最初にテストします)。

必要なポート

次の図は、 AD FS と WAP の展開のコンポーネント間で有効にする必要があるファイアウォールを示しています。 デプロイに Microsoft Entra ID/Office 365 が含まれない場合、同期要件は無視できます。

Note

ポート 49443 は、ユーザー証明書認証が使用されている場合にのみ必要であり、Microsoft Entra ID と Office 365 ではオプションです。

注意

ポート 808 (Windows Server 2012R2) またはポート 1501 (Windows Server 2016 以降) は Net. TCP ポート AD FS であり、ローカル WCF エンドポイントで構成データをサービス プロセスと PowerShell に転送するために使われます。 このポートは、Get-AdfsProperties | select NetTcpPort を実行して確認できます。 これは、ファイアウォールで開く必要はないものの、ポート スキャンに表示されるローカル ポートです。

フェデレーション サーバー間の通信

AD FS ファーム上のフェデレーション サーバーは、構成の同期のために HTTP ポート 80 を介して、ファーム内の他のサーバーおよび Web アプリケーション プロキシ (WAP) サーバーと通信します。 これらのサーバーだけを相互に通信可能にし、それ以外のサーバーと通信できないようにすることは、堅牢な防御手段です。

組織は、各サーバーにファイアウォール規則を設定することで、この状態を実現できます。 規則では、ファーム内のサーバーおよび WAP サーバーの IP アドレスからの受信通信のみを許可するようにします。 一部のネットワーク ロード バランサー (NLB) では、個々のフェデレーション サーバーの正常性を調べるために HTTP ポート 80 が使われます。 構成されているファイアウォール規則に NLB の IP アドレスを含める必要があります。

Microsoft Entra Connect とフェデレーション サーバー/WAP

この表には、Microsoft Entra Connect サーバーとフェデレーション/WAP サーバーとの間の通信に必要なポートとプロトコルが記載されています。

Protocol	Port	説明
HTTP	80 (TCP/UDP)	SSL 証明書を検証するための CRL (証明書失効リスト) をダウンロードするために使用されます。
HTTPS	443 (TCP/UDP)	Microsoft Entra ID と同期するために使用されます。
WinRM	5985	WinRM リスナー。

WAP サーバーとフェデレーション サーバー

この表は、フェデレーション サーバーと WAP サーバー間の通信に必要なポートとプロトコルについて説明しています。

Protocol	Port	説明
HTTPS	443 (TCP/UDP)	認証で使用されます。

WAP とユーザー

この表は、ユーザーと WAP サーバー間の通信に必要なポートとプロトコルについて説明しています。

Protocol	Port	説明
HTTPS	443 (TCP/UDP)	デバイスの認証で使用されます。
TCP	49443 (TCP)	証明書の認証で使用されます。

ハイブリッド展開に必要なポートとプロトコルについては、ハイブリッド参照接続ポートに関する記事をご覧ください。

Microsoft Entra ID と Office 365 のデプロイに必要なポートとプロトコルについては、「Office 365 の URL と IP アドレスの範囲」を参照してください。

有効化されているエンドポイント

AD FS と WAP がインストールされている場合、AD FSエンドポイントの既定 セットがフェデレーション サービスとプロキシで有効になります。 これらの既定値は、最も一般的に必要で使用されるシナリオに基づいて選択され、変更する必要はありません。

Microsoft Entra ID/Office 365 に対して有効になっているエンドポイント プロキシの最小セット (オプション)

Microsoft Entra ID と Office 365 のシナリオでのみ AD FS と WAP をデプロイしている組織では、プロキシで有効になっている AD FS エンドポイントの数をさらに制限して、攻撃面をより小さくすることができます。 次のシナリオでは、プロキシで有効にする必要があるエンドポイントの一覧を示します:

エンドポイント	目的
/adfs/ls/	ブラウザー ベースの認証フローと現在のバージョンの Microsoft Office では、Microsoft Entra ID および Office 365 の認証にこのエンドポイントを使用します
/adfs/services/trust/2005/usernamemixed	Office 2013 May 2015 より古い Office クライアントで Exchange Online に使用されます。 後のクライアントは、パッシブ \adfs\ls エンドポイントを使用します。
/adfs/services/trust/13/usernamemixed	Office 2013 May 2015 より古い Office クライアントで Exchange Online に使用されます。 後のクライアントは、パッシブ \adfs\ls エンドポイントを使用します。
/adfs/oauth2/	AD FS に対して直接 (つまり、Microsoft Entra ID 経由ではなく) 認証を行うように構成された最新のアプリ (オンプレミスまたはクラウド) で使用されます
/adfs/services/trust/mex	Office 2013 May 2015 より古い Office クライアントで Exchange Online に使用されます。 後のクライアントは、パッシブ \adfs\ls エンドポイントを使用します。
/federationmetadata/2007-06/federationmetadata.xml	パッシブ フローの要件。AD FS セキュリティ証明書を確認するために Office 365/Microsoft Entra ID によって使用されます。

以下の PowerShell コマンドレットを使用して、プロキシで AD FS エンドポイントを無効にすることができます:

Set-AdfsEndpoint -TargetAddressPath <address path> -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/certificatemixed -Proxy $false

認証に対する保護の強化

認証の拡張保護は、中間者 (MITM) 攻撃を軽減する機能であり、既定では AD FS で有効になっています。 設定は、次の PowerShell コマンドレットを使用して確認できます。

Get-ADFSProperties

プロパティは ExtendedProtectionTokenCheck です。 既定の設定は [許可] で、この機能をサポートしないブラウザーとの互換性を考慮せずにセキュリティ上の利点を実現できます。

フェデレーション サービスを保護するための輻輳制御

フェデレーション サービス プロキシ (WAP の一部) は、要求のあふれから AD FS サービスを保護するための輻輳制御を提供します。 Web アプリケーション プロキシとフェデレーション サーバー間の待ち時間によって、フェデレーション サーバーの過負荷状態が検出されると、Web アプリケーション プロキシは外部クライアントの認証要求を拒否します。 この機能は、推奨される待機時間のしきい値レベルで既定で構成されます。 設定を確認するには、次の操作を行います:

1. Web アプリケーション プロキシ コンピューターで、管理者特権のコマンド ウィンドウを起動します。
2. %WINDIR%\adfs\config にある AD FS ディレクトリに移動します。
3. 輻輳制御の設定を、既定値から <congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" /> に変更します。
4. ファイルを保存して閉じます。
5. net stop adfssrv および net start adfssrv を順に実行して、AD FS サービスを再起動します。

この機能のガイダンスについては、「Windows Server 2012 R2 上の AD FS に対してエクストラネット アクセスを構成する」をご覧ください。

プロキシでの標準 HTTP 要求チェック

プロキシでは、すべてのトラフィックに対して次の標準チェックも実行されます:

• FS-P 自体は、短期間の証明書に対して AD FS に認証を行います。 DMZ サーバーの侵害の疑いがあるシナリオでは、AD FS は"プロキシ信頼を取り消す" 可能性のあるプロキシからの受信要求を信頼しなくなる可能性があります。 プロキシ信頼を取り消すと、AD FS サーバーに対して任意の目的で正常に認証行うとができないように、各プロキシの独自の証明書が取り消されます。
• FS-P は、すべての接続を終了し、内部ネットワーク上の AD FS サービスへの新しい HTTP 接続を作成します。 これにより、外部デバイスと AD FS サービス間のセッション レベルのバッファーが提供されます。 外部デバイスは、AD FS サービスに直接接続しません。
• FS-P は、HTTP 要求の検証を実行します。この検証では、具体的に AD FS サービスに必要ない HTTP ヘッダーがフィルターされます。

推奨されるセキュリティ構成

すべての AD FS と WAP サーバーが最新の更新プログラムを確実に受け取るようにします。 AD FS インフラストラクチャのセキュリティに関して最も重要な推奨事項は、すべてのセキュリティ更新プログラムと、このページで AD FS に対して重要であると指定されているオプションの更新プログラムで、AD FS と WAP サーバーを最新の状態に保つ手段を設けることです。

Microsoft Entra のお客様がインフラストラクチャを監視して最新の状態に保つのに推奨される方法は、AD FS で Microsoft Entra Connect Health (Microsoft Entra ID P1 または P2 の機能) を使用することです。 Microsoft Entra Connect Health には、AD FS または WAP マシンに特に AD FS と WAP に関する重要な更新プログラムの 1 つが欠落している場合にトリガーされるモニターとアラートが含まれています。

AD FS における正常性の監視の詳細については、「Microsoft Entra Connect Health エージェントのインストール」を参照してください。

AD FS と Microsoft Entra ID との間の信頼関係にセキュリティを確保し、それを監視するためのベスト プラクティス

AD FS と Microsoft Entra ID との間でフェデレーションを行う際は、フェデレーション構成 (AD FS と Microsoft Entra ID との間で構成された信頼関係) を注意深く監視し、異常なアクティビティや不審なアクティビティを取り込むことが欠かせません。 そのためにはアラートを設定して、フェデレーション構成に変更が加えられるたびに通知を受け取することをお勧めします。 アラートの設定方法については、フェデレーションの構成に対する変更の監視に関する記事をご覧ください。

追加のセキュリティ構成

次の追加機能を構成することで、保護を強化できます。

アカウントのエクストラネット "ソフト" ロックアウト保護

Windows Server 2012 R2 のエクストラネット ロックアウト機能を使用すると、AD FS 管理者は、失敗した認証要求の最大許容数 (ExtranetLockoutThreshold) と observation window の期間 (ExtranetObservationWindow) を設定できます。 この認証要求の最大数 (ExtranetLockoutThreshold) に達すると、AD FS は、設定された期間 (ExtranetObservationWindow) の AD FS に対して、指定されたアカウント資格情報の認証の試みを停止します。 このアクションにより、AD アカウントのロックアウトからこのアカウントが保護されます。つまり、このアカウントは、ユーザーの認証に AD FS に依存する企業リソースへのアクセスを失うのを保護します。 これらの設定は、AD FS サービスが認証できるすべてのドメインに適用されます。

次の Windows PowerShell コマンドを使用して、AD FS エクストラネット ロックアウトを設定できます (例):

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

この機能について詳しくは、「AD FS のエクストラネット ロックアウトの構成」をご覧ください。

エクストラネットからのプロキシで WS-Trust Windows エンドポイントを無効にする

WS-Trust Windows エンドポイント (/adfs/services/trust/2005/windowstransport および /adfs/services/trust/13/windowstransport) は、HTTPS で WIA バインディングを使用するイントラネットに接続するエンドポイントのみを意図しています。 それらをエクストラネットに公開すると、これらのエンドポイントに対する要求によってロックアウトの保護がバイパスされる可能性があります。 次の PowerShell コマンドを使用して AD アカウントのロックアウトを保護するには、プロキシでこれらのエンドポイントを無効にする必要があります (エクストラネットから無効にする)。 プロキシでこれらのエンドポイントを無効にすることで、エンド ユーザーに既知の影響はありません。

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false

Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false

注意

AD FS ファームが Windows 内部データベース (WID) 上で実行され、セカンダリ AD FS サーバーがある場合は、プライマリ サーバーでエンドポイントを無効にした後、セカンダリ ノードで SYNC が発生するのを待って、AD FS サービスを再起動します。 セカンダリ ノードで PowerShell コマンド Get-AdfsSyncProperties を使用して、最後の SYNC プロセスを追跡します。

イントラネット アクセスとエクストラネット アクセスのアクセス ポリシーを区別する

AD FS には、ローカルの企業ネットワークから送信される要求と、プロキシ経由でインターネットから送信される要求のアクセス ポリシーを区別する機能があります。 この区別は、アプリケーションごとに、またはグローバルに実現できます。 ビジネス価値の高いアプリケーションや機密情報を含むアプリケーションでは、多要素認証を要求することを検討してください。 多要素認証は、AD FS 管理スナップインを使用して設定できます。

多要素認証 (MFA) の要求

AD FS は、特にプロキシ経由で送信される要求、個々のアプリケーション、および Microsoft Entra ID/Office 365 リソースとオンプレミス リソースの両方への条件付きアクセスに対して、強力な認証 (多要素認証など) を必要とするように構成できます。 MFA のサポート方式には、Microsoft Azure MFA と第三者プロバイダーの両方が含まれます。 ユーザーは追加情報 (ワンタイム コードを含む SMS テキストなど) を入力するように求め、AD FS はプロバイダー固有のプラグインと一緒にアクセスを許可します。

サポートされている外部 MFA プロバイダーには、「AD FS の追加認証方法を構成する」ページに記載されているものが含まれます。

Microsoft Entra ID とのフェデレーション時にクラウド Microsoft Entra 多要素認証がバイパスされないように保護を有効にする

保護を有効にして Microsoft Entra ID とのフェデレーション時にクラウド Microsoft Entra MFA のバイパスを防ぎ、フェデレーション ユーザーの多要素認証として Microsoft Entra 多要素認証を使用します。

Microsoft Entra テナントでフェデレーション ドメインの保護を有効にすると、フェデレーション ユーザーが MFA を必要とする条件付きアクセス ポリシーによって管理されるアプリケーションにアクセスするときに、Microsoft Entra 多要素認証が必ず実行されます。 これには、オンプレミスの MFA が実行されていることをフェデレーション ID プロバイダーが示した (フェデレーション トークン クレーム経由) 場合でも、Microsoft Entra 多要素認証を実行することが含まれます。 Microsoft Entra 多要素認証を毎回実施すると、侵害されたオンプレミス アカウントは、多要素認証が ID プロバイダーによって既に実行されていることを模倣することで、Microsoft Entra 多要素認証をバイパスできなくなることが保証されるため、サードパーティの MFA プロバイダーを使用してフェデレーション ユーザーに対する MFA を実行するのでない限り、この方法が強く推奨されます。

保護は、Internal Federation MS Graph API または MS Graph PowerShell コマンドレットの一部として公開されている新しいセキュリティ設定 federatedIdpMfaBehavior を使って有効にできます。 この federatedIdpMfaBehavior 設定は、フェデレーション ユーザーが MFA を必要とする条件付きアクセス ポリシーによって管理されるアプリケーションにアクセスするときに、フェデレーション ID プロバイダーによって実行される MFA を Microsoft Entra ID が受け入れるかどうかを判断します。

管理者は、次のいずれかの値を選択できます。

プロパティ	説明
acceptIfMfaDoneByFederatedIdp	Microsoft Entra ID は、ID プロバイダーで実行されている場合は MFA を受け入れます。 受け入れない場合、Microsoft Entra 多要素認証を実行します。
enforceMfaByFederatedIdp	Microsoft Entra ID は、ID プロバイダーで実行されている場合は MFA を受け入れます。 そうでない場合は、MFA を実行する要求が ID プロバイダーにリダイレクトされます。
rejectMfaByFederatedIdp	Microsoft Entra ID は常に Microsoft Entra 多要素認証を実行し、ID プロバイダーによって実行された場合は MFA を拒否します。

保護を有効にするには、次のコマンドを使用して federatedIdpMfaBehavior を rejectMfaByFederatedIdp に設定します。

MS Graph API

 PATCH /domains/{domainsId}/federationConfiguration/{internalDomainFederationId} 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

} 

例:

PATCH /domains/contoso.com/federationConfiguration/2a8ce608-bb34-473f-9e0f-f373ee4cbc5a 

{ 

"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp" 

例:

Update-MgDomainFederationConfiguration -DomainId <domainsId> -InternalDomainFederationId <internalDomainFederationId> federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

例:

Update-MgDomainFederationConfiguration -DomainId “contoso.com” -InternalDomainFederationId “2a8ce608-bb34-473f-9e0f-f373ee4cbc5a” federatedIdpMfaBehavior "rejectMfaByFederatedIdp" 

ハードウェア セキュリティ モジュール (HSM)

既定の構成では、トークンにサインするために AD FS で使用するキーは、イントラネット上のフェデレーション サーバーから離れる必要はありません。 DMZ やプロキシ コンピューターには存在しません。 必要に応じて、追加の保護を提供するために、これらのキーは、AD FS にアタッチされるハードウェア セキュリティ モジュール (HSM) で保護することをお勧めします。 Microsoft は HSM 製品を生成しませんが、AD FS をサポートする製品はいくつか市販されています。 この推奨事項を実装するには、ベンダーのガイダンスに従って署名と暗号化用の X509 証明書を作成し、次のようにカスタム証明書を指定して、AD FS インストール PowerShell コマンドレットを使用します。

Install-AdfsFarm -CertificateThumbprint <String> -DecryptionCertificateThumbprint <String> -FederationServiceName <String> -ServiceAccountCredential <PSCredential> -SigningCertificateThumbprint <String>

ここで、

• CertificateThumbprint は SSL 証明書です
• SigningCertificateThumbprint は署名証明書です (HSM で保護されたキーを使用)
• DecryptionCertificateThumbprint は暗号化された署名証明書です (HSM で保護されたキーを使用)