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

  • [アーティクル]

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

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

標準の展開トポロジ

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

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

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

A diagram depicting a standard A D F S topology.

注意

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 の展開のコンポーネント間で有効にする必要があるファイアウォールを示しています。 展開に Azure AD/Office 365 が含まれない場合、同期要件を無視できます。

ポート 49443 は、ユーザー証明書認証が使用されている場合にのみ必要です。これは、Azure AD および Office 365 ではオプションです。

a diagram showing the required ports and protocols for an A D F S deployment.

注意

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

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

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

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

Azure AD Connect および フェデレーション サーバー/WAP

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

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

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

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

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

WAP とユーザー

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

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

ハイブリッド展開に必要なポートとプロトコルの詳細については、こちらのドキュメントを参照してください。

Azure AD と Office 365 の展開に必要なポートとプロトコルについては、こちらのドキュメントを参照してください。

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

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

[省略可能] Azure AD/Office 365 に対して有効になっているエンドポイント プロキシの最小セット

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

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

以下の 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 サービスを再起動します。 参考までに、この機能に関するガイダンスについては、こちらを参照 してください。

プロキシでの標準 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 サーバーと WAP サーバーを最新の状態に保つ手段と、このページの AD FS で重要として指定されたオプションの更新プログラムを確保する方法です。

Azure AD 顧客がインフラストラクチャを監視し最新の状態に保つには、AD FS Health for AD FS (Azure AD Premium の機能) を使用する方法をお勧めします。 Azure AD Connect Health には、AD FS または WAP コンピューターに AD FS と WAP 専用の重要な更新プログラムが欠落している場合にトリガーされるモニターとアラートが含まれています。

Azure AD Connect Health for AD FS のインストールについては、こちらを参照してください。

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

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

追加のセキュリティ構成

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

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

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 )

参考までに、この機能のパブリック ドキュメントはこちらです。

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

サポートされている外部 MFA プロバイダーには、このページに記載されているプロバイダーと HDI Global が含まれます。

Azure AD とのフェデレーション時に、クラウド Azure AD 多要素認証のバイパスを回避するための保護を有効にする

Azure AD とのフェデレーション時にクラウド Azure MFA のバイパスを回避し、フェデレーション ユーザーの多要素認証として Azure AD 多要素認証を使用するための保護を有効にします。

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

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

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

プロパティ 説明
acceptIfMfaDoneByFederatedIdp Azure AD は、ID プロバイダーによって実行された場合に MFA を受け入れます。 そうでない場合は、Azure AD 多要素認証が実行されます。
enforceMfaByFederatedIdp Azure AD は、ID プロバイダーによって実行された場合に MFA を受け入れます。 そうでない場合は、MFA を実行する要求が ID プロバイダーにリダイレクトされます。
rejectMfaByFederatedIdp Azure AD は常に Azure AD 多要素認証を実行し、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"

PowerShell

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 で保護されたキーを使用)