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

  • [アーティクル]

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

適用対象: Windows Server 2012 R2
元の 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. Microsoft Office Home にアクセスし、フェデレーション ユーザーのサインイン名 (他のユーザー@の例) を入力します。com)。 Tab キーを押してログイン ボックスからフォーカスを削除した後、ページの状態が [リダイレクト] に変わるかどうかをチェックし、サインインのために Active Directory フェデレーション サービス (AD FS) にリダイレクトされます。

    注:

    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実行します。 ドメインがフェデレーションされている場合、次のスクリーンショットのように、その認証プロパティ はフェデレーションとして表示されます。

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

    2. リダイレクトが発生してもサインインのために AD FS サーバーにリダイレクトされない場合は、AD FS サービス名が正しい IP に解決されるかどうか、および TCP ポート 443 でその IP に接続できるかどうかをチェックします。

      ドメインがフェデレーションとして表示 される場合は、次のコマンドを実行してフェデレーション信頼に関する情報を取得します。

      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 クエリ文字列を使用して、優先認証方法を強制します。

    • SAML2.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. [プライマリ認証] セクションで、[グローバル設定] の横にある [編集] を選択します。 [ 認証ポリシー ] を右クリックし、[ グローバル プライマリ認証の編集] を選択することもできます。 または、[ 操作 ] ウィンドウで、[ グローバル プライマリ認証の編集] を選択します。

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

    必要な認証方法チェックボックスが選択されていることを確認します。

  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 Management スナップインを開きます。

        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" エラーが表示され、認証が失敗する可能性があります。 UPN または SAMaccountname 以外の属性を使用して AD FS で認証のユーザーを検索できるようにするには、代替ログイン ID をサポートするように AD FS を構成する必要があります。 詳細については、「 代替ログイン 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>

        注:

        AlternateLoginID は、ログインに使用する属性の LDAP 名です。 LookupForests は、ユーザーが属しているフォレスト DNS エントリの一覧です。

        代替ログイン ID 機能を有効にするには、AlternateLoginID パラメーターと LookupForests パラメーターの両方を null 以外の有効な値で構成する必要があります。

    6. AD FS サービス アカウントには、証明書の秘密キーに署名している AD FS トークンに対する読み取りアクセス権がありません。 このアクセス許可を追加するには、次の手順に従います。

      1. 新しい Token-Signing 証明書を追加すると、次の警告が表示されます。

        選択した証明書の秘密キーに、ファーム内の各サーバー上のこのフェデレーション サービスのサービス アカウントからアクセスできることを確認します。

      2. [ スタート] を選択し、[ 実行] を選択し、「mmc.exe」と入力し、Enter キーを押します。

      3. [ ファイル] を選択し、[ スナップインの追加と削除] を選択します。

      4. [証明書] をダブルクリックします。

      5. 対象のコンピューター アカウントを選択し、[ 次へ] を選択します。

      6. [ ローカル コンピューター] を選択し、[完了] を選択 します。

      7. [ 証明書 (ローカル コンピューター)] を展開し、[ Persona l] を展開し、[証明書] を選択 します。

      8. 新しいトークン署名証明書を右クリックし、[ すべてのタスク] を選択し、[ 秘密キーの管理] を選択します。

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

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

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

    7. Windows 認証の [拡張保護 ] オプションは、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 サーバーでスケジュールすることもできます。

    • Office 365 RP の発行変換要求規則が正しく構成されていません。

      複数の TLD (最上位ドメイン) があるシナリオでは、RP 信頼の作成時と更新時に Supportmultipledomain スイッチが使用されなかった場合にログオンの問題が発生する可能性があります。 詳細については、「Office 365への SSO を管理する場合の SupportMultipleDomain スイッチ」を参照してください。

    • トークンが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 Credential Manager でキャッシュされた資格情報を削除または更新すると、役立つ場合があります。

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

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

  8. 上記のどの原因も状況に該当しない場合は、Microsoft でサポート ケースを作成し、ユーザー アカウントがOffice 365 テナントの下に一貫して表示されるかどうかをチェックするように依頼します。 詳細については、「フェデレーション ユーザーが、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 月の更新プログラムのロールアップ