Ndictです。「Proxmoxで学ぶWindowsServerAD」の第2回では、クライアント視点でドメインコントローラー(DC)のフェイルオーバーを検証します。
第1回で用意した、Proxmox上のWindowsServer2016(DC1/DC2)とWindows11Proクライアントを使い、DCの停止→自動切替→両DC停止→復帰までの挙動を確認します。
クライアント側を見て「何が動き、何が止まるのか」を整理します。
0. 事前準備
まずKerberosのキャッシュを初期化します。検証中の差分を明瞭にするためです。
|
1 |
klist purge |
「チケットが削除されました」と表示されれば初期化完了です。以降の確認は、その都度DCに問い合わせて得た「新しい」情報だけで評価します。
実務でもフェイルオーバーの事前・事後でklist purgeを入れておくと、挙動の切替点が見やすくなります。
※ここでは、事前確認をクリーンに揃える意図で先に実行します。
1. 事前確認
1-1. ネットワークと DNS 設定
まず、クライアントの現状を事実として記録します。
|
1 |
ipconfig /all |
- ホスト名:user01
- プライマリDNSサフィックス:test.local
- DNSサーバー:192.168.1.A1(DC1)/192.168.1.B1(DC2)
この組み合わせであれば、クライアントはtest.localの名前解決とDC検出を実施できます。続けてAD用SRVを一度だけ引き、DNS登録の健全性を目視確認します。
|
1 |
nslookup -type=SRV _ldap._tcp.dc._msdcs.test.local |
出力にDC1.test.local:389(192.168.11.A1)とDC2.test.local:389(192.168.11.B1)が並べば想定どおりです。Server:Unknownの表示はPTR未登録を示すだけで、本件の目的には影響しません。
注: A1/B1は「ホスト部」のプレースホルダです。実環境の数値で読み替えてください（例:A1=30,B1=40など）。
1-2. ドメイン参加の状態
マシンの所属はWMIで確認します。
|
1 |
Get-CimInstance Win32_ComputerSystem | Select Name,Domain,PartOfDomain |
Domain=test.local/PartOfDomain=Trueを確認します。ユーザー側はFQDNを確認します。
|
1 |
whoami /fqdn |
CN=user01,OU=Users,DC=test,DC=localが返れば、マシン・ユーザーともにADへ正しく属しています。
1-3. 現在のログオンサーバー
「いま誰に認証してもらっているか」は環境変数で即確認できます(PowerShell)。
|
1 |
$env:LOGONSERVER |
この時点では\DC1です。以降の検証で、この値がどう切り替わるかを観察します。
1-4. セキュアチャネル(信頼チャネル)
マシンとDC間の信頼チャネルの健全性を判定します。
|
1 |
Test-ComputerSecureChannel |
結果がTrueであることを確認します。次のシナリオ(DC停止→切替)へ進む準備が整いました。
DC1停止→DC2へフェイルオーバー(クライアント描写)
DC1を計画停止(シャットダウン、またはNIC無効化)し、クライアント側の観測だけで切替の全容を追います。停止直前に観測の純度を上げるため、再度klist purgeを実行します。
|
1 |
klist purge |
DC1を落とした際、クライアントが自動的にDC2へ切り替わるかを、クライアント操作のみで確認します。
2-1. DC再探索の確認(dsgetdc)
DC1停止直後に次を実行します。
|
1 |
nltest /dsgetdc:test.local /force |
出力にDC:\\DC2.test.local、Address:192.168.1.B1が表示されます。これはDCLocatorが利用先DCとしてDC2を選定したことを示します。
2-2. セキュアチャネルの再バインド(sc_query)
数十秒の間隔で次を繰り返し実行します。
|
1 |
nltest /sc_query:test.local |
初回はStatus=1722(RPC_S_SERVER_UNAVAILABLE)と出る場合があります。その後、Status=0(NERR_Success)かつTrusted DC Name=\\DC2.test.localへ遷移します。これでセキュアチャネルの張替え完了を確認します。
2-3. ポリシーと共有の実動確認(GPO/SYSVOL)
ポリシー適用とSYSVOL参照を確認します。
|
1 2 |
gpupdate /force dir \\test.local\sysvol |
gpupdate /forceは正常完了し、\\test.local\sysvolは参照可能であることを確認します。DC2側でGPO/DFS/Netlogonが継続していることを示します。
2-4. 認証の発行元切替(Kerberos)
取得済みチケットの発行元を確認します。
|
1 |
klist |
KDC=DC2.test.localとなっていること、cifs/DC2やldap/DC2のサービスチケットが並ぶことを確認します。旧LDAP/DC1などが一時的に残っても有効期限で自然に消えます。$env:LOGONSERVERはサインアウト/サインイン後に\\DC2へ更新されます。
切替を急がせたい場合は、次の順で実行します。
|
1 2 3 4 |
ipconfig /flushdns klist purge nltest /cachepurge nltest /sc_reset:test.local |
DC1停止・DC2停止時のクライアント挙動
ドメインコントローラーを全停止した際、クライアント（Win11）が挙動を確認します。
L3疎通は生存
|
1 |
ping 8.8.8.8 |
名前解決は全滅
|
1 |
nslookup www.microsoft.com |
クライアントのDNSがDC1/DC2のみのため、両方停止時は外部名解決も行えません。
DCの探索・信頼は失敗に遷移
|
1 |
nltest /dsgetdc:test.local /force |
ERROR_NO_SUCH_DOMAINになります(図B-2上部)。|
1 |
nltest /sc_query:test.local |
STATUS_NO_LOGON_SERVERSへ落ちます(キャッシュの見え方)。
GPO/SYSVOLは利用不可
|
1 |
gpupdate /force |
|
1 |
dir \\test.local\sysvol |
既存ログオンは継続
すでにログオン中のドメインユーザーは、作業を継続できます(資格情報キャッシュ)。ただし新規ドメイン認証、パスワード変更、GPO更新、ドメイン共有への新規アクセスはできません。
Kerberosは更新不能
既存TGT/サービスチケットは有効期限内は残りますが、更新できないため、時間とともに機能低下します。
全DC停止時、クライアントはログオン自体は維持できる一方、ドメイン依存の新規処理（認証・GPO・SYSVOL・名前解決）は軒並み停止します。
今回のログはその典型を示しており、復帰後はDNS/Netlogon/Kerberosのキャッシュを明示的に掃除してから状態確認すると復旧の成否が明確になります。
まとめ
本稿ではクライアント視点で、DC1停止から自動切替、さらに両DC停止までの挙動を連続して確認しました。
DC1停止時は、nltest /dsgetdc:test.local /forceが即座にDC2を返し、数十秒の遅延を挟んでnltest /sc_query:test.localがNERR_SuccessかつTrusted DC Name=\\DC2.test.localへ遷移することでセキュアチャネルの張替えを確認できました。
あわせてgpupdate /forceと\\test.local\sysvolの到達性、klistでKDC=DC2.test.localを確認し、GPOとKerberosが運用面でも継続していることを示しました。$env:LOGONSERVERは再サインイン後に\\DC2へ同期します。
両DCを停止するとL3疎通は生存する一方、名前解決、DCLocator、信頼チャネル、GPO、SYSVOLはいずれも失敗に転じます。既存ログオンは資格情報キャッシュにより継続できますが、ドメイン依存の新規処理は停止します。KerberosのTGT/サービスチケットは有効期限内は残りますが更新できないため、時間経過とともに機能低下します。
