【AD検証ラボ】AWS / Azure で Active Directory 構築ガイド

ごきげんよう、IDチームのわかなです！

IDaaS（OktaやEntra ID）の支援していると、オンプレ Active Directory の検証環境がどうしても必要になる場面が出てきます。

• Okta AD Agent や Entra Connect の挙動確認
• フォレスト信頼関係の構築・切り替えテスト
• AD 廃止ロードマップの PoC

本記事では、AWS（EC2）と Azure（VM）それぞれで AD の検証ラボを立てる手順をまとめました！

AWS

なぜ AWS Directory Service ではなく EC2 なのか

AWS には「AWS Directory Service for Microsoft AD」というフルマネージドの AD サービスがありますが、検証ラボとしては EC2 に Windows Server を立てて自前で AD DS を構成するのがおすすめです。

マネージド AD だと以下の制約があります。

• スキーマ拡張ができない
• FSMO ロール（特定のADをマスタにする）の操作ができない
• DC（ドメインコントローラー）に直接ログインできない
• フォレスト/ドメイン設計を自由にいじれない

「壊して・直して」を繰り返す検証ラボには向きません。

EC2 のいいところ

インスタンスを停止すれば課金が止まる（EBS ストレージ分のわずかな料金は除く）ので、使わないときにお金がかからないのが最大のメリットです。

AD DS の構築やフォレスト信頼関係の検証くらいなら、EC2 でサクッと立てて、終わったら停止しておけばOK。VPC 内に閉じたシンプルな構成で始められるので、気軽に使えます。

一方で、ネットワークをまたぐ構成（マルチ VPC、Azure との接続など）になると、サブネットや VPN の設計がそれなりにしんどくなります。

必要な設定手順

1. EC2 インスタンスの作成

コスト目安： t3.large（東京リージョン）≈ $0.11/h → 1日8時間使って約 $0.88/日。

2. セキュリティグループの設定

AD の検証ラボで一番重要なのがセキュリティグループの設定です。

DC 用インバウンドルール：

検証環境なら、ソースを VPC 内の CIDR（例： 10.0.0.0/16）に絞っておけば十分です。RDP だけ自分のグローバル IP に限定しましょう。

フォレスト構成で信頼関係を組む場合は、DC（ドメインコントローラー）同士で DNS（53）、Kerberos（88）、GC（3268）が相互に通る必要があります。同一セキュリティグループ内なら自動で許可されるので、DC を同じセキュリティグループで管理するのがおすすめです。

3. Windows Server の初期設定

# ホスト名変更（再起動が入ります）
Rename-Computer -NewName "DC-01" -Restart

# タイムゾーン設定
Set-TimeZone -Id "Tokyo Standard Time"

EC2 のプライベート IP はデフォルトで固定ですが、念のため確認を。AD は DC の IP が変わると DNS がぶっ壊れます。

4. AD DS 役割のインストール

PowerShell を管理者として実行してください。

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

これで AD DS の役割がインストールされます。ただし、この時点ではまだドメインは作られていません。次のステップで DC に昇格させます。

5. フォレスト構築（DC に昇格）

Install-ADDSForest `
    -DomainName "ad.yourlab.local" `
    -DomainNetBIOSName "YOURLAB" `
    -ForestMode "WinThreshold" `
    -DomainMode "WinThreshold" `
    -InstallDNS:$true `
    -SafeModeAdministratorPassword (ConvertTo-SecureString "YourP@ssw0rd!" -AsPlainText -Force) `
    -Force:$true

実行すると自動的に再起動がかかり、再起動後は YOURLAB\Administrator でログインする形になります。

6. DNS の動作確認

AD 構築後確認すること：

nslookup -type=srv _ldap._tcp.dc._msdcs.ad.yourlab.local

期待する結果：

service = 0 100 389 dc-01.ad.yourlab.local

これが返ってこなかったら、AD のほぼ全機能が動きません。

EC2 のデフォルト DNS（VPC の .2 アドレス）が残っていると、AD の SRV レコードを引けません。VPC の DHCP オプションセットで DNS サーバーを DC の IP に変更してください。変更後は EC2 の再起動が必要です。

Server Manager で稼働しているか確認してみましょう！

Azure

いつ Azure を使うか

AD の基本検証だけなら AWS でも Azure でもどちらでも大丈夫ですが、以下の検証をしたいなら Azure のほうが圧倒的にやりやすいため、おすすめです！

• Entra Domain Services（Entra DS / MEDS）： Entra ID のユーザーを AD 互換の環境に同期するマネージドサービス。Azure 上でしか使えません
• Entra Connect（旧 Azure AD Connect）： 同じ Azure 内に AD VM と Entra Connect VM を置けるので、同期検証がスムーズ
• Entra Hybrid Join： AD 参加済みデバイスを Entra ID にも登録する構成。Azure VM + Entra Connect + Intune を同一環境でまとめて試せます
• AVD（Azure Virtual Desktop） や VDI まわりの検証

必要な設定手順

1. Azure VM の作成

コスト目安： Standard_B2ms ≈ $85/月（東京リージョン）。

2. NSG（ネットワークセキュリティグループ）の設定

AWS のセキュリティグループに相当するのが NSG です。開けるポートと理由は AWS の章と同じなので、そちらの表を参照してください。

Azure の場合、NSG はサブネットに紐づけるのが一般的です。

3. AD DS のインストール〜DC 昇格

PowerShell コマンドは AWS と同じです（Install-WindowsFeature → Install-ADDSForest）。

4. VNet の DNS 設定を変更する（Azure 固有）

Azure VM を DC にしたあと、VNet の DNS サーバー設定を DC の IP に変更する必要があります。これを忘れると、同じ VNet 内の他の VM がドメインに参加できません。

# Azure CLI
az network vnet update \
    --resource-group ad-lab-rg \
    --name ad-lab-vnet \
    --dns-servers 10.0.1.10

Azure Portal から設定する場合は、仮想ネットワーク > 設定 > DNS > 「カスタム（変更）」 を選択して DC の IP を入力します。

DNS 設定変更後、VNet 内の全 VM を再起動してください。再起動しないと新しい DNS 設定が反映されません。

AD の基本

検証ラボを立てたら、まず押さえておきたい AD の基本概念をまとめます。

ドメイン・フォレスト・OU・GPO

先ほどの Install-ADDSForest を実行すると、「1つのフォレストの中に 1つのドメインがある」という最小構成ができます。この中にユーザーや OU を作っていくイメージです。

ドメインやフォレストを分けるのはどんなとき？

• ユーザーを管理するドメインと、VDI 端末を管理するドメインを分離したいとき
• M&A やグループ統合で、別々に運用していた AD を接続する必要があるとき
• セキュリティ境界を明確に分けたいとき

フォレストを分けた場合、お互いのユーザーを認め合うために「信頼関係」を設定します。信頼関係がないと「知らない人は入れません」と拒否されます。

OU の設計は Okta や Entra Connect でインポートする範囲に直結します。あとからの変更も可能ですが、「どの OU のユーザーをどの IDaaS に同期するか」は最初に考えておくのがおすすめです。

AD DS と DC の違い

略語で混同しやすいので整理します。

先ほどの手順でいうと：

• Step 4（Install-WindowsFeature）= AD DS のインストール → まだただの Windows Server
• Step 5（Install-ADDSForest）= DC への昇格 → ここで初めてドメインコントローラーになる

「ADDC を構築する」と言われたら、この 2ステップをやる、ということです。

パスワード同期ってなに？

AD とクラウド（Entra ID）を連携するとき、「パスワードをどう扱うか」にいくつかの方式があります。IDaaS 連携の検証でよく出てくるので、違いをざっくり押さえておきましょう。

PHS（Password Hash Sync）

AD のパスワードハッシュを Entra ID に同期する方式。現在最も推奨されている方式。

• AD 側でパスワードを変更すると、しばらくして Entra ID にも反映される
• AD が落ちても、ハッシュがクラウドに保存されているのでクラウド側で認証を継続できる
• シンプルで運用が楽

PTA（Pass-through Authentication）

ログイン時にリアルタイムで AD に認証を委譲する方式。

• パスワードハッシュがクラウドに保存されない（セキュリティポリシー上これが必須な組織向け）
• オンプレに PTA Agent が必要
• AD や Agent が落ちるとクラウド認証もできなくなる

フェデレーション（ADFS）

ADFS サーバーが認証を処理して、SAML トークンを発行する方式。

• 高度な認証ポリシー（クレームルールなど）が設定可能
• ただし ADFS サーバーの構築・冗長化・運用がかなり大変
• ADFS が止まると認証全停止

検証ラボで最初に試すなら PHS がおすすめです。Entra Connect をインストールするときに同期方式を選べるので、まずは PHS で動かしてみて、必要に応じて他の方式を試す、という進め方がスムーズです。

豆知識

Windows App で Azure VM / EC2 に接続する

Azure VM や EC2 への RDP 接続には、Microsoft の Windows App（旧 Microsoft Remote Desktop）が便利です。

• macOS / iOS / Windows など複数プラットフォームで使える
• 複数の接続先を保存しておけるので、DC や Client VM を切り替えるのが楽
• Azure VM だけでなく AWS の EC2 にもそのまま使える

Entra Connect のインストーラーを持ち込む方法

Entra Connect（Azure AD Connect）の .msi インストーラーは、通常 Entra ID の管理画面からダウンロードします。

Azure Portal > Microsoft Entra ID > Microsoft Entra Connect > Connect 同期 >  最新の Entra Connect Sync バージョンをダウンロードする

ただし、検証用の AD サーバーからインターネットに出たくない（or 出られない）場合は、ローカル PC でダウンロードしてから RDP のクリップボード経由でコピペすれば持ち込めます。

まとめ

• AD 検証ラボは、マネージド AD ではなく EC2 / VM 上の自前 AD DS がおすすめ！
• セキュリティグループ / NSG は「なぜそのポートが必要か」まで理解しておくとよい
• AD DS はソフトウェア（役割）、DC はそれが入ったサーバー
• パスワード同期は PHS / PTA / フェデレーション（ADFS や PingFederate）から選択。まず PHS から試そう

AD 実験シリーズとして、引き続き書いていきたいと思います！