AD FS ⇒ Entra IDへの移行方法
現状、各種サービスの認証をAD FSに委ねている構成において、AD FSを廃止し、Entra IDで認証を一元化したい場合の話です。
構成パターンや、移行方法、注意点などを記事にしています。
現状構成における、想定のパターン
AD FSを認証に利用しているケースにおいて、以下のいずれかのパターンになるかと思います。
| パターン | サービスへのアクセス元 | サービスへのアクセス先 | サービスが設定しているIdP | Entra IDへの 移行方法概要 |
|---|---|---|---|---|
| 1 | 社内 | 社内システム | ADFS | サービスが設定しているIdPを、Entra IDに変更する |
| 2 | 社内 | 社外システムA | ADFS | サービスが設定しているIdPを、Entra IDに変更する |
| 3 | 社内 | 社外システムB | Entra ID ※1 | Entra IDにて、フェデレーション認証を解除する（Entra IDで認証が完結するようにする） |
| 4 | 社外 ※2 | 社内システム | ADFS | サービスが設定しているIdPを、Entra IDに変更する |
| 5 | 社外 ※2 | 社外システムA | ADFS | サービスが設定しているIdPを、Entra IDに変更する |
| 6 | 社外 ※2 | 社外システムB | Entra ID ※1 | Entra IDにて、フェデレーション認証を解除する（Entra IDで認証が完結するようにする） |
※1 Entra IDはフェデレーション認証により、認証要求はADFSへリダイレクトする設定となっている前提
※2 社外からのADFSへのアクセスのために、WAP(ADFS proxy）を利用します。
補足
パターン3、パターン6
段階的ロールアウトを利用することで、ユーザ単位で、「フェデレーション認証⇒マネージド認証」への移行が可能（段階的ロールアウトを利用するには、Entra Connectは必須）
段階的ロールアウトについては、以下のサイトがわかりやすいです。Staged Rollout について | Japan Azure Identity Support Blog
★段階的ロールアウトは、windows 10 ver 1903以降がサポート対象となります。Windows 10 1903 バージョンよりも古い Windows では、Microsoft Entra hybrid join, Microsoft Entra join が構成された Windows デバイスへのサインイン時に段階的ロールアウトによる認証方法の移行が考慮されない動作となります。つまり、段階的ロールアウトを利用してフェデレーション認証からパスワード ハッシュ同期、パススルー認証に移行されているユーザーでも、Windows 10 1903 バージョンよりも古い Windows デバイスを利用されている場合は、Windows デバイスへのサインイン時に発生する Microsoft Entra ID のユーザー認証ではフェデレーション認証が利用されることになります。
【段階的ロールアウトによる移行方法】
■前提
Windows 10 1903 以降のバージョンの端末（端末Ａ）とWindows 10 1903 より古いバージョンの端末（端末Ｂ）が混在している状況を想定
■フェデレーション認証からマネージド認証に移して、最終的にＡＤＦＳを廃止するための、大枠の流れ
①端末Ａを利用するユーザを段階的ロールアウトでマネージド認証に移行
②「①」の移行が完了した段階で、フェデレーション自体を解除し、端末Ｂを利用するユーザをマネージド認証に移行
③ＡＤＦＳ廃止
★②のフェデレーション自体の解除方法は、以下サイトの
「フェデレーションを解除するコマンドとして、現在は New-MgDomainFederationConfiguration と Remove-MgDomainFederationConfiguration コマンドを利用します」の部分を想定しています
https://jpazureid.github.io/blog/azure-active-directory/about-staged-rollout
パターン4
WAPを、①ADFSの認証中継、②サービス（社内システム）へのアクセス中継として利用しているはずであるため、①については、サービスが設定しているIdPを、Entra IDに変更すれば問題ないが、②への考慮が必要（要は、単純にWAPをなくすことができないということです）。②への考慮としては、WAPにおいて①の機能を無効にして、②のためにリバースプロキシ機能のみを動作させるといった対応が必要になると思います。
ADFSとEntra IDの機能差分
ADFSではできて、Entra IDではできない機能があると、移行でトラブルになります。
Microsoft Entra ID 側の動作に起因して利用できなくなる機能
オンプレミス AD と Entra ID で UPN の値が異なる場合でも、Microsoft Entra hybrid join の構成は可能ですが、UPN 要件を満たす必要あります。
Microsoft Entra hybrid join の構成では、ドメインがマネージド ドメインのユーザーでは Microsoft Entra hybrid join を構成するために制限があります。
この制限について説明すると、オンプレミス AD の UPN 属性が Microsoft Entra ID にルーティング可能である必要がある。というものになります。
「ルーティング可能」とは、オンプレミス AD ユーザーの UPN のドメイン部分が Microsoft Entra ID テナントのカスタム ドメインとして登録されている状態を指します（これを満たす（カスタムドメインとして登録する）には、全てとしてドメイン部分がインターネットで名前解決ができる状態である必要があります）
例を用いて説明します。
[Microsoft Entra ID]
Microsoft Entra ID側カスタム ドメイン : contoso.com, fabrikam.com
[ユーザー A]
オンプレミス AD 側ユーザー A UPN : mailto:onpreuser01@contoso.local
オンプレミス AD 側ユーザー A mail : mailto:user01@contoso.com Microsoft Entra ID側ユーザー A UPN : mailto:user01@contoso.com
[ユーザー B]
オンプレミス AD 側ユーザー B UPN : mailto:onpreuser02@fabrikam.com
オンプレミス AD 側ユーザー B mail : mailto:user02@contoso.com Microsoft Entra ID 側ユーザー B UPN : mailto:user02@contoso.com
[ユーザー A] の オンプレミス AD 側 UPN に含まれるドメイン [contoso.local] のドメインは Microsoft Entra ID に登録されていません。(.local であるため登録自体もできません)
この場合、オンプレミス AD ユーザーの UPN のドメイン部分が Microsoft Entra ID にルーティング不可能であるため Microsoft Entra hybrid join の PRT を取得することはできない構成となります。
このシナリオでは、オンプレミス AD 側の UPN をMicrosoft Entra ID に登録可能なカスタム ドメインのドメイン名に変更する必要があります。
一方で、[ユーザー B] は、オンプレミス AD 側 UPN に含まれるドメイン [fabrikam.com] が Azure AD にカスタム ドメインとして登録されています。
この構成であれば、オンプレミス AD ユーザーの UPN のドメイン部分が Microsoft Entra ID にルーティング可能であるため Microsoft Entra hybrid join を構成することが可能な構成となります。(Windows 10 1803 以降バージョンを利用いただいている必要があります)
この制限は、Microsoft Entra hybrid join 構成時に PRT を取得するための Microsoft Entra ID でのユーザー認証がオンプレミス AD 側の UPN 属性を利用して試行されることに起因しています。
AD FS を利用している場合には、オンプレミス AD 側の UPN 属性の値が AD FS に渡されたとしても AD FS 上でのユーザー認証が可能であるためこの制限が適用されない動作となります。
本内容については以下のMSブログでも説明がございますので必要に応じて確認ください。
Hybrid Azure AD Join とユーザーの UPN
URL:https://jpazureid.github.io/blog/azure-active-directory/haadj-and-upn/
上記の内容から、このルーティング不可能なオンプレミス AD 側の UPN を持つユーザーにて Microsoft Entra hybrid join を利用するシナリオでは、PRT の取得が出来なくなる点にご注意ください。
AD FS 側の機能を利用して実現している機能
AD FS の機能を利用して実現していた機能については、AD FS から Microsoft Entra ID に IdP を変更することで利用できなくなります。
具体的なシナリオとしては以下のようなものが上げられます。
B-1. AD FS のクレーム ルール (アクセス制御ポリシー) を利用したアクセス制御 (https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/ad-fs-client-access-policies#ad-fs-and-conditional-access-to-on-premises-resources FS 認証画面のカスタマイズ (https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/ad-fs-user-sign-in-customization)
B-2. Windows Hello for Business のハイブリッド証明書信頼展開モデル (https://learn.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust)
B-3. AD FS を利用した Azure Virtual Desktop のシングル サインオン (https://learn.microsoft.com/ja-jp/azure/virtual-desktop/configure-adfs-sso)
B-1 については AD FS 上での認証に関する機能であり、AD FS への認証が発生しない場合は利用できなくなります。 アクセス制御ポリシーは、Entra IDの条件付きアクセスポリシーのようなもので、アクセス制御ポリシーで実現できることは、基本的にはEntra IDの条件付きアクセスポリシーで実現可能です（アクセス制御ポリシーで特殊な使い方をしていなければ）
B-2, B-3 については機能を利用する上での前提条件に AD FS の構成、認証があり、AD FS を廃止した場合は前提条件を満たさなくなり利用できなくなります。ただし、B-2、B3も少しレアな使い方なので、これに当てはまるケースは少ないと思います。仮に当てはまっていても、B-2に関しては、クラウドkerborous認証モデルに変更することで対応可能かと思います。B-３に関しても、AVDへのSSOをするだけであれば、Entra IDでも実現可能です。