Microsoft Entra ID Hybrid Join を徹底検証！構成と証明書の挙動を深掘りする

この記事の内容

  • Microsoft Entra Connect Sync のインストールと Hybrid Join 構成手順
  • Hybrid Join 時に発生する証明書の種類と役割の違い
  • AD の userCertificate 属性と Entra ID 同期の関係
  • 属性を意図的に改ざん・削除した場合の挙動（意地悪テスト）
  • PRT（Primary Refresh Token）取得と SSO が成立する条件

検証環境

今回の検証には新規に構築した環境を使用しています。構成は以下のとおりです。

  • ドメインコントローラー（DC）× 2台
  • Windows 11 端末（初期状態はワークグループ参加）
  • Microsoft Entra ID テナント（開発用、カスタムドメイン割り当て済み）

この環境を起点に、Entra Connect Sync の導入からハイブリッドジョインの動作確認までを一通り実施しました。

Microsoft Entra Connect Sync のインストール

まず、DC 上に Microsoft Entra Connect Sync をダウンロードしてインストールします。

インストール開始時に以下のエラーが表示される場合があります。

TLS1.2が有効化されていません

この場合は Microsoft のドキュメントに記載されている PowerShell スクリプトを実行してレジストリを変更し、TLS 1.2 を有効にしてから再起動してください。

# TLS 1.2 有効化（Microsoftドキュメント掲載のスクリプトを使用）
# レジストリ変更後、サーバーの再起動が必要

再起動後、改めてインストールウィザードを起動するとエラーなく進行します。

今回は単一フォレスト・単一ドメインの構成のため、簡単設定を選択しました。設定内容は以下のとおりです。

  • Entra ID 管理者アカウントの資格情報を入力
  • オンプレミス AD の管理者資格情報を入力
  • パスワードハッシュ同期を有効化

構成完了後、テスト用ユーザーを AD 上に作成し、PowerShell で手動同期を実行して Entra ID 側にオブジェクトが反映されることを確認します。

Start-ADSyncSyncCycle -PolicyType Delta

Hybrid Join の構成（SCP の書き込み）

Hybrid Join を構成するには、Microsoft Entra Connect ウィザードを再度起動し、「追加のタスク」から「デバイスオプションの構成」を選択します。

  1. Hybrid Microsoft Entra 参加の構成 を選択
  2. 対象 OS として Windows 10 以降のドメイン参加済みデバイス を選択
  3. SCP（Service Connection Point）の構成 でフォレストを選択し、認証サービスに Microsoft Entra ID を指定
  4. AD 管理者の資格情報を入力して書き込みを実行

SCP が正しく書き込まれたかどうかは、ADSI エディター または ADSIEdit.msc で確認できます。

確認パス：

CN=62a0ff2e-97b9-4a43-99da.,CN=DeviceRegistrationConfiguration,CN=Services,CN=Configuration,DC=...

このオブジェクトのキーワード属性に、対象テナントの ID とドメイン名が格納されていれば構成完了です。

Windows 11 のドメイン参加と Hybrid Join の開始

Windows 11 をドメインに参加させると、Hybrid Join の処理が自動的に始まります。その流れは以下のとおりです。

タスクスケジューラーの役割

Windows には Hybrid Join を処理するためのタスクスケジューラータスクが標準搭載されています。

場所：

タスクスケジューラー>Microsoft>Windows>WorkplaceJoin>AutomaticDeviceJoin

このタスクはドメイン参加前は無効状態ですが、ドメイン参加後の最初のログオン時に自動で実行されます。内部では dsregcmd.exe が呼び出されます。

ドメイン参加直後の状態確認

ドメイン参加後の最初の再起動直後に以下のコマンドで状態を確認します。

dsregcmd /status

この時点では次のような状態になっています。

AEDznoutmreaeriApndrJJioosiiennJeeoddined:::NNYOOES

Entra ID 上にまだデバイスオブジェクトが存在しないため、タスクは実行されますが登録は失敗します。これは正常な動作です。

証明書の挙動を深掘りする

今回の検証で最も重要なポイントが、Hybrid Join 時に生成される証明書の挙動です。

登場する証明書は2種類

Hybrid Join のプロセスでは、用途の異なる2種類の証明書が関係します。

1. AD の userCertificate 属性に格納される証明書

  • ドメイン参加後、タスクスケジューラーが実行されると、コンピューターオブジェクトの userCertificate 属性に証明書データが書き込まれます
  • Entra Connect Sync は、この属性に値が存在するコンピューターオブジェクトのみを Entra ID へ同期します
  • 同期後、Entra ID 上のデバイスは「保留中」状態になります

2. ローカルコンピューターの証明書ストアに格納される証明書

  • タスクが正常に完了すると、ローカルコンピューターの「個人」ストアに証明書が格納されます
  • 発行者：MS-Organization-Access
  • この証明書は Microsoft Entra ID が発行したものです
  • 発行先のサブジェクトにはデバイス ID が含まれます

証明書の関係性

PowerShell スクリプトを使って AD の userCertificate 属性から証明書を取り出して比較した結果、以下のことが分かりました。

  • AD の属性に格納された証明書は自己署名です
  • ローカルの証明書ストアに格納された証明書は Microsoft Entra ID が署名したものです
  • 両者のサブジェクト（デバイス ID）は同じですが、シリアル番号や発行者が異なります

AD の userCertificate 属性に値が存在することが同期のトリガーとなり、その後の正式な登録プロセスで Entra ID 発行の証明書が生成されてローカルに保存されます。

Microsoft のドキュメントによる解説

Microsoft のサポートドキュメントによると、MS-Organization-Access 証明書の仕様は以下のとおりです。

  • Entra 参加済み、Hybrid 参加済み、Entra 登録済みのすべてのデバイスに発行される
  • ローカルコンピューターの「個人」証明書ストアに格納される
  • 有効期間：10 年
  • デバイスが Entra ID から登録解除されると、証明書ストアから削除される
  • この証明書を誤って削除するとユーザーの認証エラーが発生し、デバイスの再登録が必要になる

SSO が成立する条件

Hybrid Join が完了した状態でも、SSO（シングルサインオン）が成立するにはいくつかの条件を満たす必要があります。

dsregcmd /status でのSSO確認コマンド：

dsregcmd /status

ログインするユーザーが Entra ID に存在すること

ローカルの Administrator アカウントでログインしても SSO は成立しません。このアカウントは Entra ID 上に存在しないため、PRT の取得時に次のエラーが返されます。

invalid_grant-Useraccountdoesnotexistinthedirectory

AD から同期されたユーザーアカウントでログインすると、PRT が正常に取得され、SSOState が YES になります。

SSO 確認手順

  1. Entra ID に同期済みのドメインユーザーでサインイン
  2. ロック → ロック解除、またはサインアウト → サインインで PRT 取得をトリガー
  3. dsregcmd /status で AzureAdPrt : YES を確認

意地悪テスト：AD 属性を改ざんしたらどうなるか

テスト1：userCertificate 属性の値を改ざん

AD コンピューターオブジェクトの userCertificate 属性を任意の値に書き換えた状態で同期・タスク実行を行いました。

結果：

  • Entra ID にデバイスが「保留中」として同期される
  • タスクを実行しても保留が解消されず、デバイス認証は失敗する
  • 適当な値であっても同期はされるが、登録プロセスは完了しない

テスト2：userCertificate 属性を削除

userCertificate 属性を完全に削除した状態で同期を実行しました。

結果：

  • 次の同期タイミングで Entra ID 上のデバイスオブジェクトが削除される
  • デバイス認証が失敗する
  • 再度タスクを実行すると新しい証明書が生成され、属性が再設定される

テスト3：再参加後の証明書の扱い

dsregcmd /leave でデバイスを Entra ID から切り離した後、再度タスクを実行しました。

結果：

  • 新しい証明書が発行され、ローカルの証明書ストアに格納される
  • 古い証明書は削除される（上書きではなく置換）
  • AD の userCertificate 属性も新しいものに更新される

エンタープライズ CA がある場合の挙動

エンタープライズ CA（証明機関）が環境内に存在する場合、デバイス証明書が展開されている可能性があります。

今回の検証では、タスクスケジューラーによる Hybrid Join 処理は既存の証明書とは別に自己署名証明書を userCertificate 属性に追加する動作をしました。

すなわち：

  • エンタープライズ CA が発行した証明書がある場合、それは別途 userCertificate 属性に存在しうる
  • Hybrid Join プロセスが生成する証明書は、既存の属性値を上書きするのではなく追加される
  • どの証明書が Hybrid Join 用として利用されるかについては、登録プロセスを通じて正しいものが選択される

Graph API によるデバイス属性の確認

Entra ID 上のデバイスオブジェクトの属性は、Microsoft Graph Explorer から確認できます。

GEThttps://graph.microsoft.com/v1.0/devices/{object-id}

必要な権限：Device.Read.All

このクエリで取得できる属性の中に alternativeSecurityIds があり、デバイスの認証に使われるキー情報が含まれています。ただし、userCertificate 属性に相当するデータは Graph API 経由では直接確認できない場合があります。

まとめ

今回の検証で確認できた内容を整理します。

  • Hybrid Join の構成は Entra Connect ウィザードで SCP を AD に書き込むことで完了します。Windows 11 をドメイン参加させるだけで、タスクスケジューラーが自動的に Hybrid Join 処理を開始します。

  • 証明書は2種類存在します。AD の userCertificate 属性に格納される自己署名証明書と、Entra ID が発行してローカル証明書ストアに格納される MS-Organization-Access 証明書です。前者が同期のトリガーとなり、後者がPRT 取得に使用されます。

  • SSO が成立するにはユーザーが Entra ID に存在していることが必要です。ローカルアカウントのみのユーザーでは PRT を取得できません。

  • AD の userCertificate 属性を削除すると、次の同期タイミングで Entra ID 上のデバイスオブジェクトも削除されます。

  • 再登録すると証明書は更新され、新しい証明書のみが残ります。

  • 属性に任意の値が入っていても同期は実行されますが、Hybrid Join の登録プロセスは正常な証明書がなければ「保留中」のまま完了しません。

Hybrid Join 環境での認証トラブルを調査する際は、AD の userCertificate 属性の状態、ローカル証明書ストアの内容、Entra ID 上のデバイスオブジェクトの状態の3点を合わせて確認することが重要です。