Windows Server 2019で全ユーザーがログインできない原因と対処法｜DNS切り分け・セーフモード継続・Snatchランサムウェア対応

Windows Server 2019 のドメイン コントローラーで突然「全ユーザーがログインできない」「クライアントもログオン不可・通信不可」になると、まずDNSやパスワードを疑いがちです。本記事では、切り分けの順序を整理しつつ、最終的に“セーフモード起動の継続”と“Snatch ランサムウェア感染”に行き着いたケースを踏まえて、現場で役立つ確認ポイントと対処方針をまとめます。

起きている現象を一つにまとめると「DCが仕事をしていない」状態

今回の状況は、単体のログオン障害ではなく、ドメイン全体（認証・名前解決）が同時に崩れているのが特徴です。症状を並べると、共通点が見えてきます。

• サーバー（DC）に Administrator／ドメイン／ローカル いずれもログインできない（「ユーザー名またはパスワードが違います」）
• ./ユーザー名 のようにローカル指定を試すと、「ドメインが利用できないためサインインできない」
• クライアントもログオン不可、さらにインターネットへ出られない
• 回復USBから見た際、ディレクトリ表示の途中で 「DNS bad key」 のような不審な表示
• “回復コンソール経由の強制パスワード変更”を試しても改善しない

ドメイン環境（特にDCが1台の小規模構成）では、DCが停止・異常状態になると次の連鎖が起きます。

• AD DS / KDC / Netlogon が機能しない → ドメインログオンが失敗
• DNS（社内の権威DNS）が止まる/応答不良 → クライアントは社内外の名前解決ができない
• 結果として「ネットが死んだ」に見える（実体はDNS不全であることが多い）

つまり、表面は「パスワード違い」でも、実態は“認証基盤（DC）そのものが正常に起動していない／起動できていない”可能性が高い、というのが最初の見立てになります。

最初にやるべき切り分け：入力ミス・指定ミスを潰してから、構成不全へ進む

原因が深刻（マルウェア等）であっても、現場ではまず単純ミスの可能性を短時間で潰すのが効率的です。特に「ローカル指定の書き方」「DC特有のログオン挙動」を押さえると、無駄な遠回りを減らせます。

ローカル／ドメインのログオン指定を正しく理解する

まず大前提として、ドメイン コントローラー（DC）には一般的な意味での“ローカルユーザー（SAM）”が存在しません。通常のメンバーサーバーやクライアントPCと違い、DCではアカウント管理の中心がADになるためです。

さらに、DCがセーフモード（Directory Services Restore Mode / DSRM）で起動していると、ドメインアカウントではログオンできず、特定の方法（DSRMのAdministrator）に限定されます。ここを知らないと「全部パスワードが違う」ように見えて混乱が増えます。

ログオン先の意図	入力例	ポイント
ドメインユーザーでログオン	DOMAIN\user / [email protected]	DCやドメインが正常であることが前提。DNS不全やDC異常で失敗しやすい
ローカルユーザーでログオン（クライアント/メンバーサーバー）	.\user / COMPUTERNAME\user	./user ではなく .\user（ピリオド＋バックスラッシュ）
DCのセーフモード（DSRM）でログオン	Administrator（DSRMパスワード）	ドメインのAdministratorパスワードと別物になり得る。DSRMを設定していないと詰みやすい

今回のケースでも、切り分けとして重要なのが次の2点です。

• ローカル指定は .\ユーザー名（./ は誤りになりやすい）
• ただしDCの場合は“ローカルのつもり”が成立しにくい（セーフモード/DSRM絡みで挙動が変わる）

ログオン不可のときに一瞬で確認したい「ありがち」

ここは原因の本丸ではないことが多いですが、短時間で潰せます。

• キーボード配列（WinRE/セーフモード/リモートで配列が変わることがある）
• Caps Lock / Num Lock（サーバー室のKVM経由で地味に起きる）
• 時刻ずれ（Kerberos認証は時刻差に弱い。DCが単独でずれると広範囲に影響）
• アカウントロックアウト（ただし今回のように“全ユーザー”なら、より基盤障害が疑わしい）

DNSの切り分け：AD障害に見えて、実は“DNS参照先の崩れ”が引き金のこともある

ADはDNS依存が非常に強く、特にクライアントのDNS参照先が崩れると、ドメインログオン・グループポリシー・ファイル共有などが連鎖的に壊れます。今回の症状（クライアントがログオンできない、通信できない）とも整合します。

推奨されるDNSの基本形

小規模でも“基本形”を外すと一気に不安定になります。

対象	推奨DNS設定（概要）	避けたい例
クライアントPC	DC（DNSサーバー）の固定IPのみを参照	ルーターDNSやパブリックDNS（8.8.8.8等）を混在
ドメイン コントローラー（DNS稼働）	原則として自分自身（自身の固定IP、または127.0.0.1）を参照。複数DCなら相互参照も可	外部DNSを直接参照（名前解決はできてもAD関連が不整合になりやすい）
ルーター/上位DNS	クライアントに配るDNSはDCに固定。外向きはDC側のDNSフォワーダーで処理	DHCPでクライアントに「ルーターDNS」を配布

クライアント側での簡易テスト（ログオンできないときでも有効）

クライアントが「ネットに出られない」と言うとき、IP到達性はあるがDNSだけ死んでいるケースが多々あります。次のように“IPと名前解決を分けて”見ます。

テスト	例	結果の読み方
IPで外部疎通	ping 1.1.1.1	成功するなら回線やGWは生きている可能性が高い
名前解決の疎通	ping www.microsoft.com	失敗するならDNS不全の疑いが濃い
DNSサーバー応答	nslookupで既定DNSがDCになっているか確認	DCを引けない／応答が遅いなら、DC（DNS）が落ちている・セーフモード等が疑わしい

ただし今回のケースは、DNS設定だけでなくDC自体が“通常起動していない”ことが原因でした。DNSを直してもDCが正しく稼働していなければ、根本解決になりません。

“ドメインが利用できない”を一撃で説明できる原因：セーフモード起動の継続

結論から言うと、今回の大きな転機は「サーバーがセーフモードで起動し続けていた」点です。これに気づけないと、ログオン障害・DNS障害・通信障害が別々の問題に見えて泥沼化します。

DCがセーフモード（DSRM）だと何が起きるのか

Windows Serverのセーフモードでは、起動するドライバーやサービスが限定されます。さらにドメイン コントローラーの場合は、通常のセーフモードがDirectory Services Restore Mode（DSRM）として動作し、AD DSが通常通り稼働しません。

• ドメインに必要なサービスが起動しない／限定される
• 結果としてドメイン認証が成立しない（「ドメインが利用できない」系のメッセージ）
• DNSサービスも起動しない/不完全なことがあり、クライアントがDNSを失ってインターネット不可に見える

つまり、「全ユーザーのログオン不可」と「クライアントの通信不可」が、セーフモード継続という一本の線でつながります。

セーフモード継続に気づくためのチェックリスト

兆候	見え方	補足
画面の四隅にセーフモード表示	コンソール画面に「セーフ モード」表示が出る	リモート運用だと見逃しやすい。KVMや現地確認が効く
ドメインログオンがことごとく失敗	「ユーザー名またはパスワードが違います」「ドメインが利用できない」	DCのDSRMログオンと混同しやすい
クライアントが一斉に不調	ログオン不可、社内外への名前解決不可	DNSがDC固定の環境ほど影響が大きい（それ自体は正しい設計だが、DC単独障害に弱い）
起動モードが固定される	再起動しても通常起動に戻らない	ブート設定（BCD）にセーフモード指定が残っている可能性

セーフモード固定を解除する実務的アプローチ

セーフモードから通常起動に戻す方法はいくつかありますが、ログオンすらできない状況では、回復環境（WinRE）からブート設定を確認・修正するのが現実的です。ここでは“防御目的の復旧”として、よく使われる考え方を紹介します。

ブート設定（BCD）に「セーフモード指定」が残っていないか確認する

代表例として、ブートエントリに safeboot が設定されていると、再起動してもセーフモードが継続します。現場では「いつの間にかセーフモード固定になっていた」という相談が起きます。

確認の考え方

• 回復環境からコマンドプロンプトを開き、ブート設定を列挙する
• safeboot のような項目が付いていないかを見る
• 必要に応じてセーフモード指定を削除して通常起動へ戻す

WordPressにそのまま貼れる形で、コマンドの“例”を置いておきます（環境により識別子が異なるため、まず列挙して読み替えるのが安全です）。

bcdedit /enum

# safeboot が付いている場合の例（識別子は環境で異なります）
bcdedit /deletevalue {default} safeboot

回復環境から操作する場合、システムドライブの文字が通常と異なることがあります。慣れていない場合は無理に進めず、バックアップ取得や専門家の支援を優先してください。（ランサムウェア疑いがあるならなおさら）

“パスワードを無理やり変える系”が効かない理由と注意点

今回のケースでも、“回復コンソールからの強制パスワード変更”を試して改善しなかった、とされています。これは不思議ではありません。

• 原因が認証基盤（AD DS/DNS/起動モード）にある場合、パスワード変更は筋が違う
• 原因がマルウェア（侵害）の場合、変更しても再度奪取される／起動設定を書き戻される可能性がある
• 復旧の過程でシステムファイルを書き換えると、調査・監査・復旧判断が難しくなることがある

「何が起きたか分からない」「不審な表示がある」という時点で、まずは封じ込めと保全を優先し、ログオン回復のための強引な改変は慎重に扱うのが現実的です。

真因にたどり着く視点：セーフモード固定が“偶然”とは限らない

「いつの間にかセーフモードで起動していた」という事象は、人的ミス（msconfig設定など）でも起き得ます。しかし、今回のケースでは最終的にSnatch ランサムウェア感染が原因だった、と自己報告されています。

Snatch（など一部ランサムウェア）が“セーフモード”を悪用する理由

一般論として、セーフモードでは常駐型のセキュリティ製品や監視機構がフルに動作しない場合があり、攻撃者にとって都合が良いことがあります。そのため、ブート設定を変更してセーフモード起動へ誘導するタイプの事例が報告されています。

ここで重要なのは、セーフモード固定＝単なるOSトラブルと決めつけないことです。特に次のような“状況証拠”が重なるなら、インシデントとして扱うのが安全です。

不審ポイント	現場での見え方	防御側の観点（次に取るべき行動）
起動モードが勝手に変わった	通常起動に戻らない／セーフモード表示	ブート設定の改変を疑い、まず隔離・保全を検討
ログオン不可が“全員・全端末”で発生	ドメイン全体が止まったように見える	DCの稼働状態、DNS、AD DSの状態を重点確認
不審な文字列・表示（例：DNS bad key）	回復環境で見慣れないエラーや痕跡	「侵害の兆候」として扱い、ログ/ディスク保全の優先度を上げる
復旧操作が効かない	再起動しても戻らない、対処しても再発する	単純故障ではなく、仕組みとして“戻される”可能性を想定

ランサムウェア疑い／確定時に優先すべき「実務の順序」

DNS設定やログオン指定の調整は重要ですが、マルウェアが絡むと、そこに時間をかけるほど被害が広がる可能性があります。疑いが出た時点で、優先順位を切り替えましょう。

優先度	やること	狙い
最優先	ネットワークから隔離（物理的にLANを抜く／スイッチで遮断／VPN切断など）	横展開と追加暗号化の抑止
高	バックアップの保全（接続解除・世代確認）	バックアップ破壊や暗号化から守る
高	ログ/証跡の確保（可能ならディスクのイメージ取得、イベントログ退避）	侵入経路・影響範囲の特定、再発防止に必須
中	復旧方針の決定（クリーン復元か再構築か）	安全な復旧ルートを選ぶ
中	資格情報の総入れ替え（管理者/サービスアカウント含む）	再侵入・再暗号化の芽を摘む

ドメイン コントローラーは「復旧」より「再構築」を視野に入れる

DCが侵害されている可能性がある場合、“元に戻して使い続ける”リスクが高くなります。理由は単純で、DCは認証の根幹であり、侵害されると以下が起こり得るためです。

• 管理者権限の資格情報が漏えいしている可能性
• 不正な永続化（隠しアカウント、スケジュール、サービス、GPO改変など）が残りやすい
• 表面的に復旧しても、後から再侵入される

規模や要件にもよりますが、クリーンなバックアップ（暗号化・改ざん前の世代）からの復元、もしくは新規にDCを構築してドメインを健全化する選択肢を、最初から検討に入れておくのが実務的です。

復旧後の再発防止：小規模ドメインほど“仕組み”で守る

クライアント約8台の小規模環境でも、DCが止まると業務が止まります。だからこそ、運用で頑張るのではなく、仕組みで事故と侵害に強くするのが近道です。

カテゴリ	推奨施策	狙い
冗長化	可能ならDCを2台にする（DNSも冗長化）	1台障害で全停止しない
DNS設計	クライアントDNSはDC固定、外向きはDNSフォワーダーで制御	ADの安定稼働、切り分け容易化
バックアップ	オフライン/イミュータブルを含む多層バックアップ、復元テストを定期実施	暗号化されても戻れる状態を作る
資格情報	管理者のMFA、不要な特権の削減、サービスアカウントの棚卸し	侵入後の横展開を抑える
外部公開	RDP直公開を避ける（VPN/踏み台/アクセス制御）、公開ポート最小化	侵入経路の縮小
監視	イベントログの収集、アラート設計、EDR/AVの導入と健全性監視	早期検知・被害最小化
運用手順	DSRMパスワード管理、緊急時連絡手順、復旧手順の文書化	“詰み”を減らし復旧時間を短縮

今回のケースを「次に活かす」ためのまとめ

Windows Server 2019 のDCで「全ユーザーがログインできない」「クライアントもログオン不可・通信不可」になったとき、原因は一つとは限りません。しかし、切り分けの順序を間違えると、復旧も調査も長引きます。

• まずはログオン指定の基本（.\ユーザー名 等）と、DC特有の挙動（DSRM）を踏まえて、入力ミス・指定ミスを短時間で排除する
• 次にDNS参照先を確認し、クライアントがDC固定になっているか、ルーターDNS混在がないかを点検する
• そして見落としやすい本命として、セーフモード起動が継続していないかを疑う（DCなら“ドメインが利用できない”が説明できる）
• 不審点があるなら、ランサムウェア等のインシデントとして隔離・保全・再構築を優先する

特に「セーフモード固定」と「不審な表示（例：DNS bad key）」が同時に見える場合は、単なる設定ミスではなく、侵害の可能性も視野に入れたほうが安全です。復旧を急ぐほど“強引な操作”をしたくなりますが、被害拡大や再発防止の観点では、正しい順序で、確実に切り分けることが一番の近道になります。