初めに
Ndictです。よろしくお願いいたします。
少し前のActive Directoryの教科書的な設計では、回線品質や耐障害性を考慮し、拠点ごとにドメインコントローラー（DC）を配置するのが定石とされていました。
これはローカルに認証基盤を持つことで、回線断時のサインイン不可リスクを回避し、サインイン処理の高速化を図るためです。
しかし、ハードウェアの導入・更新コストやライセンス費用、そして何より現地での運用保守負荷が重くのしかかる中小規模の現場において、全拠点へのサーバー設置は現実的ではありません。
そのため現在では、「全拠点にサーバーは置かず、本社に集約してYamahaルーター等のVPNで繋ぐ」という構成が、コストパフォーマンスに優れた現実解としてよく採用されています。
今回取り上げるのは、この「本社集約型AD」と「拠点間VPN」を組み合わせた環境で発生した、一見すると不可思議なトラブル事例です。
「拠点間VPN経由の拠点では問題なく無線サインインできていたPCが、サーバーがある本社のWi-Fi環境に入った途端、ドメインコントローラーの検出だけが失敗する」
物理的に離れた経路からはADが見えていて、目と鼻の先にある本社の無線LANからはADが見えない。
ネットワーク条件が良いはずの本社で、なぜこの「逆転現象」が起きたのか？
今回はその原因と、AD環境におけるDNS設計と、拠点間VPN上でのAD運用時の注意点について解説します。
環境と前提：既存VPNへの「AD追加」
まず、今回のトラブルが発生したシステム環境を整理します。
私が担当したのはサーバー側の構築のみで、ネットワーク機器の設定やクライアントPCの展開は依頼人側で実施されるというプロジェクトでした。
サーバー構成（担当：私）
・本社に Active Directory (DC) × 2台を新規構築。
・既存のファイルサーバー等も本社に集約済み。
ネットワーク構成（既存の運用）
・既存環境: 元々、各拠点から本社のファイルサーバーへアクセスするため、Yamaha RTX1210を用いたIPsec拠点間VPNが構築済み。
・今回の変更: ネットワーク構成はそのまま流用し、そのVPN網の上にActive Directory通信を乗せる設計。
クライアント環境（担当：依頼人）
・各拠点の端末はノートPCのみ。有線LANは使用せず、Wi-Fi接続が必須。
・PC側のネットワーク設定やキッティング作業は、現地の運用ルールに基づき依頼人が実施。
一見すると、既存の稼働実績があるVPN環境を利用する手堅い構成に見えます。
しかし、ファイルサーバーへのアクセスと、Active Directoryとでは、求められるネットワーク要件が異なります。
この認識の違いが、後にトラブルの原因となりました。
1ヶ月前の運用状況（拠点）：拠点間VPN経由での稼働開始
事の発端は、トラブル発覚の約1ヶ月前に遡ります。
私がActive Directory環境（DC構築・OU設計等）の構築を完了し引き渡した後、依頼人の手によって地方拠点で新規PCの展開が開始されました。
現地での手順は以下の通りでした。
1.PCにあらかじめ作成されたローカルアカウントでサインイン。
2.手動で現地のWi‑Fi接続後、拠点ルーターの拠点間VPNにより本社ネットワークへ到達できることを確認。
3.Windowsの設定メニューから「職場または学校にアクセスする」を利用し、ドメイン参加および初回サインインを実施。
本来、Active Directoryを拠点間VPN経由で運用する場合、名前解決（DNS）や通信経路の設定には注意が必要ですが、この拠点では特にエラーが出ることもなく、ドメイン参加からサインインまで完了しました。
「既存の拠点間VPN経由でも問題なくADが稼働している」
依頼人側ではそう判断され、そのまま1ヶ月間、拠点での運用が続けられました。
トラブル発生：本社での「接続拒否」
順調に見えた運用から1ヶ月後、依頼人から一本の電話が入りました。
「拠点から本社へ戻ってきた社員のPCが、使えなくなりました」
話を聞くと、そのPCは拠点では、拠点間VPN経由でも問題なくドメインアカウントでサインインできていたのに（※キャッシュログオン等でDCが見えていなくてもログオン【サインイン】できる場合があります）、
サーバー本体がある本社へ移動し、本社のWi-Fiに繋いだ途端、ドメインコントローラーの検出ができなくなったとのこと。
「遠くの拠点では使えて、目の前の本社で使えない。どういうことですか？」
この時点では、現地のPCがどのようなIPやDNSを掴んでいるかは不明です。
しかし、Active Directoryトラブルの鉄則としてまずは定石通り、DNSから確認することにしました。
私はPCの挙動とネットワークの状態を直接確認し、最速で解決するために、トラブルの起きている本社へ急行することになりました。
現地での状況確認：Pingは通るがドメインが見えない
現地に到着し、まずは問題のPCでコマンドプロンプトを開き、状況を整理することから始めました。
最初に確認するのは、サーバーへの物理的な通信経路です。
C:\Users\user01>ping 10.0.0.10
10.0.0.10 に ping を送信しています 32 バイトのデータ:
10.0.0.10 からの応答: バイト数 =32 時間 =4ms TTL=128
...
パケット数: 送信 = 4、受信 = 4、損失 = 0 (0% の損失)
Pingの応答はあり、ネットワーク的な疎通（L3レベル）には全く問題ありません。
次に、Active Directory環境において最も重要な「PCがドメインコントローラー（DC）を認識できているか」を確認するコマンドを実行しました。
C:\Users\user01>nltest /dsgetdc:domain.local
DC 名の取得に失敗しました: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN
結果は無情にも ERROR_NO_SUCH_DOMAIN（ドメインが存在しません）。
IPアドレスでの通信はできているにも関わらず、PCは「ドメインコントローラーがどこにいるか分からない」と訴えています。
この「繋がっているのに見えない」挙動から、原因はDNSである可能性が極めて高いと判断しました。
トラブル発生：本社での「接続拒否」
PCのネットワーク設定を確認すると、DNSサーバーのアドレスは運用通り『自動取得』でしたが、配布されてきたDNSがAD向けではありませんでした。
実際に ipconfig /all を見ると、DNSサーバーはDCではなく ルーター（10.0.255.254） になっていました。
これでは、Active Directoryの動作に必要なSRVレコードを引くことができず、社内ドメインの名前解決ができるはずがありません。
検証のため、手動でDNS設定をADサーバー（DC）のアドレスに書き換え、再度確認を行いました。
現地での状況確認：Pingは通るがドメインが見えない
C:\Users\user01>nltest /dsgetdc:domain.local
DC: \\AD-Server01.domain.local
アドレス: \\10.0.0.10
...
コマンドは正常に完了しました。
DNSを正しく設定した直後、ドメインコントローラーが正常に認識されました。
全ての辻褄が合った瞬間です。
原因の特定：DNS配布（DHCP）の不備
拠点間VPN経由の拠点で「なぜかドメイン参加が成立していた」理由については、この時点ではまだ特定できていませんでした。
一方、本社ネットワークにおいては、ルーター（DHCPサーバー）のDNS配布設定がAD用に変更されておらず、PCが適切なDNSサーバーを参照できていなかったことが、本社側の原因でした。
私は依頼人に対し、以下の通り報告し、対応を完了しました。
原因： 本社ルーター（DHCP）から配布されるDNS情報に、ADサーバーのアドレスが含まれておらず、PCがドメインを見つけられなかったこと。
恒久対策： ルーターのDHCP設定を修正し、配布するDNSサーバーの値を ADサーバーのIPに変更すること。
Active Directory環境において、クライアントPCをDHCP運用する場合、「誰が正しいDNSを配るのか」は認証基盤の根幹に関わる死活問題です。
ネットワーク構築とサーバー構築で担当が分かれる際に見落としがちなポイントとして、改めて認識させられる事例でした。
これにてトラブル自体は解決し、一件落着。
……と、言いたいところですが、一見すると辻褄が合わない点が一つ残りました。
▼ DNS修正後の確認
本社のトラブル自体は、DHCP設定を修正することで無事に解決しました。
しかし、一つだけ、引っかかる点が残っています。
「なぜ、同じくDNS設定が間違っていたはずの拠点で、ドメイン参加が成立していたのか？」
拠点PCの設定も、本社と同じく「DNS自動取得（ルーターIP）」のままでした。
ADサーバーのIPなど、どこにも設定していません。
Active Directoryの正常な動作には、DNSのSRVレコードの解決が不可欠であり、本来であればドメイン参加の段階でエラーになるはずです。
それなのに、なぜ、拠点間VPN経由の拠点ではADが見えていて、ドメイン参加まで成功していたのか。
調査の結果、PC内に残されていたログから、Windowsとネットワークの狭間で起きていた「偶然の成功」の正体が浮かび上がってきました。
結論と報告
Windowsのドメイン参加処理の詳細な記録が残る C:\Windows\debug\NetSetup.log を解析したところ、拠点でのドメイン参加時に非常に示唆的な挙動が記録されていました。
まず、参加プロセスの初期段階において、DNS形式（FQDN）でのドメインコントローラー探索は ERROR_NO_SUCH_DOMAIN (1355) で明確に失敗していました。
つまり、「参加時だけ一瞬、正しいDNSを引けていた」というような都合の良い状況ではなく、ADのDNSベースのDC探索（FQDN）は、その時点で失敗していたことがログ上で確認できました。
しかし興味深いのはその直後です。
ログ上では、Windowsが探索条件を切り替え、フラット名（NetBIOS名）での探索にフォールバックし、こちらが ERROR_SUCCESS (0) で成功していました。
結論として、拠点での初回参加は「DNSが正しかったから成功した」わけではなく、「WindowsがDNSでの探索に失敗した後、別経路（NetBIOS系）の探索にフォールバックしてDCを見つけた結果、参加が成立してしまった」ものであることが判明しました。
原因究明：なぜ拠点で「参加できてしまった」のか
では、その「別経路（NetBIOS探索）」はどのようにしてVPN対向の本社へ到達したのでしょうか。
一般的に、NetBIOS名の解決に使われるブロードキャストパケットは、ルーター（L3境界）を越えることはありません。
今回の環境において、以下の可能性を一つずつ検証しました。
WINSサーバーの存在: 拠点・本社ともにWINSサーバーの配布（DHCP Option 044）はなく、設定も空でした。
UDP中継（Helper/Relay）設定: ルーター（Yamaha RTX）の設定を確認しましたが、UDPポート137/138を中継するような設定や、DHCP Relayの設定は存在しませんでした。
L2延伸: 純粋なIPsecトンネル（L3）構成であり、L2TPv3などのL2延伸機能は利用していません。
当時のパケットキャプチャが存在しないため、探索パケットが具体的にどのような経路（指向性ブロードキャスト等）で対向へ到達したかを100%断定することはできません。
ただし、NetSetup.log では「DNS（FQDN）での探索が失敗（1355）→ フラット名（NetBIOS名）での探索が成功（0）」という流れが記録されており、DNSとは別系統の名前解決経路でDC探索が成立していたこと自体は確かな事実です。
以上を踏まえると、Windowsのフォールバック機能と、ネットワーク側の条件が重なった結果、通常の設計では想定しない経路で探索が成立していた可能性があります。
「参加できた＝OK」ではなく、DNSが崩れているとたまたま通るだけの不安定な状態になり得ます。
つまり、拠点での初回ドメイン参加が成立したのは、正規のDNS名前解決によるものではなく、「Windowsのフォールバック挙動」と「ネットワーク側の条件（名前解決経路）の隙間」が偶発的に噛み合った結果でした。
これは偶然成立していただけの非常に不安定な状態です。
DNS（SRVレコード）による正規の解決経路を確保しない限り、グループポリシーの適用、Kerberos認証、パスワード変更など、Active Directory本来の機能の多くは正常に動作しません。
「繋がっているからヨシ!」とするのではなく、その接続が「正しい名前解決経路（AD DNS / SRV解決）」に基づいているかを確認することの重要性を、重要性を再認識した事例でした。
1. 決定的な証拠：NetSetup.log が示した『DNS失敗』と『別経路での成功』
今回の直接原因は、本社側DHCPが配布するDNSがAD用に設定されていなかったことでした。
ただ厄介だったのは、その見かけ上の成功のせいで、DNS不備がしばらく表面化しなかった点です。
結果として、近いはずの本社で突然つまずき、いかにもVPNや無線が悪そうに見える怪奇現象になっていました。
動いているように見える状態ほど危ない、というのを改めて痛感した一件でした。
