Windows Server 2025のドメイン コントローラーが毎日再起動しないとサインインできない問題を解決する:原因特定手順と恒久対策(Netlogon/Kerberos/DFS-R/DNS)

「Windows Server 2025 のドメイン コントローラーを毎日再起動しないとユーザーがサインインできない」という相談は、単なる“OS の不具合”で片付けると再発を招きます。本稿では、実運用で再現しやすい切り分け順と、暫定回避から恒久対策までを一気通貫で示し、再起動運用に依存しない安定稼働へ導きます。

目次

質問の背景と想定シナリオ

対象は Windows Server 2025 を実行するドメイン コントローラー(以下 DC)。ユーザーはドメイン サインインやネットワーク共有(SMB)へ接続できず、DC を再起動すると一時的に回復する、という現象です。9 月の累積更新プログラム適用後も改善せず、根本原因と恒久対策を求めている――この前提で解決を設計します。

解決の全体像(結論の要約)

  • まずは「サービス依存か、OS/基盤依存か」を 2 分探索します。Netlogon/KDC の再起動だけで回復するなら認証スタック中心の問題、効果がないなら OS/ネットワーク/SYSVOL レプリケーションを重点調査します。
  • DCDiag・repadmin・イベントログで根拠を押さえ、DNS・時刻同期・DFS-R・リソース枯渇・SPN 重複などの“よくある根因”をつぶします。
  • 恒久策は、最新更新の適用レプリケーション修復DNS/時刻同期の是正NIC/仮想化の見直し監視と自動回復の組み込み、そして複数 DC 化の 6 本柱で固めます。

再現時にまず行う切り分け(サービス再起動)

再起動せずに、認証に直結する 2 サービス(Netlogon, KDC)だけを再始動します。これで回復すれば OS 全体ではなく認証スタックに絞れます。

net stop netlogon   & net start netlogon   REM Netlogon
net stop kdc        & net start kdc        REM Kerberos Key Distribution Center
  • これでドメイン サインインや共有アクセスが回復 → Netlogon/Kerberos の停止・ハング・到達性低下が主因。
  • 効果なし → OS/ネットワーク層、DNS、SYSVOL/レプリケーションの疑いが濃厚。

DCDiag とイベントログで「どこが壊れているか」を定量化

DC 全体の健全性は DCDiag で一括確認し、ログで裏を取ります。

dcdiag /v /c /e /f:dcdiag.txt
  • dcdiag.txtFAIL / WARN 行を要チェック。
  • ログは「システム」「アプリケーション」「ディレクトリ サービス」「DNS サーバー」「DFS レプリケーション」を中心に、Netlogon, KDC, DFS-R, NTDS, DNS のイベント ID を集計。

SYSVOL/NETLOGON 共有の可視性と DFS-R の状態確認

SYSVOL/NETLOGON が共有されていないと、クライアントのログオン スクリプトやポリシー配布が機能せず、結果的に認証・権限付与に支障します。

net share
nltest /dsgetdc:<ドメイン名>
  • SYSVOL / NETLOGON が一覧にない、nltest が失敗する → DFS-R の停止/保留やレプリケーション障害の可能性。
  • DFS-R の代表的な停止兆候は、起動時の不正シャットダウン後に 保留 状態になるケース。イベント ビューアーで 2213, 2214 を確認し、復旧手順(サービスの開始、保留解除、バックログ解消)を実施します。

ネットワーク/DNS 設定の是正ポイント

重点ポイント推奨確認内容
DC の DNS 設定自分自身または他の AD DNS のみを指定。ISP 公開 DNS の混在禁止。逆引き/ゾーン委任の誤りも確認。
名前解決の健全性Resolve-DnsName _kerberos._tcp.dc._msdcs.<ドメイン> で SRV レコードが引けるかを確認。
ファイアウォールドメイン プロファイルで Kerberos(88/464), SMB(445), RPC(135) が許可されているか。
NIC ドライバー/オフロード最新版へ更新。RSC/LSO/RSS の過剰最適化が不具合の温床になる場合は無効化して比較。
ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Test-NetConnection -ComputerName &lt;他DC名&gt; -Port 88

時刻同期(W32Time)と Kerberos の関係

Kerberos はクライアントと DC の時刻差に敏感です。PDC エミュレーターの時刻源、仮想化環境の時刻同期挙動を是正しましょう。

  • 推奨:PDC エミュレーターは外部 NTP と同期。他の DC/メンバーはドメイン階層で時刻同期。
  • 仮想化 DC は、PDC 以外はハイパーバイザーの時刻同期を無効にし、ドメイン同期へ一本化(時刻ループ防止)。
w32tm /query /status
w32tm /query /peers
w32tm /config /syncfromflags:manual /manualpeerlist:"ntp.example.jp,0x8" /update
w32tm /resync

レプリケーション(NTDS/DFS-R)の定量診断

repadmin /replsummary
repadmin /showrepl * /csv &gt; showrepl.csv
  • エラー率 5% 以上や遅延が大きい場合、サイト/サブネットの定義レプリケーション トポロジスケジュールの見直しが必要。
  • DFS-R はバックログと保留解除を確認(バックログが積み上がると SYSVOL/NETLOGON の可視性が途絶)。

SPN(Service Principal Name)重複・誤登録の検出

SPN の衝突は KRB_AP_ERR_MODIFIED などの認証失敗を招き、負荷や特定タイミングで顕在化して「再起動で直る」現象を生みます。

setspn -X -F
  • 重複が出た場合は原因サーバーを特定し、意図しない SPN を削除(setspn -D)。
  • コンピューター アカウントの安全なチャネル異常は、必要に応じて Test-ComputerSecureChannel -Repair を実施。

セキュリティ ポリシー変更の影響(Netlogon, LDAP, SMB)

近年の更新で、Netlogon RPC シーリング強化、LDAP 署名/チャネル バインドの既定強化、SMB 署名強制など、古いクライアントや中間装置との相互運用性が崩れるケースがあります。以下は切り分けの観点です。

  • Netlogon:古い OS/機器が新しいセキュリティ要件に未対応だと DC 側で拒否され断続的な失敗に見えることがある。
  • LDAP:署名/チャネル バインド必須化により、古いバインドを行うアプリや機器がエラー化。
  • SMB 署名:署名必須に移行したタイミングで、古い NAS/プリンタ サーバーが認証に失敗。

これらは原則として「クライアント側の更新」や「アプリ改修」で是正します。やむを得ず一時回避する場合でも、範囲・期間・影響を厳格に限定してください。

リソース枯渇・リーク・ポート逼迫の可能性

  • LSASS/サービスのハンドルやメモリ リーク:非ページ プール(Event 2019/2020)や LSASS のメモリ肥大で認証が応答不能に。
  • エフェメラル ポート枯渇:大量の短命セッションで TIME_WAIT が蓄積し RPC/SMB が失敗。
  • ディスク I/O ボトルネック:NTDS.dit や SYSVOL の I/O 待ちが認証遅延を増幅。
perfmon  REM カウンター例:
         REM Process(lsass) - Handle Count, Private Bytes
         REM Memory - Pool Nonpaged Bytes
         REM TCPv4 - Connections Established
         REM PhysicalDisk - Avg. Disk Queue Length

設計目安として、物理メモリ 16GB 以上、システム ドライブ空き 15% 以上を確保。仮想化なら vCPU 競合・ストレージ遅延も併せて評価します。

ネットワーク基盤・仮想化固有の留意点

  • 仮想 DC のスナップショット/復元禁止(USN ロールバックの危険)。バックアップは VSS など DC 対応の手法で。
  • ハイパーバイザーの時刻同期は、PDC の設計に従って適切に構成。PDC 以外の DC は無効化してループを回避。
  • NIC の電源管理(省電力)を無効化。チーミング/仮想スイッチの設定誤りがレプリケーションや RPC に影響するため構成を棚卸し。

「暫定」と「恒久」を分けて打つ――実行順序テンプレート

  1. 再発直後の暫定回復:Netlogon/KDC を再起動。効果を記録。
  2. 健全性の採取:DCDiag, repadmin, イベントログ、net sharenltest、時刻同期、DNS。
  3. 基礎体力の底上げ:最新累積更新、NIC/BIOS/ファーム更新、ディスク空き/メモリ増設。
  4. 設計の是正:DNS 単純化、時刻階層、サイト/サブネット、レプリケーション スケジュール。
  5. 監視と自動回復:サービス障害時の自動再起動、死活監視と通知。
  6. 冗長化:二台目 DC を導入し、単一障害点を排除。

すぐ使えるコマンド集(コピー&ペースト)

認証サービスの再始動

net stop netlogon   &amp; net start netlogon
net stop kdc        &amp; net start kdc

DNS と SRV レコード

Resolve-DnsName _ldap._tcp.dc._msdcs.&lt;ドメイン&gt;
Resolve-DnsName _kerberos._tcp.dc._msdcs.&lt;ドメイン&gt;

レプリケーション健全性

dcdiag /v /c /e /f:dcdiag.txt
repadmin /replsummary
repadmin /showrepl

SYSVOL/NETLOGON・DC 検出

net share
nltest /dsgetdc:&lt;ドメイン&gt;

時刻同期の確認/再同期

w32tm /query /status
w32tm /resync

SPN の重複検出

setspn -X -F

Netlogon/KDC に自動回復(障害時再起動)を設定

sc failure netlogon reset= 86400 actions= restart/600
sc failure kdc      reset= 86400 actions= restart/600

「原因 × 症状 × 対処」を 1 ページで把握できる表

想定原因現れる症状確認コマンド/ログ暫定対処恒久対処
Netlogon/KDC のハングサインイン不可、再起動で復帰イベント(Netlogon/KDC)、sc query該当サービス再起動更新適用、監視/自動再起動、原因サービスの修正
DNS 誤設定DC 検出失敗、共有/認証失敗Resolve-DnsName、イベント(DNS)一時的に DC のみを DNS に指定ゾーン整備、ISP DNS 混在排除
DFS-R 保留/停止SYSVOL/NETLOGON が見えないイベント 2213/2214、net shareDFS-R 再開、バックログ解消安定化(NIC/ディスク)、正常終了運用の徹底
時刻ずれKerberos 失敗(KRB5KRB_AP_ERR_SKEW)w32tm /query /status即時再同期時刻階層の是正、仮想時刻同期の整理
SPN 重複断続的な認証失敗setspn -X -F該当 SPN を一時無効化SPN 設計/棚卸し、重複除去
リソース枯渇応答遅延/タイムアウトPerfMon、イベント 2019/2020不要プロセス停止メモリ増設/ディスク高速化/更新適用
セキュリティ強化との互換性古い端末/機器のみ失敗イベント(Netlogon/LDAP/SMB)影響範囲限定で回避設定クライアント更新/設定是正

チェックリスト(現場でそのまま使える)

  • [ ] 再発時に Netlogon/KDC 再起動で回復するか/しないかを記録
  • [ ] dcdiag /v /c /e の FAIL/WARN を一覧化
  • [ ] net shareSYSVOL, NETLOGON がある
  • [ ] nltest /dsgetdc:<ドメイン> が成功する
  • [ ] Resolve-DnsName _kerberos._tcp.dc._msdcs.<ドメイン> が引ける
  • [ ] repadmin /replsummary のエラー率 < 5%
  • [ ] w32tm /query /status の同期先とオフセットが妥当
  • [ ] setspn -X -F が重複なし
  • [ ] 物理メモリ 16GB 以上、システム空き 15% 以上
  • [ ] NIC ドライバー最新、省電力/過剰オフロードの無効化
  • [ ] サービスの自動回復設定(sc failure)を適用
  • [ ] 二台目 DC を導入済み(単一 DC 構成の解消)

恒久対策の実装ガイド

最新更新と既知問題の反映

  • 10 月以降の累積更新まで含め、セキュリティ更新とネットワーク スタック更新を網羅適用。
  • 更新後は必ず再起動 → DCDiag と repadmin を再実行し、事後の状態を記録。

レプリケーションと SYSVOL 安定化

  • サイト/サブネット/ブリッジヘッドを整理し、不要なハブ&スポークや長距離経由を排除。
  • DFS-R のバックログ監視を常設し、保留(2213)時は自動回復の運用手順を標準化。

DNS/時刻同期の標準設計

  • クライアント/サーバーの DNS は「AD DNS のみ」。スプリット ブレインなら検索順序と転送規則を明確化。
  • PDC は外部 NTP、その他はドメイン同期。仮想 DC の時刻同期はルール化(PDC 以外は無効)。

リソース計画と I/O 最適化

  • メモリ/CPU/ストレージの 5 年先を見据えたリザーブを計画。特に NTDS.dit と SYSVOL の I/O は高速ストレージへ。
  • SMB サーバーのチューニングは既定優先。独自レジストリ調整は最小限に(再現性の維持)。

監視・自動回復・運用基盤

  • 「Netlogon/KDC の死活」「レプリケーション遅延」「DFS-R 保留」「時刻オフセット」「DNS 応答」を日次で可視化。
  • サービスの自動再起動(sc failure)+ 3 回失敗で通知。根因解決までの 暫定策の運用化

冗長化と更新手順の定常化

  • 単一 DC を廃止し、少なくとも 2 台構成へ。PDC/LH の役割分散、障害時のフェイル手順を文書化。
  • 更新→再起動→健全性チェックの「標準手順」を運用に組み込み、“再起動でしか直らない”状態を検知したら即切り分けへ移行。

ケース別:よくある根本原因と修正例

ケース A:DFS-R が保留になり SYSVOL/NETLOGON が公開されない

現象:起動後しばらくするとログオン不能。再起動で一時的に復帰。
確認:イベント 2213/2214、net share に SYSVOL/NETLOGON が無い。
恒久策:DFS-R の保留解除とバックログ解消、ディスク健全性向上、計画停止/正常シャットダウンの徹底。

ケース B:DNS が外部 DNS を参照しており SRV 解決に失敗

現象:時間帯や端末により DC 検出失敗。
確認Resolve-DnsName _ldap._tcp.dc._msdcs.<ドメイン> の失敗。
恒久策:全サーバー/クライアントの DNS を AD DNS のみに統一、転送・ルート ヒントで外部解決。

ケース C:時刻同期の不整合(PDC と仮想化の設定競合)

現象:Kerberos 認証が断続的に失敗。
確認w32tm /query /status のオフセット増大。
恒久策:PDC を外部 NTP、他 DC はドメイン同期。ハイパーバイザーの時刻同期は PDC 以外無効。

ケース D:SPN 重複(Web/SQL/ファイル サービスの再構成後)

現象:特定サーバーの認証だけ不安定。
確認setspn -X -F で重複が検出。
恒久策:重複を除去し、サービス アカウントの SPN 管理を標準化。

ケース E:NIC ドライバーの既知不具合によるパケット欠落

現象:RPC/SMB のタイムアウトや断続エラー。
確認:イベントにネットワーク リセットやリンクフラップ、netstat の再送増加。
恒久策:NIC/ファーム更新、RSC/LSO の無効化比較、チーミング設定の見直し。

ケース F:LSASS メモリ/ハンドル リーク

現象:稼働時間が長くなるほどログオン遅延→不可。再起動で回復。
確認:PerfMon の LSASS Private Bytes/Handle Count が右肩上がり。
恒久策:問題モジュールの更新、影響機能の解除、容量増強+監視で早期検知。

作業ログの取り方(再現性と説明責任の確保)

  • すべてのコマンド結果(DCDiag/repadmin/w32tm など)をファイル出力し、再発前後の差分を保存。
  • 「再起動が必要になった瞬間」のイベント時刻を基点に、±30 分のログを抽出して因果関係を整理。
  • 復旧後の健全性レポートも必ず採取し、再現手順と回避手順をチームで共有。

二台目 DC の導入(最小のダウンタイム戦略)

単一 DC 構成は、どんなに調整しても「再起動=全停止」になります。段階的に 2 台目 DC を導入し、FSMO 役割の分担、サイト設定の見直し、DNS の冗長化を行い、片系での保守・障害でも影響を最小化します。

セーフティ ネット:自動回復と監視の最小セット

  • Netlogon/KDC の障害時に自動再起動(上記 sc failure)。
  • サービス停止/再起動を検知して通知(イベント サブスクリプションや監視製品)。
  • DFS-R 保留/バックログ、レプリケーション エラー、時刻ずれ、DNS 応答遅延を 5 分粒度で収集。

まとめ(再起動運用からの脱却)

本問題は、Netlogon/Kerberos の停止・レプリケーション障害・DNS/時刻同期の設計不良・リソース枯渇・セキュリティ強化との不整合のいずれか、もしくは複合であることがほとんどです。まずはサービス単体の再起動で依存レイヤーを切り分け、DCDiag/repadmin/イベントで根拠を固めましょう。恒久策は「最新更新」「レプリケーション修復」「DNS/時刻同期の是正」「NIC/仮想化の見直し」「監視と自動回復」「二台目 DC」の 6 本柱。これらを順序立てて実施すれば、毎日再起動しないとログオンできない運用から確実に卒業できます。


参考:実施順番のサンプル スクリプト(PowerShell)

以下は“診断→暫定回復→採取”を標準化する例です。ラボで検証のうえ、運用環境に適用してください。

# 1) 診断情報の採取
$stamp = (Get-Date).ToString("yyyyMMdd-HHmmss")
$base  = "C:\AD-Diagnostics\$stamp"
New-Item -ItemType Directory -Force -Path $base | Out-Null
dcdiag /v /c /e /f:"$base\dcdiag.txt"
repadmin /replsummary > "$base\replsummary.txt"
repadmin /showrepl * /csv > "$base\showrepl.csv"
w32tm /query /status > "$base\w32time.txt"
Resolve-DnsName _kerberos._tcp.dc._msdcs.<ドメイン> > "$base\kerberos_srv.txt"

# 2) 暫定回復(必要時)

Restart-Service -Name netlogon -Force
Restart-Service -Name kdc -Force

# 3) サービス自動回復設定

sc failure netlogon reset= 86400 actions= restart/600
sc failure kdc      reset= 86400 actions= restart/600 

よくある質問(FAQ)

  • Q: 9 月の累積更新を当てても直りません。
    A: 更新だけで直るケースは一部です。DNS/時刻/DFS-R/SPN/リソースなどの設計・運用要因を併せて是正してください。10 月以降の更新適用と再評価も推奨です。
  • Q: 一時的にでも「毎日の再起動」を継続すべき?
    A: できる限り避けてください。再起動は症状を隠蔽し、DFS-R の保留やレプリケーション遅延を悪化させる恐れがあります。サービス再起動+監視で切り分けを優先しましょう。
  • Q: 単一 DC ですが、まず何から?
    A: 二台目 DC の導入が最優先です。導入後は FSMO 分散、DNS 冗長化、バックアップ/復元の手順整備を続けます。

この記事の使い方(現場適用のコツ)

  1. まずは本記事のコマンドを “再発直後” に実行し、回復前後の差分を集める。
  2. 表の「原因 × 症状 × 対処」を使って、最短で当たりを引く(DNS/時刻/DFS-R から)。
  3. 暫定回避を当てつつ、恒久対策(設計是正・更新適用・冗長化・監視)を順に実装。

コメント

コメントする

目次