次の方法で共有

AD FS による SQL の微調整と待機時間の問題への対処

AD FS 2016の更新プログラムでは、データベース間の待機時間を短縮するために、次の機能強化が導入されました。 AD FS 2019 の今後の更新プログラムには、これらの機能強化が含まれます。

バックグラウンド スレッドでのメモリ内キャッシュの更新

以前の Always on 可用性 (AoA) のデプロイでは、マスター ノードが別のデータセンターに配置されている場合があるため、"読み取り" 操作の待機時間が存在していました。 2 つの異なるデータセンター間の呼び出しによって、待機時間が発生していました。

AD FS への最新の更新では、AD FS 構成キャッシュを更新するバックグラウンド スレッドの追加と、更新期間を設定するための設定による待機時間の短縮を目的にしています。 データベース キャッシュの更新がバックグラウンド スレッドに移動されるため、要求スレッドでデータベース検索に費やされる時間が大幅に短縮されます。

backgroundCacheRefreshEnabled を true に設定すると、AD FS によってバックグラウンド スレッドでキャッシュの更新を実行できるようになります。 キャッシュからデータをフェッチする頻度は、cacheRefreshIntervalSecs を設定することによって、時間値にカスタマイズできます。 backgroundCacheRefreshEnabled が true に設定されている場合、既定値は 300 秒に設定されます。 設定値の期間が経過すると、AD FS によってキャッシュの更新が開始されますが、更新の進行中は、古いキャッシュ データが引き続き使用されます。

AD FS でアプリケーションの要求が受信されると、AD FS によって SQL からアプリケーションが取得され、それがキャッシュに追加されます。 cacheRefreshIntervalSecs 値では、キャッシュ内のアプリケーションがバックグラウンド スレッドを使用して更新されます。 キャッシュにエントリが存在する間、バックグラウンド更新の進行中に、受信要求でキャッシュが使用されます。 5 * cacheRefreshIntervalSecs でエントリにアクセスされない場合は、キャッシュから削除されます。 構成可能な maxRelyingPartyEntries 値に達したら、キャッシュから最も古いエントリを削除することもできます。

Note

AD FS が SQL からデータベースで変更が発生したことを示す通知を受信した場合、キャッシュのデータは cacheRefreshIntervalSecs 値以外で更新されます。 この通知により、キャッシュの更新がトリガーされます。

キャッシュ更新の設定に関する推奨事項

キャッシュ更新の既定値は 5 分です。 SQL の変更が発生した場合にキャッシュ データが更新されるため、これを 1 時間 に設定して、AD FS による不要なデータ更新を減らすことが推奨されます。

AD FS によって、SQL の変更のコールバックが登録され、変更時に AD FS が通知を受信します。 この方法により、AD FS では、新しい変更が発生するとすぐに SQL からそれを受信します。

ネットワークの不具合が発生して、AD FS が SQL 通知を見逃した場合、AD FS によって、キャッシュ更新値で指定された間隔で更新されます。 AD FS と SQL の間で何らかの接続の問題が疑われる場合は、キャッシュ更新値を 1 時間未満に設定することが推奨されます。

構成の手順

構成ファイルでは、複数のキャッシュ エントリがサポートされています。 下記のものはすべて、組織のニーズに基づいて構成できます。

次の例では、バックグラウンド キャッシュ更新を有効にし、キャッシュ更新間隔を 1800 秒 (30 分) に設定しています。 これは、各 AD FS ノードで実行する必要があり、その後、AD FS サービスを再起動させる必要があります。 変更は他のノードに影響せず、すべてのノードに変更を加える前に、最初のノードをテストします。

  1. AD FS 構成ファイル (既定の場所 C:\Windows\ADFS\Microsoft.IdentityServer.ServiceHost.exe.config) に移動し、"Microsoft.IdentityServer.Service" セクションの下に次のエントリを追加します:
  • backgroundCacheRefreshEnabled - バックグラウンド キャッシュ機能が有効かどうかを指定します。 "true/false" 値。
  • cacheRefreshIntervalSecs - AD FS によってキャッシュが更新される秒単位の値。 SQL に変更があると、AD FS によってキャッシュが更新されます。 AD FS によって SQL 通知が受信され、キャッシュが更新されます。

Note

構成ファイル内のすべてのエントリで大文字と小文字が区別されます。 <cache cacheRefreshIntervalSecs="1800" > backgroundCacheRefreshEnabled="true" />

追加のサポートされている構成可能な値:

  • maxRelyingPartyEntries - AD FS によってメモリに保持される証明書利用者エントリの最大数。 この値は、oAuth アプリケーション アクセス許可キャッシュでも使用されます。 RP よりも多くのアプリケーション アクセス許可があり、すべてがメモリに格納される場合、この値はアプリケーションのアクセス許可数にする必要があります。 既定値は 1000 です。
  • maxRelyingPartyEntries -これは、AD FS によってメモリに保持される要求プロバイダー エントリの最大数です。 既定値は 200 です。
  • maxClientEntries - これは、AD FS によってメモリに保持される OAuth クライアント エントリの最大数です。 既定値は 500 です。
  • maxClaimDescriptorEntries - AD FS によってメモリに保持される要求記述子エントリの最大数。 既定値は 500 です。
  • maxNullEntries - これはネガティブ キャッシュとして使用されます。 AD FS によってデータベース内のエントリが検索され、見つからない場合、AD FS によってネガティブ キャッシュに追加されます。 これは、そのキャッシュの最大サイズです。 オブジェクトの種類ごとにネガティブ キャッシュがあり、すべてのオブジェクトに対する単一のキャッシュではありません。 既定値は 50,000 です。

データセンターにまたがる複数のアーティファクト DB のサポート

複数のデータセンターの以前の構成では、AD FS によって 1 つのアーティファクト データベースのみがサポートされていたため、取得呼び出し時にセンター データセンター間の待機時間が発生します。

データセンター間の待機時間を短縮するために、AD FS 管理者は複数のアーティファクト DB インスタンスをデプロイし、AD FS ノードの構成ファイルを変更して、異なるアーティファクト DB インスタンスを指し示すようになりました。 構成ファイルにアーティファクト データベース接続文字列を指定して、ノードごとのアーティファクト DB を使用できます。 接続文字列が構成ファイル内に存在しない場合、ノードは、構成 DB に存在する成果物データベースを使用するために、前の設計にフォールバックします。 この構成ではハイブリッド環境もサポートされます。

必要条件

複数のアーティファクト データベースのサポートを設定する前に、すべてのノードで更新を実行して、バイナリを更新します。マルチノードの呼び出しがこの機能を介して行われるためです。

  1. アーティファクト DB を作成するためのデプロイ スクリプトを生成します。複数のアーティファクト DB インスタンスをデプロイするには、管理者がアーティファクト DB の SQL デプロイ スクリプトを生成する必要があります。 この更新の一環として、既存の Export-AdfsDeploymentSQLScript コマンドレットが更新され、必要に応じて、SQL デプロイ スクリプトを生成する AD FS データベースを指定するパラメーターを受け取ることができるようになりました。

たとえば、アーティファクト DB のみのデプロイ スクリプトを生成するには、-DatabaseType パラメーターを指定し、値 "Artifact" を渡します。 省略可能な -DatabaseType パラメーターで、AD FS データベースの種類を指定し、All (既定)、Artifact、または Configuration を設定できます。 -DatabaseType パラメーターを指定しない場合、スクリプトによって、Artifact と Configuration の両方のスクリプトが構成されます。

PS C:\> Export-AdfsDeploymentSQLScript -DestinationFolder <script folder where scripts will be created> -ServiceAccountName <domain\serviceaccount> -DatabaseType "Artifact"

生成されたスクリプトは、SQL マシンで実行して、必要なデータベースを作成し、それらのデータベースに対する SQL SA アクセス許可を AD FS サービス アカウントに付与する必要があります。

  1. デプロイ スクリプトを使用してアーティファクト DB を作成します。 新しく生成された CreateDB.sql および SetPermissions.sql デプロイ スクリプトを SQL サーバー マシンにコピーして実行し、ローカル アーティファクト DB を作成します。

  2. 構成ファイルを変更して、アーティファクト DB 接続を追加します。 AD FS ノードの構成ファイルに移動し、セクション "Microsoft.IdentityServer.Service" の下で、新しく構成された ArtifactDB にエントリ ポイントを追加します。

Note

artifactStore と connectionString は、大文字と小文字が区別されます。 それらが正しく構成されていることを確認します。 <artifactStore connectionString="Data Source=.\SQLInstance;Integrated Security=True;Initial Catalog=AdfsArtifactStore" />

使用する sql 接続に一致する Data Source 値を使用します。

  1. 変更を有効にするために、AD FS サービスを再起動します。

Note

アーティファクト データベース間で SQL レプリケーションや同期を使用することは推奨されません。 データセンターごとに 1 つずつアーティファクト データベースをセットアップすることが推奨されます。

データセンター間のフェールオーバーとデータベースの復旧

フェールオーバー アーティファクト データベースは、マスター アーティファクト データベースと同じデータセンターに作成することが推奨されます。 フェールオーバーが発生した場合に、待機時間が増加することはありません。 データセンター間のフェールオーバー アーティファクト データベースは推奨されません。 以下に、複数のアーティファクト データベースで OAuth、SAML、ESL、およびトークン リプレイ検出機能を呼び出す方法を詳しく説明します。

  • OAuth と SAML

    OAuth および SAML アーティファクト要求の場合、ノードによって構成ファイル内に存在するアーティファクト DB にアーティファクトが作成されます。 構成ファイルに成果物データベース接続が含まれていない場合は、共通成果物 DB が使用されます。 アーティファクトをフェッチする次の要求が別のノードに移動すると、他のノードが 1 番目のノードに対して REST API 呼び出しを行い、アーティファクト データベースからアーティファクトをフェッチします。 これは、ノードごとにアーティファクト データベースが異なる可能性があり、ノードではそれが認識されていないために必要です。 1 番目のノードがダウンした場合、アーティファクトの解決は失敗します。 この設計のため、アーティファクト データベースを別のデータセンターにレプリケートする必要はありません。 データセンター全体がダウンしている場合は、アーティファクトを作成したノードもダウンしていて、アーティファクトを解決できなくなることを意味している可能性があります。

  • エクストラネットのロックアウト

    構成ファイルで 参照されているアーティファクト データベースが、エクストラネット ロックアウト データに使用されます。 ただし、ESL 機能の場合、AD FS はマスターを選択し、成果物 DB にデータを書き込みます。 すべてのノードがマスター ノードへの REST API 呼び出しを行い、各ユーザーに関する最新情報を取得して設定します。 複数の成果物データベースが使用されている場合、管理者は成果物 DB またはデータセンターごとにマスター ノードを選択する必要があります。

    ESL マスターとして 1 つのノードを選択するには、AD FS ノードの構成ファイルに移動し、セクション "Microsoft.IdentityServer.Service" の下に次を追加します。

    マスターで、次のエントリを追加します。 3 つのキーはすべて大文字と小文字が区別されます。

    <useractivityfarmrole masterFQDN=[FQDN of the selected primary] isMaster="true"/>

    他のノードで、次のエントリを追加します。

    <useractivityfarmrole masterFQDN=[FQDN of the selected primary] isMaster="false"/>

    Note

    複数のアーティファクト データベースではデータが同期されないため、アーティファクト DB 間で ESL 値は同期されません。 ユーザーが要求のために別のデータセンターにアクセスする可能性があるため、ExtranetLockoutThreshold をアーティファクト DB の数に依存させます (ExtranetLockoutThreshold * アーティファクト DB の数)。

    • トークン リプレイ検出

      トークン リプレイ検出データは、常に中央のアーティファクト データベースから呼び出されます。 AD FS によって、要求プロバイダー信頼からのトークンが保存され、確実に同じトークンをリプレイできないようにします。 攻撃者が同じトークンをリプレイしようとした場合、AD FS によって、アーティファクト DB にそのトークンが存在するかどうかが検証されます。 トークンが存在する場合、要求は拒否されます。 中央のアーティファクト データベースはセキュリティのために使用されます。アーティファクト DB データはレプリケートされず、攻撃者は要求を別のデータセンターに送信し、トークンをリプレイする可能性があるためです。 中央のアーティファクト データベースだけが使用されるので、このシナリオでは ArtifactDB の追加の読み取り専用コピーを作成することでデータセンター間の待機時間を回避することはできません。