MENU

ドメインコントローラーでNetlogonイベントID 5829～5831が出ない原因と対処（CVE-2020-1472/Zerologon）

Active Directory

ドメイン コントローラーに2020年8月の更新（CVE-2020-1472／Netlogon セキュア チャネル強化）を適用したのに、脆弱な接続検知のイベントID 5829～5831が出ない。これは故障とは限らず、ログの見方やフェーズの違いが原因のこともあります。本記事では「安全に洗い出す」ための確認ポイントと運用手順をまとめます。

目次

症状：2020年8月更新後にNetlogonのイベントID 5829～5831が出ない

2020年8月のセキュリティ更新（通称Zerologon／CVE-2020-1472対策）を適用すると、ドメイン コントローラー（DC）はNetlogon セキュア チャネル接続に対して「安全でない（非準拠の）接続」を検知し、イベントログで把握できるようになります。にもかかわらず、期待していたイベントID 5829～5831が一切記録されないと、“非Windows機器や古いServer 2003が危ない方式でつながっているのでは？”という不安が残ります。

前提整理：CVE-2020-1472対策は“フェーズ”でログの出方が変わる

まず押さえるべきは、Netlogon セキュア チャネル強化は段階的に展開され、フェーズによって「許可される／拒否される」挙動と、記録されるイベントIDが変わる点です。Microsoftの案内では、更新は大きく「初期展開フェーズ（2020年8月11日以降）」と「強制（Enforcement）フェーズ（2021年2月9日以降）」に分かれます。

フェーズ開始の目安DC側の基本動作ログ監視の主役運用上の狙い
初期展開フェーズ2020/08/11 以降の更新非準拠端末の検知（警告ログ）で事前洗い出しを促進5829（許可された脆弱接続）強制前に“非準拠ゼロ”へ近づける
強制フェーズ2021/02/09 以降の更新非準拠端末は原則拒否（例外はGPO許可リストのみ）5827/5828（拒否）、5830/5831（例外許可）例外を最小化し、最終的に撤去する

特に重要なのが、強制フェーズでは「イベントID 5829のログ記録がなくなる（＝出ないのが仕様）」という点です。2020年8月更新を入れたつもりでも、その後の月例更新で2021年2月以降の更新が入っている環境では、5829を探し続けても見つからない可能性があります。

まず確認：イベントは「Systemログ」「ソース NETLOGON」に記録される

5827～5831は、イベントビューアーのWindowsログ → Systemに、イベントソースNETLOGONとして記録されます。セキュリティログを見ていたり、別チャネルを見ていたりして「出ない」と誤判定するケースがあるため、最初に“見る場所”を固定しましょう。

イベントID 5827～5831の意味を整理してから監視する

「5829～5831が出ない」だけを見ても判断はできません。Microsoftはこれらを拒否・例外許可・初期フェーズ許可の3カテゴリに整理しています。

カテゴリイベントID対象意味実務での読み方
拒否5827マシン アカウント脆弱な接続が拒否されたすでに影響が出る可能性。優先度高で原因端末を追う
拒否5828トラスト アカウント脆弱なトラスト接続が拒否されたドメイン間信頼に影響し得る。急ぎで経路確認
例外許可（GPO）5830マシン アカウントGPO許可リストにより脆弱接続を許可“暫定逃がし”が動作中。期限を決めて撤去が前提
例外許可（GPO）5831トラスト アカウントGPO許可リストにより脆弱なトラスト接続を許可森林全体のリスクが上がりやすい。最小・短期で
初期フェーズ許可5829マシン アカウント初期フェーズで脆弱接続が許可された（将来は拒否される）“今は通るが、放置すると強制で止まる”。洗い出しの起点

結論：5829～5831が出ない＝ログ故障とは限らない

最重要のポイントは、イベントは「非準拠の接続が実際に発生したとき」だけ出るということです。非準拠端末が存在していても、たまたま最近その端末がDCへNetlogon セキュア チャネル接続していないなら、ログは増えません。

また、強制フェーズ（2021年2月9日以降の更新）では、非準拠接続は拒否され、5829の記録自体がなくなるため、「5829が出ない」ことだけでは判断できません。強制フェーズでは5827/5828（拒否）や、許可リスト運用時の5830/5831（例外許可）へ監視の軸を移します。

切り分け：イベントが出ないときに確認するポイント

確認ポイントよくある落とし穴確認方法（例）判断
見ているログが正しいかSecurityログや別チャネルを見ているWindowsログ → System／ソース NETLOGON をフィルター場所が違えば当然出ない
監視対象が全DCか1台のDCだけ見て結論を出す複数DCがあるなら全台のSystemログを確認・収集“担当DCの違い”で見落とすことがある
強制フェーズ相当になっていないか2020年8月更新のつもりでも月例更新で2021年2月以降が入っている2021/02/09以降の更新の適用状況、または強制設定（レジストリ）を確認強制なら 5827/5828 を優先監視
GPO許可リストを設定していないのに5830/5831を探していないか“5830/5831＝検知ログ”と誤解する5830/5831は「許可リストで例外許可した場合」に出る例外なし運用なら5830/5831は出ないのが正常
そもそも非準拠接続が発生しているか古い機器があるが最近動いていない／認証経路が別対象機器の稼働状況、認証先DC、ネットワーク到達性を確認“発生していない”ならログも出ない

強制（Enforcement）かどうかを見分ける：レジストリ「FullSecureChannelProtection」

初期展開フェーズの更新では、強制を早めたい場合にレジストリ設定でEnforcement相当へ移行できます。キーは HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters の FullSecureChannelProtection（REG_DWORD） で、1＝強制、0＝非Windows端末からの脆弱接続を許可と説明されています（再起動不要）。

項目内容
レジストリ パスHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
値の名前FullSecureChannelProtection
型REG_DWORD
1強制（非準拠接続は拒否。許可するにはGPO許可リストが必要）
0非Windows機器からの脆弱接続を許可（強制フェーズでは廃止方向）
再起動不要

注意点として、2021年2月9日以降の更新ではDCが強制モードになるため、レジストリキーの意味合いが変わります（「2021/02/09以降の更新で強制が有効になる」「その時点で当該キーは不要・非サポート」と説明されています）。

「GPOを有効化してログを出す」は基本的におすすめしない

GPO「Domain controller: Allow vulnerable Netlogon secure channel connections」は、名前の通り脆弱な接続を“例外として許可”する仕組みです。Microsoftは、これをサードパーティ機器が準拠するまでの一時的な猶予として位置付け、許可リストに入れたアカウントはリスクが上がるため、最終的には必ず取り除くべきだと注意しています。ログ目的だけで安易に許可すると、観測のために安全性を下げる本末転倒になりやすいので、原則は避けましょう。

GPO許可リストの要点：場所・意味・デフォルト

このポリシーは「特定のマシン アカウントについて、DCがsecure RPCをバイパスしてNetlogon セキュア チャネル接続を許可するか」を決めます。適用先は原則として森林内の全DC（Domain Controllers OU）です。デフォルトは未構成で、明示的な例外はありません。

項目内容
ポリシー パスComputer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
設定名Domain controller: Allow vulnerable Netlogon secure channel connections
意味指定したマシン アカウントはsecure RPCなしのNetlogon セキュア チャネル接続を許可（Allow）できる
Denyデフォルトと同等（許可しない）
再起動不要
デフォルト未構成（例外なし）

安全に洗い出すための実務フロー（おすすめ）

許可リストを広げずに、非準拠端末の有無を判断し、強制フェーズでの事故（認証できない／サービス停止）を避けるための流れを、現場向けに噛み砕くと次の通りです。

段取りやることポイントアウトプット
観測基盤を整える全DCのSystemログ（ソースNETLOGON）を検索できるようにする「担当DCの違い」を吸収する監視条件（5827～5831）とアラート
ログで候補抽出初期フェーズなら5829、強制フェーズなら5827/5828を継続監視イベントは“発生したときだけ”増える候補端末リスト（端末名・OS・IP等）
是正計画を回す更新、設定変更、更改、隔離で非準拠を減らすベンダー対応状況と更改計画をセットで管理対応計画・期限・担当
最終確認一定期間、対象イベントが出ない（または拒否が解消）ことを確認“ログが出ない＝安全”と決め打ちせず、期間を持って見る例外ゼロ運用の証跡

DC側：PowerShellでイベントを検索・一覧化する例

単体DCで、Systemログから5827～5831を抽出して現状把握します（ソースはNETLOGON）。

Get-WinEvent -FilterHashtable @{
  LogName      = 'System'
  ProviderName = 'NETLOGON'
  Id           = 5827,5828,5829,5830,5831
} -MaxEvents 200 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List

複数DCがある場合は、横断収集が効きます。集中ログ基盤がないなら、PowerShellリモートでCSV化すると「出ない／出ていた」を短時間で確認できます（実行には権限とPS Remotingの前提があります）。

$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
  Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'NETLOGON'
    Id           = 5827,5828,5829,5830,5831
  } -MaxEvents 200 |
  Select-Object @{n='DC';e={$env:COMPUTERNAME}}, TimeCreated, Id, LevelDisplayName, Message
} | Export-Csv .\netlogon_5827-5831.csv -NoTypeInformation -Encoding UTF8

EVTXを書き出して分析したい場合（Microsoft提供スクリプトの考え方）

「本番DCに負荷をかけたくない」「監査チームが手元で分析したい」場合は、イベントビューアーでSystemログをEVTXとして保存し、別マシンで集計する運用も現場ではよく使われます。MicrosoftはEVTXを処理してExcel（ピボット付き）にまとめるスクリプト例を公開しており、エクスポート手順も説明しています。

  • まず各DCで System ログを「Save All Events As…」でEVTX保存する
  • 集計用端末でEVTXをまとめて処理し、端末別・イベント別の傾向を見る
  • ログ量が多い場合は期間を区切り、定期的に繰り返す

端末側：Windowsなら Test-ComputerSecureChannel で状態を確認できる

Windows端末であれば、セキュア チャネルの状態確認に Test-ComputerSecureChannel を使えます。大量台数の一括は工夫が必要ですが、「疑わしい端末」や「重要サーバー」から優先して当てると判断が早くなります。

Test-ComputerSecureChannel -Verbose

Windows Server 2003や非Windows機器が混在する場合の現実解

古いOSや非Windows機器が絡むと、ここからが実務の勝負どころです。ポイントは「一括で安全に判定できる万能手段は少ない」ため、ログ監視＋個別確認＋ベンダー確認の合わせ技で進めることです。

対象典型パターンおすすめの確認順落としどころ
サポート中のWindows端末原則は準拠（未更新やGPO不備で例外あり）ログ（5827/5828/5829）→ 更新状況 → GPO適用更新徹底とGPO整備で解消することが多い
サポート切れWindows（例：Server 2003）準拠できない／検証も難しいログ痕跡 → どの業務が依存しているか → 代替策更改・隔離・撤去を前提に計画（“残す理由”を明文化）
非Windows機器（NAS、アプライアンス、Linux/Samba等）製品ごとに対応差／アップデート待ちベンダー情報 → ファーム更新 → どうしても無理なら暫定例外最終的にはsecure RPC対応へ更新、または置き換え

Microsoftは「サードパーティのクライアントやサーバーは、Netlogon セキュア チャネルでsecure RPCを使う必要がある。対応状況はメーカーに確認してほしい」と明記しています。

どうしても例外が必要なときの“最小化”ルール

本来は例外ゼロが理想ですが、業務都合で「今すぐ更改できない」機器が残るケースはあります。その場合でも、許可リスト運用は次のルールで“被害を最小化”してください。

  • 許可リストはセキュリティ グループで管理し、個別アカウントをGPOに直書きしない（複製遅延・運用事故を減らす）
  • 許可対象は最小限にし、期限（撤去日）を必ず設定する
  • 5830/5831が出たら「例外が動作している証跡」。更新後に必ずグループから外す
  • トラスト アカウントを許可する運用は森林全体のリスクが上がりやすいので、特に慎重に扱う

よくある質問

5829が一度も出ません。非準拠端末はゼロと判断していいですか？

可能性としては「非準拠の接続が発生していない（＝該当端末がいない、または最近接続していない）」が第一です。ただしDCが複数ある場合は“担当DCの違い”で見落とすことがあるため、全DCで一定期間監視してから結論を出すのが安全です。

5827/5828も、5829も出ません

この場合も、現時点で非準拠接続が観測されていない可能性が高いです。Microsoft Q&Aでも「非準拠の接続がなければイベントは出ない」趣旨の説明がされています。

5830/5831が出ています。まず何をすべき？

許可リストによる例外運用が動いている状態です。例外対象の機器を特定し、ベンダー更新や更改計画を前倒しして、許可リストから外せる状態に持っていくのが最優先です（例外は短期の猶予として扱うべき、とされています）。

まとめ：イベントが出ないときに“焦らず”やるべきこと

  • 5827～5831はSystemログでソース NETLOGONを確認する
  • 初期フェーズは5829、強制フェーズは5827/5828（必要なら5830/5831）に監視の軸を置く
  • 5829～5831が出ないのは「非準拠接続が発生していない」だけのことも多い
  • 許可リストGPOはログ目的で有効化せず、必要最小限・短期・撤去前提で運用する
  • 不安が残る端末は端末側確認（WindowsはTest-ComputerSecureChannel）とベンダー確認で裏を取る
Active Directory
イベントログ ドメインコントローラー Netlogon ZeroLogon CVE-2020-1472

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次