セルフマネージド Active Directory Domain Services、Microsoft Entra ID、マネージド Microsoft Entra Domain Services を比較する

アプリケーション、サービス、またはデバイスから、集中管理された ID にアクセスできるようにするには、Azure の Active Directory ベースのサービスを使用する一般的な方法が 3 つあります。 この中から ID ソリューションを選択すると、組織のニーズに最も適したディレクトリを柔軟に使用できます。 たとえば、モバイル デバイスを実行するクラウドのみを使用するユーザーを主に管理している場合、ご自分の Active Directory Domain Services (AD DS) の ID ソリューションを独自に構築して実行しても意味がない可能性があります。 代わりに、単に Microsoft Entra ID を使用できます。

Active Directory ベースのこの 3 つの ID ソリューションは、共通の名前とテクノロジを共有しますが、顧客の異なる要求に対応するサービスが提供されるように設計されています。 これらの ID ソリューションと機能セットの概要は、次のとおりです。

  • Active Directory Domain Services (AD DS) - ID と認証、コンピューター オブジェクトの管理、グループ ポリシー、信頼などの主要な機能が提供されるエンタープライズ対応のライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバー。
  • Microsoft Entra ID - Microsoft 365、Microsoft Entra 管理センター、SaaS アプリケーションなどのリソースに対して、ユーザー アカウントと認証のサービスを提供するクラウドベースの ID およびモバイル デバイス管理。
    • Microsoft Entra ID をオンプレミスの AD DS 環境と同期させて、クラウドでネイティブに機能する単一の ID をユーザーに提供できます。
    • Microsoft Entra ID の詳細については、「Microsoft Entra ID とは」を参照してください。
  • Microsoft Entra Domain Services - 完全に互換性のある従来の AD DS 機能のサブセット (ドメイン参加、グループ ポリシー、LDAP、Kerberos/NTLM 認証など) を使用してマネージド ドメイン サービスが提供されます。
    • Domain Services は Microsoft Entra ID と統合され、それ自体でオンプレミスの AD DS 環境と同期することができます。 この機能により、ID の一元管理のユース ケースを、リフト アンド シフト戦略の一部として Azure で実行される従来の Web アプリケーションに拡張することができます。
    • Microsoft Entra ID およびオンプレミスとの同期の詳細については、マネージド ドメイン内でのオブジェクトと資格情報の同期のしくみに関するページを参照してください。

この概要記事では、組織のニーズに応じて、これらの ID ソリューションを連携させる場合と個別に使用する場合を比較対比します。

Domain Services と自己管理型 AD DS

Kerberos や NTLM などの従来の認証メカニズムにアクセスする必要があるアプリケーションおよびサービスを使用している場合、クラウドで Active Directory Domain Services を提供するには、次の 2 つの方法があります。

  • "マネージド ドメイン"。Microsoft Entra Domain Services を使用して作成します。 Microsoft が、必要なリソースの作成と管理を行います。
  • "自己管理型" ドメイン: 仮想マシン (VM)、Windows Server ゲスト OS、Active Directory Domain Services (Azure AD DS) などの従来のリソースを使用して、作成および構成します。 管理者が引き続き、これらのリソースを管理します。

Domain Services では、管理者に代わって Microsoft がコア サービス コンポーネントを "マネージド" ドメイン エクスペリエンスとしてデプロイし、管理します。 管理者は、VM、Windows Server OS、ドメイン コントローラー (DC) などのコンポーネント用 AD DS インフラストラクチャのデプロイ、管理、修正プログラムの適用、セキュリティ保護は行いません。

Domain Services では、機能のより小さいサブセットが従来の自己管理型 AD DS 環境に提供され、設計と管理の複雑さの一部が軽減されます。 たとえば、設計および保守すべき AD フォレスト、ドメイン、サイト、レプリケート リンクはありません。 それでも Domain Services とオンプレミス環境の間にフォレストの信頼を作成することができます。

アプリケーションおよびサービスがクラウドで実行され、Kerberos や NTLM などの従来の認証メカニズムにアクセスする必要がある場合、Domain Services では、管理オーバーヘッドを最小限に抑えたマネージド ドメイン エクスペリエンスが提供されます。 詳細については、Domain Services でのユーザー アカウント、パスワード、および管理の管理の概念に関するページを参照してください。

自己管理型 AD DS 環境をデプロイして実行する場合、関連するすべてのインフラストラクチャとディレクトリ コンポーネントを保守する必要があります。 自己管理型 AD DS 環境では、追加の保守オーバーヘッドが発生しますが、スキーマの拡張やフォレストの信頼の作成などの追加タスクを実行できます。

クラウド内のアプリケーションおよびサービスに ID を提供する自己管理型 AD DS 環境の一般的なデプロイ モデルには、次のものがあります。

  • スタンドアロンのクラウド専用 AD DS: Azure VM はドメイン コントローラーとして構成され、個別のクラウド専用 AD DS 環境が作成されます。 この AD DS 環境は、オンプレミスの AD DS 環境と統合されません。 クラウド内の VM にサインインして管理するために、別の資格情報セットを使用します。
  • オンプレミスのドメインを Azure に拡張: VPN/ExpressRoute 接続を使用して、オンプレミスのネットワークに Azure 仮想ネットワークを接続します。 Azure VM をこの Azure 仮想ネットワークに接続して、オンプレミスの AD DS 環境にドメイン参加させます。
    • 別の方法として、Azure VM を作成し、オンプレミスの AD DS ドメインからレプリカ ドメイン コントローラーとして昇格させます。 これらのドメイン コントローラーは、オンプレミスの AD DS 環境への VPN/ExpressRoute 接続経由でレプリケートされます。 オンプレミスの AD DS ドメインは、Azure に効果的に拡張されます。

次の表では、組織に必要となる可能性のあるいくつかの機能、マネージド ドメインと自己管理型の AD DS ドメインの違いについての概要を示します。

機能 マネージド ドメイン 自己管理型 AD DS
マネージド サービス
安全なデプロイ 管理者がデプロイをセキュリティ保護
DNS サーバー (管理サービス)
ドメインまたはエンタープライズ管理者の特権
ドメイン参加
NTLM と Kerberos を使用するドメイン認証
Kerberos の制約付き委任 リソースベース リソースベースとアカウントベース
カスタムの OU 構造
グループ ポリシー
スキーマの拡張機能
AD ドメイン/フォレストの信頼 (一方向の出力方向フォレスト信頼のみ)
Secure LDAP (LDAPS)
LDAP の読み取り
LDAP の書き込み (マネージド ドメイン内)
地理的に分散したデプロイ

Domain Services と Microsoft Entra ID

Microsoft Entra ID を使用することにより、組織で使用されているデバイスの ID を管理して、これらのデバイスからの企業リソースへのアクセスを制御できます。 ユーザーは、個人のデバイスを Microsoft Entra ID に登録 (Bring Your Own (BYO) モデル) することも可能です。これにより、デバイスに ID が提供されます。 その後、ユーザーが Microsoft Entra ID にサインインし、デバイスを使用してセキュリティで保護されたリソースにアクセスすると、Microsoft Entra ID でデバイスが認証されます。 デバイスは、Microsoft Intune などのモバイル デバイス管理 (MDM) ソフトウェアを使用して管理できます。 この管理機能を使用すると、機密性の高いリソースへのアクセスを、管理対象デバイスとポリシーに準拠しているデバイスに制限できます。

従来のコンピューターおよびノート PC も Microsoft Entra ID に参加できます。 このメカニズムには、個人用デバイスを Microsoft Entra ID に登録する場合と同じメリットがあります。たとえば、ユーザーは会社の資格情報を使用してデバイスにサインインできます。

Microsoft Entra に参加しているデバイスには、次のような利点があります。

  • Microsoft Entra ID によってセキュリティ保護されたアプリケーションに対するシングル サインオン (SSO)。
  • デバイス間でのユーザー設定の企業ポリシーに準拠しているローミング
  • 会社の資格情報を使用したビジネス向け Windows ストアへのアクセス
  • Windows Hello for Business
  • 企業のポリシーに準拠しているデバイスからアプリおよびリソースへのアクセス制限

オンプレミスの AD DS 環境を含むハイブリッド デプロイの有無に関係なく、デバイスを Microsoft Entra ID に参加させることができます。 次の表は、一般的なデバイスの所有権モデルと、それらをドメインに参加させる通常の方法について概要を示します。

デバイスの種類 デバイス プラットフォーム メカニズム
個人用デバイス Windows 10、iOS、Android、macOS Microsoft Entra 登録済み
オンプレミスの AD DS に参加していない組織所有デバイス Windows 10 Microsoft Entra 参加済み
オンプレミスの AD DS に参加している組織所有デバイス Windows 10 Microsoft Entra ハイブリッド参加済み

Microsoft Entra に参加または登録しているデバイスでは、最新の OAuth/OpenID Connect ベースのプロトコルを使用して、ユーザー認証が行われます。 これらのプロトコルは、インターネット経由で動作するように設計されているため、ユーザーが会社のリソースにどこからでもアクセスするモバイル シナリオに最適です。

Domain Services に参加しているデバイスでは、アプリケーションは認証に Kerberos および NTLM プロトコルを使用できます。このため、リフト アンド シフト戦略の一環として Azure VM に移行され、そこで実行されるレガシ アプリケーションをサポートできます。 次の表は、デバイスの表現方法の違いと、ディレクトリに対してデバイス自体を認証できる方法の違いについて概要を示します。

特徴 Microsoft Entra 参加済み Domain Services 参加済み
デバイスの制御 Microsoft Entra ID Domain Services のマネージド ドメイン
ディレクトリ内の表現 Microsoft Entra ディレクトリ内のデバイス オブジェクト Domain Services マネージド ドメイン内のコンピューター オブジェクト
認証 OAuth/OpenID Connect ベースのプロトコル Kerberos および NTLM プロトコル
管理 Intune などのモバイル デバイス管理 (MDM) ソフトウェア グループ ポリシー
ネットワーク インターネット経由で動作 マネージド ドメインがデプロイされている仮想ネットワークに接続されているか、ピアリングされている必要があります
最適な対象 エンドユーザーのモバイルまたはデスクトップ デバイス Azure にデプロイされるサーバー VM

オンプレミスの AD DS と Microsoft Entra ID が、AD FS を使用したフェデレーション認証用に構成されている場合、Azure DS で使用できる (現在の、または有効な) パスワード ハッシュはありません。 フェデレーション認証が実装される前に作成された Microsoft Entra ユーザー アカウントには古いパスワード ハッシュがある可能性がありますが、これはオンプレミスのパスワードのハッシュと一致しないと考えられます。 その結果、Domain Services はユーザーの資格情報を検証できません。

次のステップ

Domain Services を使用して作業を開始するには、Microsoft Entra 管理センターを使用して Domain Services マネージド ドメインを作成します

また、Domain Services でのユーザー アカウント、パスワード、および管理の管理の概念およびマネージド ドメインでのオブジェクトと資格情報の同期のしくみについても学習できます。