Windows Serverにリモートデスクトップ（RDP）でサインインしているのに、なぜかセキュリティログのイベントID 4624（ログオン成功）が安定して記録されない――監査やインシデント調査をしていると、意外とよく出会うトラブルです。本記事では「ログオンタイプ 10 や 7 がほとんど出てこない」という具体的な事例をベースに、原因の考え方からチェックポイント、実務で使える対処・運用設計まで体系的に解説します。
RDPログオン監査でイベントID 4624が記録されない問題とは
事象の概要
ここで取り上げるケースは、次のような状況です。
- 対象は特定の 1 台の Windows Server
- RDP で通常どおりサインインして利用できている
- しかしセキュリティログに イベントID 4624（ログオン成功） が安定して記録されない
- とくに ログオンタイプ 10（RemoteInteractive: RDP 初回ログオン） と タイプ 7（ロック解除／再接続） が出ないことが多い
- 10 回 RDP 接続しても、4624（タイプ 10/7）が記録されるのは 2 回程度
- たとえば「2025/07/07 14:14 に RDP 接続したはずなのに、該当タイプの 4624 が見当たらない」といった再現がある
ポイントは、「RDP 接続自体は成功している」「ごく一部だけは 4624 が記録されている」という「断続的な欠落」です。監査の観点では非常に気持ち悪い状態であり、早めに原因を切り分けておきたい現象です。
前提知識：イベントID 4624 とログオンタイプ
まず、イベント ID 4624 のログオンタイプと RDP との関係を整理しておきます。
| ログオンタイプ | 名称 | 概要 | RDP との関係 |
|---|---|---|---|
| 2 | Interactive | コンソール（物理）ログオン | 基本的にローカルコンソール。RDP では通常使用されない |
| 3 | Network | ネットワーク経由のアクセス（SMB など） | NLA 有効時に RDP 認証の前段で出ることがある |
| 7 | Unlock | セッションのロック解除 | 既存 RDP セッションへの再接続やロック解除で出やすい |
| 10 | RemoteInteractive | リモート対話ログオン | RDP の初回ログオンで基本的に出るべきイベント |
RDP の監査では、通常「4624（タイプ 10）」と「4624（タイプ 7）」を追いかけることで、いつ・誰が・どのクライアントから RDP セッションを開始／再接続したか を把握します。ここが抜け落ちると、「本当にログオンしていたのか」「いつから接続していたのか」を後から証明しづらくなります。
想定される主な原因
このように 4624 の一部が抜け落ちる場合、代表的な原因として次の 2 つが考えられます。
- Remote Desktop Services（RDS / TermService）の遅延・不調
RDS が内部的にセッション情報をハンドリングできておらず、セキュリティログへのイベント通知がうまく行っていない、または遅延・欠落しているケースです。 - Windows イベントログ（EventLog）サービスの高負荷・バックログ
セキュリティログへの書き込みキューが詰まり、一部イベントが遅延したりドロップされたりしているケースです。
これらが絡み合うと、「たまに記録されるが、多くは記録されない」といった、厄介な断続的現象につながります。
まず試すべき対処：TermService 再起動とサーバー再起動
Remote Desktop Services（TermService）の再起動
最も手軽かつ効果が出やすいのが、Remote Desktop Services（TermService）の再起動です。
Restart-Service -Name TermService -Force
ただし、このコマンドを実行すると すべての RDP セッションが強制切断 されます。必ずメンテナンス時間帯に行い、対象サーバーにログオンしているユーザーに事前連絡を行ってください。
TermService の再起動後に RDP 接続を試し、4624（タイプ 10/7）が安定して記録されるようになれば、「RDS 側が一時的に不調だった」可能性が高いと言えます。
サーバー再起動による EventLog サービスのリセット
Windows の EventLog サービス（イベントログ）は、単体での再起動が難しいコンポーネントです。内部的なキュー詰まりやバックログでイベント書き込みが不安定になっている場合、サーバーのフル再起動が最も確実なリセット手段になります。
- 定期メンテナンスのタイミングで再起動を実施
- 再起動後に RDP 接続 → セキュリティログの 4624（タイプ 10/7）の記録状況を確認
再起動後から正常に 4624 が記録されるようであれば、EventLog サービスの状態不良や一時的な OS 内部の不整合が疑われます。
監査ポリシーの見直し：高度な監査ポリシーを前提にする
高度な監査ポリシー（Advanced Audit Policy）の確認
イベントが物理的に出ていないのか、そもそも監査ポリシーで無効化されているのかを切り分けるために、まずは監査ポリシーを確認します。
推奨は GPO（グループポリシー）による 高度な監査ポリシー の利用です。以下のサブカテゴリを「成功」「失敗」あるいは少なくとも「成功」に設定します。
| カテゴリ | サブカテゴリ | 推奨設定 | 補足 |
|---|---|---|---|
| ログオン/ログオフ | ログオン | 成功、失敗 | 4624 / 4625 を出す基本設定 |
| ログオン/ログオフ | ログオフ | 成功 | 4634 / 4647 など |
| ログオン/ログオフ | 特殊ログオン | 成功 | 特権アカウント利用時の補助 |
| ログオン/ログオフ | その他のログオン/ログオフ イベント | 成功、失敗 | 4778 / 4779 などの RDP 再接続イベント |
さらに、「高度な監査ポリシー設定をこのコンピューターの監査ポリシー設定で上書きする」（いわゆる「サブカテゴリ設定を優先」）を有効化し、古い基本監査設定との競合を避けます。これにより、OS が想定どおりに 4624 を発行しているかどうかを確認しやすくなります。
監査ポリシー変更後の確認ポイント
- GPO の適用後に
gpupdate /forceを実行 - セキュリティログで 4624 / 4625 が継続して出力されているか確認
- 4624 のログオンタイプに 3 / 7 / 10 が混在しているかをチェック
監査ポリシー自体が不適切な場合はここでかなり状況が変わるため、必ず最初期に確認すべきポイントです。
RDP 専用チャネルとセキュリティログを相関させて確認する
RDP 関連イベントログの全体像
セキュリティログだけに頼ると、4624 が欠落した際に「本当に接続していたのか」が分かりづらくなります。そこで、RDP 専用のイベントログチャネルも併用して相関させるのが実務上の定石です。
| ログ名 | イベント ID | 意味 | 用途 |
|---|---|---|---|
| Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational | 1149 | RDP 認証成功 | RDP 接続が成立したかどうかの一次判定 |
| Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | 21 | セッション作成 | 新規 RDP セッションの開始 |
| Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | 24 | セッション切断 | 切断タイミングの把握 |
| Microsoft-Windows-TerminalServices-LocalSessionManager/Operational | 25 | セッション再接続 | 再接続・ロック解除の把握 |
| セキュリティ | 4624 | ログオン成功 | ログオンタイプ 3 / 7 / 10 を中心に確認 |
| セキュリティ | 4625 | ログオン失敗 | 失敗試行の把握 |
| セキュリティ | 4778 / 4779 | RDP 再接続 / 切断 | RDP セッションのライフサイクル把握 |
4624 が欠落していても、1149 と 21 / 25 が正しく記録されていれば、「RDP 接続自体は成立していた」ことはほぼ確実と言えます。
ログオンタイプ 3 を補助的に扱う理由
ネットワークレベル認証（NLA）が有効な RDP では、しばしば次のような順序でイベントが出ます。
- ログオンタイプ 3（ネットワーク）で 4624 が記録
- その後にログオンタイプ 10（RemoteInteractive）が記録
しかし、今回のようにログオンタイプ 10 が欠落している環境では、ログオンタイプ 3 の 4624 だけが残るケースがあります。そのため、監査スクリプトでは次のような方針が有効です。
- まず 4624 のログオンタイプ 10 / 7 を収集する
- 見つからない場合や件数が少なすぎる場合は、補助的にログオンタイプ 3 も集計する
- RDP 関連イベント（1149 / 21 / 25 など）と時刻・ユーザー・クライアント IP で突き合わせて相関させる
こうすることで、4624（タイプ 10/7）だけに依存した監査に比べ、取りこぼしを大幅に減らすことができます。
PowerShell での簡易相関取得例
実務でよく使われる簡易的な PowerShell 例を示します。特定の時間帯の RDP 関連イベントをまとめて確認したい場合のイメージです。
$start = [datetime]"2025-07-07 14:00:00"
$end = [datetime]"2025-07-07 15:00:00"
# セキュリティログ：4624（タイプ 3,7,10）
$secFilter = @{
LogName = 'Security'
ID = 4624
StartTime = $start
EndTime = $end
}
$secEvents = Get-WinEvent -FilterHashtable $secFilter |
Where-Object {
$logonType = ($_ | Select-Object -ExpandProperty Properties)[8].Value
$logonType -in 3,7,10
}
# RDP 認証成功（1149）
$rcmEvents = Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational' `
-FilterHashtable @{ Id = 1149; StartTime = $start; EndTime = $end }
# LSM のセッション作成 / 再接続（21,25）
$lsmEvents = Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' `
-FilterHashtable @{ Id = 21,25; StartTime = $start; EndTime = $end }
$secEvents
$rcmEvents
$lsmEvents
ここではあえてシンプルにしていますが、実際には Logon ID や Session ID、ユーザー名、クライアント IP を抜き出して相関させることで、4624 の欠落があっても「接続の実態」をかなり正確に追跡できます。
セキュリティログ容量・保持設定とイベントドロップの兆候
ログサイズと保持方法を見直す
セキュリティログの容量が小さすぎたり、「上書きしない」設定になっていると、ログがすぐにいっぱいになり、OS がイベントを書き込めなくなる場合があります。監査の観点では、少なくとも以下の方針を検討します。
- セキュリティログの最大サイズを十分に大きくする（数百 MB～数 GB 程度、運用ポリシーに応じて）
- 保持方法は「必要に応じてイベントを上書き」に設定し、イベントドロップを起こさないようにする
- 長期保管は WEF や SIEM などの別仕組みに任せる
監査の都合で「上書きしない」を選択しているケースもありますが、その場合は 定期的な手動退避とログクリアの運用を徹底する必要があります。放置すると、ある日突然ログがいっぱいになり、新しいイベントが一切記録されなくなります。
イベントドロップやサービス停止の兆候をチェックするイベント
イベントログ関連の異常は、以下のイベントである程度検知することができます。
| ログ名 | イベント ID | 意味 | チェックポイント |
|---|---|---|---|
| セキュリティ / システム | 1100 | イベントログサービスが停止した | 予期せぬ停止がないか |
| セキュリティ / システム | 1101 | セキュリティログが満杯 | ログサイズ不足によるドロップを示唆 |
| Microsoft-Windows-Eventlog | 1108 | イベントをログに書き込めなかった | キュー詰まりや I/O 問題の兆候 |
4624 に限らず、複数種類のイベントが同時期に欠落している場合は、これらのイベントを手掛かりにイベントログサービスの状態を疑うのが効率的です。
負荷・更新プログラム・ハードウェア要因の影響
ディスク I/O・CPU 高負荷による遅延・欠落
イベントログ書き込みも結局はディスク I/O です。次のような状況だと、イベントが遅延したり、最悪ドロップされたりする場合があります。
- ページファイルやログファイルを置いているディスクの I/O が常に逼迫している
- アンチウイルスやバックアップソフトがログファイルを過剰にスキャンしている
- CPU が常時高負荷で、カーネルレベルの処理が遅延している
タスクマネージャーやリソースモニター、パフォーマンスモニターを用いて負荷状況を確認し、必要に応じて以下を検討します。
- ログファイル用のディスクを分ける
- アンチウイルスの除外設定にイベントログファイルを追加する（ベンダー推奨値を確認）
- 不要な常駐ソフトやサービスを見直す
累積更新・RDS 関連修正の適用
Windows Server の特定バージョンでは、RDS やイベントログ周りのバグが累積更新で修正されていることがあります。OS のビルド番号と更新履歴を確認し、少なくともサポートされている最新の累積更新までは適用しておくことをおすすめします。
特に、RDS や NLA 周辺で既知の問題が報告されている場合、「更新後は 4624 が正常に出るようになった」という事例も少なくありません。サーバー全体の安定性向上という意味でも、更新プログラムは重要な対策のひとつです。
取得スクリプトの堅牢化：フォールバック設計で取りこぼしを防ぐ
4624 に依存しすぎない監査設計
たとえ OS 側の問題を解消しても、「何らかの理由で 4624 が欠落する可能性」はゼロにはなりません。そのため、監査スクリプトやレポート設計の側でも冗長性を持たせることが重要です。
- メイン：4624（ログオンタイプ 10 / 7）
- サブ：4624（ログオンタイプ 3）、4778 / 4779
- 補助：RDP 関連チャネルの 1149 / 21 / 25
この 3 層構造を意識しておけば、どれか 1 つのイベントが欠落していても、他のイベントから「実際の接続履歴」を復元できる可能性が高まります。
Logon ID / セッション ID で相関させるメリット
イベントを単純に時系列で眺めるだけでは、複数ユーザーが同時に RDP 利用している環境で混乱しがちです。そこで、Logon ID（ログオン ID）やセッション IDをキーにして相関させると、次のようなメリットがあります。
- 1 つの RDP 接続に関連する 4624 / 4634 / 4778 / 4779 / 1149 / 21 / 25 をまとめて追える
- 重複ログや再接続を「同一セッション」としてグルーピングできる
- 一部のイベント欠落があっても、残りのイベントからセッションの開始・終了を補完しやすい
実装はやや複雑になりますが、監査レポートの信頼性を高めるうえで非常に有効です。
ケーススタディ：2025/07/07 14:14 の接続が 4624 に現れない
状況整理
具体例として、次のような状況を想定します。
- 対象サーバーに 2025/07/07 14:14 ごろ RDP 接続したユーザーがいる
- ユーザーはその時間帯にサーバーを確かに操作している
- しかしセキュリティログを確認しても、14:10～14:20 の間に 4624（タイプ 10 / 7）が存在しない
- むしろ、4624（タイプ 3）が 1 件だけ見つかる程度
調査の進め方（例）
- セキュリティログで 4624 / 4625 / 4634 / 4778 / 4779 を 14:00～15:00 の範囲で抽出
- 同時間帯に RDP 関連チャネル（1149、21、25）を確認
- 1149 や 21 / 25 が 14:14 付近に記録されているか確認
- もし 1149 / 21 / 25 が存在し、4624 はログオンタイプ 3 しかない場合、
- 「RDP 接続自体は成立している」
- 「4624（タイプ 10）が欠落している」
- 「欠落の原因は TermService または EventLog 側にある」
- 同時間帯に 1100 / 1101 / 1108 等のイベントログ関連の警告・エラーがないか確認
- あわせて、RDS や EventLog サービスの再起動履歴・エラー履歴も調査
このようにして、「ユーザーの証言」「RDP 関連チャネル」「4624（タイプ 3）」「イベントログ関連エラー」を総合的に突き合わせることで、「接続していたにもかかわらず 4624（タイプ 10）が欠落していた」 という状況をかなり具体的に説明できます。
運用設計：WEF / SIEM による継続監視と中央集約
Windows Event Forwarding（WEF）の活用
単一サーバー上だけでログの健全性を監視するのには限界があります。複数のサーバーを管理している場合は、Windows Event Forwarding（WEF）を用いて、イベントを中央のコレクターサーバーに集約することを検討しましょう。
- 各サーバーからセキュリティログおよび RDP 関連チャネルを転送
- コレクター側で 4624 / 4625 / 1149 / 21 / 25 などを一元的に監査
- 特定サーバーだけイベントが少なすぎる／急に減ったといった異常を早期検知
これにより、今回のような「特定の 1 台だけ 4624 が欠落している」問題も相対的に見つけやすくなります。
SIEM との連携とアラート設計
より高度な環境では、SIEM（Security Information and Event Management）製品にログを取り込み、次のようなルールを定義します。
- 通常の RDP 利用量に比べて、4624（タイプ 10 / 7）の件数が異常に少ないサーバーを検出
- 1100 / 1101 / 1108 などのイベントログ関連エラーが発生したらアラート
- 同じユーザー・同じ IP からの 4625（失敗）が連続した後に 4624（成功）が出ているかどうかの確認
こうしたルールを組み合わせることで、「イベントの欠落が起きても検知できる」「欠落の影響を最小限に抑える」体制を構築できます。
実務的なチェックリストまとめ
最後に、今回のテーマを踏まえた、実務で使えるチェックリストをまとめます。
| 分類 | チェック項目 | 目的 |
|---|---|---|
| 即時対処 | Remote Desktop Services（TermService）の再起動 | RDS 周りの一時的な不調の解消 |
| 即時対処 | サーバー再起動 | EventLog サービスを含む OS 内部状態のリセット |
| 設定確認 | 高度な監査ポリシーでログオン/ログオフ関連を有効化 | 4624 / 4625 / 4778 / 4779 などが発生する土台を整える |
| 設定確認 | 「サブカテゴリ設定を優先」を有効化 | 古い監査ポリシーとの競合を防ぐ |
| ログ設計 | セキュリティログの容量・保持方法を見直し | ログ満杯によるイベントドロップを防ぐ |
| ログ健全性 | 1100 / 1101 / 1108 などを監視 | イベントログサービスの異常を早期検知 |
| 相関 | RDP 専用チャネル（1149 / 21 / 24 / 25）を併用 | 4624 欠落時でも RDP 接続の実態を把握 |
| スクリプト | 4624（タイプ 10 / 7）に加え、タイプ 3 も補助的に取得 | 監査レポートの取りこぼしを減らす |
| 運用 | WEF や SIEM で中央集約と継続監視 | 特定サーバーだけの異常を相対的に検知 |
まとめ：TermService 再起動＋再起動で様子見しつつ、監査設計を強化する
RDP ログオン監査において、イベント ID 4624（ログオン成功）とログオンタイプ 10 / 7 が安定して記録されない現象は、
- Remote Desktop Services（TermService）の遅延・不調
- Windows イベントログサービスのバックログやログ容量不足
などが原因であることが多く、まずは TermService の再起動 や サーバー再起動 で改善するかを確認するのが現実的です。
そのうえで、
- 高度な監査ポリシーによるログオン/ログオフ監査の整備
- RDP 専用チャネル（1149 / 21 / 24 / 25）との相関取得
- セキュリティログ容量・保持設定の最適化
- 負荷と更新プログラムの見直し
- 4624 以外のイベントにフォールバックするスクリプト設計
- WEF / SIEM による継続監視と中央集約
といった対策を組み合わせることで、「たまたま 4624 が出なかったから追跡不能になる」というリスクを大きく下げることができます。
監査ログは「とれているつもり」になりがちですが、実際には今回のような欠落が起こることがあります。定期的に 実際の RDP 接続とログの記録状況を突き合わせて確認し、問題があれば早めに手を打つことが、セキュリティ運用の品質を高めるうえで非常に重要です。
コメント