「ログオンに失敗したはずなのに4625が見つからない」。このとき、記録が一度も作られなかったのか、別の端末にあるのか、保存・転送の途中で見えなくなったのかを分けて調べます。すでに記録された4625の読み方は認証ログの入門と連続失敗の調査で扱いました。この記事は「見つからない場合」の確認順に絞ります。
Microsoftのイベント4625の説明では、ログオン試行が行われたコンピューターにイベントが生成されるとされています。ドメイン環境の認証先と実際にログオンを試みた端末を混同せず、どの機器のSecurityログを見るべきかを先に決めます。認証方式や処理によって関連イベントが異なることもあるため、「どこにも4625がない＝失敗は起きていない」とは断定できません。
1. 対象端末・時刻・フィルターを揃える
申告された失敗の日時、タイムゾーン、利用者、操作した端末、接続先を確認します。イベントビューアーの「Windowsログ → セキュリティ」で、対象端末と時間帯を合わせて探します。以前に設定したフィルターが残っていないかも確認します。中央の収集基盤だけで探しているなら、まず元の端末での有無を確かめ、生成と転送を分離します。
作業メモには実在のパスワードを残しません。障害対応中のログは証跡になるため、安易に削除したり収集設定を止めたりしないでください。
2. 監査の「失敗」が有効か確認する
MicrosoftのAudit Logonは、ログオン試行の監査を説明し、4625を失敗イベントに挙げています。監査ポリシーの説明では、ローカル設定とグループポリシーによる構成が示されています。対象端末で、関連するLogon/LogoffのAudit Logonなどの失敗監査が有効か、管理者と確認します。ドメインの認証イベントを調べるときはAccount Logon側の監査も区別します。
設定の読み取りには、権限がある管理端末で次のコマンドを使えます。これは監査設定を変更しない確認用コマンドです。
auditpol /get /category:*
表示される項目名はOSの言語により異なります。結果の見方や必要権限はMicrosoftのauditpol /get資料を参照してください。監査設定を変更する場合は、ログ量、収集容量、組織のポリシーへの影響を見積もり、管理者の変更手順に従います。記事のために本番の監査を無効化したり、失敗ログオンを多数発生させたりしません。
3. 保存・転送のどこまで届いたかを確認する
元の端末のSecurityログに4625があるのに中央基盤にない場合は、収集対象、転送エージェント、フィルター、遅延、受信先の順に確認します。元の端末にもない場合は、対象端末、監査設定、検索期間の確認へ戻ります。保存期間内に見つからない場合は、イベントログ保持の確認を参照してください。ただし、保持期間が原因だったと決めつけず、証跡と設定の両方で判断します。
| 見え方 | 次に確認すること |
|---|---|
| 元端末にあり、中央にない | 収集・転送・受信側の状態 |
| 元端末にもない | 対象端末、時刻、フィルター、監査設定 |
| 過去分だけない | 保存期間、上書き、収集履歴 |
この表は切り分け方の説明であり、実測ログや特定環境の診断結果ではありません。
検証は管理下の隔離環境で
変更の影響を見たい場合は、所有・管理する隔離環境で、事前の設定と記録先を残してから少数の動作を確認します。本番アカウントや実在の認証情報を記事用の実験に使いません。安全な範囲の決め方は技術検証環境の作り方で確認できます。
