Azure Active Directory Domain Services のリソース フォレストの概念と機能

Azure Active Directory Domain Services (Azure AD DS) により、従来のオンプレミス基幹業務アプリケーションにサインイン エクスペリエンスが提供されます。 オンプレミスとクラウドのユーザーを対象に、ユーザー、グループ、およびパスワード ハッシュが Azure AD DS マネージド ドメインに同期されます。 これらの同期されたパスワード ハッシュは、オンプレミスの AD DS、Microsoft 365、Azure Active Directory に使用できる資格情報の単一セットをユーザーに提供するものです。

セキュリティが確保され、セキュリティ上の追加の利点もありますが、一部の組織では、これらのユーザー パスワード ハッシュを Azure AD または Azure AD DS に同期できません。 組織内のユーザーは、スマート カード認証のみを使用しているために、パスワードを知らない場合があります。 これらの制限により、一部の組織では、Azure AD DS を使用してオンプレミスのクラシック アプリケーションを Azure にリフト アンド シフトすることができません。

このようなニーズと制限に対処するために、リソース フォレストを使用するマネージド ドメインを作成できます。 概念に関するこの記事では、フォレストの概要と、セキュリティで保護された認証方法を提供するためにフォレストで他のリソースを信頼する方法について説明します。

フォレストとは

"フォレスト" は、Active Directory Domain Services (AD DS) で 1 つまたは複数の "ドメイン" をグループ化するために使われる論理構造です。 ドメインには、ユーザーまたはグループのオブジェクトが格納され、認証サービスが提供されます。

Azure AD DS マネージド ドメインでは、フォレストにはドメインが 1 つだけ含まれます。 多くの場合、オンプレミスの AD DS フォレストには多数のドメインが含まれます。 大規模な組織では、特に合併や買収の後に、複数のオンプレミス フォレストが存在し、各フォレストにそれぞれ複数のドメインが含まれている場合があります。

既定では、マネージド ドメインは "ユーザー" フォレストとして作成されます。 このタイプのフォレストでは、オンプレミスの AD DS 環境で作成されたユーザー アカウントも含め、Azure AD 内のすべてのオブジェクトが同期されます。 ドメインに参加している VM へのサインインなどのために、マネージド ドメインに対してユーザー アカウントを直接認証できます。 ユーザー フォレストが機能するのは、パスワード ハッシュの同期が可能で、ユーザーがスマート カード認証などの専用サインイン方法を使用していない場合です。

マネージド ドメインの "リソース" フォレストでは、ユーザーは自身のオンプレミス AD DS からの、一方向のフォレストの "信頼" を介して認証されます。 この方法では、ユーザー オブジェクトとパスワード ハッシュはマネージド ドメインに同期されません。 ユーザー オブジェクトと資格情報は、オンプレミスの AD DS にのみ存在します。 このアプローチを使用すると、企業は、LDAPS、Kerberos、NTLM などの従来の認証に依存するリソースとアプリケーション プラットフォームを Azure でホストでき、一方で認証に関する問題や懸念事項が取り除かれます。

リソース フォレストには、アプリケーションを一度に 1 コンポーネントずつリフトアンドシフトする機能も用意されています。 多くのレガシ オンプレミス アプリケーションは、Web サーバーやフロント エンド、および多数のデータベース関連コンポーネントを使用して多階層化されていることがよくあります。 これらの層によって、アプリケーション全体を 1 回の手順でリフトアンドシフトすることが困難になります。 リソース フォレストを使用すると、アプリケーションを段階的にクラウドにリフトできるため、アプリケーションを Azure に移行しやすくなります。

信頼とは

複数のドメインを持つ組織では、多くの場合、ユーザーが別のドメインの共有リソースにアクセスする必要があります。 これらの共有リソースへのアクセスのためには、あるドメインのユーザーを別のドメインに対して認証することが必要になります。 異なるドメインにあるクライアントとサーバーの間でこのような認証と承認の機能を提供するには、2 つのドメイン間に "信頼" がなければなりません。

ドメインの信頼を使用することで、各ドメインの認証メカニズムに他のドメインからの認証を信頼させることができます。 信頼は、受信認証要求が信頼されている機関 (信頼される 側のドメイン) からのものであることを確認することによって、リソース ドメイン (信頼する 側のドメイン) 内の共有リソースへのアクセスを制御するのに役立ちます。 信頼は、検証済みの認証要求のみがドメイン間を移動できるようにするブリッジとして機能します。

信頼によって認証要求が渡される方法は、信頼がどのように構成されているかによって異なります。 信頼は、次のいずれかの方法で構成できます。

  • 一方向 - 信頼される側のドメインから信頼する側のドメイン内のリソースへのアクセスを提供します。
  • 双方向 - 各ドメインからもう一方のドメイン内のリソースへのアクセスを提供します。

信頼は、次のいずれかの方法で追加の信頼関係を処理するように構成することもできます。

  • 非推移的 - 信頼は、2 つの信頼関係パートナー ドメイン間にのみ存在します。
  • 推移的 - 信頼は、どちらか一方のパートナーが信頼している他のすべてのドメインに自動的に拡張されます。

場合によっては、ドメインの作成時に信頼関係が自動的に確立されます。 その他の場合、信頼の種類を選択し、適切な関係を明示的に設定する必要があります。 使用される特定の信頼の種類と、それらの信頼関係の構造は、AD DS ディレクトリがどのように構成されているか、および異なるバージョンの Windows がネットワークに共存しているかどうかによって異なります。

2 つのフォレスト間の信頼

一方向または双方向のフォレストの信頼を手動で作成することで、1 つのフォレスト内のドメインの信頼を別のフォレストに拡張できます。 フォレストの信頼は、あるフォレストのルート ドメインと、2 番目のフォレストのルート ドメインとの間にのみ存在する推移的な信頼関係です。

  • 一方向のフォレストの信頼では、一方のフォレスト内のすべてのユーザーが、もう一方のフォレスト内のすべてのドメインを信頼できます。
  • 双方向のフォレストの信頼では、両方のフォレスト内のすべてのドメイン間に推移的な信頼関係が形成されます。

フォレストの信頼の推移性は、2 つのフォレスト パートナーに限定されます。 フォレストの信頼は、いずれか一方のパートナーによって信頼されている追加のフォレストには拡張されません。

Azure AD DS からオンプレミスの AD DS へのフォレストの信頼の図

組織の AD DS 構造に応じて、ドメインとフォレストのさまざまな信頼構成を作成できます。 Azure AD DS では、一方向のフォレストの信頼のみがサポートされています。 この構成では、マネージド ドメイン内のリソースから、オンプレミス フォレスト内のすべてのドメインへの信頼を確立できます。

信頼をサポートする技術

信頼により、DNS などのさまざまなサービスや機能を使用して、パートナーのフォレスト内のドメイン コントローラーが特定されます。 また、信頼は、NTLM および Kerberos 認証プロトコルと、Windows ベースの承認およびアクセス制御メカニズムに依存しており、AD DS ドメインとフォレストの間でセキュリティで保護された通信インフラストラクチャを実現するのに役立ちます。 次のサービスと機能は、効果的な信頼関係をサポートするのに役立ちます。

DNS

AD DS には、ドメイン コントローラー (DC) の場所と名前付け用に DNS が必要です。 AD DS が正常に機能するように、DNS から次のサポートが提供されます。

  • 名前解決サービス。これにより、ネットワーク ホストとサービスによる DC の検出が可能になります。
  • 名前付け構造。これにより、企業はディレクトリ サービス ドメインの名前に組織の構造を反映できます。

通常、DNS ドメイン名前空間は、AD DS ドメイン名前空間を反映するようにデプロイされます。 AD DS デプロイの前に既存の DNS 名前空間がある場合は、通常、DNS 名前空間は AD DS 用にパーティション分割され、AD DS フォレスト ルートの DNS サブドメインと委任が作成されます。 その後、AD DS の子ドメインそれぞれに別の DNS ドメイン名が追加されます。

DNS は、AD DS DC の場所をサポートするためにも使用されます。 DNS ゾーンには、ネットワーク ホストとサービスによる AD DS DC 検出を可能にする DNS リソース レコードが設定されます。

アプリケーションと Net Logon

アプリケーションと Net Logon サービスはどちらも、Windows 分散セキュリティ チャネル モデルのコンポーネントです。 Windows Server および AD DS と統合されたアプリケーションでは、認証プロトコルを使用して Net Logon サービスと通信することで、認証を行うことができるセキュリティで保護されたパスを確立できるようになります。

認証プロトコル

AD DS DC により、次のプロトコルのいずれかを使用してユーザーとアプリケーションが認証されます。

  • Kerberos バージョン 5 認証プロトコル

    • Kerberos バージョン 5 プロトコルは、Windows を実行しているオンプレミスのコンピューターで使用される既定の認証プロトコルであり、サードパーティのオペレーティング システムをサポートしています。 このプロトコルは RFC 1510 で規定されており、AD DS、サーバー メッセージ ブロック (SMB)、HTTP、リモート プロシージャ コール (RPC) と完全に統合されるだけでなく、これらのプロトコルを使用するクライアント アプリケーションおよびサーバー アプリケーションとも完全に統合されます。
    • Kerberos プロトコルが使用されている場合、サーバーと DC の通信は必要ありません。 代わりに、クライアントからサーバー アカウント ドメイン内の DC にチケットを要求することによって、サーバーのチケットを取得します。 その後、サーバーによってチケットが検証されます。このとき、他の機関への確認は行われません。
    • トランザクションに関係しているコンピューターで Kerberos バージョン 5 プロトコルがサポートされていない場合は、NTLM プロトコルが使用されます。
  • NTLM 認証プロトコル

    • NTLM プロトコルは、以前のオペレーティング システムで使用されていた従来のネットワーク認証プロトコルです。 互換性の理由により、それは、AD DS ドメインによって、以前の Windows ベースのクライアントとサーバー、およびサードパーティのオペレーティング システム用に設計されたアプリケーションからのネットワーク認証要求を処理するために使用されます。
    • クライアントとサーバーの間で NTLM プロトコルを使用する場合、サーバーが DC 上のドメイン認証サービスと通信し、クライアントの資格情報を確認することが必要になります。 サーバーからクライアント アカウント ドメイン内の DC にクライアントの資格情報を転送することによって、クライアントが認証されます。
    • 2 つの AD DS ドメインまたはフォレストが信頼によって接続されている場合、これらのプロトコルを使用して行われた認証要求をルーティングして、両方のフォレスト内のリソースへのアクセスを提供することができます。

承認とアクセス制御

承認と信頼のテクノロジが連携することにより、AD DS ドメインまたはフォレスト間にセキュリティで保護された通信インフラストラクチャが提供されます。 承認とは、ユーザーがドメイン内のリソースに対して持つアクセス レベルを確認することです。 信頼を使用すると、他のドメインのユーザーを認証するためのパスを提供し、それらのドメイン内の共有リソースへのユーザーの要求を承認できるようにすることで、ドメイン間のユーザー認証が容易になります。

信頼する側のドメインで行われた認証要求が、信頼される側のドメインによって検証されると、その要求はターゲット リソースに渡されます。 次に、信頼される側のドメイン内のユーザー、サービス、またはコンピューターによって行われた特定の要求を承認するかどうかが、ターゲット リソースによって (そのリソースのアクセス制御の構成に基づいて) 確認されます。

信頼によって、信頼する側のドメインに渡される認証要求を検証するためのメカニズムが提供されます。 リソース コンピューターのアクセス制御メカニズムによって、信頼される側のドメイン内の要求元に許可される最終的なアクセス レベルが決まります。

次のステップ

信頼の詳細については、Azure AD DS でのフォレストの信頼のしくみに関するページを参照してください。

リソース フォレストを使用するマネージド ドメインの作成を開始するには、Azure AD DS マネージド ドメインの作成と構成に関するページを参照してください。 その後、オンプレミス ドメインに対して出力方向のフォレストの信頼を作成できます。