AD FS プロキシの混雑回避アルゴリズムの動作

Published: / Last update: / Contributors:
feedback 共有

Note

本記事は Technet Blog の更新停止に伴い https://blogs.technet.microsoft.com/jpazureid/2018/02/01/congestion_avoidance_algorithm/ の内容を移行したものです。

元の記事の最新の更新情報については、本内容をご参照ください。

こんにちは、Azure & Identity サポート チームの石川です。
今回は、AD FS プロキシ (Windows Server 2012 R2 以降は WAP ですが、今回の記事での説明では AD FS プロキシとします) の混雑回避アルゴリズムの動作について紹介します。
社内からブラウザーを利用した Exchange Online へのアクセスは問題無いが、 Outlook を利用した場合 (アクティブ認証) やエクストラネットからのアクセス時に認証で問題が発生するというときには、AD FS プロキシ経由の認証でエラーが発生しており、それが混雑回避アルゴリズムにより認証が制限されていることが原因で生じている可能性があります。
最近の Outlook は先進認証 (= ADAL とも、モダン認証とも呼ぶ) を利用しており、この場合には Outlook もアクティブ認証ではなく、ブラウザーと同じような認証経路になります。
混雑回避アルゴリズムの動作を把握しておくことで、発生時の対処や恒久的な対応をすることができます。

混雑回避アルゴリズムとは

AD FS プロキシは、Office 365 などのサービス プロバイダーからの認証要求を受け取り、AD FS に渡すプロキシ サーバーとして動作しています。
AD FS プロキシ経由の AD FS 認証が多数発生して、AD FS からの応答が遅くなった場合、AD FS プロキシは、混雑回避アルゴリズムの制限モードを発動して、AD FS への認証要求の転送を中止します。
制限モードになった場合、後述の条件を満たさないと、AD FS プロキシ経由の AD FS 認証が完了しないため、 AD FS と連携するサービス プロバイダー (例えば Office 365 など) にサインインすることができなくなります。
さらに、AD FS プロキシ サーバーの ADFS/Admin イベント ログに次のようなイベント 230 や イベント 222 が記録されます。 

ログの名前: AD FS/Admin  
ソース: AD FS  
日付: ********  
イベント ID: 230  
タスクのカテゴリ: なし  
レベル: 警告  
キーワード: AD FS  
ユーザー: NETWORK SERVICE  
コンピューター: ********  
説明:  
フェデレーション サーバー プロキシが、フェデレーション サービスで応答時間が長くなっているため輻輳が生じていることを検出しました。  
フェデレーション サービスが過負荷状態になっているか、ネットワーク接続に問題が生じている可能性があります。  
要求の調整が行われ、同時に実行される要求の数が次のサイズに制限されています: 64。  
ユーザー操作  
フェデレーション サービスの稼働状態がその稼働能力を上回っていないことを確認してください。  
フェデレーション サービスが利用しているネットワークが停止していないことを確認してください。  
ログの名前: AD FS/Admin  
ソース: AD FS  
日付: ********  
イベント ID: 222  
タスクのカテゴリ: なし  
レベル: エラー  
キーワード: AD FS  
ユーザー: NETWORK SERVICE  
コンピューター: ********  
説明:  
タイムアウトが原因で、フェデレーション サーバー プロキシがアドレス 'https://【フェデレーション サービス名】/adfs/services/trust/2005/usernamemixed' のフェデレーション サービスへの要求を完了できませんでした。  
フェデレーション サービスは現在利用できない可能性があります。  
ユーザー操作  
フェデレーション サービスが実行されていることを確認してください。

混雑回避アルゴリズムの具体的な動作

  1. AD FS プロキシ サーバーは、AD FS サーバーに対するトークン要求を発行する度に、RoundTripTime (RTT) を取得します。
  2. 取得した RTT を基に、これまで算出してきた RTT 値の平均値を算出します。
  3. 取得した RTT の平均値、及び、固定値 (10 秒) を比較し、小さい方の値を “最終的な RTT の平均値” として設定します。
  4. 最終的な RTT の平均値が、latencyThresholdInMSec (既定値 8 秒) を超えた場合に、混雑回避アルゴリズムによる制限モードが発動します。
  5. 制限モードの発動により、その時点で AD FS に Request 中の認証要求が一定数処理されるまで、新しい認証要求を AD FS に転送せず、クライアントからの新しい要求を拒否します。
  6. AD FS プロキシ 側で、「同時接続数」を管理していますが、その値が minCongestionWindowSize まで減った場合、または 制限モードに入った時の同時接続数の 1/2 のどちらか大きいほうまで「同時接続数」が減った場合に制限モードが解除されます。
    ※ ただし、この時点で AD FS プロキシへの認証要求過多が継続しており、最終的な RTT の平均値が latencyThresholdInMSec の値を超えた場合には、再び制限モードに入ります。
    AD FS: AD FS (2.0) またはフェデレーション サーバー プロキシの管理者イベント ログに、警告を示すイベント ID 230 が表示される
    https://support.microsoft.com/ja-jp/help/2750510/ad-fs-warning-event-id-230-in-ad-fs-2.0-admin-event-log-on-federation-service-proxy

どのような場合に AD FS プロキシへの認証要求が多発するか？

主に次のような場合に、AD FS プロキシへの認証要求が多発し、混雑回避アルゴリズムによる制限モードが発動します。

  1. 出社時などユーザーが集中してサインインする時間帯
  2. Exchange Online の認証キャッシュが利用できなくなることによる Outlook の再認証が発生した場合

1 については、毎週月曜日の決まった時間帯に、規則的かつ恒常的に制限モードが発動する傾向があります。
2 について、Outlook から Exchange Online に対して、AD FS 認証を利用してアクセスをする場合、一度 Exchange Online にサインインした後、一定期間 Exchange Online 上に認証キャッシュを持つ動作があります。
Exchange Online の認証キャッシュがある場合、Outlook からの再アクセスが発生しても、AD FS 認証が不要となり、直接 Exchange Online にサインインすることが可能です。
これにより、AD FS への認証要求数が削減される効果がありますが、何らかの理由により既存の Exchange Online の認証キャッシュが利用できなくなった場合 (例: Exchange Online への通信経路を変更するなど) 、AD FS への認証要求が集中します。
また、Outlook では、メールボックスへのサインイン以外にも、利用している機能により複数の認証を必要とするため、さらに認証数が増えることがあります。

対処策

制限モードに入った場合、認証の順番待ちがされている状態ですので、通常は、時間経過により、すべての認証が完了します。
しかし、頻繁に事象が発生する場合には、つぎのような恒久的な対処が必要となります。
A) AD FS/AD FS プロキシ サーバーのスペックを強化するか AD FS サーバーの台数を増やす。
B) 混雑回避アルゴリズムのしきい値をチューニングする。(詳細は後述)
C) Outlook の認証に先進認証を利用する。
※ 先進認証を使用することで、Exchange Online の認証キャッシュに影響されないブラウザー ベースと同じパッシブ認証のフローで認証が行われます。また、トークンを保持することによる認証を必要としない期間があるため、AD FS への認証要求自体も少なくなります。
Office クライアントで Office 365 先進認証を使用する
https://support.office.com/ja-jp/article/776c0036-66fd-41cb-8928-5495c0f9168a
混雑回避アルゴリズムのしきい値の変更方法
混雑回避アルゴリズムのしきい値となる latencyThresholdInMSec の値を変更することで、制限モードが発動する条件となる AD FS からの平均応答時間の値を伸ばすことができます。

  1. AD FS プロキシ サーバー上で、以下の CONFIG ファイルをメモ帳で開きます。
    C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config
  2. ファイル内の “～” の項目で、次の一行を編集します。
    既定値 (Windows Server 2012 R2 の場合は、遅延しきい値 : 8 秒)
    設定例 (遅延閾値 : 60 秒)
  3. WAP サーバーの Active Directory Federation Services サービスを再起動します。
  4. すべての WAP サーバーで上記の設定を実施します。
    latencyThresholdInMSec の最大値は、60000 (ミリ秒) です。
    latencyThresholdInMSec の値を大きくすることにより、制限モードに入る条件となる AD FS からの平均応答時間の猶予時間が伸びるため、制限モードに入りにくくなります。
    ただし、AD FS サーバーや DC の負荷が大きくなり、最悪の場合ダウンしてしまうことも考えられますので、実際の負荷状況を確認しながら、少しずつ値を変更していただくことをお勧めしております。
    下記の弊社公開情報に、チューニングの際に参考となる AD FS、AD FS プロキシ サーバーのパフォーマンス モニターのカウンターについての記載がございますので、ご参考ください。
    AD FS: AD FS (2.0) またはフェデレーション サーバー プロキシの管理者イベント ログに、警告を示すイベント ID 230 が表示される
    https://support.microsoft.com/ja-jp/help/2750510/ad-fs-warning-event-id-230-in-ad-fs-2.0-admin-event-log-on-federation-service-proxy
    ※ チューニングに関してお困りのことがあれば、弊社プレミア サポートにご相談をいただきますと幸いです。
    エンタープライズ向け Premier サポート
    https://www.microsoft.com/ja-jp/services/premier.aspx

以上となります。AD FS プロキシを経由しての認証のみで問題が生じているケースは、混雑アルゴリズム以外にもあります。
そのようなケースでお困りなられました際には、是非サポート窓口までお問い合わせください。

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。