AVD・VDI・Autopilot などの Hybrid Join を即時完了！～デバイス同期に依存しない新方式とは？

Last updated at 2026-09-06Posted at 2026-09-06

はじめに

ドメイン参加方式 (Hybrid Join) の環境で、Azure Virtual Desktop（AVD）や Windows 365、Windows Autopilot、物理PCのキッティングなどを運用していると、

「ドメイン参加は終わっているのに Hybrid Join にならない」
「なかなか Entra 管理センターにデバイスが表示されない」
「結局 30 分くらい待つことになる」
「すぐに同期させるために、即時同期のスクリプトを実行」

・・・などの経験をしていませんか？

従来の Hybrid Join では、Active Directory に作成されたコンピューターオブジェクトが Microsoft Entra ID へ同期されることで「保留」状態となり、その後にデバイス側で登録処理が実行されることでようやく Hybrid Join が成立する状況になっています。

そのため、

AVD や Windows 365 の展開
非永続 VDI の再作成
Windows Autopilot によるキッティング
新規 PC の大量展開

といったシナリオでは、デバイス同期のタイミングが運用のボトルネックになることがありました。

そんな中、Microsoft Learn に次のドキュメントが公開されました。

公開情報：Microsoft Entra Kerberos を使用した Microsoft Entra ハイブリッド結合 (プレビュー)
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731

本機能はプレビュー提供です

本番利用を検討する際には、サポート範囲や仕様変更の可能性について最新の公開情報を確認してください。

Hybrid Join using Microsoft Entra Kerberos
（Microsoft Entra Connect や AD FS に依存しない Hybrid Join）

この説明を見て、

「え？ Hybrid Join に Entra Connect は不要になるの？」

と思った方も多いのではないでしょうか。

私も最初はそう感じました。

しかし、実際に検証してみると、この機能の本質は Entra Connect を不要にすることではありません。
※ユーザーアカウントを同期するために、Entra との同期は引き続き必要です。

本当に変わるのは、

Hybrid Join のためにコンピューターオブジェクトの同期を待つ必要がなくなること

です。

つまりこの機能は、

AVD や Windows Autopilot、VDI のキッティング時に発生する「最大 30 分程度のデバイス同期待ち」を解消するための仕組み

と理解すると非常に分かりやすくなります。

本記事では、

なぜ「Entra Connect 不要」にできるのか？
実際には何が不要になるのか？
従来の Hybrid Join と何が違うのか？
AVD や Windows Autopilot でどのようなメリットがあるのか？

を整理しながら、Microsoft Entra Kerberos を利用した新しい Hybrid Join を検証していきます。

結論
本機能によって、

Hybrid Join の高速化
非永続 VDI の同期待ち解消
Entra Cloud Sync の採用促進

という3つの効果が期待できます。

記事の全体像

従来の Hybrid Join との違い

Microsoft Entra Kerberos を利用した新しい Hybrid Join と、従来方式の違いをまとめると次のようになります。

比較表

#	従来の方式 Hybrid Join	新方式 Entra Kerberos による Hybrid Join
デバイスオブジェクト同期	必要	不要
待ち時間	最大30分	なし（即時）
サポートする Entra Connect 方式	Connect Sync のみ (Cloud Sync ※1)	Connect Sync Cloud Sync 両対応
AVD / 非永続 VDI 適性	△	◎

参考：従来の Hybrid Join

Microsoft Entra ハイブリッド参加（旧HAADJ）を構成してみた
https://qiita.com/carol0226/items/7c16c4813e2b54a76789

※1：Cloud Sync によるデバイス同期（プレビュー）
Cloud Sync によるデバイス同期が最近プレビュー提供されていることに記事を公開してから気が付きました（2026年7月提供らしい）
新方式ほどリアルタイムな Join にはならないと考えられますが、新たな選択肢が加わっていることになります。

公開情報：Microsoft Entra Cloud Sync を使用してデバイス同期を構成する (プレビュー)
https://learn.microsoft.com/ja-jp/entra/identity/hybrid/cloud-sync/device-sync?wt.mc_id=MVP_407731

従来、同期ベースの Hybrid Join では主に Microsoft Entra Connect Sync によるデバイスオブジェクト同期が使用されていました。現在は Microsoft Entra Cloud Sync にもデバイス同期機能がプレビュー提供されています。Entra Kerberos 方式の相違点は、Cloud Sync を使えること自体ではなく、Hybrid Join 登録のためのデバイスオブジェクト同期待ちを不要にできることです。

本機能のもう一つの効能～ Hybrid Join と Connect Sync の依存関係がなくなる

今回の機能で注目されているのは、

「デバイス同期なしで Hybrid Join ができる」

という点です。

しかし、実際にはもう一つ大きな意味があります。

それは、

Hybrid Join のためだけに Entra Connect Sync を維持する必要がなくなる

ということです。

現在、オンプレミス Active Directory と Microsoft Entra ID の同期には、大きく２つの方式があります。

Entra Connect Sync
Entra Cloud Sync

Entra Connect Sync と Entra Cloud Sync の違い
以下の私の記事を参照してください。
２種類の Microsoft Entra Connect
https://qiita.com/carol0226/items/487874f07d2fe90f8e0c#２種類の-microsoft-entra-connect

近年は、構成のシンプルさや高可用性の観点から、Entra Cloud Sync を採用する組織が増えています。

一方で、従来の Hybrid Join には大きな制約がありました。

Hybrid Join を実現するためには、コンピューターオブジェクト（デバイスオブジェクト）を Entra ID へ同期する必要があります。

しかし、従来（2026年7月以前）、このデバイス同期に対応していたのは Entra Connect Sync のみでした。
（※現在は Cloud Sync でもデバイス同期のプレビューが開始されていますが、同期ベースである点は変わりません）

そのため、

「本当は Cloud Sync を採用したい」

と思っていても、

「Hybrid Join が必要だから Entra Connect Sync を残さなければならない」

という状況が発生していました。

今回の Microsoft Entra Kerberos を利用した Hybrid Join では、この前提が変わります。

本方式では、Hybrid Join の成立にデバイスオブジェクト同期を必要としません。

つまり、

ユーザー同期は Cloud Sync
Hybrid Join は Entra Kerberos

という組み合わせが可能になります。

従来の

「Hybrid Join が必要 = Entra Connect Sync が必要」

という前提が崩れることになります。

これは単なる Join の高速化ではなく、

Hybrid Join と Entra Connect Sync の依存関係を解消する仕組み

とも言えるでしょう。

Cloud Sync への移行プラン（例）
例えば現在、

Entra Connect Sync
Hybrid Join

を利用している環境であれば、

Microsoft Entra Kerberos を構成する
新方式の Hybrid Join を利用する
デバイス同期への依存をなくす
同期方式を Entra Cloud Sync へ移行する

という形での段階的な移行が考えられます。

Cloud Sync を採用したいが Hybrid Join が障壁になっていた組織にとっては、非常に大きな変化と言えるでしょう。

ここからは、実際の構築・検証手順です。

1. 前提条件

本機能の利用には、以下の公開情報で説明されている前提条件を満たす必要があります。

公開情報：[前提条件]
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731#prerequisites

1-1. ロールの要件
「Microsoft Entra Kerberos Trusted Domain Object (TDO) の作成と構成」の作業に必要なロール（権限）の説明
1-2. キー配布センター (KDC) プロキシサーバーグループポリシーオブジェクト (GPO) を構成する（省略可）
既に KDC プロキシを採用している環境では、本作業が必要となります。
通常はスキップ可。
作業を行うユーザーは、ドメイン管理者であるか、GPO を構成するための委任されたアクセス許可である必要があります。
1-3. Microsoft Entra Device Registration Service Principal の構成
Microsoft Entra デバイス登録サービスプリンシパルに Kerberos エントリを追加します。
作業には、アプリケーション管理者ロールが必要です。
1-4. Windows Server 2025 を実行するドメインコントローラーを展開
ビルド 26100.6905 以降をドメイン内に最低１台
1-5. Entra Kerberos ベースの参加用にクライアントコンピューターを構成する
Windows 11 ビルド 26100.6584 以降
1-6. ユーザーが Entra ID に同期されていること
Entra Connect Sync または Entra Cloud Sync どちらも可
1-7. サービス接続ポイント (SCP) の構成
すでに、Microsoft Entra Connect を使用して Hybrid Join を構成済みの場合は、SCP は設定済みになっています。Cloud Sync を使って初めて Hybrid Join を構成する場合には、SCP の設定が必要になります。

1-1. ロールの要件

2-1.章で実施する「Microsoft Entra Kerberos Trusted Domain Object (TDO) の作成と構成」の作業に必要なロールです。オンプレミス と クラウド の権限が必要な点に注意が必要です。

オンプレミス のロール
Active Directory Domain Services の Domain Admins グループと Enterprise Admins グループのメンバー
クラウド(Microsoft Entra ID) のロール
ハイブリッドアイデンティティ管理者

1-2. キー配布センター (KDC) プロキシサーバーグループポリシーオブジェクト (GPO) を構成する（省略可）

公開情報では、「クライアントコンピューターに KDC プロキシサーバー GPO を展開しなかった場合は、このセクションをスキップします。」 と説明されています。

公開情報：KDC プロキシサーバー GPO を構成する
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731#configure-the-kdc-proxy-server-gpo

私の環境では KDC プロキシを構成せずに検証を行い、新方式で Hybrid Join が動作することまで検証しています。

KDC プロキシについての見解と手順を見るにはココをクリックしてください

公開情報の 「クライアントコンピューターに KDC プロキシサーバー GPO を展開しなかった場合は、このセクションをスキップします。」 の記載の意味が良く分からなかったので考察してみました。
まず、前提として KDC プロキシとは、以下のような場合に使われている仕組みです。

KDC プロキシとは？
インターネットや外部ネットワーク上のクライアントと Active Directory の KDC の間を仲介し、ドメインコントローラーへの直接接続なしで Kerberos 認証を可能にする安全な中継サービスです。

KDC プロキシは、外部ユーザーやワークグループ参加デバイスなど、ドメインコントローラーへ直接到達できない環境で利用されます。もともとは DirectAccess、リモートデスクトップゲートウェイ、Azure Virtual Desktop (AVD)、SMB over QUIC などのシナリオ向けに設計されました。

公開情報：Kerberos キー配布センタープロキシを構成する (Azure Virtual Desktop)
https://learn.microsoft.com/ja-jp/azure/virtual-desktop/key-distribution-center-proxy?wt.mc_id=MVP_407731

公開情報：グループポリシーオブジェクト (GPO) を構成する (SQL Server Managed Instance)
https://learn.microsoft.com/ja-jp/azure/azure-sql/managed-instance/winauth-azuread-setup-incoming-trust-based-flow?view=azuresql#configure-the-group-policy-object-gpo

Geek Wolf: M365 kerberos.microsoftonline.com の紹介
https://geekwolf.cloud/2025/03/03/Introduction-to-M365-Kerberos-Microsoft-Online.html

上記に記載したような KDC プロキシの構成が行われている環境だった場合に、既存の KDC プロキシ構成を利用している環境との整合性を取るための手順ではないかと私は考えています。その場合に、以下の手順を実施します。

上記の公開情報の手順通りに設定した場合は、以下のように表示されれば OK です。
※作業を行うユーザーは、ドメイン管理者であるか、GPO を構成するための委任されたアクセス許可である必要があります。

下図のピンクでマスクした箇所は、Entra テナントの ID を記入します。

なお、私の環境では、KDC プロキシを使っていない環境ですが、上記の設定をあえて実施した場合でも、新方式で Hybrid Join は動作していました。そのため、KDC プロキシを構成していない環境で構成しても悪影響は無いものと考えられます。

1-3. Microsoft Entra Device Registration Service Principal の構成

前提事項としては、「アプリケーション管理者ロール」が必要です。

公開情報：Microsoft Entra デバイス登録サービスプリンシパルの構成
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731#configure-microsoft-entra-device-registration-service-principal

1-4. Windows Server 2025 を実行するドメインコントローラーを展開

ビルド 26100.6905 以降の Windows Server 2025 で稼働するドメコンが、ドメイン内に最低１台必要です。

公開情報：Windows Server 2025 を実行するドメインコントローラーを展開する
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731#deploy-a-domain-controller-that-runs-windows-server-2025

以下の私の記事を参考にして、環境を手配してみてください。

Azure 上で Active Directory を構築＆ドメイン参加（Windows Server 2025 対応）
https://qiita.com/carol0226/items/6ecfb5840fa700971a1f

Active Directory ドメインサービス (ADDS) の導入
https://qiita.com/carol0226/items/b94f93adc309b5dc8ee8

考察
公開情報には、以下の記載があります。前提事項ではドメイン内に１つ以上の 2025 DC が必要と説明されているのに、ここではすべてと書かれています。

これは困惑します。公開情報をよく読むと、以下の３通りのことを言っています。

ドメイン内に１つ以上の 2025 DC
Hybrid Join を実行するすべてのドメインに 2025 DC
クライアントコンピューターは、2025 DC との接続が妨げられていない必要がある

これは、新方式の Hybrid Join を実施するデバイスのアクセス先は、2025 DC だけにしろと言っているのか、疎通さえできればよいのかが良く分かりません。

なお、私の環境では 2022 と 2025 DC が同一ネットワークに配置された構成でした。
この状態で、15回ほどドメイン参加を実施してみましたが、いずれも新方式で Hybrid Join が成立することを確認しています。

1-5. Entra Kerberos ベースの参加用にクライアントコンピューターを構成する

クライアントコンピューターは Windows 11 ビルド 26100.6584 以降である必要があります。

公開情報：Microsoft Entra Kerberos 参加用にクライアントコンピューターを構成する
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731#configure-the-client-computer-for-microsoft-entra-kerberos-join

物理PC、仮想マシン、Azure VM など、いずれも可能ですが、ドメインコントローラーとの疎通可能な環境である必要があります。

Hyper-V へ Windows 11 をインストールする
https://qiita.com/carol0226/items/eeced2b88e6d8a9914e7

ためしに、わざと要件外のバージョン (Windows 10 22H2) を使ってドメイン参加させてみましたが、当然のことながら、従来方式での Hybrid Join の動作となったことを確認しています。

1-6. ユーザーが Entra ID に同期されていること

Entra Connect Sync または Entra Cloud Sync の構成が必要です。

Entra Connect Sync の場合
以下の私の記事を参考にして、環境を手配してみてください。
Microsoft Entra Connect とは（旧：Azure AD Connect）
https://qiita.com/carol0226/items/487874f07d2fe90f8e0c
　
Entra Cloud Sync の場合
公開情報：Microsoft Entra Cloud 同期とは
https://learn.microsoft.com/ja-jp/entra/identity/hybrid/cloud-sync/what-is-cloud-sync?wt.mc_id=MVP_407731

1-7. サービス接続ポイント (SCP) の構成

すでに、Microsoft Entra Connect を使用して Hybrid Join を構成済みの場合は、SCP は設定済みになっているため、構成は不要です。Cloud Sync を使って初めて Hybrid Join を構成する場合には、SCP の設定が必要になります。

公開情報：サービス接続ポイントの構成
https://learn.microsoft.com/ja-jp/entra/identity/devices/hybrid-join-manual?wt.mc_id=MVP_407731#configure-a-service-connection-point

Entra Cloud Sync で Entra Hybrid Join を構成する方法
@mokonacl さんが記事を公開されており、この記事内で SCP の設定についても触れられています。
　
Entra Connectクラウド同期とEntra KerberosによるMicrosoft Entra ハイブリッド参加
https://qiita.com/mokonacl/items/bcada8caf5a7bbefa2e9

2. 構築手順

手順の概要

① 環境（ドメイン＆テナント）ごとに１回必要です

2-1. Microsoft Entra Kerberos Trusted Domain Object (TDO) の作成と構成
Entra Kerberos の構成に加えて -SetupCloudTrust の設定を追加します。
　
2-2. デバイス登録サービスの構成
Microsoft Entra ID 側の Device Registration Service Principal を構成するための作業です。

② Hybrid Join を実施するデバイスごとに必要です　

2-3. クライアントのドメイン参加
- Windows 11 をオンプレ AD に参加
- 起動・サインイン時に Entra Kerberos を使用し、デバイス同期を待たずに Hybrid Join
  　
2-4. 状態確認
dsregcmd /status を実行すると、
次の状態が 短時間で成立 します。
- DomainJoined : YES
- AzureAdJoined : YES

2-1. Microsoft Entra Kerberos Trusted Domain Object (TDO) の作成と構成

以下の公開情報で説明されている手順の構成が必要となります。

公開情報：Microsoft Entra Kerberos の信頼されたドメインオブジェクトを作成して構成する
https://learn.microsoft.com/ja-jp/entra/identity/devices/how-to-hybrid-join-using-microsoft-entra-kerberos?wt.mc_id=MVP_407731#create-and-configure-microsoft-entra-kerberos-trusted-domain-object
（上記より抜粋）

上記の赤枠で囲んだリンクが、以下の公開情報になっています。

公開情報：受信信頼ベースのフローで Microsoft Entra ID の Windows 認証を設定する方法
https://learn.microsoft.com/ja-jp/azure/azure-sql/managed-instance/winauth-azuread-setup-incoming-trust-based-flow

具体的な手順は、以下となります。

1．作業前確認として、AD サーバーで Active Directory ドメインと信頼関係を開いて、信頼タブを開きます。以下の画面が表示されるため、この状態を覚えておきましょう。

ポイント
本作業を完了すると、入力方向の信頼に１行追加されます。
そのため、ビフォーアフターを確認することが目的です。

※他のドメインとの信頼関係が構成されている場合には、すでに値が入っています。

2．以下の私の記事を参照し、Entra Kerberos を構成します。

Microsoft Entra Kerberos 認証を構成しオンプレミスへ SSO する
https://qiita.com/carol0226/items/a52a54ff63c19fa957e6

ポイント
別の目的で、過去に上記の記事をみて Entra Kerberos の構成が完了している人もいるかもしれません。

その場合は、それだけでは設定が足りません。

今回は、Entra Kerberos の設定に加えて、-SetupCloudTrust を付与する必要があります。これがつまり TDO の構成ということになります。

2．Entra Kerberos の状態を表示します（上記の私の記事の続きの作業になります）
CloudTrustDisplay の欄が空欄な状態です。

3．Set コマンドで -SetupCloudTrust パラメーターを追加しています。

4．以下のように CloudTrustDisplay に値が表示されるようになれば OK です。

5．再度、Active Directory の信頼関係を表示させると、下図のように１行追加されていれば OK です。

Get-ADTrust -Filter * のコマンドでも確認することができます。

ポイント
作成された入力方向の信頼を GUI から削除しても、本手順でふたたび -SetupCloudTrust を実行すれば、復元させられます。

2-2. デバイス登録サービスの構成

本手順は Microsoft Entra ID 側の Device Registration Service Principal を構成するための作業です。
そのため、ドメインコントローラーで実施する必要もなく、疎通も必要ありません。

Entra PowerShell が利用できる管理用端末とインターネット接続があれば実施可能です。
私は、Entra Join された端末で実行してみました（ドメイン参加はされていない PC です）

2-2-1. Microsoft Entra PowerShell をインストールします。

1．$PSVersionTable.PSVersion でバージョンを確認する。

表示されたバージョンによって、公開情報を読み分けます。

公開情報：Microsoft Entra PowerShell をインストールする (Ver.5 の場合)
https://learn.microsoft.com/ja-jp/powershell/entra-powershell/installation?tabs=windowspowershell&wt.mc_id=MVP_407731

公開情報：Microsoft Entra PowerShell をインストールする (Ver.7 の場合)
https://learn.microsoft.com/ja-jp/powershell/entra-powershell/installation?tabs=powershell&wt.mc_id=MVP_407731

これ以降は、Ver.5 で実行した際のキャプチャになっています。

2．Microsoft Entra PowerShell モジュールが導入されているかどうかを確認します。

Get-Module -Name Microsoft.Entra -ListAvailable

以下のように表示された場合は、入っていません。

既に導入されている場合
ここで、以下のように表示されたら、すでに導入済みです。

3．PowerShell Get を更新します。

Install-Module -Name PowerShellGet -Force -AllowClobber

4．PowerShell 実行ポリシーをリモート署名済みに設定します。

Get-ExecutionPolicy -List
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

5．Microsoft Entra PowerShell モジュールをインストールします。

Install-Module -Name Microsoft.Entra -Repository PSGallery -Scope CurrentUser -Force -AllowClobber

実行中は、以下のような進捗状況を示す表示が行われます。

6．再度 Microsoft Entra PowerShell モジュールが導入されているかどうかを確認します。

Get-Module -Name Microsoft.Entra -ListAvailable

2-2-2. デバイス登録サービスプリンシパルの構成スクリプト実行

公開情報には１ステップずつの手順と、１発ですべてを構成するスクリプトが掲載されています。
１発スクリプトの内容を解析した結果、環境を判断しながら安全に進める工夫が凝らされていることが分かり、これだったら、１発スクリプトでちゃんと構成できた・・という実績を公開した方が世のためになると判断しました。

1．公開情報をひらき、以下の場所で コピー を押してスクリプトをコピーします。

2．PowerShell に貼り付けて実行します。

3．認証画面が表示されるので、認証します。

4．私の環境では、以下のように途中で止まってしまいました。

5．再度スクリプトを貼り付けることで、続きが実行されました。

本手順では Application Administrator ロールが必要です。

権限が不足していると、次のエラーが表示されましたが、権限のあるアカウントで再実行すれば問題ありません。
Insufficient privileges to complete the operation.

2-3. クライアントのドメイン参加

クライアントコンピューターを Active Directory ドメインに参加させ、再起動します。

ドメイン参加の手順は、以下の私の記事（ドメイン参加の章）を参照してみてください。

2-4. 状態確認

結果の確認です。次の状態が 短時間で成立 します。

Microsoft Entra 管理センター
新方式の Hybrid Join では、ドメイン参加を行いデバイスの再起動を行うと１分も待たないくらいのタイミングで以下の表示になります。参加の種類は "Microsoft Entra hybrid joined"、登録済み のステータスには、日時が記録されます。

従来方式の Hybrid Join の動作
ドメイン参加後、すぐには Hybrid Join が有効にはなりません。Entra のデバイス一覧には表示されません。
以下のように、デバイスが同期されて表示されるまで最大30分掛かります。登録済みのステータスは、保留と表示されています。

そのあと、デバイス側で登録タスクが動作（または dsregcmd /join）をすると、以下のように保留から日時に更新されます。

アクティビティが更新されるまでは、さらに時間が必要でした。

デバイス側
ログオン後に、 dsregcmd /status を実行すると、以下の設定が YES になっています。

DomainJoined : YES
AzureAdJoined : YES

ドメイン離脱時の動作
新方式・従来方式で同じでした。
※Entra デバイス一覧からは即削除・AD コンピューターオブジェクトは、無効の状態

3. Intune との連携

Hybrid Join されたデバイスは、グループポリシーによって Intune へ自動登録する構成が以前からサポートされています。

新方式の Hybrid Join でも同様に、Hybrid Join の成立と連携して Intune 登録が行われます。

そのため、デバイスのデプロイ（キッティング）時に、Hybrid Join とともに、Intune へ登録し、早期に Intune 準拠状態を作ることも可能になりました。

事前のテナント設定やライセンスなどについては、以下の私の記事で説明しています。

4. Windows Autopilot との連携

Windows Autopilot で Hybrid Join を構成する場合は、独特な制御が行われています。
Autopilot サービスおよび Intune への事前登録を経た後、Intune Connector for Active Directory が AD コンピューターオブジェクトと ODJ blob を生成し、デバイスをオンプレミス AD ドメインへ参加させます。
その後、デバイス登録処理により最終的に Microsoft Entra Hybrid Joined 状態になります。

従来の Hybrid Join 方式では、このあとコンピューターオブジェクトが Entra 側へ同期されるまでに最大30分の待ちが必要でした。

新方式によって、ドメイン参加後に行われる Hybrid Join の登録処理を待たずに完了できることが期待できるため、Autopilot でも効果を発揮することが期待できます。

Hybrid Join + Windows Autopilot の構成は、以下の私の記事を参照してください。

Microsoft の Autopilot 公式手順では、本方式との組み合わせが明示されていないため、本番導入前に十分な検証が必要です。

なお、事例はあるだろうなと思って調べてみると、海外では実際に Autopilot と新方式の Hybrid Join を組み合わせた記事は出ている様子です。

5. その他注意点

繰り返しテストを行う場合の注意点：ドメイン管理者権限
ドメインから手動で離脱したあとに、再度ドメイン参加を実施して Hybrid Join を成立させることは可能でした。新規ドメイン参加時と同様に、離脱＆再参加でも、新方式なら即 Hybrid Join されました。

ドメインから離脱場合は、Entra ID のデバイス一覧からは消えますが、AD のコンピューターオブジェクトは残ります。

AD 側にコンピューターオブジェクトが残っている場合、ドメイン再参加の際には、管理者権限が必要です。一般ユーザーでドメイン参加をすると、以下のエラーが発生します。
コンピューターオブジェクトを削除すれば、一般ユーザーでもドメイン参加が可能です。

繰り返しテストを行う場合の注意点：ローカル管理者権限
ドメイン参加を行う際に、以下の選択肢が表示されます。

ここで、Domain Users しか権限を持たないユーザーが、Standard User を選択した場合は、RDP 権限が無いことに注意しましょう。以下のエラーが出ます。

これを避けるためには、ドメイン参加する際に、Administrator を選択することで、ホストへの RDP 権限が保持できます。

高い権限を持つユーザーの場合（でも動作しました）
Entra Kerberos を使ったパスワードレスのログオンでは、高い権限を持つユーザーの場合、Kerberos チケットを受け取れない・・という仕様があります。今回、新方式の Hybrid Join では、Entra Kerberos の仕組みが使われているので、同様の影響を受けるのかと思いましたが、そんなことはなく、Enterprise Admins や Domain Admins の権限を持つユーザーがドメイン参加を実施しても、新方式で Hybrid Joined の状態になりました。

正しい手順を構築して動作させれば、なんてことはない事象なのですが、私は環境構築後にうまく動作せず、上記の件が影響している可能性も考える必要があって無駄に時間を費やしたので、記載しておきました。

6. まとめ

Microsoft Entra Kerberos を利用した新しい Hybrid Join は、単なる「Join の高速化機能」ではありません。

従来の Hybrid Join が依存していた

デバイスオブジェクト同期
Entra Connect Sync

といった前提を見直し、

デバイス同期待ちの解消
非永続 VDI の運用改善
Cloud Sync と Hybrid Join の両立

を実現できる可能性を持つ仕組みです。

特に、

Azure Virtual Desktop (AVD)
Windows 365
非永続 VDI
Windows Autopilot

のような、大量展開や再作成が頻繁に発生する環境では、これまで当たり前だった「最大30分程度のデバイス同期待ち」を解消できる可能性があります。

今回の検証では、

KDC プロキシを構成しない環境
Windows Server 2022 と 2025 のドメインコントローラーが混在する環境

においても、新方式の Hybrid Join が正常に動作することを確認できました。

一方で公開情報には、

Windows Server 2025 DC の要件
KDC プロキシの役割
クライアントから 2025 DC への到達性

など、まだ解釈に迷う部分も残っています。

そのため、本番環境への導入にあたっては十分な検証が必要ですが、Hybrid Join の設計そのものを変える可能性を持った非常に興味深い機能だと感じています。

特に、

「Hybrid Join が必要だから Entra Connect Sync が必要」

という従来の前提が崩れたことは、大きな変化と言えるでしょう。

本記事が、Microsoft Entra Kerberos を利用した Hybrid Join を検討している方の参考になれば幸いです。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AVD・VDI・Autopilot などの Hybrid Join を即時完了！～ デバイス同期に依存しない新方式とは？