AD FS についてよくあるご質問 (FAQ)

次のリンクされたいずれかの記事の手順のようにすることで、AD FS をアップグレードまたは移行することができます。

• Windows Server 2012 R2 AD FS から Windows Server 2016 AD FS 以降へ。 (プロセスは、Windows Server 2016 AD FS から Windows Server 2019 AD FS にアップグレードする場合と同じです。)
  • WID データベースを使用した、Windows Server 2016 での AD FS へのアップグレード
  • SQL データベースを使用した、Windows Server 2016 での AD FS へのアップグレード
• Windows Server 2012 AD FS から Windows Server 2012 R2 AD FS へ:
  • Windows Server 2012 R2 の AD FS に移行する
• AD FS 2.0 から Windows Server 2012 AD FS へ:
  • Windows Server 2012 の AD FS に移行する
• AD FS 1.x から AD FS 2.0 へ:
  • Upgrade from AD FS 1.x から AD FS 2.0 にアップグレードする

AD FS 2.0 または 2.1 (Windows Server 2008 R2 または Windows Server 2012) からアップグレードする必要がある場合は、C:\Windows\ADFS にある付属のスクリプトを使用します。

HTTP/2 のサポートは Windows Server 2016 で追加されましたが、クライアント証明書認証に HTTP/2 を使用することはできません。 AD FS の多くのシナリオには、クライアント証明書認証が使用されます。 また、多くのクライアントでは、HTTP/1.1 を使用する要求の再試行はサポートされていません。 そのため、AD FS ファームの構成では、ローカル サーバーの HTTP の設定が HTTP/1.1 に再構成されます。 この再構成で、サーバーを再起動する必要があります。

この構成はサポートされていますが、それを行うと AD FS 2016 の新しい機能はサポートされません。 この構成は、AD FS 2012 R2 から AD FS 2016 への移行の間の一時的なものとして意図されています。 長期間使用することはできません。

はい。ただし、次のような副作用があります

• Azure AD からフェデレーション メタデータにはアクセスできないため、更新トークン署名証明書を手動で管理する必要があります。 トークン署名証明書の手動更新の詳細については、Office 365 と Azure Active Directory 用のフェデレーション証明書の更新に関する記事を参照してください。
• レガシ認証フロー (ExO プロキシ認証フローなど) を使用することはできません。

AD FS はステートレス システムなので、サインインに関する負荷分散は非常に簡単です。負荷分散システムに関する主な推奨事項を次に示します。

• IP アフィニティを使用してロード バランサーを構成しないでください。 IP アフィニティを使用すると、Exchange Online の特定のシナリオで、サーバーのサブセットに過度の負荷がかかる可能性があります。
• ロード バランサーで、AD FS サーバーへの HTTPS 接続を終了し、新しい接続を開始しないでください。
• ロード バランサーでは、AD FS に送信される HTTP パケットの送信元 IP として、接続している IP アドレスを変換する必要があります。 HTTP パケットで送信元 IP を送信できない場合は、ロード バランサーで X-Forwarded-For ヘッダーに IP アドレスを追加する必要があります。 このステップは、特定の IP 関連機能 (禁止 IP やエクストラネット スマート ロックアウトなど) を正しく処理するために必要です。 この構成が正しく実装されていない場合、セキュリティが低下する可能性があります。
• ロード バランサーでは、SNI をサポートする必要があります。 そうでない場合は、SNI をサポートしないクライアントを処理するために HTTPS バインドを作成するよう、AD FS を構成する必要があります。
• ロード バランサーで AD FS HTTP 正常性プローブ エンドポイントを使用して、AD FS または Web アプリケーション プロキシ サーバーが実行されているかどうかを検出する必要があります。 200 OK が返されない場合は、それらを除外する必要があります。

複数のマルチフォレスト構成が AD FS によってサポートされています。 基盤の AD DS の信頼のネットワークを利用して、複数の信頼された領域でのユーザーの認証が行われます。 設定が簡単で、信頼システムの正しい動作を保証するのに役立つため、双方向のフォレスト信頼を強くお勧めします。

追加として:

• パートナー ID を含む境界ネットワーク (DMZ とも呼ばれます) フォレストのような一方向のフォレスト信頼を使用する場合は、企業フォレストに AD FS を展開することをお勧めします。 境界ネットワーク フォレストは、LDAP 経由で接続された別のローカル クレーム プロバイダー信頼として扱います。 この場合、境界ネットワーク フォレスト ユーザーに対しては Windows 統合認証は機能しません。 LDAP でサポートされているメカニズムはパスワード認証だけなので、それを使用する必要があります。

  このオプションを使用できない場合は、境界ネットワーク フォレスト内に別の AD FS サーバーを設定する必要があります。 企業フォレスト内の AD FS サーバーにクレーム プロバイダーの信頼としてそれを追加します。 ユーザーはホーム領域検出を行う必要がありますが、Windows 統合認証とパスワード認証の両方が機能します。 企業フォレスト内の AD FS で境界ネットワーク フォレストからユーザーに関する詳細を取得することはできないので、境界ネットワーク フォレスト内の AD FS で発行規則を適切に変更します。

• ドメイン レベルの信頼はサポートされ、機能します。 ただし、フォレスト レベルの信頼モデルに移行することを強くお勧めします。 また、UPN ルーティングと NetBIOS の名前解決が正しく機能することを確認する必要もあります。

はい。IPv6 アドレスは、使い慣れた場所と不明な場所で考慮されます。

AD FS には、サードパーティの多要素認証プロバイダーを統合するための拡張可能なメカニズムが用意されています。 このための設定された認定プログラムはありません。 ベンダーはリリース前に必要な検証を実行したものと想定されています。

Microsoft に通知したベンダーの一覧は、AD FS 対応の多要素認証プロバイダーに関するページで確認できます。 Microsoft が把握していないプロバイダーを利用できる場合があります。 そのようなものが新しく見つかったら、一覧を更新します。

はい。サードパーティのプロキシを AD FS の前面に配置できますが、サードパーティのプロキシでは、Web アプリケーション プロキシの代わりに使用する MS-ADFSPIP プロトコルがサポートされている必要があります。

現在は、次のサードパーティ プロバイダーが認識されています。 Microsoft が把握していないプロバイダーを利用できる場合があります。 そのようなものが新しく見つかったら、この一覧を更新します。

• F5 Access Policy Manager
• Citrix アプリケーション デリバリー コントローラー (ADC)

AD FS 2016 バージョンのスプレッドシートをダウンロードできます。 このスプレッドシートは、Windows Server 2012 R2 の AD FS に使用することもできます。

Apple からは App Transport Security (ATS) と呼ばれる一連の要件がリリースされており、AD FS に対する認証を行う iOS アプリからの呼び出しに影響する可能性があります。 AD FS と Web アプリケーション プロキシ サーバーでは、ATS を使用する接続に関する要件をサポートすることで、それに準拠することができます。 具体的には、次のことを確認する必要があります。

• AD FS と Web アプリケーション プロキシ サーバーで、TLS 1.2 がサポートされています。
• TLS 接続のネゴシエートされた暗号スイートで、完全な転送機密性がサポートされています。

SSL 2.0 と 3.0 および TLS 1.0、1.1、1.2 の有効化または無効化については、AD FS での SSL プロトコルの管理に関する記事を参照してください。

ATP をサポートする TLS 暗号スイートのみが AD FS と Web アプリケーション プロキシ サーバーによってネゴシエートされるようにするには、ATP に準拠する暗号スイートの一覧に含まれていないすべての暗号スイートを無効にします。 これらを無効にするには、Windows TLS PowerShell コマンドレットを使用します。

"sub" クレームの値は、クライアント ID とアンカー クレームの値のハッシュです。

更新トークンの有効期間は、AD FS によってリモート クレーム プロバイダー信頼から取得されたトークンの有効期間になります。 アクセス トークンの有効期間は、アクセス トークンの発行対象である証明書利用者のトークンの有効期間になります。

カスタマイズされた id_token を使用して、id_token 自体に関連情報を追加できます。 詳しくは、id_token で出力されるように要求をカスタマイズする方法に関する記事をご覧ください。

特殊な ValueType (http://www.w3.org/2001/XMLSchema#json) とエスケープ文字 (\x22) が、AD FS 2016 でこのシナリオのために追加されました。 発行規則と、アクセス トークンからの最終的な出力については、次のサンプルを使用してください。

発行規則の例:

=> issue(Type = "array_in_json", ValueType = "http://www.w3.org/2001/XMLSchema#json", Value = "{\x22Items\x22:[{\x22Name\x22:\x22Apple\x22,\x22Price\x22:12.3},{\x22Name\x22:\x22Grape\x22,\x22Price\x22:3.21}],\x22Date\x22:\x2221/11/2010\x22}");

アクセス トークンで発行されたクレーム:

"array_in_json":{"Items":[{"Name":"Apple","Price":12.3},{"Name":"Grape","Price":3.21}],"Date":"21/11/2010"}

Windows Server 2019 の AD FS では、リソース値をスコープ パラメーターに埋め込んで渡すことができます。 スコープ パラメーターは、各エントリがリソースおよびスコープとして構成された、スペース区切りのリストとして作成できます。

Windows Server 2019 の AD FS によって、OAuth 認証コード付与フロー用の Proof Key for Code Exchange (PKCE) がサポートされています。

サポート対象:

• aza。 ブローカー クライアント用 OAuth 2.0 プロトコル拡張を使用していて、スコープ パラメーターにスコープ aza が含まれている場合、サーバーによって新しいプライマリ更新トークンが発行されて、応答の refresh_token フィールドにそれが設定されます。 また、新しいプライマリ更新トークンの有効期間が適用される場合は、refresh_token_expires_in フィールドにそれが設定されます。
• openid。 アプリケーションで OpenID Connect 承認プロトコルの使用を要求できるようにします。
• logon_cert。 アプリケーションでログオン証明書を要求できます。それを使用して、認証されたユーザーを対話的にサインインさせることができます。 AD FS サーバーによって、応答から access_token パラメーターが除去され、代わりに Base64 でエンコードされた CMS 証明書チェーンまたは CMC 完全 PKI 応答が提供されます。 詳細については、「処理の詳細」を参照してください。
• user_impersonation。 AD FS に on-behalf-of アクセス トークンを要求する場合に必要です。 このスコープを使用する方法の詳細については、AD FS 2016 と OAuth での On-Behalf-Of (OBO) を使用した多層アプリケーションの構築に関する記事を参照してください。

サポートされない:

• vpn_cert。 アプリケーションで VPN 証明書を要求できます。それを使用すると、EAP-TLS 認証を使用して VPN 接続を確立できます。 このスコープはサポートされなくなりました。
• email。 アプリケーションで、サインインしたユーザーのメール クレームを要求できます。 このスコープはサポートされなくなりました。
• profile。 アプリケーションで、サインインしたユーザーのプロファイル関連のクレームを要求できます。 このスコープはサポートされなくなりました。

AD FS SSL 証明書は、AD FS 管理スナップインの AD FS サービス通信証明書と同じものではありません。 AD FS SSL 証明書を変更するには、PowerShell を使用する必要があります。 AD FS と WAP 2016での SSL 証明書の管理に関する記事のガイダンスに従ってください。

SSL プロトコルと暗号スイートの有効化または無効化については、AD FS での SSL プロトコルの管理に関する記事を参照してください。

• プロキシを使用して Windows 統合認証を使用する AD FS 要求をプロキシする場合は、プロキシ SSL 証明書でフェデレーション サーバーの SSL 証明書と同じキーが使用されている必要があります。
• AD FS の ExtendedProtectionTokenCheck プロパティが有効である場合は (AD FS の既定の設定)、プロキシ SSL 証明書でフェデレーション サーバーの SSL 証明書と同じキーが使用されている必要があります。
• それ以外の場合は、プロキシ SSL 証明書と AD FS SSL 証明書のキーは異なっていてもかまいません。 同じ要件を満たしている必要があります。

アプリケーションで明示的に要求されている特定の認証 URI が構成済みで有効な認証方法にマップされている場合、AD FS のサインイン画面には 1 つの認証方法のみが表示されます。 その方法は、WS-Federation の要求では wauth パラメーターで伝達されます。 SAML プロトコルの要求では RequestedAuthnCtxRef パラメーターで伝達されます。 要求された認証方法のみが表示されます。 (パスワード サインインなど。)

Azure AD で AD FS を使用しているときは、アプリケーションで prompt=login パラメーターを Azure AD に送信するのが一般的です。 既定では、このパラメーターは、Azure AD によって、AD FS に対する新しいパスワードに基づくサインインの要求に変換されます。 このシナリオは、ネットワーク内の AD FS でパスワードのサインインが表示される、または証明書でサインインするためのオプションが表示されない、最も一般的な理由です。 この問題は、Azure AD でフェデレーション ドメインの設定を変更することによって、簡単に解決できます。

詳細については、「Active Directory フェデレーション サービスでの prompt=login パラメーターのサポート」を参照してください。

AD FS のサービス アカウントを変更するには、AD FS ツールボックスのサービス アカウント PowerShell モジュールを使用します。 手順については、「AD FS サービス アカウントを変更する」を参照してください。

「AD FS で Windows 統合認証 (WIA) を使用するようにブラウザーを構成する」を参照してください。

AD FS 上のデバイス、または AD FS を使用する Windows Hello for Business 証明書の登録に基づくアクセス制御ポリシーがない場合、BrowserSsoEnabled を無効にすることができます。 BrowserSsoEnabled を使用すると、AD FS で、デバイス情報が格納されているクライアントからプライマリ更新トークン (PRT) を収集できます。 そのトークンがないと、AD FS のデバイス認証は Windows 10 デバイスで機能しません。

管理者は、ユーザーが新しい資格情報を入力する必要なしにシングル サインオン (SSO) を利用できる期間や、管理者がその動作を制御する方法が、気になることがよくあります。 その動作、およびそれを制御する構成設定については、「AD FS のシングル サインオンの設定」を参照してください。

さまざまな Cookie とトークンの既定の有効期間は以下のとおりです (および有効期間を制御するパラメーター)。

登録済みデバイス

• PRT と SSO Cookie: 最大 90 日で、PSSOLifeTimeMins によって管理されます。 (デバイスが少なくとも 14 日ごとに使用される場合。このタイム ウィンドウは DeviceUsageWindow によって制御されます)。

• 更新トークン: 一貫性した動作を提供するため、前記のパラメーターに基づいて計算されます。

• access_token: 既定では 1 時間で、証明書利用者に基づきます。

• id_token: access_token と同じ。

未登録のデバイス

• SSO Cookie: 既定では 8 時間で、SSOLifetimeMins によって管理されます。 サインアウトしない (KMSI) が有効になっている場合の既定値は 24 時間です。 この既定値は、KMSILifetimeMins を使用して構成できます。

• 更新トークン: 既定では 8 時間。 KMSI が有効になっている場合は 24 時間。

• access_token: 既定では 1 時間で、証明書利用者に基づきます。

• id_token: access_token と同じ。

AD FS では、機密クライアントの暗黙的なフローはサポートされていません。 クライアント認証はトークン エンドポイントに対してのみ有効であり、クライアント認証なしで AD FS からアクセス トークンが発行されることはありません。 機密クライアントにアクセス トークンを必要であり、ユーザー認証も必要な場合は、承認コード フローを使用する必要があります。

HSTS は、Web セキュリティ ポリシー メカニズムです。 HTTP と HTTPS の両方のエンドポイントを持つサービスに対するプロトコル ダウングレード攻撃や Cookie ハイジャックを緩和するのに役立ちます。 それを使用すると、Web ブラウザー (または他の準拠ユーザー エージェント) は HTTPS のみを使用して対話し、HTTP プロトコルを使用してはならないことを、Web サーバーで宣言できます。

Web 認証トラフィック用のすべての AD FS エンドポイントは、HTTPS 経由専用に開かれます。 そのため、HSTS ポリシー メカニズムによって作成される脅威を AD FS で軽減できます。 (設計上、HTTP にはリスナーが存在しないため、HTTP にダウングレードすることはありません)。また、AD FS では、すべての Cookie をセキュリティで保護されたフラグでマークすることにより、HTTP プロトコル エンドポイントを持つ別のサーバーに Cookie が送信されないようにできます。

したがって、HSTS をダウングレードすることはできないため、AD FS サーバーに HSTS は必要ありません。 AD FS サーバーは、HTTP を使用できず、Cookie が安全としてマークされるため、コンプライアンス要件を満たしています。

最後に、AD FS 2016 (最新の修正プログラムを適用) と AD FS 2019 では、HSTS ヘッダーの生成がサポートされています。 この動作を構成するには、AD FS 2019 での HTTP セキュリティ応答ヘッダーのカスタマイズに関する記事を参照してください。

Web アプリケーション プロキシ サーバーの前に SSL のターミネーションを行うことはお勧めしません。 Web アプリケーション プロキシ サーバーの前でそれを行った場合、X-MS-Forwarded-Client-IP には、Web アプリケーション プロキシ サーバーの前面にあるネットワーク デバイスの IP が含まれるようになります。 AD FS によってサポートされるさまざまな IP 関連のクレームについて簡単に説明します。

• X-MS-Client-IP。 STS に接続されているデバイスのネットワーク IP。 エクストラネット要求の場合、このクレームには常に Web アプリケーション プロキシ サーバーの IP が含まれます。
• X-MS-Forwarded-Client-IP。 Exchange Online によって AD FS に転送されるすべての値が含まれる複数値のクレーム。 また、Web アプリケーション プロキシ サーバーに接続されているデバイスの IP アドレスも含まれます。
• Userip。 エクストラネット要求の場合、このクレームには X-MS-Forwarded-Client-IP の値が含まれます。 イントラネット要求の場合、このクレームには X-MS-Client-IP と同じ値が含まれます。

AD FS 2016 (最新の修正プログラムが適用されたもの) 以降のバージョンでは、X-Forwarded-For ヘッダーのキャプチャもサポートされています。 レイヤー 3 (IP が保持される) での転送が行われないすべてのロード バランサーまたはネットワーク デバイスでは、受信したクライアント IP を業界標準の X-Forwarded-For ヘッダーに追加する必要があります。

OpenID 標準で指定されているように、AD FS の UserInfo エンドポイントからは常にサブジェクト クレームが返されます。 AD FS では、UserInfo エンドポイントでの追加クレームの要求はサポートされません。 ID トークンでさらにクレームが必要な場合は、AD FS でのカスタム ID トークンに関する記事を参照してください。

このグループは、FSMO PDC の役割を持つ Windows Server 2016 ドメイン コントローラーがドメインに存在する場合にのみ作成されます。 このエラーを解決するには、グループを手動で作成します。 サービス アカウントをグループのメンバーとして追加した後、必要なアクセス許可を追加するには、次の手順のようにします。

1. [Active Directory ユーザーとコンピューター] を開きます。
2. 左側のペインでドメイン名を右クリックし、[プロパティ] を選択します。
3. [セキュリティ] を選択します。 ([セキュリティ] タブが表示されない場合は、[表示] メニューで [高度な機能] をオンにします。)
4. [詳細設定]、[追加]、[プリンシパルの選択] の順に選択します。
5. [Select User, Computer, Service Account, or Group](ユーザー、コンピューター、サービス アカウントまたはグループの選択) ダイアログが表示されます。 [Enter the object name to select](選択するオブジェクト名を入力してください) ボックスに「Key Admin Group」と入力します。 [OK] を選択します。
6. [適用対象] ボックスで、[Descendant User objects](子孫ユーザー オブジェクト) を選択します。
7. ページの一番下までスクロールして、[すべてクリア] を選択します。
8. [プロパティ] セクションで、 [Read msDS-KeyCredentialLink](msDS-KeyCredentialLink の読み取り) および [Write msDS-KeyCredentialLink](msDS-KeyCredentialLink の書き込み) を選択します。

Android ADAL ライブラリを使用するアプリの場合、フェデレーション ユーザーの Azure AD に対する認証が失敗する場合があります。 アプリでサインイン ページを表示しようとすると、AuthenticationException を受け取ります。 Chrome ブラウザーでは、AD FS サインイン ページが安全ではないという説明が表示される場合があります。

すべてのバージョンとすべてのデバイスについて、Android では証明書の authorityInformationAccess フィールドからの追加証明書のダウンロードはサポートされていません。 この制限は Chrome ブラウザーにも適用されます。 中間証明書が欠落しているサーバー認証証明書で、AD FS から証明書チェーン全体が渡されなかった場合、このエラーが発生します。

この問題は、SSL 証明書と共に必要な中間証明書を送信するように、AD FS と Web アプリケーション プロキシ サーバーを構成することで、解決できます。

AD FS および Web アプリケーション プロキシ サーバーの SSL 証明書を 1 台のコンピューターからエクスポートし、コンピューターの個人用ストアにインポートするときは、必ず秘密キーをエクスポートし、Personal Information Exchange - PKCS #12 を選択してください。

また、[Include all certificates in the certificate path if possible](証明のパスにある証明書を可能であればすべて含む) と [すべての拡張プロパティをエクスポートする] を必ずオンにしてください。

Windows サーバーで certlm.msc を実行し、コンピューターの個人証明書ストアに *.pfx をインポートします。 これにより、サーバーで証明書チェーン全体が ADAL ライブラリに渡されるようになります。

AD FS では HEAD 要求はサポートされていません。 アプリケーションでは、AD FS エンドポイントに対して HEAD 要求を使用しないようにする必要があります。 これらの要求を使用すると、予期しない、または遅延する HTTP エラー応答が発生する可能性があります。 また、AD FS イベント ログに予期しないエラー イベントが記録される場合があります。

IdP によって発行されたトークンの有効期間が 1 時間未満の場合、更新トークンは発行されません。 更新トークンが確実に発行されるようにするには、IdP によって発行されるトークンの有効期間を 1 時間以上に増やします。

RP トークンの暗号化は、AES256 に設定されています。 それを他の値に変更することはできません。

混合モードの AD FS ファームは、一時的なものです。 アップグレード プロセスの前に SSL 証明書をロールオーバーするか、SSL 証明書を更新する前にプロセスを完了してファームの動作レベルを上げることを計画するようお勧めします。 この推奨事項に従わなかった場合は、次の手順のようにして SSL 証明書を更新します。

Web アプリケーション プロキシ サーバーでは、引き続き Set-WebApplicationProxySslCertificate を使用できます。 AD FS サーバーでは、netsh を使用する必要があります。 以下の手順を実行します。

1. メンテナンスする AD FS 2016 サーバーのサブセットを選択します。

2. 前のステップで選択したサーバーで、MMC を使用して新しい証明書をインポートします。

3. 既存の証明書を削除します。

   a。 netsh http delete sslcert hostnameport=fs.contoso.com:443

   b. netsh http delete sslcert hostnameport=localhost:443

   c. netsh http delete sslcert hostnameport=fs.contoso.com:49443

4. 新しい証明書を追加します。

   a。 netsh http add sslcert hostnameport=fs.contoso.com:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable sslctlstorename=AdfsTrustedDevices

   b. netsh http add sslcert hostnameport=localhost:443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable

   c. netsh http add sslcert hostnameport=fs.contoso.com:49443 certhash=THUMBPRINT appid="{5d89a20c-beab-4389-9447-324788eb944a}" certstorename=My verifyclientcertrevocation=Enable clientcertnegotiation=Enable

5. 選択したサーバーで AD FS サービスを再起動します。

6. メンテナンスのために Web アプリケーション プロキシ サーバーのサブセットを削除します。

7. 選択した Web アプリケーション プロキシ サーバーで、MMC を使用して新しい証明書をインポートします。

8. 次のコマンドレットを使用して、Web アプリケーション プロキシ サーバーで新しい証明書を設定します。

   • Set-WebApplicationProxySslCertificate -Thumbprint " CERTTHUMBPRINT"

9. 選択した Web アプリケーション プロキシ サーバーでサービスを再開します。

10. 選択した Web アプリケーション プロキシ サーバーと AD FS サーバーを運用環境に戻します。

残りの AD FS と Web アプリケーション プロキシ サーバーを同じ方法で更新します。

AD FS と Web アプリケーション サーバーでは、エンドポイントで SSL 終了を実行しないすべてのファイアウォールがサポートされます。 また、AD FS と Web アプリケーション プロキシ サーバーには、次のメカニズムが組み込まれています。

• クロスサイト スクリプティングなどの一般的な Web 攻撃を防ぐ。
• AD FS プロキシを実行する。
• MS-ADFSPIP プロトコルによって定義されているすべての要件を満たす。

AD FS 2016 では、トークンのバインドが自動的に有効になり、プロキシとフェデレーションのシナリオでの複数の既知の問題の原因になります。 これらの問題がこのイベントの原因です。 このイベントを解決するには、次の PowerShell コマンドを実行して、トークンのバインドのサポートを削除します。

Set-AdfsProperties -IgnoreTokenBinding $true

Windows Server 2019 にアップグレードした後も、Web アプリケーション プロキシの構成バージョンは、引き続き Windows Server 2016 と表示されます。 Web アプリケーション プロキシに、Windows Server 2019 用の新しいバージョン固有の機能はありません。 AD FS でファーム動作レベルを上げた場合、Web アプリケーション プロキシは引き続き Windows Server 2016 と表示されます。 この動作は仕様です。

ESL を有効にすると、AD FS では、ADFSArtifactStore データベースでユーザーのアカウント アクティビティと既知の場所が追跡されます。 このデータベースは、追跡されるユーザーと既知の場所の数に比例してスケーリングされます。 ESL の有効化を計画するとき、ADFSArtifactStore データベースは 10 万ユーザーあたり最大 1 GB の割合で増加すると見積もることができます。

AD FS ファームで Windows Internal Database が使用されている場合、データベース ファイルの既定の場所は C:\Windows\WID\Data です。 このドライブがいっぱいにならないよう、ESL を有効にする前に、少なくとも 5 GB の空き記憶域があることを確認してください。 ESL を有効にした後は、ディスク記憶域に加えて、プロセス メモリの総量も、50 万人以下のユーザーに対して、最大 1 GB の RAM が追加されるものとして計画します。

イベントのテキストを次に示します。

Active Directory trust enumeration was unable to enumerate one of more domains due to the following error. Enumeration will continue but the Active Directory identifier list may not be correct. Validate that all expected Active Directory identifiers are present by running Get-ADFSDirectoryProperties.

このイベントは、信頼されているフォレストのチェーン内のすべてのフォレストが AD FS によって列挙され、すべてのフォレストへの接続が試みられたときに、フォレストが信頼されていないと発生します。 たとえば、AD FS フォレスト A とフォレスト B が信頼されていて、フォレスト B とフォレスト C が信頼されているとします。 AD FS は 3 つのすべてのフォレストを列挙し、フォレスト A とフォレスト C の間の信頼を検出しようとします。失敗したフォレストのユーザーを AD FS によって認証する必要がある場合は、AD FS フォレストと、失敗しているフォレストとの間に信頼関係を設定します。 失敗したフォレストのユーザーを AD FS によって認証すべきでない場合は、このイベントを無視してください。

イベントのテキストを次に示します。

Microsoft.IdentityServer.AuthenticationFailedException: MSIS5015: Authentication of the presented token failed. Token Binding claim in token must match the binding provided by the channel.

AD FS 2016 では、トークンのバインドが自動的に有効になり、プロキシとフェデレーションのシナリオでの複数の既知の問題の原因になります。 これらの問題がこのイベントの原因です。 このイベントを解決するには、次の PowerShell コマンドを実行して、トークンのバインドのサポートを削除します。

Set-AdfsProperties -IgnoreTokenBinding $true

イベントのテキストを次に示します。

System.ServiceModel.FaultException: The formatter threw an error while trying to deserialize the message: There was an error while trying to deserialize parameter schemas.microsoft.com/ws/2009/12/identityserver/protocols/policystore:maxBehaviorLevel". The InnerException message was "Invalid enum value 'Win2019' cannot be deserialized into type 'Microsoft.IdentityServer.FarmBehavior'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

このイベントは、次の両方が当てはまる場合に発生します。

• 混合モードのファームを使用している。
• ファームの最大動作レベル情報が AD FS 2019 からプライマリ フェデレーション サーバーに提供され、フェデレーション サーバー バージョン 2016 で認識されない。

MaxBehaviorLevel の値 Win2019 は、2 か月後に古くなり、ファームから自動的に削除されるまで、AD FS 2019 によってファーム内で共有されます。 このメッセージが発生しないようにするには、プライマリ フェデレーション ロールを最新バージョンのフェデレーション サーバーに移行します。 「AD FS ファームを Windows Server 2019 ファーム動作レベルにアップグレードするには」の手順に従ってください。