Azure VM に Active Directory Domain Services ドメイン コントローラーをデプロイして構成する
Azure で AD ドメイン コントローラーをデプロイする計画を立てるときに、Contoso IT スタッフが検討する必要があるいくつかの重要な点として、ネットワーク、AD DS サイト、および信頼関係があります。
デプロイに関する考慮事項
- ネットワークの推奨事項。 完全な DNS サポートのために、静的プライベート IP アドレスを使用して、各 AD DS サーバーの VM ネットワーク インターフェイス (NIC) を構成します。 また、オンプレミスからの受信トラフィックと、オンプレミスへの送信トラフィックを許可するように Active Directory サブネット ネットワーク セキュリティ グループ (NSG) の規則を構成する必要もあります。
ヒント
セキュリティに懸念があるため、パブリック IP アドレスを持つドメイン コントローラーに対して VM NIC を構成しないでください。
- サイト間接続。 主要な設計要素は、オンプレミス環境と Azure の間のサイト間接続です。 Azure でホストされる VM が内部ドメイン コントローラーと通信できるようにするには、オンプレミス ネットワークへのサイト間接続を備えた VNet を設定するか、ExpressRoute を使用する必要があります。 クロスプレミス接続には、オンプレミスのインフラストラクチャとの接続を確立するために、Azure からの受信接続をサポートする VPN サーバー、インターネット接続上の静的パブリック IP アドレス、および VNet の動的ゲートウェイが必要です。
- Active Directory サイト。 オンプレミスと Azure ベースのドメイン コントローラー間のレプリケーション トラフィックを制御できるように、AD DS のサイトを構成する必要があります。 知識整合性チェッカー (KCC) は、高帯域幅の接続を想定していて、永続的に使用可能な双方向のリング型トポロジに依存するサイト内レプリケーションを使用して、レプリケーション プロセスを制御します。 レプリケーション トラフィックはスケジュールされておらず、更新プログラムは高速化のために最適化されています。 これに対し、サイト間レプリケーションでは、コストの少ないスパニング ツリー トポロジが使用されます。既定では 3 時間の間隔ですが、1 日または 1 週間の特定の時間に制限できます。
- 信頼関係。 オンプレミスの AD ドメインが Azure の AD ドメインとは異なる AD フォレスト内に含まれている場合は、信頼関係が必要です。 Azure でオンプレミス ユーザーの認証を有効にするには、Azure 内のドメインがオンプレミス フォレスト内のログオン ドメインを信頼する必要があります。 同様に、Azure が外部ユーザーに対してログオン ドメインを提供する場合は、オンプレミス フォレストがクラウド ドメインを信頼することが必要になる場合があります。 フォレスト レベルで信頼を確立するには、フォレストの信頼を作成するか、外部信頼を作成してドメイン レベルで信頼を確立します。 フォレストレベルの信頼では、2 つのフォレスト内のすべてのドメイン間に推移的な信頼関係が作成されます。 逆に、外部ドメイン レベルの信頼では、2 つの指定したドメイン間に推移的でない信頼関係のみが作成されます。 "一方向" または "双方向" の信頼を作成することができます。
- 一方向の信頼では、一方のドメインまたはフォレスト ("着信ドメインまたはフォレスト" と呼ばれる) のユーザーが、もう一方のフォレスト ("送信ドメインまたはフォレスト" と呼ばれる) のリソースにアクセスできます。
- 双方向の信頼を使用すると、いずれかのドメインまたはフォレスト内のユーザーは、他方のリソースにアクセスできます。
Note
外部ドメインレベルの信頼は、異なるフォレストにあるドメイン間にのみ作成することをお勧めします。
次の表は、いくつかの単純なシナリオについて信頼の構成をまとめた一覧です。
| シナリオ | オンプレミスの信頼 | Azure の信頼 |
|---|---|---|
| オンプレミスのユーザーが Azure のリソースにアクセスする必要があるが、その逆はなし | 一方向、着信 | 一方向、送信 |
| Azure のユーザーがオンプレミスにあるリソースにアクセスする必要があるが、その逆はなし | 一方向、送信 | 一方向、着信 |
| Azure とオンプレミスの両方のユーザーが、Azure とオンプレミスに保持されているリソースにアクセスする必要がある | 双方向、着信と送信 | 双方向、着信と送信 |
- 読み取り専用のドメイン コントローラー (RODC)。 これを配置することで、エグレス トラフィックの量と、結果として生じる Azure サービスの料金が削減されます。 RODC は、サービスまたはアプリケーションが AD DS への書き込みアクセスを必要とする場合には機能しません。
- Flexible Single Master Operations (FSMO) のロールとグローバル カタログの配置。 ドメイン トポロジに関係なく、すべての Azure ベースのドメイン コントローラーをグローバル カタログ サーバーとして構成する必要があります。 このようにすることで、グローバル カタログの参照とユニバーサル グループ メンバーシップの評価が Azure からオンプレミスのグローバル カタログに送信される必要がなくなり、発生するエグレス ネットワーク トラフィックの料金が結果的に抑制されます。 Azure ドメイン コントローラーが別のフォレストにある場合は、その操作マスターを Azure でホストする必要があります。 Azure ドメイン コントローラーが別のドメインにある場合は、Azure の VM で、ドメインのプライマリ ドメイン エミュレーター マスター、相対 ID マスター、インフラストラクチャ マスターを構成する必要があります。
ヒント
FSMO のロールとして動作するサーバーへの接続が失敗した場合に備えて、各ドメインの 1 つ以上のサーバーをスタンバイ操作マスターに指定することを検討します。
- 可用性。 ドメインごとに少なくとも 2 つの AD ドメイン コントローラーをプロビジョニングする必要があります。 こうすることで、サーバー間の自動レプリケーションが可能になります。 また、AD ドメイン コントローラー VM の可用性セットを作成し、可用性セットごとに少なくとも 2 台のサーバーを構成することも検討してください。
Note
AD ドメイン コントローラーへの要求はドメイン内のすべてのドメイン コントローラーに分散されるため、トラフィックをドメイン内のコントローラーに転送するようにロード バランサーを構成する必要はありません。
バックアップと復元。 ドメイン コントローラーのシステム状態をバックアップするには、オンプレミスのドメイン コントローラーと同じ手順を使用します。 Update Sequence Number をロールバックする効果が生じる可能性があるため、仮想ハード ドライブのコピー ("複製") は避ける必要があります。 これにより、仮想ハード ドライブ上の AD DS データベース ファイルがコピーされても整合性のある状態にならないため、データベースを起動できなくなる可能性があります。
管理。 Azure portal を使用して AD ドメイン コントローラー VM をシャットダウンしないでください。 代わりに、ゲスト (OS) からシャットダウンして再起動します。 Azure portal を通じて AD ドメイン コントローラーをシャットダウンすると、Azure VM の割り当てが解除され、Active Directory リポジトリの VM-GenerationID と invocationID の両方がリセットされます。 これにより、AD DS の相対識別子 (RID) プールが破棄され、sysvol フォルダーが権限なしとしてマークされます。 これによってドメイン コントローラーの再構成が必要になる場合もあります。
監視。 ドメイン コントローラー VM のリソースおよび AD DS サービスを監視し、問題を迅速に修正するためのプランを作成します。 たとえば、Azure Monitor を使用すると、インフラストラクチャのパフォーマンスを分析できます。これにより、VM にサインインしなくても、ネットワークの問題を監視および診断できます。 Application Insights を使用して、インフラストラクチャの状態を確認するためのメトリックとログを提供できます。
Azure VM 上にレプリカ ドメイン コントローラーとしてドメイン コントローラーを作成するための要件と、新しいフォレストとして作成するための要件は似ています。 どちらのシナリオでも、VM の OS とデータ ディスクを作成するためのストレージ アカウントが必要です。ベスト プラクティスとして、静的 IP アドレスを使用してドメイン コントローラーを構成することをお勧めします。 ただし、1 つ目のシナリオでは、サイト間 VPN または ExpressRoute を使用して、クロスプレミス接続用に VNet を構成する必要があります。