エンタープライズ認証システムとしておなじみの Active Directory Domain Service（AD DS）ですが、初登場から20年以上を経ています。今ではMicrosoft Entra ID（Azure AD）の利用が推奨されていますが、オンプレミス環境では、引き続き新規環境の構築やOSサポート期限による更新など、いましばらくは活躍しつづけることでしょう。

AD DSについてのドキュメントはMicrosoftで各種取り揃えていますが、発売当初公開されていた詳細な仕様や制限事項についての情報は、古い情報として多くが削除され、確認が難しいです。そんな状況を鑑みたのか、Microsoftの日本サポートチームが、素晴らしいドキュメント公開しています。
ドメイン コントローラーの構築時に言われないと気付かないこと | Microsoft Japan Windows Technology Support Blog (jpwinsup.github.io)

本コラムは、以前公開させていただいたAD DS Do's and don'ts（べしべからず）- 1の続編となります。今回は「べし」の項目について、いくつかコメントを入れていきたいと思います。

1. バックアップを取りましょう

サーバー運用において、バックアップの取得は非常に重要です。ですので、サーバー運用者の腕の見せ所、と工夫されている方は大勢いらっしゃると思います。できるだけ少ない作業時間でバックアップ、できるだけ少ないメディア量での上手な運用…など、ぱっとみは検討に値すべきところですが、実際こういった工夫がかえってアダになる、ということは一考いただいたほうがよいと思います。

1.1. なぜバックアップが必要なのか

ドメインコントローラーが1台しかない環境での、バックアップの必要性については、申し上げるまでもないと思います。「2台以上の複数環境でも必要ですか？」とお問い合わせをいただくことがありますが、結論を申し上げれば、必要となります。
まず、システム全体がダウン・破損したケース（全損）を考慮する必要があります。すべてのサーバーが復旧不能になってしまった場合、過去の「定点」で取得したデータでリストアを行うしかありません。
次に、ドメインコントローラー同士で複製の整合性がとれなくなった、ケースです。ドメインコントローラー同士は可及的速やか、ないしは一定期間に同期を行い、互いに最新のデータを保持しています。ですが、ネットワーク環境の問題や設定ミスなどにより、同期が不可能になった状態で、それぞれ別の更新が発生することがあります。問題が解消すれば、同期が再開して「マージ」されるのですが、マージされた内容が意図したものでない場合、「どちらか1つのドメインコントローラーに合わせる」必要があります。この場合、不要なドメインコントローラーをリストアすることになります。
最後に、Active Directoryオブジェクトに対するオペレーションミス（オペミス）のケースです。人間が作業する以上、この問題を0％にすることはできません。正規のオペレーションによる変更情報は、正しい情報として、ドメインコントローラー間を同期してしまいます。Active Directoryゴミ箱といった救済策はありますが、復旧不可のオブジェクトを削除してしまった場合、Authoritative Restoreという特別な方法で、オブジェクトを復旧させることになります。
なお「スキーマオブジェクト」だけはAuthoritative Restoreを行えません。Active Directoryの定義情報であるスキーマは重大であるため、いったん加えた変更を巻き戻すことができないのです。スキーマに加えた変更を戻したい場合は、全損リストアと同じ方法で再復旧させる、しかないのです。

1.2. どうバックアップを取ればいいのか

バックアップの取得方法としては、筆者個人としては「ベアメタルバックアップ」をお奨めします。これは非常にシンプルな話で、定点上の全データを同時取得すればリストア時に問題ないから、です。Windowsディレクトリのデータは「Windowsの構成で中身が異なる」ケースがあり、コンポーネントのインストール状況に依存します。よくあるケースで「システムバックアップ」だけで運用する場合、この部分の考慮が足りず、正しくリストアできない場合があります。
サーバー管理者たるもの「1Byteでも節約節制すべし！」と意気込まれる方がいらっしゃるのは承知していますが、マイクロソフト（外資系IT企業）が考える、1番の節約事項は「人的リソース」になります。日本のコンピューター産業は幸か不幸か、「ハードウェアのオマケとしてのソフトウェア」「ハードウェアのオマケとしてのオペレーター」という時代があり、ハードウェアを過度に大切にする文化があります。実際一部のハードウェアリソース（バックアップ用TAPEメディアなど）は高価だったため、この考え方を後押ししていました。今ではそのようなことはない（TAPEメディア自体の利用頻度の変化）ため、運用者に負担がかからない方法を、検討すべきだと思います。
別の視点で「前後に別のイベントタスクがあり、バックアップは手早く終わらせたい」という要望もあるかと思います。Windows Server Backupでは「ボリュームシャドウコピー（VSS）」という機能があり、OSやアプリケーションを稼働のままに取得した「スナップショット」をバックアップできる機能があります。特別な追加設定は必要なく、ただ通常のバックアップ設定を行えば稼働します。
つまりOSを動作させたままバックアップが取れますので、順序性を担保させてバックアップをタスク化する必要は、基本的にはないのです。前後のイベントタスクがMSアプリケーションに関するものなら同じVSSの機能で担保できます（そうでないものもあります）。例外としてサードパーティのアプリケーションでVSSに対応していないものは、そうはなりません。このような構成は、（前回紹介させていただいた）「べからず」の見地から、ベターとは言えないと思います。

1.3. 仮想マシンのバックアップ

仮想マシンのバックアップ、とくにドメインコントローラーについては、実は非常に注意が必要です。
まず、技術的な見地だけでお話しすれば、Windows Server 2012以降のHyper-Vであれば、Hyper-Vのスナップショット機能で可能です。OSバージョンの制限があるのは、このバージョン以降には「VM generationID」識別子および「InvocationID」属性機能による、スナップショットのバージョン認識があるためです。このInvocationID属性により、スナップショットで書き戻したHDDイメージは、既存環境に対して「過去のデータバージョン」とふるまい、結果USNの不整合を起こしません。
ドメインコントローラーの情報は内部的にUSNという番号で管理されており、ドメインコントローラー間で秩序立てた関係性に基づき、異なる番号が収納されています。単にHDDイメージを過去のものに差し替えて投入すると、この秩序立てた関係性が棄損する「USNロールバック」が発生し、該当のドメインコントローラーは永久にドメインに接続できなくなります。詳細については、Active Directory Domain Services (AD DS) の安全な仮想化 | Microsoft Learnをご覧いただければと思います。

Hyper-V によるドメイン コントローラーの仮想化 | Microsoft Learnには「仮想DCのスナップショットを取得または使用しないでください。このプラクティスは、Windows Server 2012以降で技術的にサポートされていますが、適切なバックアップ戦略の代わりにはなりません。」という記述がはっきりとあります。筆者もこれに同意しますが、この理由について、個人の意見として簡単に記述しておきます。
まず、最初の問題として、「あまりにも安易にリストアできてしまう」ことによる、セキュリティリスクの問題があります。仮想マシンは容易に管理できる、そのこと自体はプロフィットになりますが、ドメインコントローラーは重要なセキュリティデータベースを保持しているため、簡単にリストアを試みられる、これ自体がリスクです。好奇心やいたずら心での操作はもちろん、別のオペミスをこっそりキャンセルするため、運用者が止むを得ず行う可能性もないわけではありません。Windows Server Backupのリストアはある程度、面倒な手順になっていますが、これも相応の理由があるということでしょう。
次に、スナップショットはバックアップ管理の要件を満たしていない、という技術的な制限事項があります。スナップショットは、構造としては「前イメージデータ全体を読み取り専用化し、動的な差分イメージを付け加えるだけ」というシンプルな構成です。書き戻したデータの整合性確認はもちろん、適切な世代管理も行えません。ファイルの整合性や世代管理を前提としたデータ構造に、そもそもなっていないわけです。上述のMS資料でも「複数のスナップショットは世代間バックアップデータとしては使えません」という旨の記述があります。
最後に、意図しないActive Directoryデータベースの破壊、が起こる可能性です。確かにWindows Server 2012以降のHyper-Vであれば、ひとまず技術的には問題が起きませんが、Windowsに習熟していないエンジニアが、非Windows仮想環境で同じ運用ができると勘違いした場合、USNロールバックの悲劇が発生します。HyperVisorソフトウェア自身がVM generationIDに対応していないと、本機能は有効になりません。仮想VM上のゲストWindowsだけで実現しているわけではないのです。

これらのリスクを勘案すると、最も確実なのは、「安全なバックアップとしてWindows Server Backupをプライマリで利用する」ことに尽きる、となります。利用の仕方は物理サーバーと同じ考え方で問題ないはずです。

2. ポートは必ず開放しましょう

Active Directoryで、過去にお問い合わせいただいた要件で、「IPアドレスを1つにまとめたい」のほかに「ポート番号を1つにまとめたい」というものがありました。Active Directoryという大きいサービスが1つあり、このサービスが使うポートを1つとしてもらえれば、お客様への説明やネットワークエンジニアの作業が極小化できる、ぜひそうしてほしい、というご要望です。
結論として、当然これは不可能なのですが、ではどのポートを使うのですか？という話で、既定のサービス以外にWindowsのエフェメラルポート（49152-65535）全部です、とお知らせすると、今でも絶句されることはあります。
ドメイン環境で使用されるポートについて | Microsoft Japan Windows Technology Support Blog (jpwinsup.github.io)
Active Directoryの主要サービス（LDAP/DNS/Kerberos/GC）は、専用のポートで通信をしていますが、それ以外の機能（Active Directory複製やDFSRなど）はMS-RPCを使用しており、このポートについて考慮する必要があります。
MS-RPCで通信するプロセスに「NetLogon」というものがあります。これはWindowsのコンピューター認証を行うためのもので、コンピューター認証を経てクライアントはドメインリソースやGPOを認識することができます。ドメインコントローラーとクライアント間でも、当然この動作は存在するため、必要なポートとなります。
Windowsのエフェメラルポートは、OSバージョンによって違います。旧32bit OS（Windows 2000/Windows Server 2003）では1024-65535（古くは1024-5000）です。万一このようなクライアントがある場合は、これに従ってポート範囲を再考することになります。

3. 優先DNSサーバーの設定を自分自身（127.0.0.1）に設定していると、起動に時間が掛かる場合があります

Active DirectoryがDNSを参照する場合、1台しかドメインコントローラーが存在しない場合は、参照するのは自分自身、になってしまいます。今でも、1台目のドメインコントローラーを構成する場合、構成後に「優先DNSサーバー」は127.0.0.1に、「フォワーダー」設定に構築前の（外部）DNSサーバーが自動設定される動作かと、思います。
本件は、この状態で2台目以降を構築した場合、（多くは上記の設定のままなので）1台目の挙動が変わってしまう、という問題です。Windows 2000にはこのような挙動はなく（その時代はループバックアドレスを使わず自分のIPアドレスを指定していましたが）、Windows Server 2003からの挙動の変更かと思います。Windows 2000相当の動作に戻すことは技術的に不可能ですし、起動したドメインコントローラーが現環境に接続するのが適切かどうか、をチェックする意味もありますので、この動作変更は妥当かと思います。
余談ですが、ループバックアドレスが途中から採用された背景として、きちんと問い合わせたわけではないのですが、個人的には「DNSサーバーは（ここでは自分自身を）逆引き解決できなければならない」というインターネット仕様に合わせようとしたのではないか、と思っています（違っていたらすみません）。
その意味では、Active Directoryでは「DNS逆引きゾーン」について、もっと積極的に推奨するべきだったのではないか、と個人的には感じています。

4. ルートDCのNTP設定に気を付けましょう

Active DirectoryではKerberos認証が使用されています。Kerberos認証ではMan-in-the-Middle（なりすまし）を防御する目的で現在時刻を使用するため、システム全体で時刻が同一である必要があります。

4.1. ドメインコントローラーの時刻同期とは

コンピューター間の時刻を同期させる方法として、Active Directoryでは一貫してNTP（Network Time Protocol）を使用しています。NTPの仕様上、ルート時刻サーバーを頂点に、子時刻サーバーが親時刻サーバーから時刻を同期する、という階層構成を採っています。ちなみにActive Directoryでの階層関係はどうなのか、ご興味がある方は第2回　Active Directoryおよびワークグループ環境での時刻同期：Windowsネットワーク時刻同期の基礎とノウハウ（改訂版） - ＠IT (itmedia.co.jp)などをご覧ください。
ルート時刻サーバーは、世界標準時刻を公開しているNISTや日本標準時刻のそれであるNICTなどが管理しています。Active DirectoryではFSMO役割のドメインコントローラーがルート時刻サーバーに相当しますが、実際はFSMOサーバーがルート時刻サーバーから時刻同期を行わない限り、「現在時刻」を反映させることができません。
通常のPC組み込みシステム（CMOS）の現在時刻は、数秒～30秒以上の誤差があるため、NTP同期を行わない場合、誤差がそのままシステムすべてに反映されてしまいます。これはセキュリティ（監査やログ記録など）において、悪影響があるため、避けるべきです。
ルート時刻サーバーとどんな頻度で、どのように同期すればいいのか、については、RFC1305に従っていただければ問題ありません。平たく申し上げれば最初は32秒程度で、段階的に64秒、128秒…と間隔が伸びていきます。最終回　NTP時刻同期サービスのトラブルシューティング：Windowsネットワーク時刻同期の基礎とノウハウ（改訂版） - ＠IT (itmedia.co.jp)などをご覧いただくと、細かいところが分かると思います。

4.2. 仮想マシンの時刻同期

前項に引き続いての話となりますが、Active Directoryの設計は物理マシンが前提なので、時刻同期もFSMOを頂点とした階層構造での同期が望ましい（期待した通りの結果になる）といえます。とくにWindows Server 2016については、OSとしてのクロック精度が高くなり、仮想マシンであっても時刻のずれ等は起こりにくくなっているのです。
ではホストからの時刻同期は使わないほうがいい？かというと、そういうことはありません。Windows Server 2016 の時間精度の向上 | Microsoft Learnに答えがあるようです。仮想マシンの弱点である「エミュレートされたCMOS」の時刻の精度（ホスト時刻に対してのずれ）が向上し、そもそも時刻がずれなくなりました。加えて、ホストとゲストのStratum（階層）や同期データを適切に比較できるようになったため、（計算上）精度が高いほうからの同期ができるようになっています。これはWindows Server 2016 Hyper-Vの機能ですので、古いホストOSや非Windowsホスト環境では当てはまらないことは、気を付けてください。クラウド（Azure VM）については、元記事にある通りの仕様となります。

4.3. 仮想マシンのバックアップ

USNロールバックにより、ドメインコントローラーのバックアップ・リストアに問題が生じる話をさせていただきましたが、それ以外の要素（個人的なこだわり？）について、前述させていただきました。

4.4. 仮想マシンの仮想ハードディスク（VHD）

最近の仮想マシンはEdgeサーバー（高負荷の処理を専従で行うための高レイテンシサーバー）の役割を求められるものもあり、パフォーマンスを無視することはできません。その意味で固定容量ディスクは有効ですが、これをした支えするストレージの性能についても、考慮の必要があると思います。本コラムでご紹介した「Azure Stack HCI」サーバーで、Edgeサーバーにフィットしたモデルもありますので、検討いただくといいかもしれません。
元記事にある「ホストのWindowsオペレーティングシステムがインストールされているディスクに仮想化したドメインコントローラーのVHDファイルを格納しないこと」ですが、端的にいうとWindowsのCドライブはディスクアクセスが非常に多いので、同じくディスクアクセスが多いドメインコントローラー（の仮想ディスク）との同居は向かない、という意味になります。Active Directoryデータベースは、ランダムの読み取りI/Oベースで動作し、ディスクキャッシュも使用しないため、ディスク自体に高負荷が発生します。物理メモリに読み込まれればキャッシュにより高速に動作しますが、最初のユーザー検索ではディスクから情報を得るため、高負荷を緩和させる方法は、基本的にありません。パフォーマンスを下げないためには「VHDディスクへのアクセスは最速にしておく」という原理原則論が必要、というわけです。

4.5. ホストOSのディスク（タイプ）

前項までは「仮想マシン側の設定」の話でしたが、この項目は「ホストOS側の設定」になります。
平たく申し上げますと、ホストOSのディスクはFUA（Force Unit Access）をサポートしていることが望ましい、ということになります。FUAとはディスクのキャッシュ制御に関するSCSIコマンドのことです。送られてきたデータをキャッシュに格納せずにディスクに出力するものだそうです。Active Directoryデータベースはキャッシュ無効の状態でデータを格納する必要がある（そうしないとデータが破損する）のですが、SCSIコマンドにより動的にキャッシュ無効となるのです。FUAがホスト側で有効になっていると、VHD→物理ディスクへの格納の際にも、動的キャッシュ無効が透過的に働きます。ヨコヤマ企画: 仮想マシンとしてのドメインコントローラーとディスクキャッシュ (g20k.jp)をご覧いただくと、非常にわかりやすいでしょう。

4.6. 長期に渡って一時停止状態にしない

ドメインコントローラーの情報は、「全台同一・最新」の内容に揃っていることが、基本です。ドメインコントローラーのユーザー情報が異なれば、クライアントのログオン先によって、認証できない（ユーザーが存在しないのだから！）ユーザーができてしまい、セキュリティ文脈上非合理な仕様になってしまいます。時々うかがうケースで「ドメインコントローラーのオンラインバックアップ」目的で、○○日前状態のドメインコントローラーを隔離配置したい、などのご要望をいただくことがあります。この場合お客様の判断で、一定間隔でドメインコントローラーを起動し複製した後、シャットダウンしてコールドスタンバイの状態にされているのですが、仮想マシンだと「一時停止」で簡単にこのような状態が作れてしまいます。
ドメインコントローラーは「マルチマスター」レプリケーションの機能で複数サーバーの異なるActive Directory情報を統合する機能があります。本来は異なるユーザーやコンピューターが（ログオンした）ドメインコントローラー上で作成され、統合時に一本化されます。ひとつのアカウント内で、属性が変更された場合も同様です。同じ属性が異なる値になった場合も、ルールに基づき一本化されます。しかし、半年や1年間同期が行われなかった場合、それぞれ乖離した内容が上書きされ、同期されたタイミングで互いが予期しない内容に上書きされてしまいます。
一例としてセキュリティ上、削除されたアカウントが復活してしまったり、逆に必要なアカウントが知らずに削除されたりしてしまうケースは致命的です。こういったことを防ぐため、Active DirectoryではTombstoneLifetimeという属性で、一定期間複製されなかった場合は複製動作を無効化する機能が備わっています。デフォルトでは180日間です。こういう問題をそもそも招来しないよう、ドメインコントローラーは常に同期しておかなければならない、というわけです。

5. Azure DNSの設定について

元記事は、少しわかりづらいですね。正確に申し上げると「Azure VM ネットワークインターフェース（NIC）のDNS設定」の話です。
オンプレミスでは、ドメインコントローラーのIPv4設定ではIPアドレス、参照先DNSサーバーなど、スタティック（固定値）である必要があります。DNSサーバーとして使用されるため、IPアドレスでの直接参照が発生するからです。ところで、Azure VNetでは、固定IPアドレスは基本的に使えません。VNetのDHCPサービスが、ネットワーク設定を管理するしくみになっています。DHCPだとIPアドレスが変わってしまったり、（DHCPオプションで配布される）参照先DNSサーバーがAzure VNet内参照に固定されてしまい、ドメインコントローラーの名前解決が適切に行えません。無理にOS側から固定IPアドレスを設定すると、通信が不安定になってしまうことがあります。 Azure VM NICは、VM毎に個別に用意されるため、このNICに固定IPアドレスや参照先DNSサーバーを「カスタム」設定することで、OS側では設定が固定化されます。見た目はDHCPからの配布ですが、配布された値が変わらないことが保証されます。
Azure VMのドメインコントローラーでは、「優先DNSサーバー」に複製パートナーを、「代替DNSサーバー」に自分自身を登録するのが、もっとも安定した名前解決を実現します。Azure VPNやExpressRouteでオンプレミス間と複製関係がある場合も、この作法を順守されることをお奨めします。

6. Azure上で日本語の言語パックを利用する場合は、構築後にWindows Updateを適用してください

こちらは、Azure VM固有の問題かと思います。説明にもある通り、グループポリシーのADMLテンプレートファイル（言語別）が、デグレーション（過去バージョンへの置き換え）してしまうことに起因する問題です。オンプレミスの場合、最初から言語が選べるので問題が顕在化しませんが、Azure VMは英語版がデフォルトなので、こういった問題が発生することがあります。なお、Azure VMの日本語化について、変わり種として、全自動で実施する方法を当社コラムAzure コラム 第8回：Windows VM 全自動日本語化に公開しておりますので、ご興味がある方はご覧ください。
余談ですが、古くからWindowsを使っておられるお客様の中には、オンプレミスであっても「英語版」をあえて使っているケースがあります。言語が違っても機能は全く同じ（IME等を除けば）なため、OEM版で英語版だった場合、ローカル化による作業時間の手間を省くためです。そしてそれ以上に重要なのが、「ミドルウェアの言語サポート」要因です。サーバーミドルウェアを別建てでインストールする場合、米国製品では英語版でないと正常動作しないものがあります。いわゆる「2バイト文字のパスを認識しない」ような仕様であっても、提供元が英語版を前提としている場合、日本語版を使うリスクは使用者が負う必要があります。ありがたいことに、こういった「仕様」はソフトウェアに断り書きがないため、最初から英語版を使うというわけです。「転ばぬ先の杖」ということですね。