次の方法で共有


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

この記事では、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 要求などのエラー コードが含まれます。

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

  1. 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 日以降に使用障害が発生する可能性があります。

    リダイレクトが発生すると、次のページが表示されます。

    A D F S リダイレクトが発生したときに表示されるページ。

    1. リダイレクトが発生せず、同じページにパスワードの入力を求めるメッセージが表示される場合は、Microsoft Entra ID または Office 365 がフェデレーションするユーザーまたはユーザーのドメインを認識しないことを意味します。 Microsoft Entra ID または Office 365 と AD FS サーバーの間にフェデレーション信頼があるかどうかを確認するには、Azure AD PowerShell から Get-msoldomain コマンドレットを実行します。 ドメインがフェデレーションされている場合、次のスクリーンショットのように、その認証プロパティは Federated として表示されます。

      コマンドレット Get-msoldomain の出力は、Microsoft Entra ID または Office 365 と A D F S サーバーの間にフェデレーション信頼があることを示しています。

    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、証明書を確認します。

  2. AD FS にリダイレクトされた後、ブラウザーは証明書の信頼関連エラーをスローする可能性があります。一部のクライアントとデバイスでは、AD FS との SSL (Secure Sockets Layer) セッションを確立できないことがあります。 この問題を解決するには、次の手順に従ってください。

    1. クライアントに提示される AD FS サービス通信証明書が、AD FS で構成されたものと同じであることを確認します。

      A D F S サービス通信証明書が、A D F S で構成されたものと同じであることを確認します。

      理想的には、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 対応以外のクライアントをサポートする方法を参照してください。

  3. 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

    1. AD FS 管理で、AD FS スナップインで 認証ポリシー を選択します。

    2. [プライマリ認証] セクションで、[グローバル設定の横にある Edit を選択します。 [認証ポリシー 右クリックし グローバル プライマリ認証の編集 選択することもできます。 または、 Actions ペインで、[グローバル プライマリ認証 編集を選択します。

    3. [グローバル認証ポリシーの 編集 ] ウィンドウの [ Primary ] タブで、グローバル認証ポリシーの一部として設定を構成できます。 たとえば、プライマリ認証の場合、 Extranet と Intranet で使用可能な認証方法を選択できます。

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

  4. 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. [成功の監査] チェック ボックスと [失敗の監査] チェック ボックスをオンにします。

          [フェデレーション サービスのプロパティ] ダイアログ ボックスの [イベント] タブにある [成功監査] チェック ボックスと [失敗監査] チェック ボックスをオンにして、D F S 監査を有効にします。

        5. サーバーで GPupdate /force を実行します。

    3. サービス プリンシパル名 (SPN) が正しく登録されていない

      重複する SPN または AD FS サービス アカウント以外のアカウントに登録されている SPN が存在する可能性があります。 AD FS ファームのセットアップでは、AD FS サービスを実行しているサービス アカウントの下に SPN HOST/AD FSservicename が追加されていることを確認します。 サービスがネットワーク サービスで実行されている AD FS スタンドアロン セットアップの場合、SPN は AD FS をホストしているサーバー コンピューター アカウントの下にある必要があります。

      [Active Directory フェデレーション サービス (AD FS)プロパティ] ダイアログ ボックスの [ログオン] タブで、A D F S サービス名を入力します。

      AD FS サービスで断続的な認証エラーが発生する可能性があるため、AD FS サービスの SPN が重複していないことを確認します。 SPN を一覧表示するには、 SETSPN -L <ServiceAccount>を実行します。

      SETSPN -L コマンドを実行して、A D F S サービスの SPN をリストします。

      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. 新しいトークン署名証明書を右クリックし、[すべてのタスク] 選択し、[秘密キーの管理] を選択

        A D F S サービス アカウントの読み取りアクセス許可を追加する手順。

      9. AD FS 2.0 サービス アカウントの読み取りアクセスを追加し、 OKを選択します。

      10. 証明書 MMC を閉じます。

    7. Windows 認証の Extended Protection オプションは、AD FS または LS 仮想ディレクトリで有効になっています。 特定のブラウザーで問題が発生する可能性があります。 AD FS が資格情報の入力を繰り返し求め、IIS の AD FS または LS アプリケーションの Windows 認証に対して有効になっている拡張保護設定に関連している場合があります。

      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 プロキシ信頼が正しく動作しているかどうかを確認します。 プロキシの信頼が壊れている可能性がある場合は、プロキシ構成を再実行します。

  5. 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 によってトークン暗号化が使用されていないことを確認します。

  6. Windows 資格情報マネージャーには、古いキャッシュされた資格情報があります。

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

  7. Office 365 の証明書利用者信頼で構成されているセキュリティで保護されたハッシュ アルゴリズムが SHA1 に設定されていることを確認します。

    STS/AD FS と Microsoft Entra ID/Office 365 の間の信頼が SAML 2.0 プロトコルを使用している場合、デジタル署名用に構成されたセキュア ハッシュ アルゴリズムは SHA1 である必要があります。

  8. 上記の原因が該当しない場合は、Microsoft でサポート ケースを作成し、Office 365 テナントの下にユーザー アカウントが一貫して表示されるかどうかを確認するように依頼します。 詳細については、「 A フェデレーション ユーザーは、Office 365、Azure、または Intune へのサインイン時に資格情報の入力を繰り返し求められるを参照してください。

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

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

    AD FS 2.0 AD FS 2012 R2
    Windows RT 8.1、Windows 8.1、および Windows Server 2012 R2 の 2014 年 12 月の更新プログラムのロールアップ