次の方法で共有

アプリケーションと認証を Microsoft Entra ID に移行するためのベスト プラクティス

  • [アーティクル]

Azure Active Directory が Microsoft Entra ID に変わったと聞き、今が Active Directory フェデレーション サービス (AD FS) を Microsoft Entra ID のクラウド認証 (AuthN) に移行する良い機会であると考えている方もいらっしゃるでしょう。 オプションを確認する際は、アプリを Microsoft Entra ID に移行するための広範なリソースとベスト プラクティスを参照してください。

AD FS を Microsoft Entra ID に移行できるようになるまでは、Microsoft Defender for Identity を使ってオンプレミスのリソースを保護してください。 脆弱性を事前に見つけて修正することができます。 評価、分析とデータ インテリジェンス、ユーザー調査の優先順位スコア付け、侵害された ID への自動対応を使います。 クラウドへの移行は、認証にパスワードレスの方法など、組織が先進認証のメリットを得られることを意味します。

次のような理由で、AD FS を移行しないことを選ぶ場合があります。

  • 環境内のユーザー名 (従業員 ID など) がフラットである。
  • カスタム多要素認証プロバイダーのために他にも必要なオプションがある。
  • VMware など、サードパーティのモバイル デバイス管理 (MDM) システムのデバイス認証ソリューションを使っている。
  • AD FS に複数のクラウドから二重にフィードされている。
  • ネットワークをエア ギャップで隔離する必要がある。

アプリケーションの移行

段階的なアプリケーション移行のロールアウトを計画し、Microsoft Entra ID の認証を受けるテスト対象のユーザーを選びます。 「Microsoft Entra ID へのアプリケーションの移行を計画する」と、Microsoft Entra ID にアプリを移行するリソースのページのガイダンスを参考にしてください。

詳細については、次のビデオ「Microsoft Entra ID を使用した簡単なアプリケーションの移行」を参照してください。

アプリケーション移行ツール

AD FS アプリを Microsoft Entra ID に移行する AD FS アプリケーション移行 (現在プレビュー段階です) は、IT 管理者が AD FS 証明書利用者アプリケーションを AD FS から Microsoft Entra ID に移行するためのガイドです。 AD FS アプリケーション移行ウィザードは、新しい Microsoft Entra アプリケーションの検出、評価、構成を行うための統合エクスペリエンスを提供します。 基本的な SAML URL、要求のマッピング、ユーザー割り当てをワンクリックで構成して、アプリケーションと Microsoft Entra ID を統合できます。 オンプレミス AD FS アプリケーションの移行をエンドツーエンドでサポートしており、次の機能を備えています。

  • アプリケーションの使用状況と影響を特定するには、AD FS 証明書利用者アプリケーションのサインイン アクティビティを評価します
  • 移行の阻害要因と、アプリケーションを Microsoft Entra ID に移行するために必要なアクションを特定するには、AD FS から Microsoft Entra への移行の可能性について分析します
  • AD FS アプリケーション用に新しい Microsoft Entra アプリケーションを自動的に構成するには、ワンクリック アプリケーション移行プロセスで新しい Microsoft Entra アプリケーションを構成します

フェーズ 1:アプリを検出してスコープを設定する

アプリの検出時には、開発中と計画段階のアプリを含めます。 移行の完了後に Microsoft Entra ID を使って認証するようにスコープを指定します。

アクティビティ レポートを使って AD FS アプリを Microsoft Entra ID に移行します。 このレポートは、Microsoft Entra ID に移行できるアプリケーションを特定するのに役立ちます。 AD FS アプリケーションの Microsoft Entra との互換性を評価し、問題を確認し、個々のアプリケーションの移行準備に関するガイダンスを提供します。

AD FS から Microsoft Entra アプリへの移行ツールを使って、AD FS サーバーから証明書利用者アプリケーションを収集し、構成を分析します。 この分析から、どのアプリが Microsoft Entra ID への移行の対象となるかがレポートに表示されます。 対象外のアプリについては、移行できない理由の説明を確認できます。

Microsoft Entra Connect AD FS 正常性エージェントを使用して、オンプレミス環境用に Microsoft Entra Connect をインストールしてください。

詳細については、「Microsoft Entra Connect とは」を参照してください。

フェーズ 2:アプリを分類し、パイロットを計画する

アプリの移行を分類することは、重要な演習です。 アプリを移行する順序を決めたら、段階的なアプリの移行と切り替えを計画します。 アプリの分類には次の条件を含めます。

  • 最新の認証プロトコル。Microsoft Entra アプリケーション ギャラリーにある、Microsoft Entra ID を使用しないサードパーティのサービスとしてのソフトウェア (SaaS) アプリなど。
  • 最新化するレガシ認証プロトコル。たとえば、サードパーティの SaaS アプリ (ギャラリーにはなく、ギャラリーに追加できるもの)。
  • AD FS を使っており、Microsoft Entra ID に移行できるフェデレーション アプリ。
  • レガシ認証プロトコルは最新化されません。 最新化により、Microsoft Entra アプリケーション プロキシを使用できる Web アプリケーション プロキシ (WinSCP (WAP)) の背後にあるプロトコルと、安全なハイブリッド アクセスを使用できるアプリケーション配信ネットワーク/アプリケーション配信コントローラーが除外される場合があります。
  • 新しい基幹業務 (LOB) アプリ。
  • 非推奨のアプリには、他のシステムと重複する機能があり、ビジネスの所有者または用途がない場合があります。

移行する最初のアプリを選ぶ場合は、シンプルにします。 条件には、複数の ID プロバイダー (IdP) 接続をサポートする SaaS アプリをギャラリーに含めることができます。 テストインスタンス アクセスを備えたアプリ、単純な要求規則があるアプリ、対象ユーザーのアクセスを制御するアプリがあります。

フェーズ 3: 移行とテストを計画する

移行およびテスト ツールには、アプリを検出、分類、移行するための Microsoft Entra アプリ移行ツールキットが含まれています。 エンドツーエンドのプロセスを説明する SaaS アプリのチュートリアルと Microsoft Entra シングル サインオン (SSO) の展開プランの一覧を参照してください。

Microsoft Entra アプリケーション プロキシについて確認し、完全な Microsoft Entra アプリケーション プロキシの展開プランを使います。 Microsoft Entra ID に接続してオンプレミスとクラウドのレガシ認証アプリケーションを保護するには、セキュリティで保護されたハイブリッド アクセス (SHA) を検討してください。 Microsoft Entra Connect を使って、AD FS ユーザーとグループを Microsoft Entra ID と同期します。

フェーズ 4: 管理と分析情報について計画する

アプリを移行したら、管理と分析情報に関するガイダンスに従って、ユーザーがセキュリティで保護された方法でアプリにアクセスして管理できるようにします。 使用状況とアプリの正常性に関する分析情報を取得して共有します。

Microsoft Entra 管理センターから、次の方法を使ってすべてのアプリを監査します。

  • [エンタープライズ アプリケーション] の [監査] を使ってアプリを監査したり、Microsoft Entra reporting API から同じ情報にアクセスして、お気に入りのツールに統合したりします。
  • エンタープライズ アプリケーション、アクセス許可を使用して Open Authorization (OAuth)/OpenID Connect を使用するアプリに関するアプリのアクセス許可を確認します。
  • [エンタープライズ アプリケーション] の [サインイン] を使い、Microsoft Entra reporting API からサインインの分析情報を入手します。
  • Microsoft Entra ブックからアプリの使用状況を視覚化します。

検証環境を準備する

PowerShell ギャラリーの MSIdentityTools を使って、Microsoft Identity 製品とサービスの管理、トラブルシューティング、報告を行います。 Microsoft Entra Connect Health を使って AD FS インフラストラクチャを監視します。 AD FS でテスト アプリを作成し、定期的にユーザー アクティビティを生成し、Microsoft Entra 管理センターでアクティビティを監視します。

オブジェクトを Microsoft Entra ID に同期するときは、クラウドで使用できる要求規則に使われているグループ、ユーザー、ユーザー属性の AD FS 証明書利用者の信頼要求規則を確認します。 コンテナーと属性の同期を確認します。

アプリ移行シナリオの違い

環境に次のシナリオが含まれる場合、アプリの移行計画には特に注意が必要です。 さらに詳しいガイダンスについては、リンクをクリックしてください。

  • 証明書。 (AD FS グローバル署名証明書)。 Microsoft Entra ID では、1 つのアプリケーションに 1 つの証明書を使うか、すべてのアプリケーションに対して 1 つの証明書を使うことができます。 有効期限をずらしてリマインダーを構成します。 証明書の管理を最小特権のロールに委任します。 Microsoft Entra ID で作成される証明書に関する一般的な質問と情報を確認して、SaaS アプリケーションへのフェデレーション SSO を確立します。
  • 要求規則と基本的な属性マッピング。 SaaS アプリケーションの場合、基本的な属性と要求間のマッピングのみが必要な場合があります。 SAML トークン要求をカスタマイズする方法を参照してください。
  • UPN からユーザー名を抽出します。 Microsoft Entra ID は、正規表現ベースの変換をサポートしています (SAML トークン要求のカスタマイズにも関連します)。
  • グループ要求。 メンバーであり、アプリケーションに割り当てられているユーザーによってフィルター処理されたグループ要求を出力します。 Microsoft Entra ID を使ってアプリケーションのグループ要求を構成することができます。
  • Web アプリケーション プロキシ。 Microsoft Entra アプリケーション プロキシを使って発行し、VPN を使わずにオンプレミスの Web アプリにセキュリティで保護された方法で接続できます。 オンプレミスの Web アプリへのリモート アクセスと、レガシ認証プロトコルのネイティブ サポートを提供します。

アプリケーション移行プロセス計画

アプリケーション移行プロセスに次の手順を含めることを検討してください。

  • AD FS アプリの構成を複製します。 アプリのテスト インスタンスを設定するか、テスト用の Microsoft Entra テナントでモック アプリを使います。 AD FS 設定を Microsoft Entra 構成にマップします。 ロールバックを計画します。 テスト インスタンスを Microsoft Entra ID に切り替えて検証します。
  • 要求と識別子を構成します。 確認とトラブルシューティングを行うには、運用アプリを再現します。 アプリのテスト インスタンスが Microsoft Entra ID テスト アプリケーションを指すようにします。 アクセスを検証してトラブルシューティングし、必要に応じて構成を更新します。
  • 運用環境インスタンスの移行を準備します。 テスト結果に基づいて、運用環境アプリケーションを Microsoft Entra ID に追加します。 複数の ID プロバイダー (IdP) を許可するアプリケーションの場合は、運用インスタンスに追加される IdP として Microsoft Entra ID を構成します。
  • Microsoft Entra ID を使うように運用環境インスタンスを切り替えます。 複数の同時 IdP を許可するアプリケーションの場合は、既定の IdP を Microsoft Entra ID に変更します。 それ以外の場合は、運用環境インスタンスに対する IdP として Microsoft Entra ID を構成します。 Microsoft Entra 運用アプリケーションをプライマリ IdP として使うように運用インスタンスを更新します。
  • 最初のアプリを移行し、移行テストを実行して、問題を修正します。 移行状態については、AD FS アプリケーション アクティビティ レポートを参照してください。潜在的な移行の問題に対処する方法に関するガイダンスが記載されています。
  • 大規模に移行します。 アプリとユーザーを段階的に移行します。 Microsoft Entra ID を使って移行されたアプリとユーザーを管理しながら、認証を十分にテストします。
  • フェデレーションを削除します。 AD FS ファームが認証に使われなくなったことを確認します。 関連する構成のフェールバック、バックアップ、エクスポートを使います。

認証を移行する

認証の移行の準備をする際に、組織にどの認証方法が必要かを決定します。

パスワードと認証のポリシー

オンプレミスの AD FS と Microsoft Entra ID の専用ポリシーを使って、オンプレミスと Microsoft Entra ID のパスワード有効期限ポリシーを調整します。 「Microsoft Entra ID のパスワード ポリシーの組み合わせと、脆弱なパスワードのチェック」を実装することを検討してください。 マネージド ドメインに切り替えると、両方のパスワード有効期限ポリシーが適用されます。

セルフサービス パスワード リセット (SSPR) を使って忘れたパスワードをユーザーがリセットできるようにすることで、ヘルプ デスクのコストを削減します。 デバイスベースの認証方法を制限します。 パスワード ポリシーを最新化して、定期的な有効期限を設定せず、リスクがある場合に失効できるようにします。 脆弱なパスワードをブロックし、パスワードを禁止パスワード一覧と照合します。 オンプレミスの AD FS とクラウドの両方でパスワード保護を有効にします。

多要素認証と SSPR を個別に制御する Microsoft Entra ID のレガシ ポリシー設定を、認証方法ポリシーを使用する統合管理に移行します。 元に戻せるプロセスでポリシー設定を移行します。 ユーザーとグループの認証方法を正確に構成すると同時に、テナント全体の多要素認証ポリシーと SSPR ポリシーを引き続き使用することができます。

Windows サインインやその他のパスワードを使わない方法には詳細な構成が必要なので、Microsoft Authenticator と FIDO2 セキュリティ キーを使ったサインインを有効にします。 グループを使ってデプロイを管理し、ユーザーの範囲を設定します。

ホーム領域検出を使ってサインイン自動高速化を構成することができます。 自動高速化サインインを使ってユーザー名入力画面をスキップし、ユーザーをフェデレーション サインイン エンドポイントに自動的に転送する方法を確認してください。 ホーム領域検出ポリシーを使ってサインイン自動高速化を防ぎ、ユーザーの認証方法と場所を複数の方法で制御します。

アカウントの有効期限ポリシー

ユーザー アカウント管理の accountExpires 属性は Microsoft Entra ID と同期されません。 結果として、パスワード ハッシュ同期用に構成された環境の期限切れの Active Directory アカウントは、Microsoft Entra ID でアクティブです。 Set-ADUser コマンドレットなど、スケジュールされた PowerShell スクリプトを使用して、ユーザー Microsoft Windows Server Active Directory アカウントを有効期限が切れた後に無効にします。 逆に、Microsoft Windows Server Active Directory アカウントから有効期限を削除する場合は、アカウントを再度有効にします。

Microsoft Entra ID を使うと、スマート ロックアウトを使って攻撃を防止できます。 ブルートフォース攻撃を軽減するために、オンプレミスでアカウントをロックする前に、クラウドでアカウントをロックします。 クラウドの間隔を短くし、オンプレミスのしきい値が Microsoft Entra のしきい値よりも少なくとも 2 倍から 3 倍大きくなるようにします。 Microsoft Entra のロックアウト期間をオンプレミス期間よりも長く設定します。 移行が完了したら、AD FS エクストラネット スマート ロックアウト (ESL) 保護を構成します。

条件付きアクセスのデプロイを計画する

条件付きアクセス ポリシーの柔軟性には慎重な計画が必要です。 計画手順については、「Microsoft Entra 条件付きアクセス デプロイの計画」を参照してください。 注意すべき重要な点は次のとおりです。

  • わかりやすい名前付け規則を使って、条件付きアクセス ポリシーの下書きを作成します
  • 次のフィールドがある設計決定ポイント スプレッドシートを使います。
    • 割り当て要因: ユーザー、クラウド アプリ
    • 条件: 場所、デバイスの種類、クライアント アプリの種類、サインインのリスク
    • コントロール: ブロック、多要素認証が必要、ハイブリッド Microsoft Windows Server Active Directory 参加済み、準拠デバイスが必要、承認されたクライアント アプリの種類
  • 条件付きアクセス ポリシー用に少人数のテスト ユーザーのセットを選びます
  • レポート専用モードで条件付きアクセス ポリシーをテストします
  • what if ポリシー ツールを使用して、条件付きアクセス ポリシーを検証します
  • 条件付きアクセス テンプレートを使用します (特に組織が条件付きアクセスを初めて使用する場合)

条件付きアクセス ポリシー

第 1 要素認証を完了したら、条件付きアクセス ポリシーを適用します。 条件付きアクセスは、サービス拒否 (DoS) 攻撃などのシナリオに対する最前線の防御ではありません。 ただし、条件付きアクセスでは、サインインのリスクや要求の場所など、これらのイベントからのシグナルを使ってアクセスを決定できます。 条件付きアクセス ポリシーのフローは、セッションとその条件を調べて、結果を中央のポリシー エンジンにフィードします。

条件付きアクセスを使うと、Intune アプリ保護ポリシーを備えた承認済み (先進認証対応) クライアント アプリのみにアクセスを制限できます。 アプリ保護ポリシーをサポートしていない場合がある古いクライアント アプリの場合、承認されたクライアント アプリのみにアクセスを制限できます。

属性に基づいてアプリを自動的に保護します。 お客様のセキュリティ属性を変更するには、クラウド アプリケーションの動的フィルター処理を使って、アプリケーション ポリシー スコープを追加および削除します。 カスタム セキュリティ属性を使って、条件付きアクセス アプリケーション ピッカーに表示されない Microsoft ファーストパーティ アプリケーションを対象にします。

条件付きアクセスの認証強度コントロールを使って、リソースにアクセスする認証方法の組み合わせを指定します。 たとえば、機密リソースへのアクセスにフィッシング耐性のある認証方法を使用できるようにします。

条件付きアクセスのカスタム コントロールを評価します。 ユーザーは、Microsoft Entra ID 以外の認証要件を満たす互換性のあるサービスにリダイレクトされます。 Microsoft Entra ID は応答を検証し、ユーザーが認証または検証された場合は、条件付きアクセス フロー内にとどまります。 「カスタム コントロールへの今後の変更点」で言及されているように、パートナーが提供する認証機能は、Microsoft Entra 管理者エクスペリエンスおよびエンド ユーザー エクスペリエンスとシームレスに連携します。

カスタム多要素認証ソリューション

カスタム多要素認証プロバイダーを使用する場合は、Multi-Factor Authentication Server から Microsoft Entra 多要素認証への移行を検討してください。 必要に応じて多要素認証を移行するための Multi-Factor Authentication Server 移行ユーティリティを使用します。 アカウント ロックアウトのしきい値、不正行為アラート、通知を設定してエンド ユーザー エクスペリエンスをカスタマイズします。

多要素認証と Microsoft Entra ユーザー認証へ移行する方法を学習します。 すべてのアプリケーション、多要素認証サービス、ユーザー認証を Microsoft Entra ID に移行します。

Microsoft Entra 多要素認証を有効にして、ユーザー グループの条件付きアクセス ポリシーの作成、多要素認証を要求するポリシー条件の構成、ユーザー構成と多要素認証の使用のテストを行う方法を学習できます。

多要素認証のためのネットワーク ポリシー サーバー (NPS) 拡張機能は、サーバーを使用してクラウドベースの多要素認証機能を認証インフラストラクチャに追加します。 NPS による Microsoft Entra 多要素認証を使う場合は、Security Assertion Markup Language (SAML) や OAuth2 などの最新のプロトコルに移行できるものを決定します。 リモート アクセス用の Microsoft Entra アプリケーション プロキシを評価し、セキュリティで保護されたハイブリッド アクセス (SHA) を使って Microsoft Entra ID でレガシ アプリを保護します。

サインインを監視する

要求とエラーの詳細については、Connect Health を使って AD FS サインインを統合し、サーバーのバージョンに応じて AD FS の複数のイベント ID を関連付けます。 Microsoft Entra サインイン レポートには、ユーザー、アプリケーション、管理対象リソースがいつ Microsoft Entra ID にサインインしてリソースにアクセスしたかに関する情報が含まれています。 これらの情報は Microsoft Entra サインイン レポート スキーマに関連付けられ、Microsoft Entra サインイン レポート ユーザー エクスペリエンスに表示されます。 レポートでは、Log Analytics ストリームによって AD FS データが提供されます。 シナリオ分析には Azure Monitor ブック テンプレートを使って変更します。 たとえば、AD FS アカウントのロックアウト、不正なパスワードの試行、予期しないサインイン試行の増加などがあります。

Microsoft Entra により、内部アプリとリソースを含め、Azure テナントへのすべてのサインインがログされます。 サインイン エラーとパターンを確認して、ユーザーがアプリケーションやサービスにどのようにアクセスするかを把握します。 Microsoft Entra ID のサインイン ログは、分析に役立つアクティビティ ログです。 ライセンスに応じて、データ保持が最長 30 日間のログを構成し、Azure Monitor、Sentinel、Splunk、その他のセキュリティ情報イベント管理 (SIEM) システムにエクスポートします。

企業ネットワーク内要求

ゼロ トラスト モデルは、要求の送信元やアクセス先のリソースに関係なく、"決して信頼せず、常に確認する" ことを要求します。すべての場所を企業ネットワークの外部であるかのようにセキュリティで保護します。 ID 保護の擬陽性を減らすために、ネットワーク内を信頼できる場所として宣言します。 すべてのユーザーに多要素認証を適用し、デバイスベースの条件付きアクセス ポリシーを確立します。

サインイン ログに対してクエリを実行して、企業ネットワーク内から接続していても、Microsoft Entra ハイブリッド参加済みまたは準拠ではないユーザーを検出します。 準拠デバイスを使っているユーザーと、拡張機能なしの Firefox や Chrome などのサポートされていないブラウザーの使用を検討してください。 代わりに、コンピューター ドメインとコンプライアンスの状態を使います。

段階的な認証移行テストと一括移行

テストには、段階的ロールアウトによる Microsoft Entra Connect クラウド認証を使って、グループによるテスト ユーザー認証を制御します。 Microsoft Entra 多要素認証、条件付きアクセス、Microsoft Entra ID Protection などのクラウド認証機能を使用してユーザー グループを選択的にテストします。 ただし、段階的な移行には段階的ロールアウトを使わないでください。

クラウド認証への移行を完了するには、段階的ロールアウトを使って新しいサインイン方法をテストします。 ドメインをフェデレーション認証からマネージド認証に変換します。 テスト ドメイン、またはユーザー数が最も少ないドメインから始めます。

ロールバックが必要になった場合に備えて、営業時間外にドメインの一括移行を計画します。 ロールバックを計画するには、現在のフェデレーション設定を使います。 フェデレーションの設計および展開ガイドのページを参照してください。

ロールバック プロセスにマネージド ドメインからフェデレーション ドメインへの変換を含めます。 New-MgDomainFederationConfiguration コマンドレットを使います。 必要に応じて、追加の要求規則を構成します。 プロセスが確実に完了するように、一括移行後 24 時間から 48 時間は、ロールバック段階的ロールアウトのままにします。 段階的ロールアウトからユーザーとグループを削除し、オフにします。

一括移行後、30 日ごとに、シームレス SSO のキーをロールオーバーします。

Update-AzureADSSOForest -OnPremCredentials $creds -PreserveCustomPermissionsOnDesktopSsoAccount

AD FS の使用を停止する

AD FS の Connect Health 利用状況分析から AD FS アクティビティを監視します。 まず、AD FS の監査を有効にします。 AD FS ファームを使用停止にする前に、AD FS アクティビティがないことを確認します。 AD FS の使用停止ガイドと AD FS 使用停止リファレンスの記事を参照してください。 主な使用停止手順の概要を次に示します。

  1. AD FS サーバーの使用を停止する前に、最終バックアップを作成します。
  2. 内部および外部のロード バランサーから AD FS エントリを削除します。
  3. AD FS サーバー ファーム名に対応するドメイン ネーム サーバー (DNS) エントリを削除します。
  4. プライマリ AD FS サーバー上で Get-ADFSProperties を実行し、CertificateSharingContainer を探します。

    Note

    ドメイン名 (DN) は、インストールの終了近くに、数回再起動した後、使用できなくなったら削除します。

  5. SQL Server データベース インスタンスをストアとして使っている場合は、AD FS 構成データベースを削除します。
  6. WAP サーバーをアンインストールします。
  7. AD FS サーバーをアンインストールします。
  8. 各サーバー ストレージから AD FS Secure Sockets Layer (SSL) 証明書を削除します。
  9. フル ディスク フォーマットを使って AD FS サーバーを再イメージ化します。
  10. AD FS アカウントを削除します。
  11. Active Directory サービス インターフェイス (ADSI) 編集を使用して、CertificateSharingContainer DN の内容を削除します。

次のステップ