Federated ユーザーの Entraハイブリッド参加のフローについて
あまり利用されていませんが、ADFSを利用して、Entra ハイブリッド参加を実現する方法があります。
この方法を使用する必要があるシナリオは、オンプレAD環境でインターネットで名前解決できないドメイン（.local等）を利用を継続しつつ、Entraハイブリッド参加を実現したいケースです。
■本記事では以下の略称を利用しています。
Microsoft Entra Hybrid Join : MEHJ
Microsoft Entra ID : ME-ID (旧名 Azure AD)
Microsoft Entra Connect : MEC
２つのフロー
Federated の MEHJ フローには以下の 2 種類があります。
1. フェデレーションの MEHJ フロー
ユーザー認証だけではなく、デバイスの ME-ID への参加もすべてフェデレーション認証で行うフロー (デバイスを MEC で同期することが必須ではないシナリオ) ※あまり知られていないですが、Entra Connectを利用せずにデバイス情報をEntraに同期する方式のようです。
2. sync-join の MEHJ フロー
デバイスの ME-ID への参加は Managed のフローと同様に MEC のデバイス同期で行われるが、ユーザー認証のみ Federated になるフロー (デバイスを MEC で同期することが必須のフロー)
1. フェデレーションの MEHJ フローの詳細
①オンプレ AD に参加している Windows 端末に、同期されているオンプレ AD ユーザーとしてログオンする
②初回のログオンでは、Windows 側のタスク スケジューラーのタスクである Automatic-Device-Join が実行される
・この際、イントラネットの DC サーバーとインターネット (=ME-ID) 両方に通信できることで、タスクの処理が進む
・作成済みの SCP の構成に従い、クライアントはフェデレーション先 (ADFS) に対して、ユーザーとデバイス両方の認証を要求する
・ ADFS にてユーザー/デバイス両方の認証が成功すると、ADFS はクライアントに対して ME-ID に提示可能なそれぞれのクレーム トークンを発行する
・上記を受け取ったクライアントは ME-ID にクレーム トークンを提示し、HME-IDJ デバイスとしての登録とユーザー認証が成功する
・この時点で、ME-ID ユーザー/デバイスとしての認証が行われ、ME-ID への [デバイスも含めたハイブリッドな認証] が完了する
・この時点の ME-ID デバイス オブジェクトの [登録済み] の状態はそのまま、[アクティビティ] の項目が [本ログオンを行った日時] になっている
・この時点で [MEHJ としての ME-ID へのデバイス認証] が完了し、クライアントに PRT (Primary Refresh Token) と呼ばれるデバイス認証トークンが発行される
つまり、1 回の Automatic-Device-Join タスクの実行で、ME-ID へのデバイスの登録/参加と、ユーザー認証による PRT の取得まで行えるイメージとなります。
2.sync-join の MEHJ フローの詳細
① オンプレ AD に参加している Windows 端末に、同期されているオンプレ AD ユーザーとしてログオンする
② 初回のログオンでは、Windows 側のタスク スケジューラーのタスクである Automatic-Device-Join が実行される
・この際、イントラネットの DC サーバーとインターネット (=ME-ID) 両方に通信できることで、タスクが成功して ME-ID とのデバイス認証に必要なデバイス証明書が作成される
・オンプレ AD コンピューター オブジェクトの userCertificate 属性にこのデバイス証明書が格納される
※ ログオン処理に伴うタスクの実行ではなく、管理者として起動したコマンド プロンプト上で dsregcmd /join を実行いただく方法でも同様の結果となります。
③上記 ②. の userCertificate 属性にデバイス証明書が格納されたコンピューター オブジェクトは、Microsoft Entra ID Connect (MEC) による同期対象となる
・つまり、②. 以降の MEC による同期時に、ME-ID に対してデバイス オブジェクトが同期される
・この時点では、ME-ID にデバイス オブジェクトが “ただ同期によって登録された” だけであり、まだデバイス認証には利用されていない
・この時点の ME-ID デバイス オブジェクトの [登録済み] の状態は、[保留中] になっている
④.再度 Windows へのログオン時に実行される Automatic-Device-Join タスクにより ME-ID へのデバイス参加のための認証処理が行われる。
・つまり、イントラネットの DC サーバーとインターネット (=ME-ID) 両方に通信できる状態での Windows へのログオンが必要
・この時点で、ME-ID のデバイス情報に呼応する認証が行われ、ME-ID への [デバイスのハイブリッドな参加状態] が完了する
・この時点の ME-ID デバイス オブジェクトの [登録済み] の状態は、[本ログオンを行った日時] になっている
※ ログオン処理に伴うタスクの実行ではなく、管理者として起動したコマンド プロンプト上で dsregcmd /join を実行する方法でも同様の結果となります。
※この時点では、ME-ID へのデバイス “参加” は完了しているものの、デバイス “認証” は完了していません。
⑤再度 ①のログオンもしくはアンロックを行うと、このログオン処理時に合わせて ME-ID へのユーザー認証も行われる (Automatic-Device-Join タスクではなくログオン時の処理となります)。
・この際には、インターネット (=ME-ID) に通信できる状態での Windows へのログオンが必要
・ME-ID は、提示されたユーザー情報を評価し、該当ユーザーがフェデレーション認証である場合、フェデレーション先への認証リダイレクトを返す。
・クライアントは、上記リダイレクトを受け、フェデレーション先 (ADFS) に対して (デバイスではなく) ユーザー認証を要求する
・ADFS にてユーザー認証が成功すると、ADFS はクライアントに対して ME-ID に提示可能なクレーム トークンを発行する
・上記を受け取ったクライアントは ME-ID にクレーム トークンを提示し、ユーザーの認証が成功する
・この時点で、ME-ID ユーザー/デバイスとしての認証が行われ、ME-ID への [デバイスも含めたハイブリッドな認証] が完了する
・この時点の ME-ID デバイス オブジェクトの [登録済み] の状態はそのまま、[アクティビティ] の項目が [本ログオンを行った日時] になっている
・この時点で [HME-IDJ としての ME-ID へのデバイス認証] が完了し、クライアントに PRT (Primary Refresh Token) と呼ばれるデバイス認証トークンが発行される
⑥以降の [ME-ID へのサインイン] 時には、⑤で取得した PRT が提示される
・この認証時に提示される PRT を元に、ME-ID は HME-IDJ 済みデバイスである、と認識する
・すでに PRT を取得済みのクライアントは、以降は Windows ログオン時もしくは約 4 時間毎にインターネットへの接続のみが行える状態であれば、PRT の更新が可能となる
Federated の MEHJ におけるユーザー認証の前提に関して
同期元のオンプレ AD ユーザーの UPN が xxx@contoso.local であっても、SCP の構成情報が [フェデレーション ドメイン] で構成されている場合、ME-ID への認証要求時にそのユーザー認証は Federated に遷移し、ADFS でのユーザー認証が行われます。
ここでクライアントが提示するユーザーの資格情報は Windows ログオン画面で指定した [オンプレ AD ユーザー] の資格情報になります。
このオンプレ AD ユーザーの資格情報を提示された ADFS は、オンプレ AD の DC サーバーに対して資格情報を提示してユーザーの認証を行います。
ここでユーザー認証が成功すると、ADFS の証明書利用者信頼の構成に即して、クライアントに対してクレーム トークンが発行されます。
このクレーム トークンをクライアントは ME-ID に提示し、サインインが完了して PRT を取得する、という流れです。
この処理を行うにあたり、以下の前提が必要になります。
①SCP が構成されており、且つその属性値としてフェデレーション ドメイン名が定義されている
②ADFS にて代替ログイン ID 構成が行われている
->代替 ID を手動で構成する
③ADFS と ME-ID 間で証明書利用者信頼が構成されており、MEHJ に必要なクレームの発行規則が ADFS 上で構成済みである
なお、上記の構成は [MEC サーバーにて、サインイン方式をフェデレーションとして構成し、ADFS ファームを “MEC の管理下に置く”] 状態にすることで、MEC の構成ウィザード内で構成されます。
①に関しては MEC の [デバイス オプションの構成] ウィザード実行によって作成することができ、②③に関しては MEC にてユーザー サインインで [AD FS とのフェデレーション] を選択してウィザードを進める中で ADFS を管理下に置くことで MEC から構成されます。
※MEHJ の目的だけに限らず、ME-ID ユーザーのフェデレーション認証の設計として [同期元オンプレ AD ユーザーの UPN と、同期先 ME-ID ユーザーの UPN 値が異なる (UPN 以外の mail 等の属性値を ME-ID ユーザーの UPN 値の同期元に指定している)] 場合、ADFS の代替ログオン ID 構成は必要となります（ADFSをMECの管理下に置く構成においては、自動的にADFSの代替ログインIDが構成されます。MECの以下で設定した属性が、ADFSの代替ログインIDの属性として使用されるようです）
MEC で ADFS を管理下に置かず、利用者自身で ADFS にクレーム発行ルールを構成する場合、MEHJ を実現するために、以下の技術情報にまとめられているクレームを 別途手動で構成する必要があります。
Microsoft Entra ハイブリッド参加の手動構成 – Microsoft Entra ID | Microsoft Learn
->要求の発行の設定
関連情報
ADFSの代替ログインIDとは
代替ログインID自体複数の意味を持ちます。
ADFSの文脈における代替ログインIDの意味は、「ADFSの認証画面（ＩＤ、パスワードを入力する画面。以下イメージ））において、ＩＤとして投入する値として、ADDSユーザのＵＰＮ属性ではなく、ＵＰＮ属性以外（mail属性等）の値を利用する方式」となります。
メモ
若干疑問点は残る（なぜ代替ログインID構成が必要なのか等）が、この辺りはMS製品内のコードレベルの話であり、ブラックボックスが多いため、「代替ログインID構成をすることで、MS製品内（ADDS、ADFS、Entra Connect、Entra ID)で適切な連携が行われるようになるのだろう、と想像し、調査は一旦ここまでとする（2025/12/20)。
■疑問点として残る点
- 「2.sync-join の MEHJ フローの詳細」において「ME-ID は、提示されたユーザー情報を評価し」とあるが、ME-IDに提示されるユーザ情報とは具体的に何か？「.local」をオンプレミスで利用している環境では、WIndowsへのログインへも「.local」を入力するため、ME-IDに送付されるユーザ情報は「.local」のUPNなのか？その場合、Entra IDは「.local」のUPN情報を保有していないはずなので、どのようにEntra ID上のユーザと紐づけるのか（Entra ID側からEntra Connect側に問い合わせが走っている？）。
- 「そのユーザー認証は Federated に遷移し、ADFS でのユーザー認証が行われます。ここでクライアントが提示するユーザーの資格情報は Windows ログオン画面で指定した[オンプレ AD ユーザー] の資格情報になります。」とあるが、ADFS代替ログインIDの設定が必須の状況下で、[オンプレ AD ユーザー] の資格情報（「.local」のUPNを想定）でADFSで認証が完了するのか（ADFS代替ログインIDの設定が必須であれば、mail属性等での認証が必要になるのではないか）
- そもそも、「.localを利用し続けつつ、Entraハイブリッドjoinを実現するために、ADFS方式を利用する場合、なぜADFS代替ログインIDの設定が必要なのか。