Microsoft Entra ID と Office 365 での AD FS の問題のトラブルシューティング

2025-01-15

この記事では、Microsoft Entra ID または Office 365 のフェデレーションユーザーの認証に関する問題のワークフローのトラブルシューティングについて説明します。

元の KB 番号: 3079872

現象

domainxx.onmicrosoft.com UPN サフィックスを持つマネージドクラウド専用ユーザーが問題なくサインインできる場合でも、フェデレーションユーザーは Office 365 または Microsoft Azure にサインインできません。
フェデレーションユーザーの場合、Active Directory フェデレーションサービス (AD FS) (AD FS) または STS へのリダイレクトは行われません。または、"ページを表示できません" というエラーがトリガーされます。
AD FS で認証しようとすると、ブラウザーで証明書関連の警告が表示されます。証明書の検証が失敗するか、証明書が信頼されていないことを示します。
"不明な認証方法" エラーまたは AuthnContext がサポートされていないことを示すエラー。また、Office 365 からリダイレクトされるときに AD FS または STS レベルでエラーが発生します。
AD FS が "アクセスが拒否されました" エラーをスローします。
AD FS は、サイトへのアクセスに問題があることを示すエラーをスローします。参照 ID 番号が含まれています。
ユーザーは、AD FS レベルで資格情報の入力を繰り返し求められます。
フェデレーションユーザーは、外部ネットワークから認証したり、外部ネットワークルートを取得するアプリケーション (Outlook など) を使用したりすることはできません。
AD FS でトークン署名証明書が変更された後、フェデレーションユーザーはサインインできません。
フェデレーションユーザーが Microsoft Azure の Office 365 にサインインすると、"申し訳ありませんが、サインインできません" というエラーがトリガーされます。このエラーには、8004786C、80041034、80041317、80043431、80048163、80045C06、8004789A、BAD 要求などのエラーコードが含まれます。

トラブルシューティングのワークフロー

Access Microsoft Office Home、フェデレーションユーザーのサインイン名 (someone@example. を入力しますcom)。 Tab を押してログインボックスからフォーカスを削除した後、ページの状態が Redirecting に変わるかどうかを確認し、サインインのために Active Directory フェデレーションサービス (AD FS) にリダイレクトされます。

Note

Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。詳細については、非推奨の最新情報を参照してください。この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。

Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。 ノート: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に使用障害が発生する可能性があります。

リダイレクトが発生すると、次のページが表示されます。
1. リダイレクトが発生せず、同じページにパスワードの入力を求めるメッセージが表示される場合は、Microsoft Entra ID または Office 365 がフェデレーションするユーザーまたはユーザーのドメインを認識しないことを意味します。 Microsoft Entra ID または Office 365 と AD FS サーバーの間にフェデレーション信頼があるかどうかを確認するには、Azure AD PowerShell から Get-msoldomain コマンドレットを実行します。ドメインがフェデレーションされている場合、次のスクリーンショットのように、その認証プロパティは Federated として表示されます。
2. リダイレクトが発生しても、サインインのために AD FS サーバーにリダイレクトされない場合は、AD FS サービス名が正しい IP に解決されるかどうか、および TCP ポート 443 でその IP に接続できるかどうかを確認します。
  
  ドメインが Federated として表示される場合は、次のコマンドを実行してフェデレーション信頼に関する情報を取得します。
```
Get-MsolFederationProperty -DomainName <domain>
Get-MsolDomainFederationSettings -DomainName <domain>
```
  Office 365 または Microsoft Entra ID によって構成されているフェデレーションパートナーの URI、URL、証明書を確認します。
AD FS にリダイレクトされた後、ブラウザーは証明書の信頼関連エラーをスローする可能性があります。一部のクライアントとデバイスでは、AD FS との SSL (Secure Sockets Layer) セッションを確立できないことがあります。この問題を解決するには、次の手順に従ってください。
1. クライアントに提示される AD FS サービス通信証明書が、AD FS で構成されたものと同じであることを確認します。
  
  理想的には、AD FS サービス通信証明書は、AD FS サービスとの SSL トンネルを確立しようとしたときにクライアントに提示される SSL 証明書と同じである必要があります。
  
  AD FS 2.0 の場合:
  - 証明書を IIS >既定の最初のサイトにバインドします。
  - AD FS スナップインを使用して、サービス通信証明書と同じ証明書を追加します。
  AD FS 2012 R2 の場合:
  - AD FS スナップインまたは Add-adfscertificate コマンドを使用して、サービス通信証明書を追加します。
  - Set-adfssslcertificate コマンドを使用して、SSL バインディングに同じ証明書を設定します。
2. AD FS サービス通信証明書がクライアントによって信頼されていることを確認します。
3. SNI 対応でないクライアントが AD FS または WAP 2-12 R2 との SSL セッションを確立しようとすると、試行が失敗する可能性があります。この場合は、AD FS または WAP サーバーにフォールバックエントリを追加して、SNI 以外のクライアントをサポートすることを検討してください。詳細については、「 Web アプリケーションプロキシおよび AD FS 2012 R2 で SNI 対応以外のクライアントをサポートする方法を参照してください。

Office 365 からリダイレクトされるときに、AD FS または STS レベルで AuthnContext がサポートされていないことを示す "不明な認証方法" エラーまたはエラーが発生する可能性があります。認証方法を適用するパラメーターを使用して AD FS または STS にリダイレクトする場合に最も一般的です。認証方法を強制するには、次のいずれかの方法を使用します。

WS-Federation の場合は、WAUTH クエリ文字列を使用して、優先認証方法を強制します。

SAML 2.0 の場合は、以下を使用します。

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

適用された認証方法が正しくない値で送信された場合、またはその認証方法が AD FS または STS でサポートされていない場合は、認証される前にエラーメッセージが表示されます。

次の表は、WS-Federation パッシブ認証のために AD FS によって認識される認証の種類 URI を示しています。

必要な認証方法	wauth URI
ユーザー名とパスワードの認証	urn:oasis:names:tc:SAML:1.0:am:password
SSL クライアント認証	urn:ietf:rfc:2246
Windows 統合認証	urn:federation:authentication:windows

サポートされている SAML 認証コンテキストクラス

認証方法	認証コンテキストクラスの URI
ユーザー名とパスワード	urn:oasis:names:tc:SAML:2.0:ac:classes:Password
パスワードで保護されたトランスポート	urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
トランスポート層セキュリティ (TLS) クライアント	urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
X.509 証明書	urn:oasis:names:tc:SAML:2.0:ac:classes:X509
統合 Windows 認証	urn:federation:authentication:windows
Kerberos	urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

認証方法が AD FS レベルでサポートされていることを確認するには、次の点を確認します。

AD FS 2.0

/adfs/ls/web.config で、認証の種類のエントリが存在することを確認します。

<microsoft.identityServer.web>
<localAuthenticationTypes>
 < add name="Forms" page="FormsSignIn.aspx" />  
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2.0: ローカル認証の種類を変更する方法

AD FS 2012 R2

AD FS 管理で、AD FS スナップインで 認証ポリシー を選択します。
[プライマリ認証] セクションで、[グローバル設定の横にある Edit を選択します。 [認証ポリシー 右クリックし グローバルプライマリ認証の編集 選択することもできます。または、 Actions ペインで、[グローバルプライマリ認証編集を選択します。
[グローバル認証ポリシーの編集 ] ウィンドウの [ Primary ] タブで、グローバル認証ポリシーの一部として設定を構成できます。たとえば、プライマリ認証の場合、 Extranet と Intranet で使用可能な認証方法を選択できます。

必要な認証方法のチェックボックスがオンになっていることを確認します。

AD FS にアクセスして資格情報を入力しても認証できない場合は、次の問題を確認してください。
1. Active Directory レプリケーションの問題
  
  AD レプリケーションが切断された場合、ユーザーまたはグループに加えられた変更がドメインコントローラー間で同期されない可能性があります。ドメインコントローラー間には、AD FS 応答 (認証と要求) に影響するパスワード、UPN、GroupMembership、または Proxyaddress の不一致が存在する可能性があります。 AD FS と同じサイト上のドメインコントローラーの確認を開始する必要があります。 repadmin /showrepsまたは DCdiag /v コマンドを実行すると、AD FS が接続する可能性が最も高いドメインコントローラーに問題があるかどうかが明らかになります。
  
  また、AD レプリケーションの概要を収集して、すべてのドメインコントローラーで AD の変更が正しくレプリケートされていることを確認することもできます。 repadmin /showrepl * /csv > showrepl.csv出力は、レプリケーションの状態を確認するのに役立ちます。詳細については、「 Active Directory レプリケーションの問題のトラブルシューティングを参照してください。
2. Active Directory でのアカウントのロックアウトまたは無効化
  
  エンドユーザーが AD FS を介して認証されると、アカウントがロックされているか無効になっていることを示すエラーメッセージが表示されません。 AD FS とログオンの監査から、パスワードが正しくないために認証に失敗したかどうか、アカウントが無効かロックされているかなどを判断できる必要があります。
  
  AD FS サーバーで AD FS とログオンの監査を有効にするには、次の手順に従います。
  1. ローカルポリシーまたはドメインポリシーを使用して、次のポリシーの成功と失敗を有効にします。
    - 監査ログオンイベント (〘〗 Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
    - [Audit Object Access] (オブジェクトアクセスの監査( Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
  2. 次のポリシーを無効にします。
    
    監査: 監査ポリシーサブカテゴリの設定 (Windows Vista 以降) を強制して、監査ポリシーカテゴリの設定を上書きする
    
    このポリシーは、 Computer configuration\Windows Settings\Security setting\Local Policy\Security Optionにあります。
    
    高度な監査を使用して構成する場合は、「 AD FS 2.0 のトラブルシューティングのためのコンピューターの構成を参照してください。
  3. 監査用に AD FS を構成します。
    1. AD FS 2.0 管理スナップインを開きます。
    2. 操作ペインで、 [フェデレーションサービスプロパティの編集] を選択します。
    3. [フェデレーションサービスプロパティ] ダイアログボックスの [イベント] タブを選択します。
    4. [成功の監査] チェックボックスと [失敗の監査] チェックボックスをオンにします。
    5. サーバーで GPupdate /force を実行します。
3. サービスプリンシパル名 (SPN) が正しく登録されていない
  
  重複する SPN または AD FS サービスアカウント以外のアカウントに登録されている SPN が存在する可能性があります。 AD FS ファームのセットアップでは、AD FS サービスを実行しているサービスアカウントの下に SPN HOST/AD FSservicename が追加されていることを確認します。サービスがネットワークサービスで実行されている AD FS スタンドアロンセットアップの場合、SPN は AD FS をホストしているサーバーコンピューターアカウントの下にある必要があります。
  
  AD FS サービスで断続的な認証エラーが発生する可能性があるため、AD FS サービスの SPN が重複していないことを確認します。 SPN を一覧表示するには、 SETSPN -L <ServiceAccount>を実行します。
  
  SETSPN -A HOST/AD FSservicename ServiceAccountを実行して SPN を追加します。
  
  SETSPN -X -Fを実行して、重複する SPN を確認します。
4. Active Directory での UPN の重複
  
  ユーザーは、SAMAccountName を使用している場合は AD FS を介して認証できますが、UPN の使用時に認証できない場合があります。このシナリオでは、Active Directory に同じ UPN を持つ 2 人のユーザーが含まれる場合があります。スクリプトを使用してユーザーを追加および変更すると、同じ UPN を持つ 2 人のユーザーが作成される可能性があります (ADSIedit など)。
  
  このシナリオで UPN を認証に使用すると、ユーザーは重複するユーザーに対して認証されます。そのため、指定された資格情報は検証されません。
  
  次のようなクエリを使用して、属性に同じ値を持つ複数のオブジェクトが AD に存在するかどうかを確認できます。
```
Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN
```
  UPN での認証要求が正しいオブジェクトに対して検証されるように、重複するユーザーの UPN の名前が変更されていることを確認します。
5. Office 365 のログイン ID としてメールアドレスを使用していて、認証のために AD FS にリダイレクトされるときに同じ電子メールアドレスを入力するシナリオでは、監査ログに "NO_SUCH_USER" エラーが表示されて認証が失敗する可能性があります。 AD FS で UPN または SAMaccountname 以外の属性を使用して認証用のユーザーを検索できるようにするには、代替ログイン ID をサポートするように AD FS を構成する必要があります。詳しくは、「Configuring Alternate Login ID (代替ログイン ID の構成)」をご覧ください。
  
  AD FS 2012 R2 の場合
  1. Update 2919355をインストールします。
  2. ファーム内のいずれかのフェデレーションサーバーで次の PowerShell コマンドレットを実行して、AD FS 構成を更新します (WID ファームがある場合は、ファーム内のプライマリ AD FS サーバーでこのコマンドを実行する必要があります)。
```
Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY" -AlternateLoginID <attribute> -LookupForests <forest domain>
```
    Note
    
    AlternateLoginID は、ログインに使用する属性の LDAP 名です。 LookupForests は、ユーザーが属しているフォレスト DNS エントリの一覧です。
    
    代替ログイン ID 機能を有効にするには、AlternateLoginID パラメーターと LookupForests パラメーターの両方を null 以外の有効な値で構成する必要があります。
6. AD FS サービスアカウントには、証明書の秘密キーに署名している AD FS トークンに対する読み取りアクセス権がありません。このアクセス許可を追加するには、次の手順に従います。
  1. 新しいトークン署名証明書を追加すると、次の警告が表示されます。
    
    選択した証明書の秘密キーに、ファーム内の各サーバー上のこのフェデレーションサービスのサービスアカウントからアクセスできることを確認します。
  2. Startを選択し、Runを選択し、「mmc.exe」と入力して Enter キーを押します。
  3. Fileを選択し、スナップイン追加/削除を選択します。
  4. Certificates をダブルクリックします。
  5. 対象のコンピューターアカウントを選択し、次へを選択します。
  6. ローカルコンピューターを選択し、Finish を選択します。
  7. Certificates (ローカルコンピューター)を展開し、Persona l を展開して、Certificates を選択します。
  8. 新しいトークン署名証明書を右クリックし、[すべてのタスク] 選択し、[秘密キーの管理] を選択。
  9. AD FS 2.0 サービスアカウントの読み取りアクセスを追加し、 OKを選択します。
  10. 証明書 MMC を閉じます。
7. Windows 認証の Extended Protection オプションは、AD FS または LS 仮想ディレクトリで有効になっています。特定のブラウザーで問題が発生する可能性があります。 AD FS が資格情報の入力を繰り返し求め、IIS の AD FS または LS アプリケーションの Windows 認証に対して有効になっている拡張保護設定に関連している場合があります。
  
  認証の拡張保護が有効になっている場合、認証要求は、クライアントが接続しようとしているサーバーのサービスプリンシパル名 (SPN) と、統合 Windows 認証が行われる外部トランスポート層セキュリティ (TLS) チャネルの両方にバインドされます。拡張保護により、既存の Windows 認証機能が強化され、認証リレーまたは "中間者" 攻撃が軽減されます。ただし、特定のブラウザーは拡張保護設定では機能しません。代わりに、資格情報の入力を繰り返し求め、アクセスを拒否します。拡張保護を無効にすると、このシナリオで役立ちます。
  
  詳細については、「 AD FS 2.0: Fiddler Web デバッガーの使用中に資格情報の入力を継続的に求めるメッセージが表示されるを参照してください。
  
  AD FS 2012 R2 の場合
  
  拡張保護を無効にするには、次のコマンドレットを実行します。
```
Set-ADFSProperties -ExtendedProtectionTokenCheck None
```
8. 証明書利用者 (RP) 信頼の発行承認規則は、ユーザーへのアクセスを拒否する場合があります。 AD FS 証明書利用者信頼では、認証されたユーザーに証明書利用者のトークンを発行するかどうかを制御する発行承認規則を構成できます。管理者は、発行された要求を使用して、要求としてプルアップされたグループのメンバーであるユーザーへのアクセスを拒否するかどうかを決定できます。
  
  特定のフェデレーションユーザーが AD FS を介して認証できない場合は、Office 365 RP の発行承認規則を確認し、[すべてのユーザーへのアクセスを許可] 規則が構成されているかどうかを確認できます。
  
  この規則が構成されていない場合は、カスタム承認規則を使用して、そのルールの条件が影響を受けるユーザーに対して "true" と評価されるかどうかを確認します。詳細については、次のリソースを参照してください。
  AD FS サーバーに直接アクセスするときにイントラネットから認証できるが、AD FS プロキシ経由で AD FS にアクセスするときに認証できない場合は、次の問題を確認します。
  - AD FS サーバーと AD FS プロキシでの時刻同期の問題
    
    AD FS サーバーの時刻とプロキシの時刻が同期していることを確認します。AD FS サーバーの時刻がドメインコントローラー上の時刻から 5 分以上離れている場合、認証エラーが発生します。 AD FS プロキシの時刻が AD FS と同期されていない場合、プロキシの信頼は影響を受け、破損します。そのため、AD FS プロキシ経由の要求は失敗します。
  - AD FS サービスとの AD FS プロキシ信頼が正しく動作しているかどうかを確認します。プロキシの信頼が壊れている可能性がある場合は、プロキシ構成を再実行します。
AD FS がトークンを発行すると、Microsoft Entra ID または Office 365 によってエラーがスローされます。このような状況では、次の問題について確認します。
- トークンの AD FS によって発行される要求は、Microsoft Entra ID のユーザーの各属性と一致する必要があります。 Microsoft Entra ID または Office 365 のトークンでは、次の要求が必要です。
  
  WSFED:
  UPN: この要求の値は Microsoft Entra ID のユーザーの UPN と一致している必要があります。
  ImmutableID: この要求の値は、Microsoft Entra ID のユーザーの sourceAnchor または ImmutableID と一致している必要があります。
  
  Microsoft Entra ID で User 属性値を取得するには、次のコマンドラインを実行します。
```
Get-MsolUser -UserPrincipalName <UPN>
```
  SAML 2.0:
  IDPEmail: この要求の値は、Microsoft Entra ID のユーザーのユーザープリンシパル名と一致している必要があります。
  NAMEID: この要求の値は、Microsoft Entra ID のユーザーの sourceAnchor または ImmutableID と一致している必要があります。
  
  詳細については、「シングルサインオンを実装するための SAML 2.0 ID プロバイダーの使用」を参照してください。
  
  例:
  この問題は、同期されたユーザーの UPN が AD で変更され、オンラインディレクトリが更新されていない場合に発生する可能性があります。このシナリオでは、AD でユーザーの UPN を修正するか (関連するユーザーのログオン名と一致するように) または次のコマンドレットを実行して、Online ディレクトリ内の関連ユーザーのログオン名を変更できます。
```
Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -NewUserPrincipalName [DomainUPN-AD]
```
  また、AADsync を使用して MAIL を UPN として同期し、EMPID を SourceAnchor として同期していますが、AD FS レベルの証明書利用者要求規則が更新されず、MAIL が UPN として、EMPID が ImmutableID として送信されていない可能性があります。
- AD FS と Office 365 の間にトークン署名証明書の不一致があります。
  
  これは最も一般的な問題の 1 つです。 AD FS ではトークン署名証明書を使用して、ユーザーまたはアプリケーションに送信されるトークンに署名します。 AD FS と Office 365 の間の信頼は、このトークン署名証明書に基づくフェデレーション信頼です (たとえば、Office 365 は、受信したトークンが信頼する要求プロバイダー [AD FS サービス] のトークン署名証明書を使用して署名されていることを確認します)。
  
  ただし、AD FS のトークン署名証明書が、証明書の自動ロールオーバーまたは管理者の介入によって変更された場合 (証明書の有効期限が切れた後または前)、フェデレーションドメインの Office 365 テナントで新しい証明書の詳細を更新する必要があります。これは自動的には発生しない可能性があります。管理者の介入が必要な場合があります。 AD FS のプライマリトークン署名証明書が Office 365 で認識されているものと異なる場合、AD FS によって発行されたトークンは Office 365 によって信頼されません。そのため、フェデレーションユーザーはサインインできません。
  
  Office 365 または Microsoft Entra ID は、サービスがパブリックネットワーク経由で到達可能であると仮定して、AD FS サービスへのアクセスを試みます。 AD FS のフェデレーションメタデータを定期的にポーリングして、AD FS の構成変更 (主にトークン署名証明書情報) をプルしようとします。このプロセスが機能していない場合、グローバル管理者は Office 365 ポータルで、トークン署名証明書の有効期限と更新に必要なアクションに関する警告を受け取る必要があります。
  
  Get-MsolFederationProperty -DomainName <domain>を使用して、AD FS と Office 365 にフェデレーションプロパティをダンプできます。ここでは、TokenSigningCertificate 拇印を比較して、フェデレーションドメインの Office 365 テナント構成が AD FS と同期しているかどうかを確認できます。トークン署名証明書の構成に不一致がある場合は、次のコマンドを実行して更新します。
```
Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
```
  次のツールを実行して、トークン署名証明書の自動証明書ロールオーバーを監視し、Office 365 テナントを自動的に更新するタスクを AD FS サーバーでスケジュールすることもできます。
  
  AD FS でのシングルサインオンの確認と管理
- Office 365 RP の発行変換要求規則が正しく構成されていません。
  
  複数の TLD (最上位ドメイン) があるシナリオでは、RP 信頼の作成時と更新時に Supportmultipledomain スイッチが使用されなかった場合にログオンの問題が発生する可能性があります。詳細については、「 SupportMultipleDomain スイッチ」を参照してください。Office 365 への SSO を管理する場合。
- Microsoft Entra ID または Office 365 に対してトークンが発行されるときに、AD FS または STS によってトークン暗号化が使用されていないことを確認します。
Windows 資格情報マネージャーには、古いキャッシュされた資格情報があります。

ワークステーションからポータル (または Outlook を使用している場合) へのログイン中に、ユーザーが資格情報の入力を求められたときに、Windows 資格情報マネージャー (Control Panel\User Accounts\Credential Manager) にターゲット (Office 365 または AD FS サービス) の資格情報が保存されることがあります。これにより、資格情報のプロンプトをしばらく防ぐことができますが、ユーザーパスワードが変更され、資格情報マネージャーが更新されないと、問題が発生する可能性があります。そのシナリオでは、古い資格情報が AD FS サービスに送信されるため、認証が失敗します。 Windows 資格情報マネージャーでキャッシュされた資格情報を削除または更新すると、役立つ場合があります。
Office 365 の証明書利用者信頼で構成されているセキュリティで保護されたハッシュアルゴリズムが SHA1 に設定されていることを確認します。

STS/AD FS と Microsoft Entra ID/Office 365 の間の信頼が SAML 2.0 プロトコルを使用している場合、デジタル署名用に構成されたセキュアハッシュアルゴリズムは SHA1 である必要があります。
上記の原因が該当しない場合は、Microsoft でサポートケースを作成し、Office 365 テナントの下にユーザーアカウントが一貫して表示されるかどうかを確認するように依頼します。詳細については、「 A フェデレーションユーザーは、Office 365、Azure、または Intune へのサインイン時に資格情報の入力を繰り返し求められるを参照してください。

アクセスするクラウドサービス (Microsoft Entra ID と統合) によって、AD FS に送信される認証要求が異なる場合があります。たとえば、特定の要求に Wauth や Wfresh などの追加のパラメーターが含まれる場合があり、これらのパラメーターによって AD FS レベルで動作が異なる場合があります。

AD FS バイナリは、既知の問題の修正プログラムを含むように常に更新することをお勧めします。最新の更新プログラムの詳細については、次の表を参照してください。

AD FS 2.0	AD FS 2012 R2
Active Directory フェデレーションサービス (AD FS) (AD FS) 2.0 の更新プログラムロールアップ 3 の説明 AD FS サーバーにセキュリティ更新プログラムの2843638をインストールした後、更新プログラムを使用していくつかの問題を解決できます	Windows RT 8.1、Windows 8.1、および Windows Server 2012 R2 の 2014 年 12 月の更新プログラムのロールアップ

次の方法で共有

Microsoft Entra ID と Office 365 での AD FS の問題のトラブルシューティング

現象

トラブルシューティングのワークフロー

フィードバック

その他のリソース