Windows Server 2016 の DHCP フェールオーバーを運用していると、「メッセージ認証（Message Authentication）」で使う共有シークレット（Shared Secret）を昔設定したはずなのに、いざ変更や復旧が必要になったタイミングで思い出せない…ということがあります。本記事では、フェールオーバー関係を壊さずに共有シークレットを再設定する実務的な手順と、作業前後の確認ポイントをまとめます。
今回の「共有シークレットを忘れた」問題とは
Windows Server 2016 の DHCP フェールオーバー（DHCP Failover）は、2台の DHCP サーバーがリース情報やスコープ構成を同期し、片系障害時にも IP アドレス配布を継続できる仕組みです。フェールオーバー関係の作成時に「メッセージ認証（Message Authentication）」を有効にすると、相互通信の正当性を検証するために 共有シークレット（Shared Secret／共有パスワード） を設定します。
この共有シークレットは運用上とても重要ですが、セキュリティの観点から 後から画面上で平文表示できない（または思い出せない） ことが多く、担当者交代やサーバー更改、障害復旧のタイミングで「忘れたので再設定したい」というニーズが発生します。
DHCP フェールオーバーの基本（押さえておくと切り分けが速い）
DHCP フェールオーバーは「フェールオーバー関係（Relationship）」単位で構成され、関係の中に複数スコープを紐づけて同期します。関係を複数持つ構成（拠点ごと・用途ごとに分ける等）もあるため、共有シークレットも 関係ごと に存在します。
| モード | 特徴 | 向いているケース | 運用上の注意 |
|---|---|---|---|
| 負荷分散（Load Balance） | 通常時から2台が分担して応答する | 配布トラフィックが多い／冗長化と性能を両立したい | 片系だけが応答していると偏りが起きやすいので監視が重要 |
| ホットスタンバイ（Hot Standby） | 通常時は主系が応答し、待機系はバックアップとして動く | 運用をシンプルにしたい／主系を固定したい | 待機系へ切り替わる条件（状態）と復帰手順を明確にする |
共有シークレットとメッセージ認証の役割
共有シークレットは、DHCP フェールオーバーの パートナー間通信（リースの複製・状態同期など）を認証するための秘密情報です。クライアントPCが DHCP 要求を出す際に使うものではなく、あくまで DHCP サーバー同士 が「相手が正しいパートナーである」ことを確認するために利用されます。
また、パートナー間通信が成立するためには、サーバー間で必要な通信が通っていることが前提です。特にフェールオーバー関連では TCP 647（DHCP Failover の通信で使われることが多い）など、環境のファイアウォールやセキュリティ製品の影響を受けやすいポイントがあります。共有シークレットの再設定で直らない場合は、ネットワーク経路や遮断も疑ってください。
| 項目 | 概要 | よくある誤解 |
|---|---|---|
| 共有シークレット（Shared Secret） | フェールオーバー相手と共有する秘密情報。メッセージ認証で利用。 | 「クライアント配布に影響するパスワード」ではない |
| メッセージ認証（Message Authentication） | DHCP サーバー間の通信を認証し、なりすましや改ざんを検出する仕組み。 | 「有効にすると必ず性能が落ちる」わけではない（ただし環境次第） |
| DHCP フェールオーバー | 2台構成でリース情報を複製し、片系障害時にも配布を継続。 | DHCPv6 のフェールオーバー機能ではない（Windows の標準フェールオーバーは DHCPv4 が中心） |
共有シークレットを忘れたときに起こりがちな症状
- フェールオーバー関係の状態が「通信中断（Communication Interrupted）」になり、復帰しない
- イベントログに認証関連のエラーが出る
- フェールオーバー関係の編集や再作成をしようとして、共有シークレットが分からず詰む
- サーバー更改で片側を入れ替える際、旧設定が分からず移行作業が止まる
ただし、共有シークレットを忘れたこと自体が直ちにクライアント配布停止を意味するわけではありません。多くの環境では「状態確認」や「構成変更」が必要になったタイミングで問題化します。だからこそ、壊す前に安全にリセットする手順 を押さえておくのが重要です。
結論：DHCP MMC で「メッセージ認証を一度オフ→再度オン」にして再設定する
Windows Server 2016 では、DHCP 管理コンソール（DHCP MMC）からフェールオーバー関係を編集し、「メッセージ認証」を一度無効化してから再度有効化 することで、共有シークレットを新しい値に再設定できます。フェールオーバー関係を削除して作り直すより影響範囲を抑えやすく、実務上もっとも現実的な方法です。
作業前のチェックリスト（失敗しないための下準備）
| チェック項目 | 確認内容（例） | 理由 |
|---|---|---|
| パートナー2台が同時にオンライン | DHCP01 / DHCP02 両方でサービス稼働、疎通OK | 片側のみで変更すると、状態不整合や認証エラーが長引く |
| フェールオーバー関係名の把握 | 関係名（Relationship Name）、対象スコープ | 別関係を誤って編集しないため |
| 運用モードの把握 | 負荷分散（Load Balance）/ ホットスタンバイ（Hot Standby） | 一時的な停止や偏りの影響を見積もるため |
| 業務影響の少ない時間帯 | 夜間・休日など | 変更中に一時的な認証エラーや同期遅延が起きても切り戻ししやすい |
| 事前バックアップ | DHCP の構成/データベースをエクスポート（可能なら） | 万一関係を作り直す事態になっても復旧を早められる |
| 監視・確認手段 | イベントログ、状態表示、疎通、クライアント更新テスト | 「変更できたか」を客観的に判断するため |
作業前バックアップの例（参考）
作業そのものは小さくても、DHCP は影響が大きい役割です。可能であれば、作業前に構成をエクスポートしておくと安心です（コマンドや保存先の運用は環境ポリシーに合わせてください）。
# 例：DHCP サーバーの構成をエクスポート（Windows Server 2016 以降で利用できる環境が多い）
# 実行前に Get-Help Export-DhcpServer で引数を確認してください
Export-DhcpServer -ComputerName "DHCP01" -File "C:\\Backup\\dhcp01.xml" -Leases具体的な手順（DHCP 管理コンソール）
- DHCP サーバーに管理者権限でサインインし、DHCP 管理ツール（dhcpmgmt.msc） を開きます。
- 左ペインで対象サーバーを展開し、［IPv4］を右クリック → ［プロパティ］ を開きます。
- ［フェールオーバー］タブ を開き、対象のフェールオーバー関係（Relationship）を選択します。
- ［編集（Edit）］ をクリックして編集画面を開きます。
- ［メッセージ認証を有効にする（Enable Message Authentication）］ のチェックを 外して 適用します。
- 続けて、同じ項目のチェックを 再度入れます。
- 表示される 共有シークレット（Shared Secret） を 新しい値 に設定して保存します。
ポイントは「オフ→オン」の操作です。これにより GUI 上で共有シークレット欄が再入力可能になり、忘れてしまった旧値を知らなくても新しい値で更新できます。
運用上の注意（ここを外すとトラブルになりやすい）
- 共有シークレットはペアで一致 している必要があります。通常は編集操作がパートナーにも反映されますが、反映状況は必ず確認してください。
- パートナー側に反映されない場合は、相手サーバー側でも同じフェールオーバー関係を開き、同じ新しい共有シークレット を設定し直すと整合が取れることがあります（両方オンラインで実施してください）。
- 作業中に一時的な認証エラーや同期遅延が起きる可能性があります。可能であれば 業務影響の少ない時間帯 に実施します。
- 変更直後は「正常」に戻るまでタイムラグが出る場合があります。焦って関係削除に進まず、まずはログと状態を確認します。
- 複数のフェールオーバー関係がある場合は、対象関係を取り違えないように 関係名と紐づくスコープ を必ず確認します。
変更後に必ず確認したいポイント
共有シークレットを再設定したら、「設定が保存された」だけで満足せず、フェールオーバーが実運用として健康状態に戻ったこと を確認します。DHCP はネットワークの基盤なので、念入りにチェックしておくほど安全です。
| 確認場所 | チェック項目 | 正常の目安 | NGの場合の着眼点 |
|---|---|---|---|
| DHCP MMC（フェールオーバー関係） | 関係の状態（State） | 「Normal」など正常状態 | 通信中断のままなら疎通・FW・認証設定を再確認 |
| DHCP MMC（スコープ） | 両系に同じスコープが存在し、有効になっている | スコープの欠落や無効化がない | 手動変更の履歴がある場合は差分が出やすい |
| イベント ビューアー | DHCP-Server/Operational のエラー有無 | 認証失敗や複製失敗が収束 | 変更直後の一過性か、継続発生かを切り分け |
| スコープの複製状況 | リース/予約/ポリシーが両系で一致 | 大きな差分がない | 関係の再同期（レプリケーション）が必要なことも |
| クライアント動作テスト | ipconfig /renew 等で更新 | 更新が成功し、配布が継続 | 片系しか応答していない場合はモードや状態を確認 |
フェールオーバーの状態表示で見るべき代表例
表示されるステータス名は環境や表示言語で差がありますが、概念としては次のような状態に分類されます。運用メモとして残しておくと、障害時に慌てずに済みます。
| 状態のイメージ | 意味 | 最初にやること |
|---|---|---|
| Normal（正常） | パートナー通信・複製が成立している | 定期的な監視と変更管理 |
| Communication Interrupted（通信中断） | 一定期間パートナーと通信できていない | 疎通、FW、DNS、時刻同期、サービス稼働を確認 |
| Partner Down（相手停止） | パートナーが停止している／到達不可と判断 | 相手の稼働状況、障害有無、復旧見込みを確認 |
イベントログの場所（迷子になりがちなポイント）
DHCP のフェールオーバー関連の状況は、イベント ビューアーで以下を確認すると追いやすくなります。
- イベント ビューアー → アプリケーションとサービス ログ
- Microsoft → Windows → DHCP-Server → Operational
「認証」「複製（replication）」「パートナー」などの文言が含まれるイベントは特に重要です。エラーが継続して出ている場合は、次章のトラブルシューティングを参照してください。
うまくいかないときのトラブルシューティング
共有シークレットの更新は比較的シンプルですが、ネットワークや権限、DNS など周辺要因で躓くことがあります。よくある症状と切り分け観点を表にまとめます。
| 症状 | 想定原因 | 対処の方向性 |
|---|---|---|
| 状態が「Communication Interrupted」から戻らない | 相互疎通不可（FW/ACL/ルーティング）、名前解決不良、時刻ずれ | 疎通（特にパートナー間通信）、DNS、NTP（時刻同期）を確認。まずは OS 間で名前解決と通信ができる状態にする |
| 編集したはずなのに相手側で反映されない | パートナーがオフライン、権限不足、コンソール接続先の取り違え | 両方オンラインで実施。どのサーバーの MMC を開いているかを再確認し、管理者権限で操作 |
| 変更直後に一時的にエラーが増える | 再認証・再同期の過程で一過性に出る | 数分〜しばらく様子を見て収束するか確認。継続する場合は疎通・認証設定を再点検 |
| スコープの差分が埋まらない | 複製が止まっている、片系で手動変更が多い | フェールオーバー関係の健康状態を戻してから、必要に応じて複製（レプリケーション）を実施 |
| クライアントからは IP が取れているが不安が残る | 片系偏り、スタンバイ側が待機のまま、監視が弱い | モード（Load Balance/Hot Standby）と状態を確認し、監視項目（リース数・エラー）を整備 |
それでも直らない場合の最終手段
ネットワーク要因や構成破損でフェールオーバー関係自体が回復できない場合、最後の手段として フェールオーバー関係の削除 → 再作成 が必要になることがあります。ただし、この作業は影響範囲が大きく、スコープやリースの同期方法によっては「意図しない配布」につながるリスクがあるため、次の点に注意してください。
- 削除前に、どちらがアクティブか（主系か）を明確にする
- スコープ設定や予約、ポリシー、オプションが両系で一致しているかを確認してから実施する
- 作業手順は検証環境で事前にリハーサルできると理想
多くの場合、今回の「メッセージ認証をオフ→オン」手順でリセットできるため、いきなり削除・再作成に進まないことをおすすめします。
共有シークレットを“二度と忘れない”ための運用設計
共有シークレットを忘れたことが問題になる背景には、「設定した担当者しか知らない」「ドキュメント化されていない」「引き継ぎがない」といった運用課題が潜んでいます。再発防止のため、次のような運用ルールを整備すると安定します。
| 観点 | おすすめ | 理由 |
|---|---|---|
| 長さ・複雑さ | 十分に長いランダム文字列（例：20〜32文字以上） | 推測されにくく、総当たり耐性が高い |
| 保管場所 | パスワードマネージャー／権限管理された手順書 | 担当者依存を排除し、監査性を高める |
| 共有範囲 | 最小限（運用担当＋管理者） | 漏えいリスクを下げる |
| 変更（ローテーション） | 更改や体制変更のタイミングで見直し | 長期固定によるリスクと属人化を抑える |
| 変更時の手順 | 本記事の「オフ→オン」手順を標準化 | 緊急時にも迷わず実施できる |
よくある質問
共有シークレットをリセットすると、クライアントの IP 配布は止まりますか？
環境にもよりますが、共有シークレットの更新作業自体は「DHCP サーバー同士の認証情報」を更新する操作です。作業中や直後にフェールオーバー通信が不安定になると、状態によっては片系での配布に寄ったり、一時的に遅延が出たりする可能性があります。影響を最小化するためにも、両方のサーバーがオンラインであることと、業務影響が少ない時間帯での作業を推奨します。
片側のサーバーだけで変更しても大丈夫ですか？
おすすめしません。フェールオーバーはペアとして成立する仕組みのため、片側だけの変更は不整合を招きやすくなります。原則として 両方オンライン の状態で、DHCP MMC のフェールオーバー関係編集から実施し、変更後に状態が正常に戻ったことを確認してください。
PowerShell で確認できますか？
DHCP サーバーには管理用の PowerShell モジュールが用意されているため、状態確認に利用できます。例えば、フェールオーバー関係の一覧や状態を確認したい場合は、次のように「取得系」のコマンドから始めると安全です。
Get-DhcpServerv4Failover
# リモートのサーバーを明示する場合（例）
Get-DhcpServerv4Failover -ComputerName "DHCP01"変更系のコマンドは環境差分や影響範囲が大きいことがあるため、まずは GUI 手順で確実にリセットし、PowerShell は 確認・監視 の用途から取り入れると事故が起きにくくなります。
まとめ
Windows Server 2016 の DHCP フェールオーバーで共有シークレット（Shared Secret）を忘れてしまった場合でも、フェールオーバー関係を壊さずに再設定できる可能性があります。DHCP MMC のフェールオーバー関係編集で「メッセージ認証」を一度オフにしてから再度オンにすることで、新しい共有シークレットを入力し直せます。作業前後のチェック（両系オンライン、状態確認、イベントログ確認）を徹底し、運用ドキュメントやパスワード管理とセットで“次に困らない状態”まで整備しておくことが、安定運用への近道です。
コメント