【Microsoft 365】監査ログでサインイン失敗を追う時に見るイベントと利用者への聞き取り

多くの企業でMicrosoft 365の利用が拡大する中、ユーザーがサインインできないというトラブルは日常的に発生します。管理者としては、問題の原因を迅速に特定し、解決に導く必要があります。そのために有効なのが、Microsoft 365の監査ログとAzure ADサインインログです。これらのログを正しく読み解き、さらに利用者への適切な聞き取りを組み合わせることで、原因を効率的に特定できます。本記事では、監査ログでサインイン失敗を追う際に注目すべきイベントと、利用者への聞き取りの具体的な方法を解説します。

監査ログで確認できるサインイン失敗のイベント一覧

サインイン失敗を追跡する際にまず確認すべきは、Azure ADのサインインログと統合監査ログの2種類です。それぞれのログで表示されるイベント名や情報が異なります。統合監査ログでは、主に”UserLoggedIn”や”FailedSignIn”などのイベントが記録されますが、サインイン失敗の詳細はAzure ADサインインログの方がはるかに詳細です。以下に代表的なイベントを説明します。

Azure ADサインインログの主要イベント

Azure ADのサインインログでは、各サインイン試行に対してステータス(成功、失敗、中断)が記録されます。失敗の場合、”SignInFailure”や”FailedSignIn”のようなイベント名はなく、代わりにStatusフィールドに”Failure”と表示され、FailureReasonに具体的な理由が記載されます。例えば、”Invalid username or password”や”User is blocked”などです。また、条件付きアクセスによるブロックは”ConditionalAccessFailure”ではなく、Statusが”Interrupted”となり、FailureReasonに条件付きアクセスポリシー名が表示されます。

統合監査ログの主要イベント

統合監査ログ(UnifiedAuditLog)では、Office 365全体の操作が記録されます。サインイン関連では”UserLoggedIn”(成功)、”SignInFailed”(失敗)、”ConditionalAccessPolicyEvaluated”(条件付きアクセスの評価)などのイベントが利用可能です。ただし、統合監査ログはAzure ADサインインログほど詳細ではなく、失敗理由のコードは限られています。そのため、まずはAzure ADサインインログを確認し、必要に応じて統合監査ログで関連操作を追うという順序が効率的です。

サインイン失敗の原因を切り分けるための観点

原因を特定するには、端末側、アカウント側、管理設定側の3つの観点で切り分けることが重要です。以下に各観点の詳細とログでの確認ポイントを示します。

観点	主な原因例	ログでの確認ポイント
端末側	ブラウザのキャッシュ、アプリの設定ミス、古い証明書	クライアントIPアドレスやUserAgentから端末情報を特定
アカウント側	パスワード誤り、多要素認証(MFA)失敗、アカウントロック	FailureReasonに”InvalidPassword”や”MfaRequired”など
管理設定側	条件付きアクセスブロック、リスクポリシーによる中断	Statusが”Interrupted”、FailureReasonにポリシー名

端末側の詳細確認

端末側の問題は、ユーザーが使用しているブラウザやアプリの設定に起因します。例えば、ブラウザに古い資格情報がキャッシュされている場合、正しいパスワードを入力してもサインインに失敗することがあります。ログでは、ClientAppフィールドに”Browser”や”Mobile Apps and Desktop clients”と表示され、UserAgentからブラウザのバージョンが確認できます。また、IPアドレスから端末のネットワーク環境も把握できます。

アカウント側の詳細確認

アカウント側の原因で最も多いのはパスワード誤りとMFA失敗です。FailureReasonに”InvalidUsernameOrPassword”や”MfaChallengeFailed”などが表示されます。また、一定回数以上の失敗でアカウントがロックされた場合、”AccountLocked”というエラーが発生します。管理者がパスワードをリセットした直後に失敗が続く場合は、レプリケーションの遅延も考えられます。

管理設定側の詳細確認

条件付きアクセスやIdentity Protectionのリスクポリシーが原因となる場合、サインインログのStatusが”Interrupted”となり、FailureReasonに対象のポリシー名やリスクレベルが表示されます。例えば、”Blocked by Conditional Access policy: Require MFA for all users”や”Risk detected: medium”などです。これらのポリシーは管理者側で設定されているため、ユーザー自身では対処できません。必ず管理者がポリシーを確認し、必要に応じて例外を追加します。

利用者への聞き取りで有効な質問例

ログだけでは特定できない情報を補うため、利用者への聞き取りが重要です。ただし、聞き取りはユーザーの負担にならないように、必要最小限の質問に絞りましょう。以下に有効な質問例を挙げます。

• エラーメッセージのスクリーンショットはありますか?また、表示されたエラーコードを教えてください。
• いつ頃からサインインできなくなりましたか?最後に成功したのはいつですか?
• どのデバイス(PC、スマホ、タブレット)から、どのアプリ(Outlook、Teams、ブラウザなど)を使用していましたか?
• 他のデバイスやブラウザでも同じ現象が発生しますか?
• 多要素認証(MFA)の設定に変更はありませんか?新しいスマホに変えたなど。
• パスワードを最近変更しましたか?または、他の人と共有していませんか?

これらの質問によって、端末固有の問題か、アカウント全体の問題かを切り分けることができます。また、スクリーンショットがあれば、ログのイベントと照合して誤認識を防げます。

実際の調査手順

ここでは、サインイン失敗の連絡を受けてから原因を特定するまでの手順をステップごとに説明します。以下の手順は管理者権限を持つユーザーを前提としています。

1. 利用者から連絡を受けたら、まずは情報を整理します。氏名、発生時刻、使用デバイス、エラーメッセージをヒアリングします。
2. Azure ADサインインログを開き、該当ユーザーの最近のサインイン試行を検索します。期間は発生時刻の前後30分程度で設定します。
3. 失敗しているサインインのStatusとFailureReasonを確認します。ここで端的な原因がわかることが多いです。
4. もしFailureReasonが不明瞭な場合(例:”Other”や”Unknown”)、統合監査ログで同じ時間帯のイベントを確認します。”SignInFailed”や”ConditionalAccessPolicyEvaluated”を探します。
5. 条件付きアクセスが原因と思われる場合は、Azure ADの条件付きアクセスポリシーを確認し、該当ユーザーがどのポリシーに該当しているかを調べます。
6. ログだけでは判断できない場合は、ユーザーに追加の聞き取りを行います。特に、他のデバイスでの動作確認や、MFAアプリの状態を確認します。
7. 原因が特定できたら、適切な対処を行います。パスワードリセット、MFA再登録、条件付きアクセスの例外追加などです。
8. 対処後、ユーザーにサインインが成功することを確認してもらい、ログに成功イベントが記録されていることを確認します。

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

実際によく遭遇する失敗パターンをいくつか紹介します。それぞれのログ上の特徴と、聞き取りのポイントをまとめます。

パスワード変更直後の同期遅延

管理者またはユーザーがパスワードを変更した直後に、一部のサービスで古いパスワードがキャッシュされているために失敗することがあります。ログには”InvalidUsernameOrPassword”が表示されますが、ユーザーは「正しいパスワードを入力している」と主張します。この場合、数分待つことで解決する場合が多いですが、キャッシュのクリアやアプリの再起動を促します。

条件付きアクセスが意図せずブロック

管理者が新しい条件付きアクセスポリシーを導入した際に、想定外のユーザーがブロックされるケースです。ログには”Interrupted”とブロックしたポリシー名が表示されます。ユーザーに話を聞くと「急に使えなくなった」と言うことが多いです。対処としては、ポリシーの条件を見直すか、ユーザーを除外グループに追加します。

MFAアプリの時刻ずれ

多要素認証アプリ(Microsoft Authenticatorなど)の端末時刻がずれていると、ワンタイムパスワードが一致せず認証に失敗します。ログには”MfaChallengeFailed”が表示されます。ユーザーに「スマホの時刻設定を自動にしてください」と伝えるだけで解決します。

よくある質問

監査ログの保持期間はどのくらいですか?

Azure ADサインインログは、ライセンスによって異なります。Azure AD Freeの場合は7日間、Azure AD Premium P1またはP2の場合は30日間です。統合監査ログはOffice 365 E5などのライセンスで90日間保存されます。保持期間を過ぎたログは参照できませんので、長期間の調査が必要な場合はログを外部にエクスポートすることを検討してください。

聞き取りでどのようなことに気をつければよいですか?

プライバシーに配慮し、パスワードそのものを聞くことは避けてください。また、ユーザーの利用状況を過度に詮索しないように注意します。エラーメッセージや操作手順に焦点を当て、ユーザーが自発的に情報を提供しやすい雰囲気を作ることが重要です。

まとめ

サインイン失敗の調査では、Azure ADサインインログと統合監査ログを組み合わせて原因を特定します。ログのイベントを正しく解釈するためには、FailureReasonやStatus、条件付きアクセスポリシーの情報を確認することが重要です。また、ログだけでは得られないユーザーの状況を把握するために、適切な聞き取りを行うことで、調査の精度が向上します。本記事で紹介した手順と観点を参考に、効率的にトラブルシューティングを進めてください。日頃からログの確認方法に慣れておくことで、問題発生時の対応がスムーズになります。

👥

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

🔐

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