Microsoft Entra IDは2026年6月より、Entra Connect SyncまたはCloud SyncによるオンプレミスADからEntra IDへの「ハードマッチング」を、Entraロールを保持するクラウド管理ユーザーオブジェクトに対してブロックする運用に変更した。特権昇格攻撃への対策として実施されたこのセキュリティ強化は、ハイブリッドID環境を運用する多くの日本企業に直接影響する。
ハードマッチングとは何か
Entra Connect Syncを使ってオンプレミスのActive Directory（AD）とEntra IDを同期する場合、ディレクトリ間でオブジェクトを紐付ける方法が2つある。
- ソフトマッチング（Soft Matching）: UPNやSMTPアドレスなどの属性を使って自動的に一致させる方法
- ハードマッチング（Hard Matching）:
ImmutableId（sourceAnchor）を直接書き込み、オブジェクトを強制的に紐付ける方法
ハードマッチングは移行シナリオや既存オブジェクトの引き継ぎで便利な反面、「攻撃者がオンプレミスADを侵害した際に、クラウド側の特権ユーザーアカウントに自由に紐付けて乗っ取る」という権限昇格攻撃の経路になり得る。今回のブロックはこの穴を塞ぐ措置だ。
何が変わるのか
ロール保持ユーザーへのハードマッチングがブロック
2026年6月1日以降、Entra IDロール（グローバル管理者、特権ロール管理者など）を保持しているクラウドユーザーオブジェクトに対して、オンプレミスからのハードマッチングが拒否されるようになった。
影響を受けるシナリオは主に以下の通り：
- Entra Connect Syncを使った既存構成のメンテナンス中に特権ユーザーを再マッチングしようとするケース
- Cloud Sync経由でADからオブジェクトを取り込む際に管理者アカウントと紐付けようとするケース
- ディザスタリカバリやテナント移行でImmutableIdを操作するケース
Connect Syncの設定変更に管理者認証が必須に（近日対応予定）
あわせて予告されている変更として、Entra Connect Syncの設定変更（機能の有効化・無効化など）に際して、クラウド管理者のインタラクティブ認証が必須になる。ウィザードからの操作でもPowerShellからの操作でも、変更を確定するために認証済み管理者のサインインが求められる。
これにより、万が一Connect Syncサーバー自体が侵害されても、設定を勝手に変更することが格段に難しくなる。
NetBIOS名解決テストが「情報提供のみ」に格下げ
Entra ConnectのAD DSヘルス監視エージェントにある「NetBIOS Name Sysvol Connectivity」テストが、アラート生成対象から情報提供のみに変更された。NetBIOSは現代のAD環境では必須でなくなっているケースが多く、アラートノイズを減らす実用的な変更といえる。
実務への影響——日本のIT管理者が今すぐ確認すべきこと
影響を受ける可能性のある構成の確認
まず現在の環境でハードマッチングを使っているかどうかを確認する。Entra Connect SyncでImmutableIdを手動設定しているオブジェクトが対象になる。
ImmutableIdが設定されているユーザーを確認
Get-MgUser -All -Property DisplayName,UserPrincipalName,OnPremisesImmutableId | Where-Object { $_.OnPremisesImmutableId -ne $null } | Select-Object DisplayName, UserPrincipalName, OnPremisesImmutableId
特権ロールの棚卸し
次に、Entraロールを保持しているクラウドユーザーを棚卸しする。特に「クラウドオンリーで作成した管理者アカウント」に対して、何らかの同期設定が絡んでいないかを確認したい。
Entraロールを保持しているユーザー一覧
Get-MgRoleManagementDirectoryRoleAssignment -All | Where-Object { $_.PrincipalType -eq ‘User’ } | Select-Object -ExpandProperty Principal
移行・DR計画の見直し
今後のテナント移行やディザスタリカバリ計画に「特権ユーザーへのハードマッチング」が含まれている場合は、代替手順を検討しておく必要がある。ロールを一時的に外してからマッチングし、完了後に再付与するフローが現実的な回避策になる。
Connect Sync設定変更の運用フロー見直し
近日中に適用されるConnect Sync設定変更の管理者認証要件についても、変更管理プロセスにインタラクティブ認証のステップを組み込む準備をしておきたい。自動化スクリプトで設定変更を行っている環境では、対応が必要になる可能性がある。
筆者の見解
この変更は地味に見えて、実はかなり重要なセキュリティ強化だ。
ハイブリッドID環境において、オンプレミスのADは「クラウドへの橋頭堡」として常に攻撃者に狙われる。ADが侵害されれば、ハードマッチングという正規の同期機能を使って、クラウド側の特権アカウントを乗っ取ることが理論上可能だった。今回のブロックはその経路を塞ぐ措置であり、方向性としては完全に正しい。
「常時アクセス権の付与は特権アカウント管理における最大のリスク」という原則からすれば、そもそも特権ロールをクラウドユーザーに永続的に付与した状態で同期の対象にしていること自体が問題の根っこだ。Entra PIMを使ったJust-In-Time（JIT）でのロール昇格を組み合わせれば、ハードマッチングの必要性そのものをかなり減らせる。
MicrosoftがID基盤のセキュリティ強化に継続的にコミットしているのは評価できる。ただ、こうした変更が「突然の制限」として現場に降ってくると、運用担当者が慌てることになる。事前の影響調査ツールや移行ガイドをもっと早い段階で整備してほしいというのが正直なところだ。今回の変更も、実際の適用前に自環境への影響を把握できる仕組みがあれば、現場の準備がより楽になる。
Microsoft Entra IDをID管理の基盤として使い続けることの妥当性は揺らいでいない。その上で、この変更をきっかけに「ハイブリッドID環境における特権アカウントの管理が本当に適切か」を見直す機会にしてほしい。
出典: この記事は Microsoft Entra ID blocks hard-matching to role-holding cloud users from June 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。