Microsoft Entra ID の AD FS アプリケーション移行機能を利用して AD FS と SAML 連携しているアプリケーションを Entra ID に移行してみる

はじめに

以下公開情報にある [前提条件] を満たしている環境の場合、Entra ID の機能を利用して AD FS の [証明書利用者信頼] の SAML 連携済みのアプリケーションを Entra ID の [エンタープライズ アプリケーション] に移行することができます。

AD FS アプリケーション移行を使用して AD FS アプリを Microsoft Entra ID に移行する

参考情報

今回動作検証を行うにあたって参考にした公開情報は以下になります。

AD FS アプリケーションの移行 (プレビュー) の概要
AD FS アプリケーション移行を使用して AD FS アプリを Microsoft Entra ID に移行する

やってみる

まず、この移行機能を利用するために、前提条件を満たしておく必要があります。
AD FS 向けの Microsoft Entra Connect Health エージェントが AD FS サーバーにインストールされていない場合は、以下公開情報を参考に AD FS の監査ログの有効化と共にインストールを進めてください。

AD FS 用の Microsoft Entra Connect Health エージェント

動作検証を行うために利用した移行対象のアプリケーションと環境について

・SAML プロトコルを利用して AD FS と連携している Salesforce
・AD FS サーバーの OS は Windows Server 2022
・WAP サーバーの OS は Windows Server 2022

また、この移行機能が利用できるアプリケーションの構成について。上記 [参考情報] の公開情報に記載されているとおり以下制限があります。端的に言うと SAML 連携しているアプリケーションのみが移行可能で OIDC (OpenID Connect) や OAuth 、WS-Federation プロトコルで連携しているアプリケーションは現時点 (2024/09/13) では移行対象に含まれていません。

サポートされている構成
支援付き AD FS アプリケーション移行では、次の構成がサポートされます。

・SAML アプリケーションの構成のみをサポートします。
・新しい Microsoft Entra アプリケーション名をカスタマイズするオプション。
・ユーザーは、アプリケーション テンプレート ギャラリーから任意のアプリケーション テンプレートを選択できます。
・SAML アプリケーションの基本的な構成 (識別子と応答 URL) の構成。
・テナントのすべてのユーザーを許可する Microsoft Entra アプリケーションの構成。
・Microsoft Entra アプリケーションへのグループの自動割り当て。
・AD FS 証明書利用者の要求構成から抽出された Microsoft Entra と互換性のある要求の構成。

サポートされない構成:
AD FS アプリケーション移行では、次の構成はサポートされません。

・OIDC (OpenID Connect)、OAuth、WS-Fed の構成はサポートされていません。
・条件付きアクセス ポリシーの自動構成はサポートされていません。ただし、ユーザーはテナントで新しいアプリケーションを構成した後で同じように構成できます。
・署名証明書は、AD FS 証明書利用者アプリケーションから移行されません。

移行前の状態確認

Azure ポータルのサービス一覧から [Microsoft Entra ID] を選択します。
概要ページの左ペインにある [使用状況と分析情報] を選択します。

左ペインから [AD FS アプリケーションの移行] を選択します。

AD FS の [証明書利用者信頼] 上に連携しているアプリケーションの一覧が表示されます。(直近 30 日間の間にフェデレーション認証していないアプリケーションは表示されません)
今回は以下赤枠の Salesforce アプリの移行を試みてみます。
現在 [すべてのアプリ] の欄にあり、[移行準備完了] の項目にリストされていないので、移行ツールが現時点では利用できないようです。

そのため、[追加の手順が必要です] のリンクをクリックし、理由を確認していきます。

移行に関する潜在的な問題を解消する必要があるため、以下赤枠の [Relying Party has SignedSamlRequestsRequired set to true.] をクリックします。

以下メッセージを読むと、AD FS サーバー側で SAML Request に SP (Salesforce) が署名を行うように要求しているとこの警告が出るようです。

参考情報にも載せている AD FS アプリケーションの移行 (プレビュー) の概要 にも記載があります。

結果	合格/警告/不合格	説明
Test-ADFSRPSignedSamlRequestsRequired Relying Party has SignedSamlRequestsRequired set to true (証明書利用者で SignedSamlRequestsRequired が true に設定されている)	合格/不合格	アプリケーションは、SAML 要求の署名を検証するよう AD FS で構成されています。 Microsoft Entra ID では、署名された SAML 要求は受け入れられますが、署名は検証されません。 Microsoft Entra ID には、悪意のある呼び出しから保護するためのさまざまな方法があります。 たとえば、Microsoft Entra ID では、アプリケーションで構成された応答 URL を使用して SAML 要求が検証されます。 Microsoft Entra ID によってトークンが送信されるのは、アプリケーション用に構成された応答 URL のみです。 この結果によって移行が妨げられている場合は、ご連絡ください。

Microsoft Entra ID は SP が SAML Request に署名をしてきても署名の検証を行いません。
そのため AD FS サーバー側で当該の設定値を無効 (True → False) に設定変更します。

プライマリ AD FS サーバーにログオンし AD FS に接続後に以下コマンドを叩くことで対象の証明書利用者信頼名 [Salesfoece_20240903] の [SignedSamlRequestsRequired] が [True] となっていることが確認できます。

> Get-AdfsRelyingPartyTrust -name "Salesforce_20240903" | select SignedSamlRequestsRequired

SignedSamlRequestsRequired
--------------------------
                      True

以下コマンドで当該のパラメーターを無効 (False) に変更します。

> Set-AdfsRelyingPartyTrust -TargetName "Salesforce_20240903" -SignedSamlRequestsRequired $False

再度 Get コマンドを利用して当該のパラメーターが [False] に変更されたことを確認します。

> Get-AdfsRelyingPartyTrust -name "Salesforce_20240903" | select SignedSamlRequestsRequired

SignedSamlRequestsRequired
--------------------------
                     False

次に、赤枠の [At least one non-migratable rule was detected.] をクリックします。

以下画面が表示されました。条件付きアクセスに置き換えられると書いているので [発行承認規則] の事を指しているのだと分かります。
Windows Server 2016 OS 以降では手書きのクレーム ルールではなく [アクセス制御ポリシー] が使われます。
もしかしたら [アクセス制御ポリシー] から [クレーム ルール] に設定を変えることでここの表示が変わるかもしれないので試してみます。

式)
Set-AdfsRelyingPartyTrust -TargetName "証明書利用者信頼名" -AccessControlPolicyName $null

実行例)
Set-AdfsRelyingPartyTrust -TargetName "Salesforce_20240903" -AccessControlPolicyName $null

アクセス制御ポリシーの表示)

AccessControlPolicyName              : 特定のグループを許可
AccessControlPolicyParameters        : {GroupParameter}
ResultantPolicy                      : RequireFreshAuthentication:False
                                       IssuanceAuthorizationRules:
                                       {
                                         Permit users
                                           from '***\Sales' group
                                       }

発行承認規則 (IssuanceAuthorizationRules) の表示)

IssuanceAuthorizationRules           : exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-36757314-3400472429-19
                                       49950067-10101"])=>issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

公開情報には以下のとおり、[特定のグループを許可します。] も移行機能のサポート対象に含まれているように見えましたが、利用している環境依存の問題なのか不明ですが、構成テストの合格対象にはなりませんでした。そのため、 [アクセス制御ポリシー] にて [すべてのユーザーを許可] として検証を進めます。

[ユーザーとグループ] タブ

支援されたユーザーとグループの構成では、オンプレミスの AD FS 環境からの次の構成がサポートされます。

・テナントのすべてのユーザーを許可します。
・特定のグループを許可します。

また、この移行機能を利用する際の留意点として、Entra ID の [AD FS のアプリケーションの移行] の画面で [追加の手順が必要です] と表示されているため AD FS サーバー側で必要な対処を行いますが、その結果が Entra ID の [AD FS のアプリケーションの移行] 画面上で反映されるのが、以下公開情報に記載のとおり UTC の 00:00 頃 (日本時間の朝 9 時頃) になっています。

AD FS アプリケーション移行の分析情報の状態の更新

アプリケーションが更新されると、内部エージェントは数分以内に更新プログラムを同期します。 ただし、AD FS 移行分析情報ジョブは、更新プログラムを評価し、新しい移行状態を計算する役割を担います。 これらのジョブは 24 時間ごとに実行されるようにスケジュールされています。つまり、データは 1 日に 1 回だけ、協定世界時 (UTC) の 00:00 頃に計算されます。

そのため、当該の機能を利用して移行を進める際には、例えば月曜日に修正を行っても火曜日の朝 9 時頃まで待つ必要があるということになります。
(AD FS サーバー側で Connect Health の Agent や Updater を手動更新したり、AD FS サーバーを OS ごと再起動しても反映されなかったのは、上記以降分析情報ジョブが 1 日 1 回だけ動作する仕様によるものであることがこの公開情報を見て判断できました。)

支援付き移行を試す

ようやく、準移行準備完了の状態になったので、支援付き移行を試していきます。
[準備完了] のリンクをクリックします。

全ての項目がクリアになっていることが以下画面ショットからも確認できます。[移行を開始する] をクリックします。

[基本] の項目が以下のように表示されます。
ここでは Entra ID テナントのエンタープライズ アプリケーションで表示するアプリケーション名とアプリケーション テンプレートが選択できます。
アプリケーション テンプレートを選択することで、当該の SaaS アプリケーションのロゴなどが自動的にセットされるようです。
編集のリンクをクリックします。

検索ボックスで [Salesforce] と入力し、表示される Salesforce のチェック ボックスにチェックをいれて [選択] を選択します。

アプリケーション名については任意のアプリケーション名を入力し、[次：ユーザーとグループ>] を選択します。

[ユーザーとグループ」の項目では [すべてのユーザーが許可されています。] が表示されました。
これは AD FS サーバーの [証明書利用者信頼] の [アクセス制御ポリシー] が [すべてのユーザーを許可] に設定されているためです。
そのまま [次：SAML 構成 >] を選択します。

(参考) AD FS 証明書利用者信頼名 [Salesforce_20240903] のアクセス制御ポリシーが [すべてのユーザーを許可] に設定されている。

[SAML 構成] の項目では [識別子] と [応答 URL] が自動でセットされていることが確認できます。

こちらは AD FS の [証明書利用者信頼] の表示名 [Salesforce_20240903] のプロパティを選択することで表示される [識別子] タブと [エンドポイント] タブの [SAML アサーション コンシューマー エンドポイント (応答 URL)] の値を取得してきていることを意味しています。
[次：要求 >] を選択します。

(参考) AD FS [証明書利用者信頼] の表示名 [Salesforce_20240903] の [識別子] タブ

(参考) AD FS [証明書利用者信頼] の表示名 [Salesforce_20240903] の [エンドポイント] タブ

[要求] の項目では AD FS の [要求発行ポリシー] の項目を選択することで表示される [発行変換規則] の設定値を取得してきていることが分かります。
以下設定値は Name ID (名前 ID ：nameidentifier) として UPN (user.userprincipalname) を SAML SSO するために必要な属性として要求するよう構成されていることを意味します。

AD FS サーバーの [発行変換規則] として複数のクレーム ルールを定義している場合は、以下画面上に複数の要求ルールが表示されます。
そのまま [次：次のステップ >] を選択します。

(参考) AD FS [証明書利用者信頼] の表示名 [Salesforce_20240903] の [発行変換規則]

[次のステップ] の項目では [アプリケーションは問題なく移行されます。] と表示されました。そのまま [次：確認と作成 >] を選択します。

[確認と作成] の項目にて、それぞれの項目で設定、表示されている値が一覧で表示されます。
問題なければそのまま [作成] を選択し、構成を開始します。

右上に以下のような画面が表示されますので、構成されるまで待ちます。

構成が成功すると以下のような画面が表示されます。

[AD FS アプリケーションの移行] の画面にて [構成の準備の完了] に移動したことが確認できます。
赤枠の [Microsoft Entra でアプリケーションを構成する] のリンクを選択します。

[シングル サインオン] の画面に遷移しました。
SP-Initiated で動作させるために [必須] の項目である [サインオン URL] は移行ツールの [SMAL 構成] の項目では確かに表示されていなかったので、別途手動でセットする必要がありそうです。
それ以外の項目は AD FS の [証明書利用者信頼] の設定がそのまま Entra ID 側にもセットされていました。

現在私の検証環境ではドメインが [フェデレーション ドメイン] のままなので、移行した Entra ID 経由の認証ではなく、AD FS 認証が行われますが、ドメインをマネージド ドメインに切り替える前や、ステージド ロールアウト (段階的ロールアウト) 活用して段階的移行を進める過程において、この機能を活用して Entra ID テナントに SAML 連携済みアプリケーションを移行しておくことで、移行作業を効率的に進められそうですね。

さいごに

Entra ID テナントの [AD FS アプリケーション移行機能] を実際に試してみました。
AD FS の [証明書利用者信頼] 上に SAML 連携しているアプリケーションを比較的簡単に移行 (構成) ができました。
Entra ID のエンタープライズ アプリケーション側に移行設定した後も、アプリケーション管理者等の管理者ユーザーにて設定を追加、見直しもできるので、移行後の微調整も可能です。

移行できる対象が SAML 連携しているアプリケーションに限定されているなど、現時点では当該機能の制約がありますが、実際に利用されている AD FS の設定値を取り込んでくれるので、設定間違いが起きにくくなり、また、移行作業も簡略化できるので活用して損はないと思いました。

今回の検証内容が参考になれば幸いです。