本記事はマイクロソフト社員によって公開されております。
こんにちは。Windows Commercial Support Directory Services チームです。
ドメイン コントローラーは多くの組織で利用されておりますので、今までドメイン コントローラーの設計や運用に関わったことがなかったものの、急に担当することになってしまったという方も多いのではないでしょうか。
今回は、そのような方向けに、これからドメイン コントローラーを新規で構築する際に、言われないと中々気付きにくいことについて、紹介させていただきます。
後から予期しないトラブルに直面することを避けるためにも、構築時から問題の起きにくい構成を目指していきましょう！
非推奨の話
※ 以下の構成は推奨しておりませんが、この構成においてサポートをお断りすることはございません。
ただし、最終的に構成変更以外の対処が難しい場合もございますので、後々のトラブルを避けるためにも、特別な理由がない限り、非推奨の構成は予め避けておくのが良いかと存じます。
NAT は非推奨！
言われないと中々気付かないものの代表として、Active Directory は製品として NAT 環境下で利用されることを想定して設計および検証されていないという点が挙げられます。
そのため、NAT が存在する環境で問題が発生した際に、原因が NAT デバイスであった場合には、NAT を使用しない構成への変更以外の対処方法がご案内できない場合がございます。
上記の理由から、弊社では NAT 環境で Active Directory ドメインを構成することを、できる限り採用されないことをお勧めさせていただいております。
NAT 経由の Active Directory のサポート境界の説明
ロード バランサーも非推奨！
実はロード バランサーも非推奨です。
Active Directory では製品として、クライアント側で負荷分散されることを想定して設計および検証されているため、LDAP や LDAPS、DNS などの通信にロード バランサーを用いることは正式にサポートされておりません。
Load balancers and Active Directory
マルチホーム構成も非推奨！
マルチホーム (複数の NIC もしくは 1 つの NIC に複数の IP アドレス) 構成について、構成そのものについてサポートはしておりますが、弊社としては現在も (特別な要件がない限り) マルチホーム構成は非推奨となります。
気付かずにマルチホーム構成のまま運用していて、複製に失敗するというお問い合わせをいただくことがよくあります。
AD CS との同居も非推奨！
ドメイン コントローラーと AD CS (証明書サービス) が同一サーバー上に稼働しているご状況は以下の理由から推奨しておりません。
AD DS の障害でドメイン コントローラーの再昇格が必要な場合において、AD CS のアンインストールが必要となります。
ドメイン コントローラーに問題が発生した場合の復旧方法として、降格し再昇格することが必要になる場合がありますが、
AD CS が同居していている場合、AD CS をアンインストールしなければドメイン コントローラーとして降格ができない動作になっております。
ドメイン コントローラーの復旧のために AD CS の役割を他のサーバーに移行する必要があるなど、ドメイン コントローラーの問題解決に制約がありますので、ドメイン コントローラーに AD CS の役割を同居させることはおすすめしておりません。AD DS を Windows Server バックアップから復元した際に AD CS の情報もバックアップ時点の情報でリストアされます。
Windows Server バックアップから復元した場合、 AD CS の情報もバックアップ時点の状態に戻るため、バックアップ時点からリストア時点までの期間に発行していた証明書が、失効できなくなるためご留意いただく必要がございます。何かしら障害が発生した場合などで AD DS/ AD CS どちらの障害か判断ができない場合に、切り分けが難しいケースが想定されます。
切り分けがや調査が難航し、通常より障害復旧にお時間を要する可能性もございます。
DHCP との同居も非推奨！
AD の機能に問題が発生し OS の再インストールが必要になった際、AD の復旧を行うために DHCP の機能まで不必要に巻き込まれてしまう可能性があるため、DHCP との同居もおすすめしておりません。
ドメイン コントローラーにインストールされている動的ホスト設定プロトコル (DHCP) サーバーのサービスの無効化と削除
Exchange Server や SQL Server との同居も非推奨！
このような構成をとっているケースは稀ではあると存じますが、Exchange Server や SQL Server 等の他の機能との同居も非推奨です。
基本的には、各機能ごとにサーバーを用意して稼働されることをおすすめいたします。
ドメイン コントローラーへの Exchange のインストールは推奨されない
SQL Server 2016 および 2017: ハードウェアとソフトウェアの要件
フェールオーバー クラスター環境でドメイン コントローラーをノードとして追加することはできません！
Windows Server 2012 以降では、クラスター ノードとしてドメイン コントローラーを追加することは、非推奨ではなくサポート対象外となりました。
実際にドメイン コントローラーをクラスター ノードに追加することもできなくなっております。
フェールオーバー クラスター環境でドメイン コントローラーをノードとして追加することはできません
構成の話
バックアップを取りましょう！
バックアップを取得していない構成を見かけることがありますが、バックアップは必ず採取しましょう。
何か問題が発生した際、残念なことにバックアップからの復旧以外の方法ではどうしても復旧ができない場合があります。
なお、ドメイン コントローラーでは、Windows Server バックアップおよび Azure Backup 等が弊社では正式にサポートされているバックアップ方式です。
特に Windows Server バックアップはサーバー OS にバンドルされていますので、比較的簡単に利用できます。
ポートは必ず開放しましょう！
何か問題が発生した際、調査を進めると実はポートが開放されていないだけだった、ということがよくあります。
ドメイン コントローラーおよびクライアントで開放しなければならないポートは以下の公開情報にまとめられておりますので、事前にご確認ください。
特に、RPC のポートは一時ポートを開けるため忘れがちですが、RPC の通信の流れは以下のようになっているため、一時ポートを空けないと正常に通信ができない場合があります。
① RPC クライアントが RPC エンドポイント マッパーに対象アプリケーションのリッスン ポートをリクエスト (tcp/135)
② RPC エンドポイント マッパーが対象アプリケーションのリッスン ポートをレスポンス (RPC 動的ポート)
③ RPC クライアントが RPC 動的ポートに接続してサブルーチン等を呼び出す
優先 DNS サーバーの設定を自分自身 (127.0.0.1) に設定していると、起動に時間が掛かる場合があります！
ドメイン コントローラーは OS の起動時、起動までの間に変更された最新のデータベース情報を取得するために初期同期と呼ばれる処理を実施し、これが完了するまでは Active Directory としての機能を提供いたしません。
この時ドメイン コントローラーは複製パートナーを探索するために、ドメインの SRV レコードを DNS サーバーに問い合わせます。
一方、DNS サーバーは Active Directory 統合ゾーンを利用している場合は Active Directory から DNS のゾーン情報を読み込む処理を行い、
読み込み処理が完了しサービスが起動することで、初めて DNS サーバーとしての機能が利用できるようになります。
そのため、Active Directory と DNS がお互いを利用する状態が発生し、サービスのタイムアウトまで待つ間にデッドロックが発生する場合があります。
Active Directory と DNS サーバーのデッドロック
ルート DC の NTP 設定に気を付けましょう！
Active Directory の NTP の構成として、 FSMO 以外のドメイン コントローラーは FSMO の役割を持つドメイン コントローラーを時刻同期先として参照し、FSMO の役割を持つドメイン コントローラーは外部の信頼できる NTP サーバーを参照することを推奨しています。
FSMO の役割を持つドメイン コントローラーでタイムソースを指定しない場合、ドメイン内の時刻は、FSMO の役割を持つドメイン コントローラーのローカル クロックに依存してしまうため、時刻ズレが発生してしまう可能性があるためです。
仮想環境の話
VM上に構築する際の注意点
ドメイン コントローラーを仮想化する上で以下の留意事項がございます。
時刻同期について
物理環境と同様に、FSMO (PDC) で外部の NTP サーバーを利用して時刻同期を行い、他のドメイン コントローラー、ドメイン メンバーは PDC と時刻同期を行うように構成することが一般的です。
仮想環境ではホスト OS と時刻同期を行う機能がございますが、ドメイン コントローラーが NTP サーバーとホストの双方から時間を同期させた場合、ドメイン コントローラーの時間が頻繁に変化する可能性があります。
そのため、ドメイン コントローラーとして構成された仮想マシンでは、ホストとの時間の同期を無効にし、既定の Windows タイム サービス (W32time) ドメイン階層時間の同期を使用してください。
また、仮想環境の特性上、システム時刻が遅れやすくなっているため、時刻同期の間隔を短くするなどの対応を行うことも効果的です。
なお、ドメイン コントローラーが Azure IaaS 上の VM であれば、5 秒に一度といった頻度で Azure 基盤上のホスト OS との時刻を一致させているため、”Hyper-V Time Synchronization Service” サービスで時刻同期を行っても問題ございません。(オンプレミス環境に FSMO のドメイン コントローラーが存在し、VPN もしくは ExpressRoute でドメイン コントローラー間を繋いでいるケースは除く)バックアップについて
Windows Server 2008 R2 における Hyper-V では、スナップショットからの復元を行った場合、USN ロールバックと呼ばれるデータベースの不整合が発生することがございました。
Windows Server 2012 以降では、スナップショットからのドメイン コントローラーの復元に対応するようになり、Windows Server 2012 における Hyper-V と Windows Server 2012 の Active Directory の組み合わせでは VM-generation ID とよばれる識別番号を利用し、不整合が発生しないよう実装が変更されております。
ただし、上記の機能はあくまで補助的な位置付けとなっており、常用的にドメイン コントローラーのバックアップ、復元にスナップショットをご利用いただくことは推奨いたしておりません。
そのため、 Windows Server バックアップまたは他の VSS ライター ベース バックアップ ソリューションを使用することをお勧めします。仮想ハードディスク (VHD) について
VHD で差分ディスクを用いることで、パフォーマンスの低下が発生することが報告されております。
そのため、ドメイン コントローラーにおいては、仮想ハードディスクに差分ディスクを使用することは推奨されません。
容量可変の VHD を使用いただくよりも、容量固定の VHD を使用いただく方がパフォーマンスの向上が見込めます。
また、パフォーマンスを最適にするために、他のサービスやアプリケーションが頻繁に使用するディスクやホストの Windows オペレーティング システムがインストールされているディスクに仮想化したドメイン コントローラーの VHD ファイルを格納しないことが推奨されます。ホスト OS のディスクについて
停電などの障害が発生した場合でも Active Directory データベースの整合性を維持できるように、Active Directory ディレクトリ サービスでは、バッファに格納することなく書き込みを行っております。
仮想ドメイン コントローラーをホストする仮想化ソフトウェアで、FUA が正しく動作し、ホスト OS で FUA をサポートするディスク (SCSI や ファイバ チャネルなど) を使用している場合は、バッファが無く書き込みを行うことができるため問題はございません。
仮想ドメイン コントローラーをホストする仮想化ソフトウェアで、FUA をサポートしていない場合や、ホスト OS で IDE ドライブや ATA ドライブを使用する場合は、書き込みキャッシュを無効にすることが推奨されます。長期に渡って一時停止状態にしない
Hyper-V には仮想マシンを一時停止させる機能が実装されておりますが、本機能によって長期に渡って複製ができない状態を継続させないようご注意ください。
長期に渡り複製ができていない状態が続きますと、廃棄期間 (Tombstone Lifetime) を超過してしまい複製が再開できなくなったり、残留オブジェクトが生成されドメイン コントローラー間で不整合が発生する可能性が高まります。
Running Domain Controllers in Hyper-V
Azure DNS の設定について
Azure では、仮想ネットワーク、または、ネットワーク インターフェース (NIC)にて、仮想マシンが参照する DNS サーバーを設定する必要があります。
一方、ドメイン コントローラーでは、通常、OS 上で DNS サーバーを静的に設定します。
ただし、動的に DNS サーバーを設定していた場合でも、DC への昇格時に警告は表示されますが、通信自体は正常に行えます。
そのため、Azure 上にドメイン コントローラーを構築する際は、仮想マシン内の OS の NIC のプロパティは動的にして、Azure 上の NIC または 仮想ネットワークでカスタム DNS を設定する方法をご案内しています。
なお、Azure 上の NIC の DNS サーバーの設定は、NIC が関連付けられている仮想ネットワークから継承されます。
(仮想ネットワークと NIC のどちらにも DNS サーバーを指定した場合、NIC の設定が適用されます。)
手順は以下の通りです。
- Azure ポータル ( https://portal.azure.com/) にログインし、左ペイン (または画面上部 [すべてのサービス]) より、[仮想ネットワーク] を選択します。
- ドメイン コントローラーが作成されている仮想ネットワークを選択します。
- 「設定」ブレードより [DNS サーバー] を選択します。
- “カスタム” を選択し、表示されるテキスト ボックスに DNS サーバーの IP アドレスを入力します。
複数の DNS サーバーを指定することが可能です。 - 画面上部 [保存] をクリックします。
※ 上記手順 5 の実行により、仮想マシン (ドメイン コントローラー) の再起動が発生する場合がございますので、
比較的影響の少ないタイミングで作業をご実施くださいますようお願いいたします。
Azure 上で日本語の言語パックを利用する場合は、構築後に Windows Update を適用してください！
Azure が展開する OS イメージは予め更新プログラムがほぼ最新の状態で適用されている状態でデプロイされます。
この状態において、管理用テンプレートの構成ファイルである ADMX および言語ファイルである英語フォルダー (en-us) の ADML も最新のものが適用されています。
英語 OS の環境を日本語化する際に、言語パックのインストールを実施と共に、日本語フォルダー (ja-jp) の ADML ファイルも同時に適用されますが、この ADML が最新の言語ファイルでないために、グループ ポリシー管理エディターを起動した際に以下のメッセージが表示される場合があります。
“リソース XXXXXXX が見つかりませんでした。
ファイル XXXXXX、行 XX、列 XXX”
OS の言語切り替え後に Windows Update を実施することで、ADML ファイルが更新され、エラーが解消されますので、上記のエラーが表示された場合は、まずは Windows Update を適用してください。
ローカル グループ ポリシー エディター (gpedit.msc) の実行時の .admx エラー
更新履歴
2023/10/23 : 本ブログの公開