ここが変だよ、AADサインインログ - part1（リクエストID重複編）

AADサインインログとは

Azure Active Directory（以下、AAD）の認証時に発生するログです。
AADの[サインインログ]から確認することや、

Azure Active Directoryの[診断設定]からログを出力させることもできます。

本稿では[診断設定]で出力できる以下のログの中でもSigninLogsについて、

”ログとしてここが扱いづらい！”
という点をまとめていきます。

リクエストIDとは

リクエストIDとは、AADユーザーの認証行為ごとに採番される一意のIDです。サインインの成否に関わらず、1回の認証行為に対して1つ払い出されます。

[サインインログ]から確認すると赤枠部分がそれにあたり、日本語では要求IDとも記載されることがあります。
[診断設定]から出力させた場合（本稿ではLog Analyticsワークスペースへ出力）、Idというフィールド（カラム）名で出力されます。

リクエストID重複問題

さて、問題となってくるのが[診断設定]におけるIdフィールドの重複です。
以下のようなクエリを実行し、Idごとの件数を確認してみます。

SigninLogs
| where TimeGenerated > ago(90d)
| summarize count() by Id

ほとんどが1件ですがいくつかのリクエストIDにおいて2件以上ログが出力されていることがわかります。
では赤枠の6件を見てみましょう。

いくつかフィールドをピックアップしていますが、同じリクエストIDであっても異なるログの内容を出力しています。
認証が成功しているログ（ResultType==0）のものもあれば、失敗しているものもあり、
認証方式が多要素認証のものもあれば（AuthenticationRequirement=="multiFactorAuthentication"）、単一要素認証（IDとパスワードのみの認証）のものもあります。

それで、何が問題なのか。ただ6件出ているだけなのでは？とはいきません。
同じログを[サインインログ]で見てみましょう。

こちらは1件しか出力されません。認証は成功していて、多要素認証利用していると記載されています。

Microsoftさん、これ、何？

Microsoft社のAzureサポート窓口へ確認したところ、
これらのログ（＝SigninLogs）にはAzure ADの内部処理によるログも出力されるようで、1つの認証行為に対して複数のデバッグ目的のログが出力されることがある、そうです。
GUI上の[サインインログ]から確認できる内容は最終的な結果を表すものですが、[診断設定]から確認できる内容は途中経過も出力しているとのことでした。

結局何が問題？

[診断設定]を使ってログを貯められている組織は多いかと思います。
インシデント発生時に当該ログを調査することもあるでしょう。
ログを確認した際に最終的な結果ではなく途中経過も調査対象になることで、例えば、

・実際のサインイン試行回数よりログ件数のほうが多いためサインインの件数に差が生じる
・サインイン結果が異なるため、最終的に認証成功しているにもかかわらず、途中で認証失敗のログが出力されることで「被害がない」と誤認する可能性がある

などが考えられます。
特に"被害の有無"に関しては組織がインシデントに対応するにあたっての判断に関わる部分となりますので、誤認した場合は致命的です。

どうすればいいの？

Microsoft社サポートによるとリクエストIDごとの最新のログが最終的な結果を表すとのことですので、ログの時間を表す"CreatedDateTime"が一番新しいログを参照すればよいです。が、その値が同じ場合もあるのでその際はingestion_time()という関数によってログがLog Analyticsへ入力された時間を確認できますのでそちらが最新のログを最終的な結果としましょう。

SigninLogs
// 以下2行を追加
//
// Id及びCreatedDateTimeごとに最新の入力時間のログに絞る
| summarize arg_max(ingestion_time(), *) by Id, CreatedDateTime
// Idごとに最新のCreatedDateTimeのログに絞る
| summarize arg_max(CreatedDateTime, *) by Id

もう少しわかりやすくなると解析しやすくなるなあと思う次第です。
※途中経過と最終結果のフラグをどこかのフィールドに立ててほしいです。。。。
part1と記載していますがモノ申したいことはいくつかありますので"連載"します。

次回は「誤ったUserPrincipalNameの使い方」編です。