Microsoft Entra Connect Sync / Cloud Sync を運用している組織は、2026年6月1日以降、Microsoft Entra ロールを持つ既存のクラウド管理ユーザーに対するハードマッチがブロックされる点を最優先で確認すべきです。これは単なる同期仕様の変更ではなく、オンプレミス Active Directory 側の属性操作を起点に、クラウド上の特権ユーザーを引き継ぐ権限昇格パスを閉じるためのセキュリティ変更です。Microsoft は、Microsoft Entra Connect Sync または Cloud Sync が、新しい AD ユーザーを Microsoft Entra ロール保持ユーザーへ hard-match しようとする処理をブロックすると案内しています。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Microsoft Entra の hard-match security change が何を防ぐのか、影響を受ける構成、2026年6月1日までに管理者が確認すべき項目、エラー発生時の現実的な対応方針を整理します。対象は、Microsoft Entra Connect Sync / Cloud Sync を扱う Hybrid identity admin、セキュリティアーキテクト、Microsoft 365 / Entra ID 管理者です。
Microsoft Entra Connect Sync / Cloud Sync のハードマッチ変更で何が変わるのか
今回の変更点は明確です。Microsoft Entra ロールを保持しているクラウド管理ユーザーに対して、新しいオンプレミス AD ユーザーをハードマッチさせ、Source of Authority（SoA）をオンプレミス側へ引き継ぐ処理がブロックされます。
Microsoft の公開情報では、2026年6月1日から、Microsoft Entra Connect Sync または Cloud Sync が、Active Directory から追加された新しいユーザーオブジェクトを、Microsoft Entra ロールを持つ既存のクラウド管理ユーザーへ hard-match する試みをブロックすると説明されています。対象のクラウド管理ユーザーに onPremisesImmutableId、つまり sourceAnchor が設定されており、かつ Microsoft Entra ロールが割り当てられている場合、同期による SoA の乗っ取りはできなくなります。(TECHCOMMUNITY.MICROSOFT.COM)
| 項目 | 変更後の扱い | 管理者が見るべきポイント |
|---|---|---|
| Microsoft Entra ロールを持つクラウド管理ユーザーへのハードマッチ | ブロック対象 | 管理者ロール、PIM 対象、緊急アクセス用アカウントを棚卸しする |
| ロールを持たないクラウドユーザーへのハードマッチ | 今回の変更では影響なし | ただしテナント全体の hard-match ブロック設定には注意する |
| ソフトマッチ | 今回の変更では影響なし | 既存の管理者ロール衝突や属性重複エラーは別途確認する |
| すでにハードマッチ済みの継続同期 | 今回の変更では影響なし | OU 除外、復元、再同期などで「新しいマッチング」が発生する場合は注意する |
重要なのは、「Microsoft Entra Connect Sync をアップグレードすればよい」という話ではない点です。Microsoft Entra ID 側がハードマッチの試行をブロックするため、Cloud Sync を使っている場合も対象になります。同期エンジンの種類よりも、ロールを持つクラウド管理ユーザーを、オンプレミス AD 由来の新規オブジェクトで引き継ごうとしていないかが判断軸になります。
そもそもハードマッチとは何か
ハードマッチとは、オンプレミス AD から同期される新しいオブジェクトと、既存の Microsoft Entra ID オブジェクトを、sourceAnchor / OnPremisesImmutableId の一致によって結び付ける仕組みです。
Microsoft Entra Connect または Cloud Sync が新しい AD オブジェクトを追加すると、Microsoft Entra ID は受信した sourceAnchor の値を、既存のクラウド管理オブジェクトの OnPremisesImmutableId と照合します。一致した場合、そのクラウドオブジェクトの SoA がオンプレミス側へ移り、AD 側の属性でクラウド側の属性が更新されます。これが hard-match です。(TECHCOMMUNITY.MICROSOFT.COM)
似た言葉にソフトマッチがあります。ソフトマッチは userPrincipalName や proxyAddresses を使って既存ユーザーを探す方式です。Microsoft Learn では、userPrincipalName または proxyAddresses による一致を soft-match、sourceAnchor による一致を hard-match と説明しています。(Microsoft Learn)
| マッチ方式 | 主な照合キー | 使われる場面 | 失敗しやすいポイント |
|---|---|---|---|
| ハードマッチ | sourceAnchor / OnPremisesImmutableId | 既存クラウドユーザーをオンプレミス管理へ移す、フォレスト移行後に同一ユーザーとして接続する | sourceAnchor の不一致、特権ユーザーへのマッチ、テナント側の hard-match ブロック |
| ソフトマッチ | UPN、primary SMTP address | 既存クラウドユーザーと AD ユーザーをメールアドレスなどで結び付ける | proxyAddresses 重複、UPN 重複、ImmutableId が既に設定済みのユーザー |
ハードマッチ自体は、正しく使えば移行や復旧に役立つ機能です。問題は、クラウド側の特権ユーザーまでオンプレミス AD 側から引き継げる状態にしておくと、オンプレミス環境の侵害が Entra ID の特権侵害につながる可能性があることです。
この変更が閉じる「権限昇格パス」
今回の hard-match security change が防ごうとしているのは、オンプレミス AD の操作権限を足場にして、Microsoft Entra ID の特権ユーザーを乗っ取るパスです。
典型的には、次のような条件が重なるとリスクが高まります。
| リスク条件 | なぜ危険か |
|---|---|
| クラウド管理ユーザーが Microsoft Entra ロールを持っている | Global Administrator、Privileged Role Administrator、Hybrid Identity Administrator などの権限が乗っ取り対象になり得る |
| そのクラウドユーザーに OnPremisesImmutableId が設定されている | AD 側の sourceAnchor と一致すれば hard-match の対象になり得る |
| オンプレミス AD 側でユーザー属性を変更できる権限がある | 攻撃者や誤設定が、意図しないマッチングを誘発する余地がある |
| Password Hash Sync を使っている | 既存ユーザーを同期で引き継ぐと、クラウド側のパスワードハッシュがオンプレミス AD 側の値で上書きされる可能性がある |
Microsoft Learn でも、既存の Microsoft Entra ID ユーザーと同期ユーザーが一致すると、クラウド管理だったオブジェクトがオンプレミス管理へ変換され、オンプレミス AD に値がある属性はクラウド側で上書きされると説明されています。Password Hash Sync を使う場合、Microsoft Entra ID 側のパスワードハッシュもオンプレミス AD 側のハッシュで上書きされるため、計画なしに既存ユーザーを同期対象へ入れるのは危険です。(Microsoft Learn)
つまり、今回の変更は「AD と Entra ID の同期が失敗しやすくなる変更」ではなく、クラウド特権アカウントをオンプレミス AD から奪える余地を狭める変更です。ハイブリッドID環境では、オンプレミス AD の管理権限とクラウドの管理権限を同じ信頼境界で扱わない設計が重要になります。
影響を受けやすい運用シナリオ
特に注意すべきなのは、日常的なユーザー作成よりも、移行・復旧・再同期の場面です。平常時は問題が表面化していなくても、OU フィルターの変更、AD フォレスト移行、削除済みユーザーの復元、Cloud Sync への切り替えなどをきっかけに、新しいマッチング処理が発生することがあります。
AD フォレスト移行やアカウント再作成
フォレスト移行で新しい AD ユーザーを作り、既存の Entra ID ユーザーへ同一人物として接続したい場合、ハードマッチを使う設計が取られることがあります。対象ユーザーに Microsoft Entra ロールが残ったままだと、2026年6月1日以降は InvalidHardMatch のような同期エラーに直面する可能性があります。Microsoft Learn は、既存の Microsoft Entra オブジェクトに特権ロールがあり OnPremisesImmutableId を持つ場合、危険な hard match を防ぐため InvalidHardMatch が発生する条件を説明しています。(Microsoft Learn)
クラウド専用管理者を後からオンプレミス管理へ移す運用
Microsoft は、既存の Microsoft Entra ID 管理者アカウントとオンプレミスアカウントを同期させることを強く推奨していません。管理者アカウントを「後から同期に乗せる」運用は、データ上書きや権限継承の面で事故が起きやすく、今回の変更後はさらにブロック対象として表面化しやすくなります。(Microsoft Learn)
緊急アクセス用アカウントの扱い
緊急アクセス、いわゆる break-glass アカウントは、同期対象に入れないクラウド専用アカウントとして分離するのが基本です。Microsoft は、緊急時に使うクラウド専用の Global Administrator アカウントを用意することを推奨しています。(Microsoft Learn)
緊急アクセス用アカウントをオンプレミス AD と結び付けてしまうと、オンプレミス障害や AD 侵害の影響を受けやすくなります。今回の変更を機に、緊急アクセス用アカウントが同期スコープ外であること、通常業務に使われていないこと、条件付きアクセスや MFA の例外設計が文書化されていることを確認してください。
2026年6月1日までに実施すべき確認リスト
変更日前にやるべきことは、「全ユーザーを調べる」ではなく、ロールを持つクラウド管理ユーザーと、ハードマッチを使う予定の運用を交差させて確認することです。
| 優先度 | 確認項目 | 判断基準 |
|---|---|---|
| 高 | Microsoft Entra ロールを持つユーザーの棚卸し | Active assignment だけでなく、PIM の eligible assignment も確認する |
| 高 | ロール保持ユーザーの同期状態 | クラウド専用か、同期済みか、OnPremisesImmutableId があるかを見る |
| 高 | 6月1日以降の移行・復旧作業 | AD フォレスト移行、OU 再スコープ、ユーザー復元、Cloud Sync 切り替えがないか確認する |
| 中 | テナント全体の hard-match ブロック設定 | BlockCloudObjectTakeoverThroughHardMatchEnabled を必要時以外 True にできるか判断する |
| 中 | 監視とエスカレーション | InvalidHardMatch を誰が検知し、誰がロール一時解除を承認するか決める |
| 中 | 手順書の更新 | 「管理者ロールを外してから同期する」などの例外手順に承認フローを入れる |
Microsoft Learn では、ハードマッチを使ってクラウド専用アカウントを引き継ぐ必要がない限り、hard matching を無効化することが推奨されています。設定後は、必要なマッチング作業が終わったら再び True に戻すべき設定として扱われます。(Microsoft Learn)
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockCloudObjectTakeoverThroughHardMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Featuresこの設定は、今回の「ロール保持クラウドユーザーへのサービス側ブロック」と同じものではありません。テナント全体で hard-match takeover を抑止する追加の防御策として整理すると理解しやすくなります。
InvalidHardMatch が出たときの対応方針
2026年6月1日以降、正当な移行作業であっても、対象のクラウドユーザーに Microsoft Entra ロールが残っていると hard-match が失敗する可能性があります。Microsoft Learn は、InvalidHardMatch の条件として、テナントで BlockCloudObjectTakeoverThroughHardMatchEnabled が有効な場合、または既存の Microsoft Entra オブジェクトに特権ロールと OnPremisesImmutableId がある場合を挙げています。(Microsoft Learn)
対応で重要なのは、AD 側の sourceAnchor を何度も変えて試すことではなく、クラウド側の対象ユーザーが本当にハードマッチしてよいユーザーかを確認することです。
正当な移行・復旧であることが確認できた場合は、Microsoft が示す一般的な流れに沿って、対象ユーザーの特権ロールを一時的に外し、OnPremisesImmutableId を確認し、同期を完了させた後にロールを戻すという対応が考えられます。Microsoft Learn でも、特権ユーザーの hard match conflict では、削除済みであれば復元し、管理ロールを削除し、OnPremisesImmutableId を確認し、同期完了後に管理ロールを再割り当てする流れが示されています。(Microsoft Learn)
ただし、この対応は通常運用ではなく、変更管理された例外作業として扱うべきです。最低限、次の条件を満たしてから実施してください。
- 対象ユーザーが本当に同一人物・同一業務アカウントであることを確認する
- 一時的にロールを外しても運用が止まらない代替管理者を用意する
- PIM、監査ログ、チケット番号、承認者を記録する
- 同期完了後にロール、MFA、条件付きアクセス、サインインリスクを再確認する
- 作業後に
BlockCloudObjectTakeoverThroughHardMatchEnabledを必要な状態へ戻す
Cloud Sync 利用組織も対象として見るべき理由
Cloud Sync は Microsoft Entra Connect Sync とは構成や管理体験が異なりますが、今回の変更は Cloud Sync も対象です。Microsoft の案内では、Microsoft Entra Connect Sync または Cloud Sync が hard-match する試みをブロックすると明記されています。(TECHCOMMUNITY.MICROSOFT.COM)
そのため、Cloud Sync へ移行済みの組織でも、次の確認を省略しないでください。
| 確認対象 | Cloud Sync でも必要な理由 |
|---|---|
| ロール保持ユーザーの棚卸し | 同期方式に関係なく、クラウド側の特権ユーザーが保護対象になる |
| AD 側のスコープ設定 | 新しく同期対象に入ったユーザーが既存クラウドユーザーと一致する可能性がある |
| 移行・復旧手順 | Cloud Sync 切り替え時に再マッチングや属性競合が起きることがある |
| エラー監視 | Connect Sync とは表示箇所が異なっても、原因は同じ hard-match conflict の可能性がある |
「Connect Sync ではないから関係ない」と判断すると、2026年6月1日以降のユーザー移行や復旧で想定外のブロックに遭遇します。Cloud Sync 採用組織ほど、同期スコープ、属性マッピング、管理者ロールのライフサイクルを同時に見直すべきです。
2026年7月以降の別変更と混同しない
日本語圏の管理者が特に混乱しやすいのが、ハードマッチに関する別のセキュリティ強化です。Japan Azure Identity Support Blog では、2026年7月1日以降に OnPremisesObjectIdentifier の検証が追加され、ハードマッチ成功条件が変わる予定であることを説明しています。また同ブログは、Microsoft Entra ロールを持つクラウドユーザーへの hard-match ブロック通知とは別の通知として整理しています。(JP Azure ID)
整理すると、次のように分けて考えると実務で混乱しにくくなります。
| 変更 | 主な対象 | 実務上の見方 |
|---|---|---|
| 2026年6月1日以降のロール保持クラウドユーザーへの hard-match ブロック | Microsoft Entra ロールを持つクラウド管理ユーザー | 特権ユーザーの乗っ取り防止。この記事の主題 |
| 2026年7月1日以降に段階適用予定の OnPremisesObjectIdentifier 検証 | より広い hard-match 手順 | フォレスト移行、同期元切り替え、既存同期ユーザーの再接続手順に影響し得る |
どちらも「ハードマッチのセキュリティ強化」ですが、日付、条件、影響範囲が異なります。移行計画では、Microsoft Entra ロール保持ユーザーの扱いを先に整理し、そのうえで 7月以降の一般的な hard-match 手順変更も確認するのが安全です。
設計として見直すべきポイント
今回の変更は、単発の同期エラー対策ではなく、ハイブリッドIDの設計を見直すきっかけです。
管理者アカウントを通常ユーザーと分離する
日常業務用アカウントに Microsoft Entra ロールを付けたまま、同じユーザーをオンプレミス AD と強く結び付ける設計は避けるべきです。管理者用アカウントは用途ごとに分け、クラウド特権アカウントは原則としてオンプレミス同期の影響を受けないように設計します。
ハードマッチを常用手段にしない
ハードマッチは便利ですが、日常的なユーザー統合手段として乱用すると、属性上書き、誤マッチ、特権移譲のリスクが増えます。移行や復旧で使う場合は、対象ユーザー、sourceAnchor、ロール、承認、ロール復元手順をチケットに残す運用にしてください。
ロール付与のタイミングを見直す
新規管理者を作成する場合、同期と属性確認が終わる前に Microsoft Entra ロールを付与しないほうが安全です。先にユーザーの SoA、UPN、メール、MFA、条件付きアクセス、PIM 設定を確認し、その後に最小権限でロールを割り当てる流れにすると、hard-match ブロックによる移行失敗も減らせます。
監査ログと同期エラーを同じ運用で見る
InvalidHardMatch は、単なる同期担当者だけの問題ではありません。特権アカウントの不正な引き継ぎを止めた可能性もあります。同期エラー監視、Entra ID 監査ログ、PIM ロール変更、AD 側の属性変更ログを、セキュリティ運用の観点で相関確認できるようにしておくべきです。
まず着手すべき実務アクション
最初の一歩は、すべての同期設定を変更することではありません。まず、Microsoft Entra ロールを持つユーザーの一覧を作り、クラウド専用・同期済み・OnPremisesImmutableId ありのどれに該当するかを分類してください。
次に、2026年6月1日以降に予定している AD フォレスト移行、ユーザー再作成、OU フィルター変更、Cloud Sync 移行、削除済みユーザーの復元作業を洗い出します。その中に、Microsoft Entra ロールを持つユーザーが含まれる場合は、作業手順を見直してください。
最後に、hard-match を使わない期間は BlockCloudObjectTakeoverThroughHardMatchEnabled を True にする運用を検討します。必要なマッチング作業がある場合だけ、承認された変更ウィンドウで一時的に扱うのが現実的です。Microsoft も、既存クラウドアカウントを引き継ぐ必要がない限り hard matching を無効化することを推奨しています。(Microsoft Learn)
今回の変更で守られるのは、Microsoft Entra ID の特権境界です。6月1日以降に慌てて同期エラーを直すのではなく、今のうちに「どの管理者アカウントが、どのディレクトリを信頼元としているのか」を可視化してください。それが、hard-match takeover による権限昇格を防ぐ最も実践的な対策です。
コメント