レガシーアプリのAzure移行: Microsoft Entra Domain Services と IaaS ドメインコントローラーの使い分け

By Mirko Peters · 2026-08-14

Azure における Microsoft Entra Domain Services と IaaS ドメインコントローラーを比較します。レガシーアプリを移行する際のアーキテクチャ上のトレードオフを解説します。

Automatically translated with AI from the original post. Read the English original

Windows レガシーアプリを Azure にリフト アンド シフトする際、アーキテクトは重大なID上の判断を迫られます。従来の Active Directory ドメインコントローラーの仮想マシンを展開するか、マネージド クラウド サービスを利用するかです。本ガイドでは、レガシー Azure ワークロードに対して、カスタム IaaS ドメインコントローラーではなく Microsoft Entra Domain Services を選択する場合の、アーキテクチャ上のトレードオフ、運用負荷、コストへの影響を解説します。

重要なポイント

• Microsoft Entra Domain Services は、IT チームがドメインコントローラーの仮想マシンを展開、パッチ適用、復旧することなく、従来の Windows ドメイン機能をマネージドサービスとして提供します。
• Azure に IaaS ドメインコントローラーを展開すると、RDP アクセスやドメイン管理者権限を含め、管理者が完全な制御を得られます。一方で、運用負荷は大幅に増加します。
• LDAP、Kerberos、NTLM、グループ ポリシーに依存するレガシーワークロードは、マネージド ドメインの互換性レイヤーを使用することで、Azure 上でそのまま動作させることができます。
• Entra Domain Services は、厳密な一方向のID同期モデルを採用しています。ユーザー レコードは、マネージド ドメインで直接管理するのではなく、信頼できる情報源で管理する必要があります。
• 適切なIDアーキテクチャの選択は、LDAP の書き込みアクセスやスキーマ変更など、アプリケーションの要件に大きく左右されます。

レガシー Azure 移行のジレンマ

オンプレミスのサーバールームから Azure の仮想マシンにレガシー業務アプリケーションを移しても、そのアプリケーションが自動的にクラウドネイティブになるわけではありません。レガシーなエンタープライズ リソース プランニング システム、財務プラットフォーム、カスタム .NET アプリケーションなど、多くの既存 Windows アプリケーションは従来の Active Directory を前提に設計されています。これらのワークロードをクラウドに移しても、LDAP でディレクトリ サービスに問い合わせ、Kerberos チケットで認証し、グループ ポリシーで設定を適用することを前提としています。

クラウド アーキテクトは、すぐに戦略的な判断を迫られます。ハイブリッド VPN トンネルを使って Azure 仮想ネットワークをオンプレミスのドメインコントローラーに接続する方法もあります。ただし、この構成では遅延が生じ、ネットワーク リンクが切断された場合に危険な単一障害点となります。あるいは、Azure 内に新しい Windows Server 仮想マシンを作成し、ドメインコントローラーに昇格させて、新しいフォレストまたはレプリカ ドメインを構築する方法もあります。

Azure でドメインコントローラーの仮想マシンを自前で構築すると、完全な制御を得られますが、同時にクラウド インフラストラクチャ チームが Active Directory の管理者にもなります。OS のパッチ適用、ディレクトリ レプリケーションの監視、災害復旧計画、特権の高いアカウントの資格情報窃取からの保護など、すべてに責任を負うことになります。レガシーアプリケーションを稼働させ続けながら運用負荷を抑えたい組織にとって、これは不必要な負担となることが少なくありません。

Entra Domain Services と IaaS ドメインコントローラーの比較: 主要なアーキテクチャの違い

Microsoft Entra Domain Services と IaaS ドメインコントローラーの構築の違いを理解することは、回復性の高い Azure クラウド環境を設計するうえで欠かせません。Entra Domain Services はマネージドの互換レイヤーとして機能します。基盤となるドメインコントローラーのインフラストラクチャは Microsoft が裏側で運用・保守し、高可用性、自動バックアップ、Entra ID とのバックグラウンド同期を確保します。

Entra Domain Services を利用すると、エンジニアがドメインコントローラーにリモート デスクトップで接続しなくても、Azure の仮想マシンをドメインに参加させ、LDAP クエリを実行し、Kerberos や NTLM によるサインインを処理できます。ただし、このマネージド サービスには代償があります。基盤となるオペレーティング システムにはアクセスできず、Active Directory スキーマを変更することもできず、ドメイン管理者やエンタープライズ管理者の権限も付与されません。

一方、IaaS ドメインコントローラーを展開すると、ディレクトリ アーキテクチャを完全に制御できます。スキーマを拡張したり、カスタムの信頼関係を構成したり、任意の組織単位を追加したり、特殊なグループ ポリシー オブジェクトを制限なく実装したりできます。この柔軟性の代償は運用の手間です。チームは、事前のヘルス チェック、データベースのデフラグ、ドメインコントローラーがクラッシュした場合の緊急復旧手順など、ドメインのライフサイクル全体を管理する必要があります。

運用上のトレードオフと管理上のガードレール

Azure でマネージド ドメインを採用する前に、クラウド管理者は日々の運用がどう変わるかを慎重に評価する必要があります。カスタムの IaaS ドメインコントローラーでは、ディレクトリのあらゆる側面をきめ細かく制御できます。管理タスクを自動化するカスタム PowerShell スクリプトを作成したり、サードパーティのセキュリティ エージェントをドメインコントローラーに直接インストールしたり、repadmin などのネイティブ ユーティリティでレプリケーション エラーをトラブルシューティングしたりできます。

Microsoft Entra Domain Services は、こうした直接的な運用方法をマネージドのガードレールに置き換えます。管理は Entra Domain Services Administrators という専用グループを通じて行い、ドメインに参加させた別の Windows 仮想マシンにインストールした管理ユーティリティを使用します。カスタムの組織単位の作成、DNS レコードの管理、サポートされているグループ ポリシー設定の適用はできますが、中核となるインフラストラクチャには厳密にアクセスできません。

さらに、ID 管理は厳密な一方向の同期モデルに従います。ユーザーとグループの ID は、信頼できる情報源（Entra ID のクラウドのみのユーザー、またはオンプレミスの Active Directory から同期された ID）からマネージド ドメインへ流れます。Entra Domain Services を主要なディレクトリとしてユーザー属性を変更することは避けてください。そうした変更は上位に同期されず、最終的には上書きされてしまいます。

意思決定の枠組み：適切なアーキテクチャの選択

適切な方法を選ぶには、組織固有の技術要件と長期的なクラウド戦略を評価する必要があります。主な目的がレガシー ワークロードの Azure への移行であり、ドメインコントローラーとして Windows Server 仮想マシンを運用する負担をなくしたいのであれば、ほぼ常にマネージド サービスが推奨されます。

次のような場合は Microsoft Entra Domain Services を使用します。

• LDAP の読み取り検索、Kerberos、NTLM、またはドメイン参加機能を必要とするレガシー アプリケーションを Azure に移行する場合。
• Azure 上のカスタム ドメインコントローラー仮想マシンのパッチ適用、監視、復旧に伴う負担を避けたい場合。
• クラウド ファーストまたはクラウドのみの組織で、オンプレミスの拠点を構築せずに、一部の Azure ワークロードに従来のドメイン サービスが必要な場合。
• アプリケーションが、安全な仮想ネットワーク内で標準的なグループ ポリシーの適用やサービス アカウントの管理を必要とする場合。

次のような場合は IaaS のカスタム ドメインコントローラーを選択します。

• レガシー アプリケーションが LDAP の書き込みアクセスを必要とする場合、または Active Directory スキーマの変更を求める場合。
• エンタープライズ アーキテクチャで、複雑なマルチドメイン フォレスト、カスタムの信頼構成、またはドメインコントローラーのオペレーティング システムへの直接アクセスが必要な場合。
• セキュリティ チームが、エンタープライズ管理者権限や専用のディレクトリ監査ツールの直接展開を含む、完全な管理制御を義務付けている場合。

まとめと次のステップ

Azure で堅牢な ID アーキテクチャを設計するには、ワークロードごとに必要な正確な認証モデルを合わせる必要があります。最新のクラウドアプリケーションは、安全なトークンベースのシングルサインオンと多要素認証のために Microsoft Entra ID を活用しますが、レガシーなワークロードでは従来の Windows ドメインサービスが必要になることが多くあります。マネージドのクラウドサービスを展開するか、独自の IaaS インフラストラクチャを構築するかの判断によって、チームの継続的な運用負荷が決まります。

このテーマをさらに掘り下げ、最新のワークプレース セキュリティ、クラウド アーキテクチャ、Microsoft 365 戦略についての専門家の見解を聞くには、ポッドキャストの完全版をお聴きください。エピソード全体を聴くと、Microsoft の ID 管理についてさらに詳しく理解できます。

よくある質問

Entra Domain Services を使用している場合、ドメインコントローラーに RDP で接続できますか?

いいえ。Microsoft が基盤となるドメインコントローラーのインフラストラクチャを完全に管理するため、ドメインコントローラーのオペレーティングシステムへの管理者アクセス権や、リモートデスクトップで接続する機能は提供されません。

Entra Domain Services を有効にすると、ユーザーのパスワードはどうなりますか?

Kerberos および NTLM 認証を成功させるには、Entra Domain Services で特殊なハッシュデータが必要です。クラウドのみのユーザーの場合、通常は、マネージドドメインを有効にした後にユーザーがパスワードを変更し、必要な暗号ハッシュを生成する必要があります。

Entra Domain Services で Active Directory スキーマを変更できますか?

いいえ。完全マネージドのクラウドサービスであるため、管理者は基盤となる Active Directory スキーマを変更したり、コアとなるディレクトリ構造を変更する LDAP 書き込み操作を実行したりすることはできません。

Entra Domain Services とのID同期はどのように行われますか?

ID は信頼できる唯一の情報源(クラウドユーザーの場合は Entra ID、または Entra Connect 経由のオンプレミス Active Directory)から、マネージドドメインへ一方向に流れます。マネージドドメイン内で直接行った変更は、上位のソースに同期されません。