【Entra ID】サインインログに失敗理由が出ない時の監査ログと期間指定の見方

Entra ID(旧Azure AD)のサインインログは、ユーザーがサインインに失敗した原因を特定するための重要な情報源です。しかし、実際にサインインログを確認すると「失敗理由」の欄が空欄になっていることがあります。このような場合、管理者は原因の切り分けに苦慮し、適切な対応が遅れてしまう可能性があります。本記事では、サインインログに失敗理由が表示されない原因と、監査ログや期間指定を活用して問題を特定する方法を詳しく解説します。会社のIT管理に携わる方が、迅速かつ的確にトラブルシューティングを行えるよう、具体的な手順と注意点をまとめました。

サインインログに失敗理由が出ない原因

サインインログで失敗理由が空欄になる主な原因は、以下の3つに大別されます。これらの要因を理解しておくことで、問題発生時の初動が速まります。

1. クライアント側の認証エラーがログに記録されないパターン

サインイン要求がEntra IDに到達する前に、クライアント側でブロックされた場合です。例えば、端末の時刻が大きくずれている、ブラウザに古い認証キャッシュが残っている、OSの資格情報マネージャーに誤った資格情報が保存されている、などのケースが該当します。これらのエラーはクライアント側で完結するため、Entra ID側のサインインログとしては「試行すら行われなかった」という扱いになり、ログそのものが存在しない、または失敗理由が記録されません。

2. 条件付きアクセスが適用される前の段階で発生するエラー

Entra IDの条件付きアクセスポリシーは、ユーザーが認証された後に評価されます。しかし、認証プロセスの初期段階(デバイスの登録状況不足やテナントの制限など)で拒否された場合、サインインログには「失敗」としか表示されず、詳細な理由コードが付与されないことがあります。この現象は、特にゲストユーザーや外部テナントとの連携時に発生しやすいと言われています。

3. テナント設定やライセンスに起因するログ記録の制限

Entra IDのサインインログは、無償ライセンス(Free)では直近7日間のみ保存され、詳細な理由が省かれる項目があります。また、診断設定(Diagnostic Settings)でログの出力先が正しく構成されていない場合も、期待するログが得られない原因になります。特に、サードパーティのSIEMツールで監査ログを取り込んでいる場合、シンタックスの違いにより失敗理由が空欄になる可能性もあります。

トラブルシューティング手順

以下の手順に沿って、原因を段階的に切り分けてください。各手順は管理者権限が必要なものも含まれますので、適切な権限を持ったアカウントで実行してください。

1. 端末側の時刻と認証キャッシュを確認する:社用PCのシステム時刻が正しいか確認してください。また、ブラウザのシークレットモードでサインインを試行し、キャッシュの影響を排除します。ブラウザの「パスワードと自動入力設定」で保存されている資格情報も削除してください。
2. 条件付きアクセスポリシーの評価を確認する:Entra ID管理センターの「条件付きアクセス」で、対象ユーザーに適用されるポリシーを一覧表示します。「ポリシーの評価」機能を使って、実際のサインイン試行がどのポリシーに引っかかったかを確認できます。
3. サインインログのフィルターを最適化する:「サインインログ」画面で、[日付] フィルターを「過去24時間」または「過去7日間」に設定し、さらに [ユーザープリンシパル名] や [アプリケーション] で絞り込みます。失敗理由が空欄の行を特定したら、その行の [監査ID] を控えてください。
4. 監査ログで詳細を追跡する:「監査ログ」画面に移動し、[期間] をサインイン失敗の発生時刻の前後30分程度に設定します。次に [アクティビティ] フィルターで「サインインに失敗しました(Sign-in failed)」を選択、または [作成者] にユーザーのUPNを入力します。監査ログのイベントから詳細なエラーコードを読み取ります。
5. 診断設定とライセンスを確認する:テナントの [Entra ID] > [監査ログと診断設定] で、ログの保存先が正しく設定されているか確認してください。また、利用中のライセンスが「Microsoft Entra ID P1」以上であることも確認します。P1以上でないと、詳細な失敗理由がログに含まれない場合があります。
6. Microsoft 365管理センターのユーザー監査レポートを併用する:Microsoft 365管理センターの「レポート > 監査ログ」でも、ユーザーのサインインアクティビティを確認できます。ここで記録されるイベントはEntra IDの監査ログとほぼ同期されていますが、画面によって表示される項目が異なるため、クロスチェックとして有効です。

比較表:サインインログと監査ログの特徴

項目	サインインログ	監査ログ
主な用途	ユーザーのサインイン成否とその概略を把握	管理者操作や構成変更、認証に関する詳細イベントの追跡
記録されるイベント	サインイン要求ごとに1レコード	条件付きアクセスの評価、MFA要求、ディレクトリ変更など多様
失敗理由の詳細度	基本的にコード表示(理由不明の場合は空欄の可能性あり)	エラーコード+説明文+関連リソースなど多彩な情報を提供
データ保持期間	無償ライセンス:7日、P1:30日、P2:30日	無償ライセンス:7日、P1:30日、P2:30日
検索機能の制約	フィルター項目が限定的(ユーザー、アプリ、日付など)	多くの属性でフィルター可能(アクティビティ、ターゲット、作成者など)

よくある失敗パターンと対処例

現場で実際に発生した事例を基に、代表的な失敗パターンを紹介します。これらの事例を参考に、自社の環境で同様の事象が発生していないか確認してみてください。

• パターン1:レガシー認証の使用 – サインインログで「失敗理由:なし」となり、監査ログに「Non-interactive sign-in failure」が記録される場合。原因は、旧式のIMAPやPOP接続などレガシー認証プロトコルの利用です。対処として、該当アプリケーションでモダン認証を有効にするか、条件付きアクセスでレガシー認証をブロックしてください。
• パターン2:多要素認証(MFA)設定の不完全 – サインインログでは「MFA要求が必要」と表示されるが失敗理由が空欄、監査ログに「MFA registration required」のイベントが残る場合。ユーザーがMFA登録を完了していないか、登録方法に問題があります。Microsoft Entra ID管理センターでユーザーのMFA登録状況を確認し、再登録を促してください。
• パターン3:条件付きアクセスのポリシー評価エラー – サインインログに「Access denied due to Conditional Access policy」と表示されるものの、ポリシー名が記載されない場合。監査ログで「Conditional Access Policy evaluation」イベントを検索すると、どのポリシーが適用されたかがわかります。ポリシーの設定を見直し、ユーザーが条件を満たせるか確認してください。
• パターン4:認証代理(Proof of Possession)の失敗 – 最新のMFA方式(FIDO2や証明書ベースの認証)でエラーが発生した場合、サインインログには失敗とだけ表示され、詳細が監査ログに記録されます。監査ログで「Authentication method required」や「Device registration required」を確認し、ユーザーのデバイス登録や認証方法の設定を見直してください。

管理者に確認・報告すべき情報

サインインログで失敗理由が確認できない問題を、上位の管理者や権限保持者に報告する際は、以下の情報を整理して伝えてください。これにより、迅速な調査と対応が期待できます。

• 発生日時とタイムゾーン(UTCで記録されるため、日本時間に換算すること)
• 対象ユーザーのユーザープリンシパル名(UPN)と所属組織
• サインインログで確認した「失敗理由(空欄)」「アプリケーション」「IPアドレス」「デバイス情報」
• 監査ログで見つけた関連イベントの「アクティビティ」「作成者」「ターゲット」の値
• すでに試したトラブルシューティング手順とその結果

これらの情報を報告する際には、必ず画面のスクリーンショットやログのCSV出力も添付しましょう。特に監査ログは大量のイベントが含まれるため、関連する行のみを切り出して提示すると、管理者の負担が軽減されます。

よくある質問(FAQ)

Q1. サインインログの保持期間が短くて困っています。延長する方法はありますか?

A. はい。Microsoft Entra ID P1またはP2ライセンスを購入すると、サインインログの保持期間が30日に延長されます。さらに、診断設定を構成してストレージアカウントやLog Analyticsワークスペースにログをエクスポートすれば、長期間保存することも可能です。

Q2. 監査ログを確認しても目的のイベントが見つかりません。どうすればよいですか?

A. フィルター条件を広く取りすぎて見落としている可能性があります。まずは「アクティビティ」フィルターを使わずに、対象ユーザーのUPNを「作成者」または「ターゲット」に入力し、期間を前後1時間に設定して様子を見てください。それでも見つからない場合、そのサインイン試行はEntra IDに到達していない(クライアント側でブロックされた)可能性が高いです。

Q3. 失敗理由が空欄のサインインログを、監査ログなしで特定する方法はありますか?

A. 直接的な方法はありません。ただし、サインインログの「詳細」タブを開くと、追加の診断情報が表示されることがあります。また、Graph APIを使用してサインインログを取得し、status.additionalDetailsプロパティを確認することで、空欄の理由が補完されるケースもあります。APIの利用には適切な権限が必要です。

まとめ

Entra IDのサインインログで失敗理由が表示されない場合、まずは端末側の設定やキャッシュを排除し、それでも原因が特定できなければ監査ログを活用してください。監査ログはサインインログよりも詳細な情報を提供するため、トラブルシューティングの強力なツールとなります。また、ライセンスや診断設定の見直しも重要です。これらの手順を踏むことで、問題解決の時間を大幅に短縮できます。日頃から定期的にログを確認し、異常が発生した場合の切り分け手順をチーム内で共有しておくことをお勧めします。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。