Active Directory Domain Services サイトの設計と Azure NetApp Files の計画に関するガイドラインを理解する
Active Directory Domain Services (AD DS) の設計と計画を適切に行うことは、Azure NetApp Files ボリュームを使用するソリューション アーキテクチャにとって鍵となります。 SMB ボリューム、デュアル プロトコル ボリューム、NFSv4.1 Kerberos ボリュームなどの Azure NetApp Files 機能は、AD DS と共に使用するように設計されています。
この記事では、Azure NetApp Files に対応した AD DS のデプロイ戦略を開発するうえでの推奨事項について説明します。 この記事を読む前に、AD DS が機能レベルでどのように動作するかについてよく理解しておく必要があります。
Azure NetApp Files の AD DS 要件を確認する
Azure NetApp Files ボリュームをデプロイする前に、Azure NetApp Files が AD DS に確実に接続されるように、Azure NetApp Files の AD DS 統合要件を確認する必要があります。 AD DS と Azure NetApp Files の統合が正しくなかったり、不完全であったりすると、SMB、デュアル プロトコル、または Kerberos NFSv4.1 ボリュームのクライアント アクセスが中断したり、停止したりする可能性があります。
サポートされる認証シナリオ
Azure NetApp Files では、SMB 経由のアクセスについて、以下の方法による ID ベースの認証がサポートされています。
- AD DS 認証: AD DS 参加済みの Windows マシンは、SMB 経由で、Active Directory 資格情報を使用して Azure NetApp Files 共有にアクセスできます。 クライアントには、AD DS への通信経路が必要です。 オンプレミスまたは Azure 上の仮想マシンにセットアップされた AD DS があり、デバイスが AD DS ドメイン参加済みである場合、Azure ファイル共有の認証には AD DS を使用してください。
- Microsoft Entra Domain Services 認証: クラウド ベースの Microsoft Entra Domain Services 参加済み Windows 仮想マシンでは、Microsoft Entra Domain Services 資格情報を使用して Azure NetApp Files ファイル共有にアクセスできます。 このソリューションの場合は、Microsoft Entra Domain Services が、お客様のために従来の Windows Server AD ドメインを実行します。
- Linux クライアント用の AD Kerberos 認証: Linux クライアントは、SMB 経由で、Kerberos 認証を使用し、AD DS を使用する Azure NetApp Files にアクセスできます。
ネットワークの要件
Azure NetApp Files ボリュームを使用した予測可能な Active Directory Domain Services 操作では、AD DS ドメイン コントローラーへのネットワーク接続が安定していて、待機時間が短い (ラウンドトリップ時間 [RTT] が 10 ミリ秒 [ms] 以内) ことが強く推奨されます。 Azure NetApp Files と AD DS ドメイン コントローラー間のネットワーク接続が不適切であるか、ネットワーク待機時間が長いと、クライアント アクセスの中断やクライアントのタイムアウトが発生する可能性があります。
Note
10 ミリ秒の推奨事項は、「サイト設計の作成: サイトにする場所の決定」のガイダンスに従っています。
ネットワーク トポロジと構成に関する次の要件を満たしていることを確認してください。
- Azure NetApp Files でサポートされているネットワーク トポロジが使用されていることを確認してください。
- AD DS ドメイン コントローラーに、Azure NetApp Files ボリュームをホストする Azure NetApp Files 委任サブネットからのネットワーク接続があることを確認してください。
- AD DS ドメイン コントローラーを使用するピアリングされた仮想ネットワーク トポロジでは、Azure NetApp Files から AD DS ドメイン コントローラーへのネットワーク接続をサポートするようにピアリングが正しく構成されている必要があります。
- ネットワーク セキュリティ グループ (NSG) および AD DS ドメイン コントローラー ファイアウォールには、AD DS と DNS への Azure NetApp Files 接続をサポートするように適切に構成された規則が必要です。
- 最適なエクスペリエンスを得るために、Azure NetApp Files と AD DS ドメイン コントローラー間の RTT ネットワーク待機時間が 10 ミリ秒以下であることを確かめます。 RTT が 10 ミリ秒を超える場合、待機時間の影響を受けやすいアプリケーション/環境でアプリケーションまたはユーザー エクスペリエンスが低下する可能性があります。 RTT が高すぎて望ましいユーザー エクスペリエンスが得られない場合は、Azure NetApp Files 環境にレプリカ ドメイン コントローラーをデプロイすることを検討してください。 「Active Directory Domain Services に関する考慮事項」もご覧ください。
ワイドエリア ネットワーク経由のネットワーク待機時間に関する Microsoft Active Directory 要件の詳細については、「サイト設計の作成」を参照してください。
必要なネットワーク ポートは次のとおりです。
サービス | Port | プロトコル |
---|---|---|
ICMPv4 (ping) | 該当なし | エコー応答 |
DNS* | 53 | TCP、UDP |
Kerberos | 88 | TCP、UDP |
NeTBIOS データグラム サービス | 138 | UDP |
NetBIOS | 139 | UDP |
LDAP** | 389 | TCP、UDP |
セキュリティ アカウント マネージャー (SAM)/ローカル セキュリティ機関 (LSA)/SMB | 445 | TCP、UDP |
Kerberos (kpasswd) | 464 | TCP、UDP |
Active Directory グローバル カタログ | 3268 | TCP |
Active Directory のセキュリティで保護されたグローバル カタログ | 3269 | TCP |
Active Directory Web サービス | 9389 | TCP |
* Active Directory DNS のみ
** LDAP over SSL (ポート 636) は現在サポートされていません。 代わりに、LDAP over StartTLS (ポート 389) を使用して LDAP トラフィックを暗号化してください。
DNS の詳細については、「Azure NetApp Files のドメイン ネーム システムについて」を参照してください。
タイム ソースの要件
Azure NetApp Files では、タイム ソースとして time.windows.com が使用されます。 Azure NetApp Files によって使用されるドメイン コントローラーが、time.windows.com またはその他の正確で安定したルート (階層 1) のタイム ソースを使用するように構成されていることを確認してください。 Azure NetApp Files とお客様のクライアントまたは AS DS ドメイン コントローラーの間のずれが 5 分を超える場合、認証は失敗し、Azure NetApp Files ボリュームへのアクセスも失敗する可能性があります。
Azure NetApp Files で使用する AD DS を決定する
Azure NetApp Files は、AD 接続用に Active Directory Domain Services (AD DS) と Microsoft Entra Domain Services の両方をサポートしています。 AD 接続を作成する前に、AD DS と Microsoft Entra Domain Services のどちらを使用するかを決定する必要があります。
詳細については、「セルフマネージド Active Directory Domain Services、Microsoft Entra ID、マネージド Microsoft Entra Domain Services を比較する」を参照してください。
Active Directory Domain Services に関する考慮事項
次のシナリオでは、Active Directory Domain Services (AD DS) を使用する必要があります。
- オンプレミスの AD DS ドメインでホストされている AD DS ユーザーが、Azure NetApp Files リソースにアクセスできるようにする必要がある。
- 一部をオンプレミス、一部を Azure でホストしているアプリケーションから、Azure NetApp Files リソースにアクセスする必要がある。
- サブスクリプション内の Microsoft Entra テナントと Microsoft Entra Domain Services を統合する必要がない場合、または Microsoft Entra Domain Services が技術要件に合わない場合。
Note
Azure NetApp Files は、AD DS の読み取り専用ドメイン コントローラー (RODC) の使用をサポートしていません。 書き込み可能なドメイン コントローラーはサポートされており、Azure NetApp Files ボリュームでの認証に必要です。 詳細については、「Active Directory のレプリケーションの概念」をご覧ください。
Azure NetApp Filesで AD DS を使用する場合は、「Azure 仮想ネットワークに AD DS をデプロイする」のガイダンスに従って、AD DS に対する Azure NetApp Files のネットワークおよび DNS 要件を満たしていることを確認してください。
Microsoft Entra Domain Services に関する考慮事項
Microsoft Entra Domain Services は、Microsoft Entra テナントと同期されるマネージド AD DS ドメインです。 Microsoft Entra Domain Services を使用することの主なメリットは以下のとおりです。
- Microsoft Entra Domain Services はスタンドアロン ドメインです。 そのため、オンプレミスと Azure の間でネットワーク接続を設定する必要はありません。
- デプロイと管理のエクスペリエンスが簡素化されます。
以下のシナリオでは、Microsoft Entra Domain Services を使用してください。
- AD DS をオンプレミスから Azure へと拡張して、Azure NetApp Files リソースへのアクセスを提供する必要がない。
- セキュリティ ポリシーにより、オンプレミスの AD DS を Azure へと拡張することができない。
- AD DS に関する十分な知識がない。 Microsoft Entra Domain Services を使用するほうが、Azure NetApp Files の利用による成果が上がりやすいと考えられます。
Azure NetApp Files で Microsoft Entra Domain Services を使用する場合は、Microsoft Entra Domain Services のドキュメントで、アーキテクチャ、デプロイ、管理のガイダンスを参照してください。 Azure NetApp Files のネットワークおよび DNS 要件を満たしていることも確認してください。
Azure NetApp Files で使用する AD DS サイト トポロジを設計する
Azure NetApp Files の SMB、デュアル プロトコル、または NFSv4.1 Kerberos ボリュームを使用するソリューション アーキテクチャでは、AD DS サイト トポロジを適切に設計することが不可欠です。
AD DS サイトのトポロジや構成が正しくないと、次の動作が発生する可能性があります。
- Azure NetApp Files の SMB、デュアル プロトコル、または NFSv4.1 Kerberos ボリュームを作成できない
- ANF AD 接続構成を変更できない
- LDAP クライアント クエリのパフォーマンスが低い
- 認証の問題
Azure NetApp Files 用の AD DS サイト トポロジは、Azure NetApp Files ネットワークの論理表現です。 Azure NetApp Files 用の AD DS サイト トポロジを設計するには、ドメイン コントローラーの配置を計画し、サイト、DNS インフラストラクチャ、ネットワーク サブネットの設計を行って、Azure NetApp Files サービス、Azure NetApp Files ストレージ クライアント、AD DS ドメイン コントローラー間の良好な接続を確保する必要があります。
Azure NetApp Files AD サイト名で構成された AD DS サイトに割り当てられた複数のドメイン コントローラーに加えて、Azure NetApp Files AD DS サイトには 1 つ以上のサブネットを割り当てることができます。
Note
Azure NetApp Files AD DS サイトに割り当てるすべてのドメイン コントローラーとサブネットは、適切に接続され (RTT 待機時間が 10 ミリ秒未満)、Azure NetApp Files ボリュームで使用されるネットワーク インターフェイスから到達可能である必要があります。
Standard ネットワーク機能を使用している場合は、ユーザー定義ルート (UDR) またはネットワーク セキュリティ グループ (NSG) 規則によって、Azure NetApp Files と Azure NetApp Files AD DS サイトに割り当てられている AD DS ドメイン コントローラーとのネットワーク通信がブロックされないようにする必要があります。
ネットワーク仮想アプライアンスまたはファイアウォール (Palo Alto Networks や Fortinet ファイアウォールなど) を使用している場合は、Azure NetApp Files と、Azure NetApp Files AD DS サイトに割り当てられている AD DS ドメイン コントローラーやサブネット間のネットワーク トラフィックがブロックされないように構成する必要があります。
Azure NetApp Files での AD DS サイト情報の使用
Azure NetApp Files では、認証、ドメイン参加、LDAP クエリ、Kerberos チケット操作をサポートするためのドメイン コントローラーを検出するために、Active Directory 接続で構成された AD サイト名が使用されます。
AD DS ドメイン コントローラーの検出
Azure NetApp Files では、4 時間ごとにドメイン コントローラーの検出が開始されます。 Azure NetApp Files は、サイト固有の DNS サービス リソース (SRV) レコードに対してクエリを実行して、Azure NetApp Files AD 接続の AD サイト名フィールドに指定された AD DS サイト内に、どのドメイン コントローラーがあるかを特定します。 Azure NetApp Files ドメイン コントローラーのサーバーの検出は、ドメイン コントローラーでホストされているサービス (Kerberos、LDAP、Net Logon、LSA) の状態を確認し、認証要求に最適なドメイン コントローラーを選択します。
Azure NetApp Files AD 接続の [AD サイト名] フィールドで指定された AD DS サイトの DNS SRV レコードには、Azure NetApp Files が使用する AD DS ドメイン コントローラーの IP アドレスの一覧が含まれている必要があります。 DNS SRV レコードの有効性は、nslookup
ユーティリティを使用して確認できます。
Note
Azure NetApp Files によって使用される AD DS サイト内のドメイン コントローラーに変更を加える場合は、新しい AD DS ドメイン コントローラーをデプロイしてから既存の AD DS ドメイン コントローラーを廃止するまで、少なくとも 4 時間待機してください。 この待機時間により、Azure NetApp Files が新しい AD DS ドメイン コントローラーを検出できるようになります。
廃止された AD DS ドメイン コントローラーに関連付けられている古い DNS レコードが DNS から削除されていることを確認してください。 これにより、Azure NetApp Files が廃止されたドメイン コントローラーとの通信を試行しなくなります。
AD DS LDAP サーバーの検出
Azure NetApp Files NFS ボリュームに対して LDAP が有効になっている場合は、AD DS LDAP サーバーの個別の検出プロセスが発生します。 Azure NetApp Files で LDAP クライアントが作成されると、Azure NetApp Files は AD DS SRV レコードに対してクエリを実行する際、AD 接続で指定した AD DS サイトに割り当てられた AD DS LDAP サーバーではなく、ドメイン内のすべての AD DS LDAP サーバーの一覧を照会します。
大規模または複雑な AD DS トポロジでは、AD 接続で指定された AD DS サイトに割り当てられている AD DS LDAP サーバーが確実に返されるようにするために、DNS ポリシーまたは DNS サブネットの優先順位付けの実装が必要になる場合があります。
または、LDAP クライアント用に最大 2 つの優先 AD サーバーを指定し、AD DS LDAP サーバー検出プロセスをオーバーライドすることもできます。
重要
Azure NetApp Files LDAP クライアントの作成時、検出された AD DS LDAP サーバーに Azure NetApp Files が到達できない場合は、LDAP 対応ボリュームの作成が失敗します。
AD サイト名の構成が正しくないか不完全な場合の結果
AD DS サイトのトポロジや構成が正しくないか不完全な場合、ボリュームの作成エラー、クライアント クエリの問題、認証エラー、Azure NetApp Files AD 接続の変更エラーが発生する可能性があります。
重要
Azure NetApp Files AD 接続を作成するには、[AD サイト名] フィールドは必須です。 定義する AD DS サイトは、存在し、適切に構成されている必要があります。
Azure NetApp Files は、AD DS サイトを使って、AD サイト名で定義されている AD DS サイトに割り当てられているドメイン コントローラーとサブネットを検出します。 AD DS サイトに割り当てられているすべてのドメイン コントローラーは、ANF によって使われる Azure 仮想ネットワーク インターフェイスからのネットワーク接続が良好で、到達可能である必要があります。 Azure NetApp Files が使用する AD DS サイトに割り当てられた AD DS ドメイン コントローラー VM は、VM をシャットダウンするコスト管理ポリシーから除外する必要があります。
Azure NetApp Files が AD DS サイトに割り当てられているドメイン コントローラーに到達できない場合、ドメイン コントローラー検出プロセスにより、AD DS ドメインに対してすべてのドメイン コントローラーの一覧を取得するクエリが実行されます。 このクエリから返されるドメイン コントローラーのリストは、順序なしのリストです。 その結果、Azure NetApp Files は到達可能でない、または適切に接続されていないドメイン コントローラーを使用しようとすることがあり、これによってボリューム作成の失敗、クライアント クエリの問題、認証の失敗、および Azure NetApp Files の AD 接続の修正に失敗することがあります。
Azure NetApp Files AD 接続によって使われる AD DS サイトに割り当てられたサブネットに、新しいドメイン コントローラーがデプロイされるたびに、AD DS サイトの構成を更新する必要があります。 Azure NetApp Files によって使われる AD DS サイトに割り当てられたドメイン コントローラーに対する変更が、サイトの DNS SRV レコードに反映されていることを確認します。 DNS SRV リソース レコードの有効性は、nslookup
ユーティリティを使用して確認できます。
Note
Azure NetApp Files は、AD DS の読み取り専用ドメイン コントローラー (RODC) の使用をサポートしていません。 Azure NetApp Files で RODC が使用されないようにするには、RODC との AD 接続の AD サイト名フィールドを構成しないようにしてください。 書き込み可能なドメイン コントローラーはサポートされており、Azure NetApp Files ボリュームでの認証に必要です。 詳細については、「Active Directory のレプリケーションの概念」をご覧ください。
Azure NetApp Files 用の AD DS サイト トポロジ構成のサンプル
AD DS サイト トポロジは、Azure NetApp Files がデプロイされているネットワークの論理的な表現です。 このセクションでは、AD DS サイト トポロジのサンプル構成シナリオで、Azure NetApp Files の基本的な AD DS サイト デザインを示します。 これは、Azure NetApp Files のネットワークや AD サイト トポロジを設計する唯一の方法ではありません。
重要
複雑な AD DS や複雑なネットワーク トポロジを使用する場合は、Azure NetApp Files のネットワークと AD サイトの設計について、Microsoft Azure クラウド ソリューション アーキテクト (CSA) のレビューを受けるようにしてください。
次の図は、例となるネットワーク トポロジを示しています。
サンプル ネットワーク トポロジでは、オンプレミスの AD DS ドメイン (anf.local
) が Azure 仮想ネットワークに拡張されています。 オンプレミス ネットワークは、Azure ExpressRoute 回線を使用して Azure 仮想ネットワークに接続されています。
Azure 仮想ネットワークには、ゲートウェイ サブネット、Azure Bastion サブネット、AD DS サブネット、Azure NetApp Files 委任サブネットの 4 つのサブネットがあります。 anf.local
ドメインに参加している冗長 AD DS ドメイン コントローラーは、AD DS サブネットにデプロイされています。 AD DS サブネットには、IP アドレス範囲 10.0.0.0/24 が割り当てられています。
Azure NetApp Files では、認証、LDAP クエリ、および Kerberos に使用されるドメイン コントローラーを決定するのに、1 つの AD DS サイトのみを使用できます。 サンプル シナリオでは、2 つのサブネット オブジェクトが作成され、Active Directory サイトとサービス ユーティリティを使用して呼び出された ANF
サイトに割り当てられます。 一方のサブネット オブジェクトは AD DS サブネット 10.0.0.0/24 にマップされ、もう一方のサブネット オブジェクトは ANF 委任サブネット (10.0.2.0/24) にマップされます。
Active Directory サイトとサービス ツールで、AD DS サブネットにデプロイされた AD DS ドメイン コントローラーが ANF
サイトに割り当てられていることを確認してください。
割り当てられていない場合は、Azure 仮想ネットワーク内の AD DS サブネットにマップされるサブネット オブジェクトを作成します。 Active Directory Sites and Services ユーティリティで [サブネット] コンテナーを右クリックし、[新しいサブネット...] を選択します。[新しいオブジェクト - サブネット] ダイアログで、AD DS サブネットの IP アドレス範囲 10.0.0.0/24 が [プレフィックス] フィールドに入力されます。 サブネットのサイト オブジェクトとして ANF
を選択します。 [OK] を選択してサブネット オブジェクトを作成し、ANF
サイトに割り当てます。
新しいサブネット オブジェクトが正しいサイトに割り当てられていることを確認するには、サブネット オブジェクト 10.0.0.0/24 を右クリックし、[プロパティ] を選択します。 [サイト] フィールドに ANF
サイト オブジェクトが表示されます。
Azure 仮想ネットワーク内の Azure NetApp Files 委任サブネットにマップするサブネット オブジェクトを作成するには、Active Directory サイトとサービス ユーティリティで [サブネット] コンテナーを右クリックし、[新しいサブネット...] を選択します。
リージョン間レプリケーションに関する考慮事項
Azure NetApp Files リージョン間レプリケーションを使用すると、あるリージョンから別のリージョンに Azure NetApp Files ボリュームをレプリケートして、ビジネス継続性とディザスター リカバリー (BC/DR) の要件をサポートできます。
Azure NetApp Files の SMB、デュアル プロトコル、および NFSv4.1 Kerberos ボリュームでは、リージョン間レプリケーションがサポートされます。 これらのボリュームのレプリケーションには、次のものが必要です。
- ソース リージョンと宛先リージョンの両方に作成された NetApp アカウント。
- ソース リージョンと宛先リージョンに作成された NetApp アカウントでの Azure NetApp Files Active Directory 接続。
- AD DS ドメイン コントローラーがデプロイされ、宛先リージョンで実行されている。
- Azure NetApp Files が宛先リージョン内の AD DS ドメイン コントローラーと良好にネットワーク通信できるようにするために、Azure NetApp Files ネットワーク、DNS、および AD DS サイト デザインを宛先リージョンに適切にデプロイする必要がある。
- 宛先リージョンの Active Directory 接続が、宛先リージョンの DNS リソースと AD サイト リソースを使用するように構成されている必要がある。