エンタープライズ認証システムとしておなじみの 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)

本コラムのタイトル「Do's and don'ts」は、直訳すると「べし、べからず」という意味になります。それにふさわしい内容かと思いますので、主だったものについて、いくつかコメントを入れていきたいと思います。

1. NATは非推奨

非推奨、とコメントされていますが、技術的には「そもそも不可能」というレベルかと思います。
NATというのは、ネットワークの内側から外側への送出の際に、発信元IPアドレス（内部）を自動変換して外部のIPアドレスとしてしまうことで、「IPアドレスの節約」を目的に作られたと理解しています。副次的にセキュリティの効果（内部IPアドレスの隠蔽）があるという触れ込みで、ある時期多用され、ファイアウォールの代用として設計されたシステムが散見されます。
このルールにあてはめたい、と、ときどきご相談を受けますが、以下の理由で技術的には不可能です。

1.1. MS-RPCの問題

MS-RPC（Microsoft Remote Procedure Call）というプロセス間通信のためのプロトコルが存在します。詳細は上記資料を確認いただきたいのですが、少ないリソースで動作できるため、「昔は」脆弱なハードウェアで動作させる前提だったWindowsでは、必須の機能です。Active Directoryの認証機関（LSA）やLDAPサービス、Active Directory複製サービスをホストしています。MS-RPCの仕様上、利用ポートが動的のため、NATによる「ポートフォワード」を行うことができず、したがって利用できません。こういった見地で、MS-RPC用のNATテーブルは用意実装されていません。

1.2. Kerberosの問題

KerberosはActive Directoryの認証のかなめです。実はKerberos認証では、Man-in-the-Middle（なりすまし）という大きな技術的課題が設計当初から存在し、Active Directoryでは事前認証という技術で、これを緩和しています（技術解説は割愛します）。より高度なMan-in-the-Middle対策を行いたい場合、「クライアントのIPアドレス」を事前認証プロセス内で提示する機能をもっています。NATがはさまれた場合、正しい値が伝わらないため、当然認証に失敗します。少なくともMicrosoft KerberosではNATは想定されていない理解です。

1.3. SMBの問題

WindowsのSMBはNAPTに対応していません（記憶では過去のMSKBにあったと思います）。一応の説明ですが、NAPTとは複数の内部IPアドレスとポートから、外部IPアドレスを同時利用するしくみです。SMBはグループポリシーの適用に利用されますが、クライアントが複数台同時稼働するのは前提条件となります。したがってグループポリシー適用時に大きな問題となるでしょう。SMB用のNATテーブルも当然定義されていない理解です。

2. ロードバランサーは非推奨

こちらも、技術的には不可能と認識しています。
ロードバランサーを使用する場合、よくあるケースでは、サービス（ユーザー利用）面に証明書キーを配置し通信を「暗号化したい」、あるいは「Active DirectoryサービスのIPアドレス」を単一にみせることで、ネットワーク機器のファイアウォール設定の見通しをよくしたい、などでご要望をいただくことがあります。こちらも以下の理由で不可能とご理解ください。

2.1. 暗号化したい

まず前提として、たとえばKerberos認証シーケンスの鍵データ類はすでに暗号化されているなど、セキュリティについては、すべてにおいて必要十分には配慮された理解です。通常システムは心配しすぎる必要はありません。Active Directory全体の仕様上、個別要素毎に暗号化する方法は用意されていません。たとえばLDAPは認証時に「無認証でアクセス」する中途プロセスが必要で、LDAPS（LDAP over HTTPS）を通信全部に強制する、といったことはできません。昔のWindowsをご存じの方からは「SMBのセキュリティが低い」と指摘をいただくことがあるのですが（当社が製造した実装ではないのですが…）、その場合SMBv3から可能になった「SMB通信の暗号化」を使用して、SMB通信を単体で暗号化することは可能です。
きわめて高セキュリティな要件を求められるお客様で、「通信全部を暗号化したい」といったケースでは、「Windowsドメイン分離」という技術を使用することは可能です。ひらたく申し上げると、IPsecによりTCP/UDP自体を暗号化するもので、暗号化キーに証明書ではなく「Active Directoryコンピューター認証」を利用できる強みがあります。詳細はDomain Isolation Policy Design | Microsoft Learnをご覧いただければと思いますが、利用を除外しないといけないサービス（DNSなど）の存在や、ドメイン参加を容易に行えない運用など、考慮事項が多数ある点はご理解ください。

2.2 入口／出口をひとつに見せたい

Active Directoryは分散型のシステムであり、「サービス単位での名前解決を行う」ことと「同期により全サーバーの情報をそろえておく」が前提として組み込まれています。これを担保する技術が「Service Location（SRV）locator resource records」であり、Information on RFC 2782 » RFC Editor (rfc-editor.org)で定義されています。必要なサービス（LDAPやKerberosなど）にアクセスすると「複数のIPアドレス」が提示され、優先度の高いIPアドレスにアクセスする、というモデルです。これはクライアントだけでなく、ドメインコントローラー同士も同じ動作になります。
上記のシーケンスは仕様で変えられないため、SRVレコードを他の名前解決に置き換えることはできません。HostsにSRVレコードを記述することはできませんし、SRVレコード側を無理にひとつのIPアドレスにまとめた場合、ドメインコントローラー間の同期が不可能となり、正常動作しないでしょう。
クライアントとの認証やドメインコントローラー間の複製を、ある程度特定したもの同士に「絞りたい」という場合、Active Directoryサイトを構成することで、実現は可能です。Active Directoryサイトとは、仮想的な「ネットワーク物理境界」であり、同じサイトに属しているドメインコントローラーとクライアントが優先的に通信したり、サイト同士で複製ルートを構成してActive Directory同期のネットワーク流路を指定したりできます。詳細はActive Directory サイトとサービスの概要 ‐ Active Directory のサイト コンテナ階層 | Microsoft Learnからご確認いただくとよいでしょう。

3. マルチホームも非推奨

マルチホームというのは、1台のサーバーに複数NICを割り当てることで、ゾーンニングを行う考え方です。たとえばユーザー認証用と、運用管理用のネットワークを分けることで、ネットワーク帯域の監視やログ記録（IPアドレス）の見通しをよくしよう、という考え方に基づくものと考えられます。これとは別に、ドメインコントローラー経由でインターネットにアクセスする（ドメインコントローラーをNATルーター化する）という話もないわけではありません。小規模環境では、ネットワーク機器も含めたすべての機能を1台のドメインコントローラーに集約したい、という考え方も（是非は別にして）存在しています。
結論を申し上げますと、こちらも推奨できません。これはDNSの負荷分散の考え方に由来しているからです。
Active Directoryの負荷分散は「DNSラウンドロビン」機能に依存しています。DNSラウンドロビンとは、特定のFQDNへのクエリに対して、複数のIPアドレスを順番に提示していく技術です。古典的ですが、Active Directoryの初登場は2000年であり、このしくみは根本的には現在まで変わっていません。
マルチホームが実装された場合、SRVレコードの名前解決の際、ユーザーネットワークから要求に対して運用管理のIPアドレスを1/2（NICが2つならば）の確率で提示してしまいます。通信できないネットワークのIPアドレスが提示された場合、Active Directoryでは「不正なIPアドレスが返された」として、以後の認証プロセスをストップしてしまいます。適切なIPアドレスを再要求するしくみは、ありません。したがってこのようなネットワーク構成を採ることは、Active Directory環境では許容できないのです。

3.1. 特定のNICのネットワークだけを有効化したい

どうしてもこのようにしたい場合、ユーザー認証用のネットワークアドレスだけが、（Active Directoryの）SRVレコードへのクエリで返ってくるようにします。要はユーザー認証用のIPアドレスだけがDNSゾーンに登録され、運用管理用のIPアドレスが削除されればよいのです。
特定のNICのIPアドレスをActive Directoryから削除する方法については、ドメイン ネーム システム (DNS) に不要なネットワーク インターフェイス コントローラー (NIC) を登録しないようにする - Windows Server | Microsoft Learnをご参照ください。
この場合ですが、Active Directoryから削除されたNICへのアクセスにはKerberos認証を使うことができなくなるので、注意する必要があります。NTLM認証でのアクセスとなりますが、Active Directoryでは「ダウンレベル認証」としての扱いとなり、セキュリティ上の制約や認証不可などが発生するケースがあります。こういう動作については甘受するしかありません。

3.2. どちらもKerberos認証できるようゾーンニングしたい

複数のネットワークで完全にゾーンニングされたかたちで、Kerberos認証をどちらも有効化したい、このような場合は、「Split-Brain DNS」機能を利用することで、実現は可能です。
これはBINDにおけるsplit DNSに対応する機能ですが、Active DirectoryではSRVレコードが呼び出すホスト名に対して有効化することになります。機能の詳細については、Active Directory でスプリット ブレイン DNS に DNS ポリシーを使用する | Microsoft Learnをご覧いただきたいのですが、Windowsでは、分岐条件にネットワークアドレスだけではなく、様々な条件を設定することができるのが強みです。
なおこの機能はWindows Server 2016以降のDNSサーバーしか動作しません。Windows Server 2012 R2以前には利用できないのでご注意ください。

3.3. 上述した設定を使っていませんが問題がありません。なぜですか？

実はこの問題は古くから存在し、Windows 2000 Server～Windows Server 2003で限定的ながら、対策されていたからです。
これは「ネットマスクの順序を有効にする」機能によるものです。クエリ元の「ネットワークアドレス」部分に注目し、それと同じ（あるいは似た）ネットワークアドレスに属するIPアドレスを優先的に返す、という挙動になっています。詳細はネットマスクの順序付け機能とラウンド ロビン機能の説明 - Windows Server | Microsoft Learnを、ご覧いただければと思います。ネットマスクの設定を変更すれば、単純なネットワーク環境ならばある程度対応できますが、複雑なネットワーク環境では対応できません。

4. AD CS／DHCPとの同居も非推奨

ドメインコントローラーは「Active Directoryの認証のしくみ」を保証する、という重要な役割を担っています。他のソフトウェア、サードパーティのソフトウェアはもちろんのこと、Windowsの追加サービス（役割）やコンポーネントについても、影響がでないよう最初からインストールしないことが推奨されています。
原則的な理由としては、他のサービスの同時稼働によるパフォーマンス低下の影響や、物理メモリやディスクリソースの枯渇によるトラブルを、未然に防ぐためです。RDBMSなど、物理メモリやディスクリソースを無尽蔵に消費していくソフトウェアは、とくに注意する必要があります。
ところで、Windows 2000がリリースされた当初はAD CSやDHCPの同居を非推奨とする、資料はとくに存在していなかったように記憶しています。少なくともWindows 2000 Serverリソースキット（日経BP社刊行／2000年）には、そういった記述は見当たらなかったと思います。
現在このように記載されているのは、Windows 2000の頃には想定していない、運用上の問題点に対応してのことと、考えられます。

4.1. ドメインコントローラーのホスト名が変更できる

Windows 2000では、ドメインコントローラーのホスト名を昇格後に変更することはできません。いったん降格し、ホスト名を変更したうえで再昇格が必要でした。Windows Server 2003 R2以降は、ドメインコントローラーのホスト名をそのままの状態で変更できるようになっています。この機能を生かす場合、他のソフトウェアの影響で「実態としてホスト名の変更ができない」状況は避ける必要があります。
AD CSはサービスの仕様上、サーバーのホスト名を後から変更することはできません。どうしても変更したい場合、AD CSをアンインストールし、ホスト名を変更してから再インストールしないといけないのです。その際「AD CS証明機関名」は旧来のままにしないと、Active Directoryでの整合性がとれなくなるなど、二次的な問題が発生します。このような憂き目にあわないようにする最善の方法は、「最初から組み合わせない」ということになります。

4.2. ドメインコントローラーは「消耗品」である

にわかには信じられない物言いですね。説明が必要かと思います。
端的に申し上げると、現在のドメインコントローラーは、必要に応じて「破棄・再構築」を行うサーバーという扱いになっている、ということです。前提としてドメインコントローラーが「複数台」の運用になっている環境では、その一部（1台のみ）が破損することがあっても、全台の同時破損はほぼ発生しません。
ドメインコントローラーが破損した場合、基本的にはリストアによる再投入が普通なのですが、破損の状況がデータの不整合によるActive Directory同期の問題の場合、稼働中システムの情報を保護する見地で、不整合のドメインコントローラーを破棄する選択肢があります。破損ドメインコントローラーを破棄し、既存のActive Directoryから破棄したドメインコントローラーの情報を削除し、追加ドメインコントローラーとして再構成する、という方法です。
この際、ほかのサーバーアプリケーションやWindows役割が既存環境にインストールされていたら、非常に問題です。これらはバックアップからリストアするしかなく、OS全体をリストアしない、という手法では個別にバックアップ情報を抽出管理しないといけません。Windows役割については、重要なデータについては個別バックアップの機能がありますが、すべての情報を簡単に個別バックアップする手法は用意されていません。
したがって、運用コストが非常に高くなったり、そもそも実現できなかったりします。こういう事態は避ける必要があります。

4.3. ドメインコントローラーは単独役割で利用するのが必須なのか？

はい、その通りとなります。ただし、何事にも例外は存在します。たとえばNPS（Network Policy Server）の利用については、特記事項があります。
NPSはRADIUSサーバーの機能を指します。RADIUSサーバーでは、ネットワークにおけるユーザーやデバイスの「認可」（リソース使用許可の確認）を行う役割を持っています。IEEE802.1x認証などで活躍するソリューションですが、Active Directoryの「認証」後、速やかに認可処理が行われることが求められます。大量の処理が発生するような環境では、応答速度の迅速化が求められるケースがあります。その際、AD DSと同居していることで、認証→認可のネットワーク距離をゼロレベルとして、応答速度を速めることが可能です。この情報についてはネットワーク ポリシー サーバーのベスト プラクティス | Microsoft Learnを参考にしてください。
また古い資料ですが、AD FSとAD DSの同居に関するものも、存在しています。前提条件として、

というものであることに注意してください。当然推奨事項ではありません。こちらをふまえてAD FS の配置を計画する | Microsoft Learnをご覧いただければと思います。
なお、どうしても「単一サーバーにドメインコントローラー含め多数のサーバー機能を統合したい」というご要望がある場合、Windows Server Essentialsを利用する方法があります。Active Directory／Exchange Serverなどオフィスサーバーのアプリケーションが最初からインストール済みの状態になっている小規模向けソリューションです。OEMとしての利用が前提となります。詳細についてはWindows Server Essentials の概要 | Microsoft Learnなどをご参照ください。

5. Exchange Server や SQL Server との同居も非推奨

サーバーアプリケーションは「サービス」を広くユーザーに提供するものですので、アプリケーションとしての準備が必要です。原則的には大量の要求に対して即応できるよう、サーバーリソース（CPUやメモリ）の「大量確保」を行うものが多数です。こういうアプリケーションはAD DSとの同居は向きません。AD DSも同じようにActive Directory認証のためリソースの大量確保を行おうとして、衝突が発生してしまうから、になります。Microsoftの製品であっても、それは変わらない、が原則となります。
それ以外にも、製品固有の問題で推奨できないケースが存在します。SQL Serverを例に、簡単にご説明します。

5.1. インスタンスの「サービスアカウント」の問題

SQL Serverでデータベースサービスを提供するプロセスを「インスタンス」と呼びます。インスタンスを起動する際、認証のためのアカウントが必要になり、サービスアカウントと呼びます。サービスアカウントはWindows OSで用意しますが、前提としては「ローカルアカウント」になります。ドメインコントローラーに昇格した場合、ローカルアカウントは削除され、ドメインアカウントのコピーを受け取る仕様です。すると、昇格前のサービスアカウントが存在しなくなり、インスタンスは起動できません。
最悪の場合、SQL Serverの再インストールの必要があるケースがあります。サービスアカウントの種類によっては、グループポリシー「サービスとしてのログオンを許可する」で修正できることもあります。
どうしても使用したい場合は、ドメインコントローラーに昇格済みの状況でインストールする必要があります。

5.2. 設定変更の問題

SQL Serverの設定変更を行いたい場合に、問題が生じることがあります。たとえばコンピューター名を変更したい場合、ドメインコントローラーだけでも注意が必要ですが、SQL Serverがからむとさらに面倒になります。端的に申し上げるとSQL Serverの名前変更は以下の2段階の作業が必要になります。

詳細についてはSQL Server のスタンドアロン インスタンスをホストするコンピューターの名前を変更する - SQL Server | Microsoft Learnを参考にしていただきたいのですが、煩雑な作業となりますので、できればやらないことに越したことはありません。
ドメイン名の変更（別ドメインへの移行）を行いたい場合、致命的な問題になります。ドメインコントローラーをそのまま他ドメインに加えることはできないため、降格の必要がありますが、この際SQL Serverが破損してしまいます。
ちなみにExchange Serverの場合、コンピューター名の変更はサポートされていません。したがって万一ドメインコントローラーの都合で名前変更を行いたい場合、致命的な問題になります。

6. フェールオーバー クラスター環境でドメイン コントローラーをノードとして追加することはできません

Windowsにはクラスター機能（MSFC：Microsoft Failover Cluster）が備わっており、最低2ノード＋共有フォルダーの環境があれば、高可用性を備えたサーバーシステムを構築できます。この構成にはドメイン環境が必要なのですが、サーバーのリソース節約や、他から独立した単一クラスターとして構成するため、ドメインコントローラーと（サービスを提供する）ノードサーバーを共用したい、という要望をいただくことがあります。
MSFCは内部的に複雑な動作（プロセスやディスクの切り替え・ネットワークハードビートなど）を行っており、どうしてもトラブルが発生しがちになる機能です。ドメインコントローラーと共用している場合、トラブル時の切り分けや対応が非常に困難になること、クラスターオフライン時にドメインコントローラー機能に影響が出るようなケースは、好ましくありません。併せてセキュリティ的にも、必要以上にドメインコントローラーにアクセスが行われる環境では、なんからのセキュリティインシデントが発生する可能性を常に考慮しなければならないでしょう。
古いWindows OSではこのような構成を時折見かけるのですが、Windows Server 2012 R2以降のドメインコントローラーでは、この構成自体を採ることができなくなりました。上記のような事情から、強制的に設定不可に仕様を変更したのだろう、と思われます。

ひとまず、今回は本情報の「べからず」部分について、解説させていただきました。次回は後半となる「べし」部分について、解説させていただきます。