💻 ドメインコントローラー構築時の落とし穴！誰も教えてくれない注意点 #activedirectory

この記事の内容

• Active Directory ドメインコントローラー構築時に見落とされがちな「非推奨構成」を網羅的に解説します
• 「サポートされる/されない」「推奨/非推奨」の意味の違いから丁寧に整理します
• NAT・ロードバランサー・マルチホーム・役割の同居など、現場でよく見かける構成の落とし穴を紹介します
• バックアップ・ポート開放・DNS 設定・時刻同期など、運用面の重要ポイントも取り上げます
• Azure 上でドメインコントローラーを展開する際の注意事項についても説明します

はじめに

今回の内容は、日本 Microsoft の Windows サポートチームが公開しているブログをもとに、実際の現場経験を交えながらお届けします。ドメインコントローラーの構築・運用に携わる方であれば、必ず一度は確認しておきたい内容が揃っていますので、ぜひ最後までご覧ください。

「サポート」「推奨」の意味を正しく理解する

本題に入る前に、「サポートされる/されない」「推奨/非推奨」という言葉の意味を正確に押さえておく必要があります。

サポートとは「動作保証」ではない

「サポートされる」という言葉を「動く」という意味だと誤解されている方が多くいます。しかし、これは別の話です。

サポートされる構成とは、以下を意味します。

• Microsoft がその構成でのテストを実施している
• 動作することが期待されている
• 万が一動かない場合、原因を調査して修正してもらえる

つまり「絶対に動く」ではなく、「動かなかった場合に直してもらえる」というのが正確な意味です。

非推奨とは「動かない」ではない

同様に「非推奨」も「動かない」という意味ではありません。

• 非推奨構成：動作する可能性はあるが、テストが十分に行われていない
• サポートは受けられるが、最終的に「推奨構成に変更してください」と言われる可能性がある
• 責任と理解のうえで使い続けることは選択肢としてあり得るが、事前に避けておくのが無難

この前提を踏まえたうえで、以下の話を読み進めてください。

ドメインコントローラーの非推奨構成

NAT 経由の Active Directory

NAT（ネットワークアドレストランスレーション）経由の構成は非推奨です。Microsoft の公式声明には以下のように明記されています。

• NAT 経由の Active Directory は Microsoft によってテストされていない
• NAT 経由の構成はお勧めしない
• NAT 経由の Active Directory に関連するサポートは制限される

企業合併後に NAT でネットワークをつないだ環境にまとめて Active Directory を展開したいというケースは現場でも珍しくありません。実際のところ普通に動作することも多いですが、非推奨であることを理解したうえで使用するかどうかを判断してください。

なお、Microsoft がテスト済みとしている唯一の NAT 構成は、クライアントを NAT のプライベート側に配置し、すべてのサーバーを NAT のパブリック側に配置する 1 対 1 の NAT 構成です。

ロードバランサーの使用

ロードバランサーを使って負荷分散を行う構成も非推奨です。

Active Directory にはクライアント側に負荷分散の仕組みが既に組み込まれています。ドメインコントローラーの一覧は DNS に登録されており、クライアントはその一覧からランダムに接続先を選択します。1 台が停止しても自動的に別のドメインコントローラーへ切り替わります。

外部のロードバランサーを挟むと、ドメインコントローラーの構成が変わった際にロードバランサーの設定も合わせて変更する必要が生じるなど、不要な複雑さが加わります。クライアントが既に自律的に負荷分散してくれているため、ロードバランサーは不要です。

マルチホーム構成

複数の NIC を持つ、または 1 つの NIC に複数の IP アドレスを構成している状態（マルチホーム構成）も非推奨です。

例として、サービス用ネットワークと監視用ネットワークの両方に足を出している構成を考えてみましょう。

この場合、以下のような問題が生じます。

• DC が自分の IP アドレスを DNS に登録する際、監視用 NW の IP アドレスも登録してしまうと、クライアントがその IP アドレスへ通信しようとして到達できない
• 逆に、監視サーバーはサービス用 NW の IP アドレスへ通信しようとして到達できない
• 非対称ルーティング（行きと帰りで経路が異なる状態）が発生し、通信が成立しない

対処として、DNS に登録する IP アドレスをレジストリ設定で制御するなどが必要になります。どうしてもこの構成が必要な場合は、仕組みを十分に理解したうえで適切な設定を行ってください。

役割の同居は「混ぜるな危険」

AD CS（証明書サービス）との同居

AD CS をドメインコントローラーと同じサーバーで動かすのは非推奨です。

主な理由は障害復旧時にあります。ドメインコントローラーに問題が生じた場合、一般的な対処法として「AD DS をアンインストールして再昇格する」というパターンがあります。この際、AD CS も一緒にアンインストールが必要になり、証明書サービスが巻き添えを食らいます。

また、バックアップからリストアした場合、AD CS のデータもバックアップ時点に戻ってしまいます。これにより、リストア後に「失効させたはずの証明書が復活する」「発行済み証明書が消える」といった問題が起こる可能性があります。

DHCP との同居

DHCP サーバーとの同居も非推奨です。こちらも障害発生時に複雑な問題が起きる可能性があるため、分離することが推奨されています。

Exchange Server・SQL Server との同居

Exchange Server や SQL Server との同居も非推奨です。

ドメインコントローラーはローカルグループやユーザーデータベースの扱いが通常のメンバーサーバーと異なります。Exchange Server をメンバーサーバーで動かす場合とドメインコントローラーで動かす場合とでは、グループに関する機能の動作が異なるケースがあります。

フェールオーバークラスターのノードとして追加

ドメインコントローラーをフェールオーバークラスターのノードとして追加することも非推奨です。フェールオーバークラスター自体が Active Directory を必要とするため、「ドメインコントローラーが起動していないとクラスターが動かない、クラスターが動いていないとドメインコントローラーが起動できない」という鶏と卵の関係になりかねません。

この構成はあまりにも問題が多いため、特定のバージョン以降ではソフトウェアレベルでブロックされるようになっています。

まとめ：とにかく混ぜるな危険

検証環境で正常系の動作確認のみを行う場合はともかく、本番環境では複数の役割を同一サーバーに詰め込むことは絶対に避けてください。現在は仮想環境の普及により役割を分離するコストが大幅に下がっています。役割は必ず分離する、という原則を守りましょう。

構成・運用上の注意事項

バックアップの取得

ドメインコントローラーの復旧は、通常バックアップを使わない手順（アンインストール→再昇格）から試みます。そのため「バックアップは不要では？」と思われることもありますが、スキーマ周りの障害など、バックアップからのリストアが唯一の解決策となるケースもあります。

バックアップにはWindows 標準のバックアップ機能を使用することを推奨します。

サードパーティ製バックアップソフトウェアは、リストア時に内部的に Microsoft 非サポートの方法を使っているケースがあります。ライセンス費用を払い、テストまで済ませたにもかかわらず、いざリストアしてみると「Microsoft サポート外の戻し方です」と言われるという事態が実際に起きています。標準機能でのバックアップがもっとも安全です。

ポートの開放

Active Directory が正常に動作するためには、広範囲のポートを開放する必要があります。特に注意が必要なのが RPC のダイナミックポートです。

RPC は通信開始時にまず 135 番ポートで「何番ポートを使えばいいか」を問い合わせ、返答されたポートで実際の通信を行います。このダイナミックポートの範囲が広大なため、セキュリティポリシーで必要最低限のポートのみを開ける運用をしている環境では驚かれることがありますが、これが Microsoft の推奨構成です。

レジストリ設定でダイナミックポートの範囲を狭めることは可能ですが、ポートが不足すると通信できなくなるリスクがあるため、基本的には変更せずにそのまま使用することが推奨されています。

優先 DNS サーバーの参照先

ドメインコントローラーの DNS 参照先として自分自身を指定することは避けてください。

ドメインコントローラーは起動時に他のドメインコントローラーから更新情報を受け取ってから動き出します。この際、DNS を参照して他のドメインコントローラーの場所を確認しようとします。ここで DNS 参照先が自分自身だと、まだ起動していない自分に問い合わせが行くため、デッドロック状態になる可能性があります。

優先 DNS サーバーには他のドメインコントローラー（PDC エミュレーターなど）を指定しておくことを推奨します。この設定はメンテナンス時の順序にも影響するため、複数台のドメインコントローラーをメンテナンスする際は停止・再起動の順番にも注意が必要です。

NTP（時刻同期）の設定

ドメイン内では以下のような時刻同期の階層構造があります。

PDC エミュレーターの役割を持つドメインコントローラーは、外部の NTP サーバーと時刻同期するよう構成することが必須です。

時刻がずれると認証周りを含む多くの機能に深刻な影響が出ます。検証環境でも長期間運用する場合や、スナップショットの適用・一時停止を繰り返す場合は特に注意が必要です。

仮想環境でのドメインコントローラー運用

時刻同期の注意

仮想環境では物理環境よりも時刻がずれやすい傾向があります。ホスト OS とゲスト OS の時刻同期機能と、ドメインの NTP 階層を同時に使用すると、どちらかがわずかにずれた際に影響が出やすくなります。ホスト OS との仮想マシン時刻同期機能は使用しないことが推奨されています。

スナップショットの取り扱い

仮想環境では手軽にスナップショットが取れますが、ドメインコントローラーへの使用は推奨されていません。

特に「USN ロールバック」は深刻な問題を引き起こすことで有名でした。Windows Server 2012 以降ではこの問題を防ぐためのブロック機能が実装されていますが、スナップショットからの復元自体がドメインコントローラーにとって好ましくない操作であることに変わりありません。

本番環境では、スナップショットではなくWindows 標準バックアップによるバックアップを取得してください。スナップショットがあるからバックアップ不要という考え方は誤りです。

差分仮想ハードディスクの使用禁止

差分 VHD / VHDX（Hyper-V の差分ディスク）の使用は非推奨です。パフォーマンスが大幅に低下するため、使用しないようにしてください。

ディスク書き込みキャッシュの注意

ホスト OS や仮想化基盤でディスクへの書き込みキャッシュが有効になっている場合、突然の電源断でデータベースの整合性が失われる可能性があります。

ドメインコントローラーはデータベースへの書き込みを即時書き込み（キャッシュを経由しない書き込み）で行うよう設計されています。仮想環境で Forced Unit Access（FUA）がサポートされていれば問題ありませんが、サポートされていない場合や IDE/ATA ドライブを使用している場合は、キャッシュを手動で無効化する必要があります。

長期間の停止禁止

ドメインコントローラーを長期間シャットダウンしたまま、または仮想環境で一時停止したまま放置することは避けてください。

Active Directory にはトゥームストーン期間（既定 60 日）があり、これを超えると複製ができなくなります。仮想環境では一時停止が容易なため特に注意が必要です。

Azure 上でのドメインコントローラー構築

DNS 設定の方法

Azure 上の VM に Active Directory を展開する場合、DNS の設定方法は通常のオンプレミスとは異なります。

• OS の NIC プロパティでの DNS 設定は行わず、「自動取得」のままにする
• DNS サーバーの指定は、Azure の NIC リソースまたは仮想ネットワークのカスタム DNS 設定で行う

この Azure の流儀に従った設定を行ってください。

言語パック適用後の Windows Update

Azure の VM イメージは英語版が基本です。日本語化のために言語パックを適用した場合、以下の問題が発生することがあります。

• ADMX ファイル（管理テンプレート）は最新版
• ADML ファイル（言語リソース）の日本語版は古いバージョンがインストールされる
• バージョンの不一致によりグループポリシー管理でエラーが発生する場合がある

言語パックを適用した後は、必ず Windows Update を実行してください。 これにより ADML ファイルも最新版に更新され、バージョンの不一致が解消されます。Windows Update を適用しない運用をしている場合でも、言語パック適用後の Windows Update は実施するようにしてください。

まとめ

本記事では、ドメインコントローラー構築・運用における主な注意点を解説しました。要点を以下に整理します。

• 「非推奨」は「動かない」ではなく「テスト不十分でサポートが制限される」という意味
• NAT・ロードバランサー・マルチホーム構成は非推奨
• AD CS・DHCP・Exchange Server・SQL Server との同居は非推奨。役割は必ず分離する（混ぜるな危険）
• バックアップは Windows 標準機能で取得し、スナップショット頼りにしない
• RPC のダイナミックポート（49152 ～ 65535）を含む広範囲のポート開放が必要
• ドメインコントローラーの DNS 参照先に自分自身を指定しない
• PDC エミュレーターは外部 NTP サーバーと時刻同期するよう構成する
• 仮想環境では時刻ずれ・スナップショット・長期停止に特に注意する
• Azure 上では DNS 設定を OS ではなく Azure リソース側で行い、言語パック適用後は Windows Update を忘れずに実施する

これらの項目をご自身の環境と照らし合わせて確認いただくことで、ドメインコントローラーの安定した運用につながります。