サインイン ログ アクティビティの詳細について学習する
Microsoft Entra は、コンプライアンスのために Azure テナントへのすべてのサインインをログ記録します。 IT 管理者は、ログの値を正しく解釈できるように、サインイン ログの値の意味を把握しておく必要があります。
この記事では、サインイン ログの値について説明します。 これらの値は、サインイン エラーのトラブルシューティングに役立つ情報を提供します。
サインイン アクティビティ コンポーネント
Microsoft Entra ID では、サインイン アクティビティは次の 3 つの主要なコンポーネントで構成されます。
- 対象者: サインインを実行する本人 (ユーザー)。
- 方法: アクセスに使用されるクライアント (アプリケーション)。
- 内容: 本人によってアクセスされるターゲット (リソース)。
サインインについて調べるときに、これら 3 つのコンポーネントに焦点を当てて検索を絞り込みます。そうすることで、詳細をすべて確認しないで済みます。 これら 3 つのコンポーネントにはそれぞれ関連する識別子があり、それらから多くのことが分かる可能性があります。 各サインインには、サインインの試行を関連アクティビティに関連付ける一意の識別子も含まれています。
担当者
次の詳細がユーザーに関連付けられています。
- User
- ユーザー名
- ユーザー ID
- サインイン識別子
- ユーザーの種類
どのように
次の詳細を確認することで、ユーザーがサインインしている方法を識別できます。
- 認証の要件
- クライアント アプリ
- クライアント資格情報の種類
- 継続的アクセス評価
対象
次の詳細を使用して、ユーザーがアクセスしようとしているリソースを識別できます。
- アプリケーション
- アプリケーション ID
- リソース
- Resource ID
- リソース テナント ID
- リソース サービス プリンシパル ID
一意識別子
サインイン ログには、いくつかの一意の識別子も含まれています。これらから、サインインの試行に関する詳細な情報を得ることができます。
- 関連付け ID: 関連付け ID は、同じサインイン セッションからのサインインをグループにします。 この値はクライアントによって渡されるパラメーターに基づいているため、Microsoft Entra ID では精度を保証できません。
- 要求 ID: 発行されたトークンに対応する識別子です。 特定のトークンを使用したサインインを探す場合は、まず、トークンから要求 ID を抽出する必要があります。
- 一意のトークン識別子: サインイン中に渡されるトークンの一意識別子。 この識別子は、サインインとトークンの要求を関連付けるために使用されます。
サインイン アクティビティの詳細
サインインの試行にはそれぞれ、これら 3 つの主要なコンポーネントに関連付けられている詳細が含まれています。 それらの詳細は、サインインの種類に基づいて、複数のタブに分けられています。
基本情報
[基本情報] タブには、サインインの試行に関連付けられている詳細情報の大部分が含まれます。 一意の識別子を書き留めます。サインインの問題をトラブルシューティングする際に、それらが必要になる場合があります。 [基本情報] タブの詳細を使用して、だれが、どのように、何をのパターンに従うことができます。
[基本情報] タブからサインイン診断を起動することもできます。詳細については、サインイン診断の使用方法に関する記事を参照してください。
サインインのエラー コード
サインインに失敗した場合は、関連するログ項目の [基本情報] タブで、理由に関する詳細情報を取得できます。 エラー コードと関連する失敗の理由が詳細に表示されます。 詳細については、サインイン エラーのトラブルシューティング方法に関する記事を参照してください。
場所とデバイス
[場所] と [デバイス情報] タブには、ユーザーの場所と IP アドレスに関する一般的な情報が表示されます。 [デバイス情報] タブには、サインインに使用されるブラウザーとオペレーティング システムの詳細が表示されます。 このタブには、デバイスが準拠しているか、マネージドであるか、ハイブリッド Microsoft Entra に参加しているかについての詳細も表示されます。
認証の詳細
サインイン ログの詳細にある [認証の詳細] タブには、各認証の試行に関する次の情報が表示されます。
- 適用された認証ポリシーの一覧 (条件付きアクセス、セキュリティの既定値群など)。
- サインインに使用された認証方法のシーケンス。
- 認証の試行が成功したかどうかとその理由。
この情報を使用すると、ユーザーのサインインの各ステップをトラブルシューティングできます。 これらの詳細を使用して、次の情報を追跡します。
- MFA によって保護されたサインインの回数。
- 各認証方法の使用状況と成功率。
- パスワードレス認証方法の使用 (パスワードレス電話サインイン、FIDO2 など)。
- トークン クレームによって認証要件が満たされる頻度 (ユーザーが対話形式でパスワードの入力や SMS OTP の入力を求められない場合など)。
条件付きアクセス
テナントで条件付きアクセス (CA) ポリシーが使用されている場合は、それらのポリシーがサインインの試行に適用されたかどうかを確認できます。 サインインに適用できるすべてのポリシーが一覧表示されます。 ポリシーの最終的な結果が表示されるので、ポリシーがサインインの試行に影響を与えたかどうかをすぐに確認できます。
- 成功: サインインの試行に CA ポリシーが正常に適用されました。
- 失敗: サインインの試行に CA ポリシーが適用されましたが、サインインの試行は失敗しました。
- 未適用: 適用されるポリシーの条件とサインインが一致しませんでした。
- 無効: サインインの試行時にポリシーが無効になりました。
レポート専用
条件付きアクセス (CA) ポリシーはユーザーのサインイン エクスペリエンスを変更し、プロセスを中断する可能性があるため、ポリシーが正しく構成されていることを確認することをおすすめします。 レポート専用モードでは、ポリシーを有効にする前に、ポリシーを構成し、その潜在的な影響を評価できます。
サインイン ログのこのタブには、ポリシーのスコープ内にあったサインインの試行の結果が表示されます。 詳細については、「条件付きアクセスのレポート専用モードとは」の記事を参照してください。
サインインの詳細情報と考慮事項
サインイン ログを確認するときは、次のシナリオを考慮することが重要です。
IP アドレスと場所: IP アドレスと、そのアドレスを持つコンピューターが物理的に配置されている場所の間に明確な関連性がありません。 モバイル プロバイダーや VPN は、クライアント デバイスが使用されている場所から遠く離れていることが多い中央プールから IP アドレスを発行します。 現時点では、トレース、レジストリ データ、逆引きなどの情報に基づいて IP アドレスを物理的な場所に変換するのがいいでしょう。
日時: サインイン試行の日時は、サインインを試みたユーザーではなく、Microsoft Entra 管理センターにサインインしたユーザーのタイム ゾーンにローカライズされます。
条件付きアクセス:
Not applied
: サインイン中にポリシーがユーザーとアプリケーションに適用されていません。Success
: サインイン中に 1 つ以上の条件付きアクセス ポリシーがユーザーとアプリケーションに対して適用または評価されました (ただし、必ずしも他の条件が適用されたとは限りません)。 条件付きアクセス ポリシーが適用されない場合でも、評価された場合、条件付きアクセスの状態は [成功] と表示されます。Failure
: サインインによって少なくとも 1 つの条件付きアクセス ポリシーのユーザーとアプリケーションの条件が満たされたうえで、制御の許可が満たされていないか、またはアクセスをブロックするように設定されています。- 条件付きアクセスは、Windows Hello for Business などの Windows サインインには適用されません。 条件付きアクセスにより、デバイス サインイン プロセスではなく、クラウド リソースへのサインイン試行が保護されます。
継続的アクセス評価: 継続的アクセス評価 (CAE) がサインイン イベントに適用されたかどうかを示します。
- 認証ごとに複数のサインイン要求があり、対話型タブまたは非対話型タブのどちらかに表示されます。
- CAE は要求の 1 つに対してのみ true として表示され、対話型タブまたは非対話型タブに表示されます。
- 詳細については、「Microsoft Entra ID の継続的アクセス評価を使用してサインインを監視してトラブルシューティングする」を参照してください。
クロス テナント アクセスの種類: アクターがリソースにアクセスするために使用するクロステナント アクセスの種類を表します。 次のいずれかの値になります。
none
- Microsoft Entra テナントの境界を越えなかったサインイン イベント。b2bCollaboration
- B2B Collaboration を使用してゲスト ユーザーによって実行されるクロス テナント サインイン。b2bDirectConnect
- B2B によって実行されるクロス テナント サインイン。microsoftSupport
- Microsoft 外部テナントで Microsoft サポート エージェントによって実行されるクロス テナント サインイン。serviceProvider
- テナント内のクラウド サービス プロバイダー (CSP) の顧客に代わって、CSP または同様の管理者によって実行されるクロステナント サインイン。unknownFutureValue
- クライアントが列挙リストの変更を処理するのに役立つ MS Graph によって使用されるセンチネル値。 詳細については、「Microsoft Graph の操作に関するベスト プラクティス」を参照してください。
テナント: サインイン ログは、テナント間のシナリオに関連する 2 つのテナント識別子を追跡します。
- ホーム テナント -ユーザー ID を所有するテナント。 Microsoft Entra ID は、ID と名前を追跡します。
- リソース テナント - (ターゲット) リソースを所有するテナント。
- プライバシー コミットメントのため、テナント間のシナリオでは、Microsoft Entra ID はホーム テナント名を設定しません。
- テナントの外部のユーザーがリソースにアクセスしていることを確認するには、ホーム テナントがリソース テナントと一致しないすべてのエントリを選択します。
多要素認証 (MFA) ユーザーが MFA を使用してサインインすると、複数の個別の MFA イベントが実際に発生します。 たとえば、ユーザーが間違った検証コードを入力した場合、または時間内に応答しなかった場合、サインイン試行の最新の状態を反映するより多くの MFA イベントが送信されます。 これらのサインイン イベントは、Microsoft Entra サインイン ログに 1 つの行項目として表示されます。 ただし、Azure Monitor で同じサインイン イベントは、複数の行項目として表示されます。 これらのイベントにはすべて同じ
correlationId
があります。Authentication requirement (認証の要件): サインインが成功するためにすべてのサインイン手順で必要な最高レベルの認証を示します。
- Graph API では、
$filter
(eq
とstartsWith
演算子のみ) がサポートされています。
- Graph API では、
Sign-in event types (サインイン イベントの種類): イベントが表すサインインのカテゴリを示します。
- ユーザー サインイン カテゴリは
interactiveUser
またはnonInteractiveUser
であり、サインイン リソースの isInteractive プロパティの値に対応します。 - マネージド ID カテゴリは
managedIdentity
です。 - サービス プリンシパル カテゴリは servicePrincipal です。
- Microsoft Graph API では、
$filter
(eq
演算子のみ) がサポートされています。 - Azure portal にはこの値は表示されませんが、サインイン イベントは、そのサインイン イベントの種類と一致するタブに配置されます。 使用できる値:
interactiveUser
nonInteractiveUser
servicePrincipal
managedIdentity
unknownFutureValue
- ユーザー サインイン カテゴリは
ユーザーの種類: サンプルには
member
、guest
、またはexternal
が含まれています。認証の詳細:
- OATH 検証コードは、OATH ハードウェア トークンとソフトウェア トークン (Microsoft Authenticator アプリの認証など) の両方で認証方法として記録されます。
- [認証の詳細] タブでは、ログ情報が完全に集計されるまで、最初のうちは不完全または不正確なデータが表示されることがあります。 たとえば、次のような場合が確認されています。
- サインイン イベントが最初にログに記録された場合、 [トークンの要求によって満たされました] というメッセージが正しく表示されません。
- [プライマリ認証] の行が最初はログに記録されません。
- ログの詳細がわからない場合は、要求 ID と関連付け ID を収集して、さらなる分析またはトラブルシューティングに使います。
- 認証またはセッション有効期間に関する条件付きアクセス ポリシーが適用されている場合は、サインイン試行の上に一覧表示されます。 それらのオプションのいずれも表示されない場合、そのようなポリシーは現在適用されていません。 詳細については、「条件付きアクセスのセッション制御」を参照してください。