大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第2回 ドメイン環境の構築

こんにちは！ 第1回では、Active DirectoryとDNS、認証の関係を整理しました。今回は、その基盤となるドメイン環境の構築を考えます。

名前を決め、Windows Serverをドメイン コントローラーへ昇格させ、端末が必要なDNSを使えるようにする。この順で、構築前の判断と設定の意味を見ていきましょう。

対象はWindows ServerのActive Directory Domain Services（AD DS）です。漫画は概念を説明する架空の会話であり、実際の導入事例ではありません。

連載の構成

• 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
• 【★今回です★】第2章：ドメイン環境の構築 - 検証環境の構築手順
• 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
• 第4章：プロキシサーバーと統合Windows認証
• 第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
• 第6章：トラブルシューティング - よくある問題と解決方法
• 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
• 第8章：実践的な構成例 - AIセキュリティツールとの統合事例

2.1 ドメイン名の設計

2.1.1 DNS名とNetBIOS名を区別する

ADのドメインには、DNS名と短いNetBIOS名があります。

たとえば、DNS名を corp.example.com、NetBIOS名を CORP とする構成です。前者はDNSによる名前解決などに、後者は CORP\user のような従来形式の表記などに使われます。

相互運用性を考えるなら、名前は英字・数字・ハイフンを基本にし、部署名や拠点名など変更しやすい言葉を避けます。表示できる文字と、長期運用に適した名前は同じではありません。

2.1.2 .localを新規ドメインに選ばない理由

.localは、単なる「社内用」という印ではありません。

.local で終わる名前は、mDNS（Multicast DNS）という同一リンク上の名前解決で特別に扱われます。通常のDNSと扱いが重なるため、新しいADの名前として安易に選ぶと、端末やアプリによる名前解決の違いを持ち込んでしまいます。

既存の .local 環境が必ず動かなくなる、という意味ではありません。新規構築では衝突しにくい名前を選び、既存環境は名前変更の影響と代替策を調べてから対応します。

2.1.3 所有するドメインの下に名前を置く

登録し、自分たちが管理できるドメインのサブドメインを使う方法が基本です。

説明用の例として、所有する名前を example.com と見立て、その下の corp.example.com をAD用に使います。実際の設計では、自社が管理している名前へ置き換えます。

公開WebサイトとADで同じ名前空間を使う場合は、内外のDNSレコードをどう管理するかも決めます。内部と外部で同じ名前への応答を変える構成を、スプリットDNSと呼びます。

.internal は、ICANNが2024年に私的利用向けとしてルートから委任しないことを決めた名前です。ただし、ADの名前、サインイン名、公開サービスの名前をどう使い分けるかは、別途設計する必要があります。

名前を社内向けに分けても、それだけでアクセスを遮断できるわけではありません。通信や公開範囲の制御は、DNSとは別に設定します。

2.1.4 組織変更とクラウド連携を見据える

ADのドメイン名と、人が入力するサインイン名を分けて考えます。

UPN（User Principal Name）は、user@example.com のような利用者のサインイン名です。@ の後ろのUPNサフィックスには、ADのDNS名とは異なる名前を追加できます。

サフィックスを追加することと、各利用者のUPNを変更することは別の操作です。既存アプリやサインインへの影響を確認してから、利用者へ適用します。

Microsoft Entra IDと同期する場合は、そのサフィックスのドメインをEntra側で確認することも計画します。既存ADのDNS名が .local だからという理由だけで、ドメイン全体の改名が必須になるわけではありません。

部署や拠点が増えるたびに、ADドメインを増やす必要はありません。

管理の委任やポリシー適用はOU、ネットワークの場所や複製はサイトとして検討します。OUはオブジェクトの整理単位、サイトはサブネットなどに基づくネットワーク上の区分です。

2.2 AD DSの役割とDCへの昇格

2.2.1 役割の追加で何が用意されるか

Windows Serverの「役割」は、そのサーバーが提供する機能です。

AD DSの役割を追加すると、DCを構成するための機能を導入できます。管理ツールも合わせて用意しますが、役割を入れただけではDCへの構成は終わりません。

1. 1サーバーマネージャーで「役割と機能の追加」を開く。
2. 2対象サーバーを確認し、Active Directory Domain Servicesと必要な管理ツールを追加する。
3. 3インストールの結果を確認し、続いてDCへの昇格に進む。

インストール前に、そのサーバーがワークグループにあるのか、既存ドメインに参加しているのかを確認します。ドメインに参加していないサーバーを、メンバーサーバーと呼ぶことはできません。

2.2.2 昇格で新規作成か既存への追加かを選ぶ

昇格時には、どのAD環境を構成するのかを決めます。

フォレストは、一つ以上のドメインを含み、スキーマなどを共有するADのまとまりです。最初の環境を作る場合と、既存ドメインへDCを追加する場合では、選ぶ処理も前提条件も異なります。

新規フォレストでは、ルートドメイン名を指定します。続いてDNSなどの構成を確認し、ディレクトリサービス復元モード（DSRM）用のパスワードを、安全に管理できる形で設定します。

昇格後は再起動し、ドメイン情報、DNSの登録、SYSVOL・NETLOGONなどの共有を確認します。既存ドメインへ追加した場合は、他のDCとの複製も確認対象です。

ウィザードを最後まで進めたことだけで、端末から利用できるとは判断しません。名前解決、DCへの接続、ドメイン参加やサインインなど、実際に使う経路で確かめます。

2.2.3 役割の配置は停止時の影響から決める

DC、DNS、DHCPは、担当する仕事が異なります。

人数だけで「小規模だから1台」「大規模だから分離」とは決められません。止められる時間、管理できる台数、更新の手順、復旧方法を並べ、同居させる利点と障害の影響を比べます。

複数の書き込み可能なDCは、通常のディレクトリ更新を受け付ける対等な複製先です。単純な「主系だけが書き込み、予備は待機」という構成ではありません。

仮想化しても、復旧設計は必要です。

複数DCを同じ仮想化ホストに集めると、そのホストの停止でまとめて利用できなくなります。ホストやストレージの故障範囲まで含めて配置を考えます。

対応する仮想化基盤では、VM-Generation IDを使ったDCの復元保護があります。それでもスナップショットだけをバックアップの代わりにせず、ADのバックアップと復元手順を用意します。

2.3 DHCPとDNSの設定をつなぐ

2.3.1 DHCPはIPアドレス以外の設定も配る

DHCPは、端末へIP設定を一定期間貸し出す仕組みです。

その貸し出しをリースと呼びます。配布するアドレスの範囲をスコープとして決め、固定で使うサーバーなどのアドレスと重ならないようにします。

DHCPでドメイン名を受け取っても、コンピューターアカウントの作成やADへの参加は行われません。ネットワーク設定の配布とドメイン参加は、別の処理です。

別サブネットのDHCPサーバーへ要求を届ける場合は、DHCPリレーを使う構成を検討します。ルーターを越えた先のサーバーへ、端末のブロードキャストがそのまま届くとは考えません。

2.3.2 ADの名前を解決できるDNSを配布する

端末に配るDNSサーバーは、ADの名前空間を解決できるものに揃えます。

公開DNSを「予備」として混ぜても、AD内部の名前を解決する代わりにはなりません。WindowsのDNSクライアントは、名前が存在しないという応答を受けた場合、次のDNSへ順番に聞き直すわけではありません。

外部サイトの名前は、社内DNSからフォワーダーなどを通して解決するように構成できます。DNSサーバーを配った後は、社内と外部の両方の名前が解決できることを確認します。

Windows Server DHCPでは、スコープのアドレス範囲や除外範囲を決め、ルーターやDNSサーバーなどのオプションを設定します。ADドメインで使うWindows DHCPサーバーは、ADでの承認も確認します。

ルーターで配る場合も、必要な情報は同じです。

次はYamahaのコマンド仕様に沿った説明用の断片です。DNSサーバーを .10 と .11、配布範囲を .100～.199 とし、固定アドレスとの重複を避けています。

dhcp scope 1 192.168.1.100-192.168.1.199/24
dhcp scope option 1 router=192.168.1.1
dhcp scope option 1 dns=192.168.1.10,192.168.1.11
dhcp scope option 1 domain=corp.example.com

複数のDNSアドレスは、カンマで区切ります。実機に投入する完全な設定ではないため、対象モデル・ファームウェアの対応、DHCPの有効化、既存スコープとの重複を別途確認してください。

古いファームウェアには、スコープの再設定で関連オプションが消えるものもあります。変更後は設定を読み直し、実際の端末が受け取った値まで確認します。

2.3.3 DHCPの配置と引き継ぎを設計する

どこへ置くかと、止まったときにどう続けるかを一緒に決めます。

Windows ServerのDHCPフェールオーバーでは、2台でIPv4スコープのリース情報を共有できます。負荷分散か待機系かを選び、別サブネットから使う場合は両方へ要求が届くリレー設定も確認します。

単にアドレス範囲を二つに分けて配る方式とは異なります。また、リース情報の共有とスコープ設定変更の反映は別であり、設定変更後には必要な複製操作を行います。

DHCPがDNSを代理更新する場合は、その認証情報も設計します。DC上でDHCPを動かす構成では、DC自身の強い権限をそのまま使わせず、専用の標準ユーザーアカウントをDNS更新用に設定する方法を確認します。

構築後は、新しい端末への配布、リース更新、片系停止時の動作、DNS登録を試します。DHCPのサービスが起動しているだけでは、利用者の端末が必要な設定を受け取れる証明にはなりません。

まとめ

ドメイン環境の構築では、名前の設計、DCへの昇格、端末に配るDNS設定をつなげて考えます。役割を追加したことや、DHCPが動いていることだけで判断せず、端末から利用する経路まで確認しましょう。

サーバーの配置は社員数だけで決めず、停止時の影響と復旧方法を基準にします。構成図と設定値、確認した手順を残しておくと、増設や障害対応にも役立ちます。

次回予告

第3回では、クライアントPCとサーバーのドメイン参加を扱います。参加の仕組みと手順、つまずいたときの確認点を整理していきましょう。

それでは、また次回、お会いしましょう！