Azure で Active Directory Domain Services を使用してディレクトリと ID サービスを実装するオプションを選択する

  • 7 分

Contoso は、AD DS を使用して、ユーザー、コンピューター、アプリケーション、およびその他のリソースを認証します。 Contoso は、基幹業務 (LOB) アプリケーションの一部をオンプレミスで、一部を Azure に実装することを計画しています。 IT スタッフは、Azure からオンプレミスに認証要求を送信する際に待機時間が発生する可能性があることを懸念しています。 その結果、この待機時間を短縮するために、Azure にディレクトリ サービスと ID サービスを実装することを検討しています。 Azure にドメイン コントローラーを配置するいくつかの理由として、次のようなものがあります。

  • オンプレミスのディレクトリに回復性を提供します。
  • Azure 環境内で Azure ベースのサービスの認証要求を維持します。
  • オンプレミスの AD DS から世界中のサイトにアクセスを拡張します。

概要

Azure VM に Active Directory ドメイン コントローラーをデプロイするプロセスは、オンプレミス環境にドメイン コントローラーをデプロイするプロセスと似ています。 主な違いの 1 つは、Azure でドメイン コントローラーをデプロイするときに、データベースが破損する可能性を回避するために、Azure VM のデータ ディスクに Active Directory データベースを配置する必要があることです。 Azure VM のオペレーティング システム ディスクの読み取りと書き込みのキャッシュ設定によって、データベースの破損が発生する可能性があります。 Azure には、Azure で AD DS を使用してディレクトリと ID サービスを実装するための複数のオプションが用意されています。 考慮事項と要件は、選択したデプロイ シナリオによって異なります。

Azure VM にのみ AD DS をデプロイする

このシナリオには VNet の作成が含まれますが、クロスプレミス接続は必要ありません。 通常、このデプロイは新しいフォレストで開始し、すべてのドメイン コントローラーは Azure VM 上でのみ実行されます。 このシナリオでは、ドメイン コントローラーの静的 IP アドレスを設定することを検討してください。 これは、次の場合に一般的なシナリオです。

  • Kerberos 認証に依存するが、オンプレミスのディレクトリ サービスに関連する要件を持たないアプリ。
  • 既存のオンプレミス AD DS 環境がない未開発のデプロイ。

オンプレミスのインフラストラクチャと Azure VM の両方に AD DS をデプロイする

このシナリオは、LDAP に対応し、Windows 統合認証をサポートするアプリに共通しています。 このシナリオでは、クロスプレミス接続を備えた VNet を作成し、クラウドで実行されている VM に適切な IP アドレスを割り当てる必要があります。

このシナリオの主なゴールは、受信トラフィック (イングレス) は無料でも送信トラフィック (エグレス) はそうでないことを考慮して、ソリューションのコストを最適化することです。 これは、Azure のシステムとアプリケーションは、認証、LDAP 参照、およびネーム サーバーの解決のために、Azure の AD DS ドメイン コントローラーを参照するためです。 このシナリオでは、クラウドベースのドメイン コントローラーに認証することで、アプリにアクセスするユーザーにより高速なパフォーマンスとより優れたサインイン エクスペリエンスが提供されます。

オンプレミスの環境と Azure VM に AD DS をデプロイする場合、次の表で説明するように、Azure でサポートされている複数のオプションがあります。

デプロイ オプション 説明
Azure VM に追加の AD DS ドメイン コントローラーをデプロイする アプリケーションの一部がオンプレミスでホストされ、一部が Azure でホストされる場合は、Azure で AD DS をレプリケートする方が効率的になる可能性があります。 これにより、クラウドからオンプレミスで実行されている AD DS に返される認証要求の送信が原因の待機時間を削減できます。 このアーキテクチャは、オンプレミス ネットワークと Azure 仮想ネットワークが仮想プライベート ネットワーク (VPN) または ExpressRoute によって接続されている場合によく使用されます。 このアーキテクチャでは、双方向のレプリケーションもサポートされています。つまり、オンプレミスまたはクラウドのいずれかで変更を行うことができ、両方のソースの整合性が維持されます。 このアーキテクチャの一般的な用途には、オンプレミスと Azure 間で機能が配布されるハイブリッド アプリケーション、および Active Directory を使用して認証を実行するアプリケーションとサービスがあります。
オンプレミスの Active Directory フォレスト内のドメインによって信頼されている別の AD フォレストまたはドメインを Azure にデプロイする AD DS は、ID 情報を階層構造で格納します。 階層構造の最上位ノードは "フォレスト" と呼ばれます。 1 つのフォレストには複数のドメインが含まれ、ドメインには他の種類のオブジェクトが含まれています。 この参照アーキテクチャには、オンプレミス ドメインと同じ AD フォレストのメンバーである AD DS ドメインを Azure に作成することが含まれます。 このシナリオでは、異なるドメイン間に信頼関係を作成する必要はありません。これは、同じフォレスト内のドメインが本質的に (自動的に) 互いに信頼関係を持つためです。 または、オンプレミス ドメインとの一方向の送信または双方向の信頼関係を持つように、Azure に AD DS フォレストを作成することもできます。 このシナリオでは、Azure のフォレストには、オンプレミスに存在しないドメインが含まれています。 信頼関係があるため、オンプレミス ドメインに対して行われたサインインは、別の Azure ドメイン内のリソースへのアクセスで信頼される場合があります。 このアーキテクチャは、クラウドで保持されているオブジェクトと ID のセキュリティ分離を維持しつつ、個々のドメインをオンプレミスからクラウドに移行する場合によく使用されます。