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 へ:
  • AD FS 1 からアップグレードします。x から AD FS 2.0

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

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

この構成はサポートされていますが、AD FS 2016 の新機能はサポートされません。 この構成は、AD FS 2012 R2 から AD FS 2016 への移行中に一時的なものになります。 長期間使用しないでください。

はい。ただし、副作用として:

• Microsoft Entra ID はフェデレーション メタデータにアクセスできないため、トークン署名証明書の更新を手動で管理する必要があります。 トークン署名証明書を手動で更新する方法の詳細については、「 Office 365 と Microsoft Entra ID のフェデレーション証明書を更新する」を参照してください。
• 従来の認証フロー (ExO プロキシ認証フローなど) を使用することはできません。

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

• ロード バランサーは、IP アフィニティを使用して構成しないでください。 特定の Exchange Online シナリオでは、IP アフィニティによってサーバーのサブセットに過度の負荷がかかる可能性があります。
• ロード バランサーは、HTTPS 接続を終了して、AD FS サーバーへの新しい接続を開始してはなりません。
• ロード バランサーは、接続 IP アドレスが AD FS に送信されるときに、HTTP パケット内のソース 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 の多要素認証プロバイダーを参照してください。 私たちが知らないプロバイダーが利用可能な場合があります。 新しいリストが見つかると、一覧が更新されます。

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

現在、次のサードパーティ プロバイダーが認識されています。 私たちが知らないプロバイダーが利用可能な場合があります。 新しいリストが見つかったら、この一覧を更新します。

• F5 アクセス ポリシー マネージャー
• Citrix アプリケーション配信コントローラー (ADC)

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

Apple は、AD FS に対する認証を行う iOS アプリからの呼び出しに影響する可能性がある App Transport Security (ATS) と呼ばれる一連の要件をリリースしました。 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 プロトコルの管理」を参照してください。

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

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

更新トークンの有効期間は、AD FS がリモート要求プロバイダーの信頼から取得したトークンの有効期間です。 アクセス トークンの有効期間は、アクセス トークンが発行される証明書利用者のトークンの有効期間です。

カスタマイズしたid_tokenを使用して、id_token自体に関連情報を追加できます。 詳細については、「 id_tokenで出力する要求をカスタマイズする」を参照してください。

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

発行規則の例:

=> 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 では、リソース値をスコープ パラメーターに埋め込んで渡すことができます。 scope パラメーターは、各エントリがリソース/スコープとして構造化されているスペース区切りのリストとして編成できます。

Windows Server 2019 の AD FS では、OAuth 承認コード付与フローのコード交換用証明キー (PKCE) がサポートされています。

サポート：

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

サポートされていません:

• vpn_cert。 アプリケーションが VPN 証明書を要求できるようにします。これは、EAP-TLS 認証を使用して VPN 接続を確立するために使用できます。 このスコープはサポートされなくなりました。
• 電子メール。 アプリケーションがサインインしているユーザーの電子メール要求を要求できるようにします。 このスコープはサポートされなくなりました。
• プロフィール。 アプリケーションがサインインしているユーザーのプロファイル関連の要求を要求できるようにします。 このスコープはサポートされなくなりました。

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 証明書とは異なるキーを持つことができます。 同じ 要件を満たす必要があります。

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

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

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

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: PSSOLifeTimeMins によって管理される最大 90 日間。 (デバイスが少なくとも 14 日ごとに使用されている場合。この時間枠は DeviceUsageWindow によって制御されます)。

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

• access_token: 証明書利用者に基づいて、既定で 1 時間。

• id_token: access_tokenと同じです。

未登録のデバイス

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

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

• access_token: 証明書利用者に基づいて、既定で 1 時間。

• id_token: access_tokenと同じです。

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

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

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

そのため、HSTS をダウングレードできないため、AD FS サーバーに HSTS は必要ありません。 AD FS サーバーは、HTTP を使用できないため、および Cookie がセキュリティで保護されたマークが付けられているため、コンプライアンス要件を満たしています。

最後に、AD FS 2016 (最も up-to-date パッチを含む) と AD FS 2019 では、HSTS ヘッダーの出力がサポートされます。 この動作を構成するには、「 AD FS を使用して 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 (最新のパッチが最も up-to) 以降のバージョンでは、X-Forwarded-For ヘッダーのキャプチャもサポートされています。 レイヤー 3 で転送されないロード バランサーまたはネットワーク デバイス (IP は保持されます) では、受信クライアント IP を業界標準の X-Forwarded-For ヘッダーに追加する必要があります。

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

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

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

Android ADAL ライブラリを使用するアプリの場合、フェデレーション ユーザーの Microsoft Entra ID への認証が失敗する可能性があります。 サインイン ページを表示しようとすると、アプリは AuthenticationException を取得します。 Chrome ブラウザーでは、AD FS サインイン ページが安全でないと記述されている可能性があります。

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

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

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

また、 可能な場合は必ず [証明書パスにすべての証明書を含める ] を選択し、 すべての拡張プロパティをエクスポートしてください。

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. 既存の証明書を削除します。

   ある。 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. 新しい証明書を追加します。

   ある。 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 データベースが 100,000 ユーザーあたり最大 1 GB の割合で拡張されると見積もることができます。

AD FS ファームが Windows 内部データベースを使用している場合、データベース ファイルの既定の場所は C:\Windows\WID\Data です。 このドライブの空き容量を防ぐには、ESL を有効にする前に、少なくとも 5 GB の空きストレージがあることを確認してください。 ディスク ストレージに加えて、500,000 以下のユーザー人口に対して最大 1 GB の RAM で ESL を有効にした後に、合計プロセス メモリを拡大することを計画します。

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

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 では認識されません。

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

この問題を解決するには、次の手順を実行します:

1. AD FS 管理コンソールを起動します。
2. [サービス>スコープの説明] に移動します。
3. [スコープの説明] で、[ その他のオプション] を選択し、[ スコープの説明の追加] を選択します。
4. [ 名前] に 「ugs」と入力し、 適用>OK を選択します。
5. 管理者として PowerShell を起動します。
6. コマンド Get-AdfsApplicationPermission を実行します。 ScopeNames :{openid, aza}値を持つClientRoleIdentifierを探します。 ObjectIdentifier の値を書き留めておきます。
7. コマンド Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs' を実行します。
8. AD FS サービスを再起動します。
9. クライアントで、クライアントを再起動します。 Windows Hello for Business を構成するように求められます。
10. 構成ウィンドウが表示されない場合は、トレース ログを収集し、さらにトラブルシューティングを行う必要があります。

はい。ただし、Windows Server 2019 以降でのみ使用できます。 スコープ パラメーターは、各エントリがリソースまたはスコープ ( <create a valid sample request> など) として構造化されたスペース区切りのリストとして編成できます。

はい。ただし、Windows Server 2019 以降でのみ使用できます。 AD FS では、OAuth 承認コード付与フローのコード交換用証明キー (PKCE) がサポートされています。

AD FS を 使用した Azure Virtual Desktop のシングル サインオンの構成に関するページに記載されているように、AD FS は、特定の Windows Hello For Business シナリオで認証されたアカウントに代わってログオン証明書を登録します。 既定では、これらの証明書には SID 拡張機能が含まれていないので、KDC によって拒否されます。 KDC の要件の詳細については、「 KB5014754: Windows ドメイン コントローラーでの証明書ベースの認証の変更」を参照してください。 Windows Server 2019、Windows Server 2022、および Windows Server 2025 の AD FS の更新プログラムを使用して、発行された証明書に強力なマッピング要件を満たす SID 拡張機能が含まれるようにします。 この動作を有効にするには、ファームのすべての AD FS サーバーに最新の Windows 更新プログラムをインストールし、プライマリ AD FS サーバーで次のコマンドレットを実行します。

• Set-AdfsCertificateAuthority -EnrollmentAgent -AddSIDCertificateExtension $true