次の方法で共有


Microsoft Entra Domain Services の仮想ネットワーク設計の考慮事項と構成オプション

Microsoft Entra Domain Services から、他のアプリケーションおよびワークロードに認証および管理サービスが提供されます。 ネットワーク接続は重要なコンポーネントです。 仮想ネットワークリソースが正しく構成されていないと、アプリケーションとワークロードは、Domain Services によって提供される機能と通信して使用することができません。 仮想ネットワークの要件を計画し、Domain Services が必要に応じてアプリケーションとワークロードにサービスを提供できることを確認します。

この記事では、Domain Services をサポートするための Azure 仮想ネットワークの設計の考慮事項と要件について説明します。

Azure 仮想ネットワークの設計

ネットワーク接続を提供し、アプリケーションとサービスが Domain Services マネージド ドメインに対して認証できるようにするには、Azure 仮想ネットワークとサブネットを使用します。 マネージド ドメインを独自の仮想ネットワークにデプロイするのが理想的です。

同じ仮想ネットワーク内に別のアプリケーション サブネットを追加して、管理 VM または軽量なアプリケーション ワークロードをホストすることができます。 Domain Services 仮想ネットワークとピアリングされた大規模または複雑なアプリケーション ワークロードの場合は、通常、別の仮想ネットワークが最適な設計です。

以下のセクションに記載されている仮想ネットワークとサブネットの要件を満たしている場合は、その他の設計の選択肢が有効です。

Domain Services の仮想ネットワークを設計する際には、次の考慮事項が適用されます。

  • Domain Services は、仮想ネットワークと同じ Azure リージョンにデプロイする必要があります。
    • 現時点では、Microsoft Entra テナントごとにデプロイできるマネージド ドメインは 1 つのみです。 マネージド ドメインは、1 つのリージョンにデプロイされます。 仮想ネットワークは、必ず Domain Services をサポートするリージョンで作成または選択します。
  • 他の Azure リージョンとアプリケーション ワークロードをホストする仮想ネットワークの距離を考慮します。
    • 待機時間を最小限に抑えるには、マネージド ドメインの仮想ネットワーク サブネットの近く、または同じリージョンにコア アプリケーションを保持します。 Azure 仮想ネットワーク間には、仮想ネットワーク ピアリングまたは仮想プライベート ネットワーク (VPN) 接続を使用できます。 以下のセクションでは、これらの接続オプションについて説明します。
  • 仮想ネットワークは、マネージド ドメインが提供するサービス以外の DNS サービスに依存することはできません。
    • Domain Services は独自の DNS サービスを提供しています。 これらの DNS サービス アドレスを使用するように仮想ネットワークを構成する必要があります。 追加の名前空間の名前解決は、条件付きフォワーダーを使用して実現できます。
    • カスタム DNS サーバーの設定を使用して、VM などの他の DNS サーバーからのクエリを送信することはできません。 仮想ネットワーク内のリソースでは、マネージド ドメインから提供される DNS サービスを使用する必要があります。

重要

Domain Services は、有効にした後、別の仮想ネットワークに移動できません。

マネージド ドメインは、Azure 仮想ネットワーク内のサブネットに接続します。 次の点を考慮して、Domain Services 用にこのサブネットを設計します。

  • マネージド ドメインは、独自のサブネットにデプロイする必要があります。 仮想ネットワーク ピアリングで既存のサブネット、ゲートウェイ サブネット、またはリモート ゲートウェイの設定を使用することはサポートされていません。

  • マネージド ドメインのデプロイ時に、ネットワーク セキュリティ グループが作成されます。 このネットワーク セキュリティ グループには、サービス通信を正しく行うために必要な規則が含まれています。

    • 独自のカスタム規則を持つ既存のネットワーク セキュリティ グループを作成または使用しないでください。
  • マネージド ドメインには、3 ~ 5 個の IP アドレスが必要です。 サブネットの IP アドレス範囲でこの数のアドレスを提供できることを確認してください。

    • 使用可能な IP アドレスを制限すると、マネージド ドメインで 2 つのドメイン コントローラーを維持できなくなる可能性があります。

    Note

    次の問題のため、仮想ネットワークとそのサブネットにはパブリック IP アドレスを使用しないでください。

    • IP アドレスの不足: IPv4 パブリック IP アドレスは限られており、その需要は利用可能な供給を超えることがよくあります。 また、IP がパブリック エンドポイントと重複する可能性があります。

    • セキュリティ リスク: 仮想ネットワークにパブリック IP を使用すると、デバイスがインターネットに直接公開されるため、不正アクセスや潜在的な攻撃のリスクが高まります。 適切なセキュリティ対策を講じないと、デバイスがさまざまな脅威に対して脆弱になる可能性があります。

    • 複雑さ: パブリック IP を使用した仮想ネットワークの管理は、外部 IP 範囲を処理し、ネットワークの適切なセグメンテーションとセキュリティを確保する必要があるため、プライベート IP を使用する場合よりも複雑になる可能性があります。

    プライベート IP アドレスを使用することを強くお勧めします。 パブリック IP を使用する場合は、選択したパブリック範囲内で選択した IP の所有者/専用ユーザーであることを確認してください。

次の図の例は、マネージド ドメインに独自のサブネットがあり、外部接続用にゲートウェイ サブネットがあり、アプリケーション ワークロードが仮想ネットワーク内の接続されたサブネットにある有効な設計を示しています。

Recommended subnet design

Domain Services 仮想ネットワークへの接続

前のセクションで説明したように、マネージド ドメインは、Azure の 1 つの仮想ネットワークにのみ作成できます。また、Microsoft Entra テナントごとに作成できるマネージド ドメインは 1 つのみです。 このアーキテクチャに基づいて、アプリケーション ワークロードをホストする 1 つ以上の仮想ネットワークをマネージド ドメインの仮想ネットワークに接続することが必要になる場合があります。

次のいずれかの方法を使用して、他の Azure 仮想ネットワークでホストされているアプリケーション ワークロードを接続できます。

  • 仮想ネットワーク ピアリング
  • 仮想プライベート ネットワーク (VPN)

仮想ネットワーク ピアリング

仮想ネットワーク ピアリングは、Azure バックボーン ネットワークを介して 2 つの仮想ネットワークを接続するメカニズムであり、仮想マシン (VM) などのリソースがプライベート IP アドレスを使用して相互に直接通信できるようにします。 仮想ネットワーク ピアリングは、同じ Azure リージョン内の VNet を接続するリージョン ピアリングと、異なる Azure リージョン間で VNet を接続するグローバル仮想ネットワーク ピアリングの両方をサポートします。 この柔軟性により、リージョンの場所に関係なく、複数の仮想ネットワークにアプリケーション ワークロードを含むマネージド ドメインをデプロイできます。

Virtual network connectivity using peering

詳細については、Azure 仮想ネットワークのピアリングの概要に関するページを参照してください。

仮想プライベート ネットワーク (VPN)

仮想ネットワークをオンプレミス サイトの場所に構成する場合と同じ方法で、仮想ネットワークを別の仮想ネットワークに (VNet 間) 接続することができます。 どちらの接続でも、VPN ゲートウェイを使用して、IPsec/IKE を使用してセキュリティで保護されたトンネルを作成します。 この接続モデルを使用すると、マネージド ドメインを Azure 仮想ネットワークにデプロイし、オンプレミスの場所または他のクラウドに接続することができます。

VPN Gateway を使用した仮想ネットワーク接続

仮想プライベート ネットワークの使用方法の詳細については、「Microsoft Entra 管理センターを使用して VNet 間 VPN ゲートウェイ接続を構成する」を参照してください。

仮想ネットワークを接続するときの名前解決

マネージド ドメインの仮想ネットワークに接続される仮想ネットワークには、通常、独自の DNS 設定があります。 仮想ネットワークに接続しても、接続中の仮想ネットワークがマネージド ドメインから提供されるサービスを解決するための名前解決は自動的に構成されません。 アプリケーション ワークロードがマネージド ドメインを見つけられるように、接続している仮想ネットワークの名前解決を構成する必要があります。

名前解決を有効にするには、接続している仮想ネットワークをサポートする DNS サーバー上で条件付き DNS フォワーダーを使用するか、マネージド ドメインの仮想ネットワークと同じ DNS IP アドレスを使用します。

Domain Services によって使用されるネットワーク リソース

マネージド ドメインでは、デプロイ時にいくつかのネットワーク リソースが作成されます。 これらのリソースは、マネージド ドメインの正常な運用と管理のために必要であり、手動で構成することはできません。

Domain Services によって使用されるネットワーク リソースをロックしないでください。 ネットワーク リソースがロックされている場合は、そのリソースを削除できません。 その場合にドメイン コントローラーを再構築する必要があるとき、IP アドレスの異なる新しいネットワーク リソースを作成する必要があります。

Azure リソース 説明
ネットワーク インターフェイス カード Domain Services は、Windows Server 上で Azure VM として実行されている 2 つのドメイン コントローラー (DC) 上でマネージド ドメインをホストします。 各 VM には、仮想ネットワークのサブネットに接続する仮想ネットワーク インターフェイスがあります。
動的標準パブリック IP アドレス Domain Services は、Standard SKU のパブリック IP アドレスを使用して同期および管理サービスと通信します。 パブリック IP アドレスの詳細については、「Azure における IP アドレスの種類と割り当て方法」を参照してください。
Azure Standard Load Balancer Domain Services では、ネットワーク アドレス変換 (NAT) および負荷分散 (セキュリティで保護された LDAP と共に使用する場合) に Standard SKU のロード バランサーを使用します。 Azure Load Balancer の詳細については、Azure Load Balancer の概要に関する記事を参照してください。
ネットワーク アドレス変換 (NAT) 規則 Domain Services は、安全な PowerShell リモート処理のために、ロード バランサーで 2 つのインバウンド NAT 規則を作成して使用します。 Standard SKU ロード バランサーが使用されている場合は、アウトバウンド NAT 規則もあります。 Basic SKU ロードバランサーでは、アウトバウンド NAT 規則は必要ありません。
負荷分散規則 マネージド ドメインが TCP ポート 636 上のセキュリティで保護された LDAP 用に構成されている場合、トラフィックを分散する 3 つの規則がロード バランサーに対して作成され、使用されます。

警告

ロード バランサーやルールの手動での構成など、Domain Services によって作成されたネットワーク リソースは削除または変更しないでください。 ネットワーク リソースのいずれかを削除または変更すると、Domain Services サービスの停止が発生することがあります。

ネットワーク セキュリティ グループと必要なポート

ネットワーク セキュリティ グループ (NSG) には、Azure 仮想ネットワーク内のネットワーク トラフィックを許可または拒否するルールの一覧が含まれています。 マネージド ドメインを展開すると、サービスが認証および管理機能を提供できるようにする一連の規則を含むネットワーク セキュリティ グループが作成されます。 この既定のネットワーク セキュリティ グループは、マネージド ドメインがデプロイされる仮想ネットワーク サブネットに関連付けられています。

次のセクションでは、ネットワーク セキュリティ グループと、受信ポートおよび送信ポートの要件について説明します。

受信接続

マネージド ドメインで認証と管理サービスを提供するには、次のネットワーク セキュリティ グループの受信規則が必要です。 マネージド ドメインの仮想ネットワーク サブネットのネットワーク セキュリティ グループ規則は編集も削除もしないでください。

source 発信元サービス タグ Source port ranges 宛先 サービス 宛先ポート範囲 Protocol アクション 必須 目的
サービス タグ AzureActiveDirectoryDomainServices * Any WinRM 5986 TCP Allow はい ドメインの管理。
サービス タグ CorpNetSaw * Any RDP 3389 TCP Allow 省略可能 サポートのためのデバッグ

Microsoft Entra 管理センターを使用して CorpNetSaw サービス タグを使用できないことに注意してください。また、PowerShell を使用して CorpNetSaw のネットワーク セキュリティ グループ規則を追加する必要があります。

Domain Services は、既定のセキュリティ規則である AllowVnetInBound と AllowAzureLoadBalancerInBound にも依存しています。

ネットワーク セキュリティ グループ規則のスクリーンショット。

AllowVnetInBound 規則により、VNet 内のすべてのトラフィックが許可され、DC で適切に通信およびレプリケートできるほか、ドメイン参加やその他のドメイン サービスをドメイン メンバーに許可できます。 Windows の必須のポート範囲の詳細については、「Windows のサービス概要およびネットワーク ポート要件」を参照してください。

サービスがロードバランスを介して適切に通信して DC を管理できるように AllowAzureLoadBalancerInBound 規則も必須となります。 このネットワーク セキュリティ グループは Domain Services を保護し、マネージド ドメインが正しく機能するために必要です。 このネットワーク セキュリティ グループを削除しないでください。 これがないと、ロード バランサーは正常に機能しません。

必要に応じて、Azure PowerShell を使用して必要なネットワーク セキュリティ グループとルールを作成することができます。

警告

正しく構成されていないネットワーク セキュリティ グループまたはユーザー定義のルート テーブルを、マネージド ドメインが展開されているサブネットに関連付けると、Microsoft のドメインのサービスと管理の機能が中断する可能性があります。 Microsoft Entra テナントとマネージド ドメインの間の同期も中断されます。 同期、修正プログラムの適用、または管理を中断する可能性のあるサポートされていない構成を回避するために、リストされているすべての要件に従います。

Secure LDAP を使用する場合は、必要な TCP ポート 636 の規則を適宜追加することで、外部トラフィックを許可することができます。 この規則を追加しても、ネットワーク セキュリティ グループの規則がサポート対象外の状態に設定されることはありません。 詳細については、「インターネット経由での Secure LDAP アクセスをロック ダウンする」を参照してください。

Azure SLA は、不適切に構成されたネットワーク セキュリティ グループまたはユーザー定義のルート テーブルによって更新または管理がブロックされているデプロイには適用されません。 ネットワーク構成が壊れていると、セキュリティ パッチの適用が妨げられる可能性もあります。

送信接続

送信接続の場合、AllowVnetOutbound および AllowInternetOutBound を維持するか、次の表にリストされている ServiceTag を使用して送信トラフィックを制限できます。 AzureUpdateDelivery の ServiceTag は、PowerShell を介して追加する必要があります。 Log Analytics を使用する場合は、EventHub を送信先に追加します。

優先度が高い他の NSG が送信接続を拒否していないことをご確認ください。 送信接続が拒否された場合、レプリカ セット間のレプリケーションは機能しません。

送信ポート番号 プロトコル ソース Destination (公開先) アクション 必須 目的
443 TCP Any AzureActiveDirectoryDomainServices Allow はい Microsoft Entra Domain Services 管理サービスとの通信。
443 TCP Any AzureMonitor Allow はい 仮想マシンの監視。
443 TCP Any 記憶域 Allow はい Azure Storage との通信。
443 TCP [任意] Microsoft Entra ID 許可 はい Microsoft Entra ID との通信。
443 TCP Any GuestAndHybridManagement Allow はい セキュリティ パッチの自動管理。

Note

AzureUpdateDelivery タグと AzureFrontDoor.FirstParty タグは、2024 年 7 月 1 日の時点で非推奨となっています。 既定の AllowInternetOutBound 規則 (優先度 65001) を使用する場合、変更は必要ありません (AzureUpdateDelivery タグと AzureFrontDoor.FirstParty タグの有無にかかわらず)。 詳細については、「AzureUpdateDelivery サービス タグへの変更」を参照してください。

ポート 5986 - PowerShell リモート処理を使用した管理

  • PowerShell のリモート処理を使用してマネージド ドメインの管理タスクを実行するために使用されます。
  • このポートにアクセスできない場合、マネージド ドメインの更新、構成、バックアップおよび監視は行えません。
  • このポートへの受信アクセスを AzureActiveDirectoryDomainServices サービス タグに制限できます。

ポート 3389 - リモート デスクトップを使用した管理

  • マネージド ドメイン内のドメイン コントローラーへのリモート デスクトップ接続に使用されます。このポートを変更したり、別のポートにカプセル化したりすることはできません。
  • 既定のネットワーク セキュリティ グループの規則では、CorpNetSaw サービス タグを使用してトラフィックがさらに制限されます。
    • このサービス タグでは、Microsoft 企業ネットワーク上のセキュリティで保護されたアクセス ワークステーションのみが、マネージド ドメインへのリモート デスクトップを使用できます。
    • アクセスは、管理やトラブルシューティングのシナリオなど、業務上の正当な理由でのみ許可されます。
  • この規則を [拒否] に設定し、必要な場合にのみ [許可] に設定することができます。 ほとんどの管理タスクと監視タスクは、PowerShell リモート処理を使用して実行されます。 RDP は、Microsoft が高度なトラブルシューティングのためにマネージド ドメインへのリモート接続が必要になるような頻度の低いイベントでのみ使用されます。

このネットワーク セキュリティ グループの規則を編集しようとすると、ポータルから CorpNetSaw サービス タグを手動で選択することはできません。 CorpNetSaw サービス タグを使用する規則を手動で構成するには、Azure PowerShell または Azure CLI を使用する必要があります。

たとえば、次のスクリプトを使用して、RDP を許可する規則を作成できます。

Get-AzNetworkSecurityGroup -Name "nsg-name" -ResourceGroupName "resource-group-name" | Add-AzNetworkSecurityRuleConfig -Name "new-rule-name" -Access "Allow" -Protocol "TCP" -Direction "Inbound" -Priority "priority-number" -SourceAddressPrefix "CorpNetSaw" -SourcePortRange "*" -DestinationPortRange "3389" -DestinationAddressPrefix "*" | Set-AzNetworkSecurityGroup

ユーザー定義のルート

ユーザー定義ルートは、既定では作成されず、Domain Services が正しく機能するためには必要ありません。 ルート テーブルを使用する必要がある場合は、0.0.0.0 ルートに変更を加えないようにしてください。 このルートを変更すると、Domain Services が中断され、マネージド ドメインがサポートされない状態になります。

また、それぞれの Azure サービス タグに含まれる IP アドレスからの受信トラフィックをマネージド ドメインのサブネットにルーティングする必要があります。 サービス タグとそれに関連付けられている IP アドレスの詳細については、「Azure の IP 範囲とサービス タグ - パブリック クラウド」を参照してください。

注意事項

これらの Azure データセンターの IP 範囲は、予告なしに変わる可能性があります。 最新の IP アドレスを取得していることを検証するプロセスを用意してください。

次のステップ

Domain Services で使用されるネットワーク リソースと接続オプションの詳細については、次の記事を参照してください。