クラウドへの移行

Active Directory フットプリントの増加を停止することに向けて組織を調整したら、既存のオンプレミス ワークロードを Microsoft Entra ID に移行することに集中できます。 この記事ではさまざまな移行ワークストリームについて説明します。 この記事のワークストリームは、ユーザーの優先順位とリソースに基づいて実行できます。

一般的な移行ワークストリームには、次のステージがあります。

• 検出: 環境内に現在あるものを確認する。

• パイロット: 新しいクラウド機能をワークストリームに応じてユーザー、アプリケーション、またはデバイスの小さなサブセットにデプロイする。

• スケールアウト: パイロットを拡張して、クラウドへの機能の移行を完了する。

• カットオーバー (該当する場合): 古いオンプレミス ワークロードの使用を停止する。

ユーザーおよびグループ

パスワードの有効化 (セルフサービス)

Microsoft では、パスワードレス環境をお勧めしています。 それまでは、オンプレミスのシステムから Microsoft Entra ID にパスワードのセルフサービス ワークフローを移行して、環境を簡素化できます。 Microsoft Entra ID セルフサービス パスワード リセット (SSPR) を使用すると、管理者やヘルプ デスクが関与することなく、ユーザーが自分でパスワードを変更したり、リセットしたりできます。

セルフサービス機能を有効にするには、組織に適した認証方法を選択します。 認証方法が更新されたら、Microsoft Entra 認証環境に対してユーザーのセルフサービス パスワード機能を有効にできます。 デプロイのガイダンスについては、「Microsoft Entra のセルフサービス パスワード リセットのデプロイに関する考慮事項」を参照してください。

追加の考慮事項には、次のものがあります。

• 監査モードを使用してドメイン コントローラーのサブセットに Microsoft Entra パスワード保護をデプロイして、最新ポリシーの影響に関する情報を収集します。
• SSPR と Microsoft Entra MFA のための結合された登録を徐々に有効化します。 たとえば、すべてのユーザーを対象に、リージョン、子会社、または部門別にロールアウトします。
• 脆弱なパスワードを一掃するために、すべてのユーザーのパスワード変更サイクルを確認します。 サイクルが完了したら、ポリシーの有効期限を実装します。
• モードが [強制] に設定されているドメイン コントローラーのパスワード保護構成を切り替えます。 詳細については、「オンプレミスの Microsoft Entra パスワード保護を有効にする」を参照してください。

グループの管理を移動する

グループと配布リストを変換するには、次のようにします。

• セキュリティ グループの場合は、ユーザーをセキュリティ グループに割り当てる既存のビジネス ロジックを使用します。 ロジックと機能を Microsoft Entra ID と動的グループに移行します。

• Microsoft Identity Manager で提供される自己管理グループ機能の場合は、その機能をセルフサービス グループ管理に置き換えます。

• Outlook で配布リストを Microsoft 365 グループに変換できます。 これは、組織の配布リストに Microsoft 365 グループのすべての機能を与える優れたアプローチ方法です。

• 配布リストを Outlook の Microsoft 365 グループにアップグレードし、オンプレミスの Exchange サーバーの使用を停止します。

ユーザーとグループのプロビジョニングをアプリケーションに移動する

アプリケーションのプロビジョニング フローを Microsoft Identity Manager などのオンプレミスの ID 管理 (IDM) システムから削除して環境を簡素化できます。 アプリケーションの検出に基づき、次の特性に基づいてアプリケーションを分類します。

• Microsoft Entra アプリケーション ギャラリーとのプロビジョニング統合が行われている、環境内のアプリケーション。

• ギャラリー内にはないが、SCIM 2.0 プロトコルをサポートするアプリケーション。 これらのアプリケーションは、Microsoft Entra クラウド プロビジョニング サービスとネイティブに互換性があります。

• ECMA コネクタを使用できるオンプレミス アプリケーション。 これらのアプリケーションは、Microsoft Entra オンプレミス アプリケーションのプロビジョニングと統合できます。

詳細については、「Microsoft Entra ID の自動ユーザー プロビジョニングのデプロイを計画する」を参照してください。

クラウド人事プロビジョニングに移動する

人事プロビジョニング ワークフローをオンプレミスの IDM システム (Microsoft Identity Manager など) から Microsoft Entra ID に移動することによって、オンプレミスのフットプリントを削減できます。 Microsoft Entra クラウド人事プロビジョニングでは、次の 2 つのアカウントの種類を使用できます:

• Microsoft Entra ID を使用するアプリケーションのみを使用している新しい従業員の場合は、クラウド専用アカウントをプロビジョニングすることを選択できます。 このプロビジョニングにより、Active Directory のフットプリントを含めることができます。

• Active Directory への依存関係があるアプリケーションにアクセスする必要がある新しい従業員の場合は、"ハイブリッド アカウント" をプロビジョニングできます。

Microsoft Entra クラウド人事プロビジョニングでは、既存の従業員の Active Directory アカウントも管理できます。 詳細については、「Microsoft Entra ユーザー プロビジョニングのためのクラウド人事アプリケーションの計画」と「デプロイ プロジェクトを計画する」を参照してください。

ライフサイクル ワークフローを動かす

既存の joiner/mover/leaver ワークフローおよびプロセスを Microsoft Entra クラウド環境への適用性と妥当性評価に関して評価します。 その後、ライフサイクル ワークフローを使用して、これらのワークフローを簡略化し、新しいワークフローを作成できます。

外部 ID 管理を移動する

組織で Active Directory またはその他のオンプレミス ディレクトリに、ベンダー、請負業者、コンサルタントなどの外部 ID のアカウントがプロビジョニングされている場合は、それらのサードパーティ ユーザー オブジェクトをクラウドでネイティブに管理することによって環境を簡素化できます。 次のような可能性があります。

• 新しい外部ユーザーに対しては、Microsoft Entra External ID を使用します。これによって、ユーザーの Active Directory 占有領域が停止されます。

• 外部 ID 用にプロビジョニングしている既存の Active Directory アカウントについては、ローカル資格情報 (パスワードなど) を企業間 (B2B) コラボレーション用に構成することで、それらを管理するオーバーヘッドを取り除くことができます。 「内部ユーザーを B2B コラボレーションに招待する」の手順に従います。

• Microsoft Entra エンタイトルメント管理を使用して、アプリケーションとリソースへのアクセス権を付与します。 ほとんどの企業にはこのための専用システムとワークフローがあり、それらをオンプレミスのツールから移動できるようになりました。

• アクセス レビューを使用して、不要になったアクセス権や外部 ID を削除します。

デバイス

Windows 以外のワークステーションを移動する

Windows 以外のワークステーションを Microsoft Entra ID と統合して、ユーザー エクスペリエンスを強化し、条件付きアクセスなどのクラウドベースのセキュリティ機能を活用できます。

• macOS の場合:

  • macOS を Microsoft Entra ID に登録し、モバイル デバイス管理ソリューションを使用して登録/管理します。

  • Apple デバイス用の Microsoft Enterprise SSO (シングル サインオン) プラグインをデプロイします。

  • macOS 13 のプラットフォーム SSO のデプロイを計画します。

• Linux の場合は、Microsoft Entra 資格情報を使用して Linux 仮想マシン (VM) にサインインできます。

ワークステーション用の他の Windows バージョンを置き換える

ワークステーションに次のオペレーティング システムがある場合は、クラウドネイティブ管理 (Microsoft Entra 参加と統合エンドポイント管理) を活用するために、最新バージョンにアップグレードすることを検討してください:

• Windows 7 または 8.x

• Windows Server

VDI ソリューション

このプロジェクトには、2 つの主要なイニシアチブがあります。

• 新しいデプロイ: オンプレミスの Active Directory を必要としない、Windows 365 や Azure Virtual Desktop などのクラウドマネージド仮想デスクトップ インフラストラクチャ (VDI) ソリューションをデプロイします。

• 既存のデプロイ: 既存の VDI デプロイが Active Directory に依存している場合は、ビジネス目標とゴールを使用して、ソリューションを維持するか Microsoft Entra ID に移行するかを決定します。

詳細については、以下を参照してください:

• Azure Virtual Desktop に Microsoft Entra 参加済み VM にデプロイする

• Windows 365 計画ガイド

アプリケーション

セキュリティで保護された環境を維持するために、Microsoft Entra ID では先進認証プロトコルがサポートされています。 アプリケーション認証を Active Directory から Microsoft Entra ID に移行するには、次の手順を実行する必要があります:

• 変更なしで Microsoft Entra ID に移行できるアプリケーションを判別する。

• アップグレードによって移行できるアップグレード パスがあるアプリケーションを判別する。

• 移行するために置換や重要なコード変更が必要なアプリケーションを判別する。

アプリケーション検出イニシアチブの結果は、アプリケーション ポートフォリオの移行のための優先順位付き一覧を作成することです。 この一覧には、次のアプリケーションが含まれています。

• ソフトウェアへのアップグレードまたは更新が必要であり、アップグレード パスが利用可能である。

• ソフトウェアへのアップグレードまたは更新が必要であるが、アップグレード パスが利用可能ではない。

一覧を使用して、既存のアップグレード パスがないアプリケーションをさらに評価できます。 ビジネス価値によってソフトウェアの更新が正当化されるかどうか、またはインベントリから削除するべきかどうかを判断します。 ソフトウェアをインベントリから削除するべきである場合は、置換が必要かどうかを判断します。

結果に基づいて、Active Directory から Microsoft Entra ID への変換のさまざまな側面を再設計できます。 サポートされていない認証プロトコルを使用するアプリケーションのために、オンプレミスの Active Directory を、Azure のサービスとしてのインフラストラクチャ (IaaS) に拡張するために使用できる方法があります (リフト アンド シフト)。 この方法を使用するには、例外を必要とするポリシーを設定することをお勧めします。

アプリケーションの検出

アプリ ポートフォリオをセグメント化したら、ビジネス価値とビジネスの優先順位に基づいて移行の優先順位を設定できます。 ツールを使用して、アプリ インベントリを作成または更新できます。

アプリを分類するには、次の 3 つの主な方法があります。

• 先進認証アプリ: これらのアプリケーションでは、先進認証プロトコル (OIDC、OAuth2、SAML、WS-Federation など) が使用されるか、Active Directory フェデレーション サービス (AD FS) などのフェデレーション サービスが使用されます。

• Web アクセス管理 (WAM) ツール: これらのアプリケーションでは、SSO にヘッダー、Cookie、および同様の手法が使用されます。 これらのアプリには、通常、Symantec SiteMinder などの WAM ID プロバイダーが必要です。

• レガシ アプリ: これらのアプリケーションでは、Kerberos、LDAP、Radius、リモート デスクトップ、NTLM (推奨されない) などのレガシ プロトコルが使用されます。

Microsoft Entra ID を各種類のアプリケーションで使用することで、さまざまなレベルの機能を提供でき、これによってさまざまな移行戦略、複雑さ、トレードオフが生じます。 一部の組織には、検出ベースラインとして使用できるアプリケーション インベントリがあります。 (このインベントリは完了または更新されていないことが一般的です。)

先進認証アプリを検出するには、次のようにします。

• AD FS を使用している場合は、AD FS アプリケーション アクティビティ レポートを使用します。

• 別の ID プロバイダーを使用している場合は、ログと構成を使用します。

次のツールは、LDAP が使用されているアプリケーションを検出するのに役立ちます。

• Event1644Reader: フィールド エンジニアリング ログを使用してドメイン コントローラーに対して行われた LDAP クエリに関するデータを収集するためのサンプル ツール。

• Microsoft 365 Defender for Identity: サインイン操作監視機能を使用するセキュリティ ソリューション。 (Secure LDAP ではなく LDAP を使用してバインドをキャプチャすることに注意してください。)

• PSLDAPQueryLogging: LDAP クエリに関するレポートを作成するための GitHub ツール。

AD FS またはその他のフェデレーション サービスを移行する

Microsoft Entra ID への移行を計画する場合は、先進認証プロトコル (SAML や OpenID Connect など) を使用するアプリを最初に移行することを検討してください。 Azure アプリ ギャラリーの組み込みコネクタを使用するか、Microsoft Entra ID での登録を使用して、Microsoft Entra ID で認証を行うようにこれらのアプリを再構成できます。

Microsoft Entra ID にフェデレーションされていた SaaS アプリケーションを移動したら、オンプレミスのフェデレーション システムの使用を停止するための手順がいくつかあります:

• アプリケーション認証を Microsoft Entra ID に移動する

• Azure Multi-Factor Authentication Server から Microsoft Entra 多要素認証に移行する

• フェデレーションからクラウド認証に移行する

• Microsoft Entra アプリケーション プロキシを使用している場合にリモート アクセスを内部アプリケーションに移動する

WAM 認証アプリを移動する

このプロジェクトでは、SSO 機能を WAM システムから Microsoft Entra ID に移行することに重点を置きます。 詳細については、Symantec SiteMinder から Microsoft Entra ID へのアプリケーションの移行に関する記事を参照してください。

アプリケーション サーバー管理戦略を定義する

インフラストラクチャ管理の観点から、オンプレミス環境では、管理業務を分割するために、多くの場合、グループ ポリシー オブジェクト (GPO) と Microsoft Configuration Manager 機能が組み合わせて使用されます。 たとえば、業務は、セキュリティ ポリシーの管理、更新管理、構成管理、監視に分割できます。

Active Directory はオンプレミスの IT 環境用であり、Microsoft Entra ID はクラウドベースの IT 環境用です。 機能の 1 対 1 のパリティはここには存在しないため、アプリケーション サーバーをいくつかの方法で管理できます。

たとえば、Azure Arc は、ID およびアクセス管理 (IAM) に Microsoft Entra ID を使用する場合に、Active Directory に存在する多くの機能を 1 つのビューにまとめるために役立ちます。 Microsoft Entra Domain Services を使用して、特に特定のビジネス上または技術的な理由で GPO を使用する場合に、Microsoft Entra ID でサーバーをドメインに参加させることができます。

次の表を使用して、オンプレミス環境を置き換えるために使用できる Azure ベースのツールを判別してください。

アプリケーション サーバー管理に使用できる詳細情報を次に示します。

• Azure Arc を使用すると、Azure 以外の VM に対して Azure 機能が有効になります。 たとえば、オンプレミスまたはアマゾン ウェブ サービスで使用されている Windows Server の Azure 機能を取得するために使用できたり、SSH で Linux マシンを認証するために使用できたりします。

• Azure VM 環境を管理してセキュリティで保護します。

• 移行または部分的移行の実行を待つ必要がある場合は、Microsoft Entra Domain Services で GPO を使用できます。

Microsoft Configuration Manager を使用したアプリケーション サーバーの管理を必要とする場合、Microsoft Entra Domain Services を使用してこの要件を満たすことはできません。 Microsoft Configuration Manager を Microsoft Entra Domain Services 環境で実行することはサポートされていません。 代わりに、オンプレミスの Active Directory インスタンスを、Azure VM で実行されているドメイン コントローラーに拡張する必要があります。 または、新しい Active Directory インスタンスを、Azure IaaS 仮想ネットワークにデプロイする必要があります。

レガシ アプリケーションの移行戦略を定義する

レガシ アプリケーションには、Active Directory への次のような依存関係があります。

• ユーザー認証と承認: Kerberos、NTLM、LDAP バインド、ACL。

• ディレクトリ データへのアクセス: LDAP クエリ、スキーマ拡張機能、ディレクトリ オブジェクトの読み取り/書き込み。

• サーバー管理: サーバー管理戦略によって決定される。

これらの依存関係を減らすかまたは排除するには、3 つの主な方法があります。

方法 1

最も推奨される方法では、レガシ アプリケーションから、先進認証が使用されている SaaS の代替手段に移行するプロジェクトに着手します。 SaaS の代替手段をMicrosoft Entra ID に対して直接認証します:

1. Microsoft Entra Domain Services を Azure 仮想ネットワークにデプロイし、アプリケーションに必要な追加の属性を組み込むようにスキーマを拡張します。

2. Microsoft Entra Domain Services にドメイン参加済みの Azure 仮想ネットワーク上の VM にレガシ アプリをリフト アンド シフトします。

3. Microsoft Entra アプリケーション プロキシまたは安全なハイブリッド アクセス パートナーを使用して、レガシ アプリをクラウドに発行します。

4. レガシ アプリが使用されなくなって廃止されたら、最終的に Azure 仮想ネットワークで実行されている Microsoft Entra Domain Services の使用を停止します。

方法 2

最初の方法が不可能であり、アプリケーションが Active Directory への強い依存関係を持っている場合は、オンプレミスの Active Directory を Azure IaaS に拡張できます。

最新のサーバーレス ホスティングをサポートするようにリプラットフォームできます。たとえば、サービスとしてのプラットフォーム (PaaS) を使用します。 または、先進認証をサポートするようにコードを更新できます。 アプリを Microsoft Entra ID と直接統合できるようにすることもできます。 Microsoft ID プラットフォームの Microsoft 認証ライブラリについて説明します。

1. 仮想プライベート ネットワーク (VPN) または Azure ExpressRoute 経由で Azure 仮想ネットワークをオンプレミス ネットワークに接続します。

2. オンプレミスの Active Directory インスタンスの新しいドメイン コントローラーを仮想マシンとして Azure 仮想ネットワークにデプロイします。

3. ドメイン参加済みの Azure 仮想ネットワーク上の VM にレガシ アプリをリフト アンド シフトします。

4. Microsoft Entra アプリケーション プロキシまたは安全なハイブリッド アクセス パートナーを使用して、レガシ アプリをクラウドに発行します。

5. 最終的に、オンプレミスの Active Directory インフラストラクチャの使用を停止し、完全に Azure 仮想ネットワークで Active Directory を実行します。

6. レガシ アプリが自然減少によって廃止されたら、最終的に Azure 仮想ネットワークで実行されている Active Directory インスタンスの使用を停止します。

方法 3

最初の移行が不可能であり、アプリケーションが Active Directory への強い依存関係を持っている場合は、新しい Active Directory インスタンスを Azure IaaS にデプロイできます。 予見可能な将来にわたってアプリケーションをレガシ アプリケーションのままにするか、または機会があったらアプリケーションの使用を停止します。

この方法を使用すると、アプリを既存の Active Directory インスタンスから切り離して領域を減らすことができます。 これは最後の手段としてのみ考えることをお勧めします。

1. 新しい Active Directory インスタンスを仮想マシンとして Azure 仮想ネットワークにデプロイします。

2. 新しい Active Directory インスタンスにドメイン参加済みの Azure 仮想ネットワーク上の VM にレガシ アプリをリフト アンド シフトします。

3. Microsoft Entra アプリケーション プロキシまたは安全なハイブリッド アクセス パートナーを使用して、レガシ アプリをクラウドに発行します。

4. レガシ アプリが自然減少によって廃止されたら、最終的に Azure 仮想ネットワークで実行されている Active Directory インスタンスの使用を停止します。

戦略の比較

VPN 認証を移行する

このプロジェクトでは、VPN 認証を Microsoft Entra ID に移行することに重点を置きます。 VPN ゲートウェイ接続ではさまざまな構成が利用できることを理解しておくことが重要です。 また、どの構成が自分のニーズに最適かを判断する必要があります。 ソリューションの設計の詳細については、「VPN Gateway の設計」を参照してください。

VPN 認証に Microsoft Entra ID を使用することに関する重要なポイントは、次のとおりです:

• VPN プロバイダーで先進認証がサポートされているかどうかを確認します。 次に例を示します。

  • チュートリアル: Microsoft Entra SSO と Cisco Secure Firewall - Secure Client の統合

  • チュートリアル: Microsoft Entra SSO と Palo Alto Networks GlobalProtect の統合

• Windows 10 デバイスの場合は、組み込みの VPN クライアントに Microsoft Entra サポートを統合することを検討してください。

• このシナリオを評価した後、VPN 認証を行うためのオンプレミスへの依存関係を削除するソリューションを実装できます。

リモート アクセスを内部アプリケーションに移動する

環境を簡素化するために、Microsoft Entra アプリケーション プロキシまたは安全なハイブリッド アクセス パートナーを使用してリモート アクセスを提供できます。 これにより、オンプレミスのリバース プロキシへの依存関係ソリューションを削除できます。

上記のテクノロジを使用してアプリケーションへのリモート アクセスを有効にすることは、中間の手順であることを理解しておくことが重要です。 アプリケーションを Active Directory から完全に切り離すには、さらに多くの作業を行う必要があります。

Microsoft Entra Domain Services を使用すると、Microsoft Entra アプリケーション プロキシを使用してリモート アクセスを有効にしながら、アプリケーション サーバーをクラウド IaaS に移行し、Active Directory から切り離すことができます。 このシナリオの詳細については、「Microsoft Entra Domain Services 用に Microsoft Entra アプリケーション プロキシをデプロイする」をチェックしてください。

次のステップ

• はじめに
• クラウドへの変換体制
• Microsoft Entra フットプリントを確立する
• クラウド優先のアプローチを実装する