Entra Connectでソフトマッチ重複が起きると、同じユーザーのはずなのに同期できず、InvalidSoftMatch や AttributeValueMustBeUnique が出たり、見覚えのない [email protected] の UPN に変わったりします。原因の中心は、同じ UPN または主SMTPを持つのに、sourceAnchor / ImmutableId が別物になっていることです。直し方は、正とするオブジェクトを決め、誤った側の重複属性を外すか、同一人物なら sourceAnchor をそろえてハードマッチに戻す、のどちらかです。 (Microsoft Learn)
特に起きやすいのは、オンプレユーザーの再作成、フォレスト移動、Entra Connect の再構成で sourceAnchor が変わったケース、既存クラウドアカウントに管理者ロールが付いているケース、そしてユーザーではなくグループや連絡先が同じメールアドレスを持っているケースです。重複属性の回復性が有効なテナントでは、競合属性だけが隔離されて“同期が進んだように見える”こともあるため、エラー表示だけで安心しないほうが安全です。 (Microsoft Learn)
Entra Connectのソフトマッチ重複を最初に理解する
Microsoft Entra ID は、オンプレから入ってくる新規オブジェクトに対して、まず sourceAnchor / ImmutableId でハードマッチし、一致しなければ userPrincipalName または主SMTPでソフトマッチします。proxyAddresses でソフトマッチに使われるのは 主SMTP (SMTP:) だけで、既存オブジェクトを後から同じ値に変えても再照合はされず、代わりにエラーになります。ソフトマッチが成功すると、そのクラウドオブジェクトには sourceAnchor が追加され、以後はハードマッチ前提になります。 (Microsoft Learn)
| 属性 | 役割 | 見落としやすい点 |
|---|---|---|
| sourceAnchor / ImmutableId | ハードマッチの主キー | 変わると別オブジェクト扱いになる |
| userPrincipalName | ソフトマッチ候補 | UPNベースのソフトマッチは機能設定の影響を受ける |
proxyAddresses の主SMTP (SMTP:) | ソフトマッチ候補 | セカンダリアドレスは照合の主役ではない |
| proxyAddresses のその他値 / mail | 一意性チェック | ソフトマッチ用でなくても重複エラーは起きる |
この表は、Microsoft Learn の照合ロジックと重複属性エラーの説明を、切り分けしやすい形に整理したものです。 (Microsoft Learn)
オンプレの UPN suffix がテナントで未検証だったり、無効文字が含まれていたりすると、クラウド側 UPN は <MailNickName>@<tenant>.onmicrosoft.com> に再計算されます。クラウド UPN が違うだけで“別人ができた”と判断すると切り分けを誤るので、まず verified domain と UPN 文字列の妥当性を見てください。 (Microsoft Learn)
Entra Connectでソフトマッチ重複が起きる主な原因
同じユーザーを作り直した
最も多いのは、オンプレ AD のユーザーを削除・再作成した、あるいは同じ UPN / 主SMTP の新規ユーザーを作ったケースです。見た目は同じ人でも、sourceAnchor と SID は別物なので、Entra 側では“既存ユーザーの引き継ぎ”ではなく“重複する別ユーザーの作成”として扱われやすく、InvalidSoftMatch や AttributeValueMustBeUnique につながります。 (Microsoft Learn)
sourceAnchor を変えた、または変わってしまった
フォレスト移動、Entra Connect の再インストール、sourceAnchor 設定の変更でも起こります。Microsoft Learn では、再インストール時に別の sourceAnchor を選ぶと以前同期していたオブジェクトが InvalidSoftMatch で止まる例が示されており、sourceAnchor 自体も“初回インストールで決める主キー”として後から軽く変える前提ではありません。 (Microsoft Learn)
クラウド側がソフトマッチの相手になれない
ソフトマッチは、相手のクラウドオブジェクトがすでに別の ImmutableId を持っていると成立しません。さらに、既存クラウドユーザーに管理者ロールが付いている場合、Microsoft Entra ID は既定でオンプレユーザーとのマッチを許可しません。既存の管理者アカウントをオンプレ同期に取り込む運用は、Microsoft も強く非推奨としています。 (Microsoft Learn)
実は相手がユーザーではなくグループか連絡先
ユーザーの重複に見えて、実際にはメール対応グループや連絡先が同じ proxyAddresses を持っていることもあります。この場合は ObjectTypeMismatch になりやすく、ユーザー側だけ見ていても解決しません。特に共有アドレスや部署アドレスを先に Microsoft 365 側で作っている環境では起きやすいパターンです。 (Microsoft Learn)
先に確認したい設定と属性
まず見るべきは sourceAnchor の設計 と、テナント側の ソフトマッチ関連機能 です。Microsoft Entra Connect では、ユーザーの sourceAnchor として ms-DS-ConsistencyGuid を使う構成がサポートされており、これを使う場合は AD DS コネクタ アカウントにその属性への書き込み権限が必要です。sourceAnchor は後から容易に変えられず、エクスポート後に値が変わると、そのオブジェクトの変更は止まります。 (Microsoft Learn)
テナント側の主要設定は、Graph PowerShell でまとめて確認できます。少なくとも SoftMatchOnUpnEnabled、BlockSoftMatchEnabled、SynchronizeUpnForManagedUsersEnabled を見てください。UPN ベースのソフトマッチが必要なのに SoftMatchOnUpnEnabled が無効、あるいはソフトマッチ自体を全体ブロックする BlockSoftMatchEnabled が有効だと、期待した照合は起きません。UPN を直したのにクラウド側へ反映されないときは、管理対象ユーザーの UPN 更新同期に関わる SynchronizeUpnForManagedUsersEnabled も要確認です。 (Microsoft Learn)
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.Read.All"
Get-MgDirectoryOnPremiseSynchronization |
Select-Object -ExpandProperty Features |
Format-Listこの確認コマンドと機能名は Microsoft Learn の同期サービス機能ドキュメントに基づきます。 (Microsoft Learn)
運用面では、通常時はソフトマッチをブロックしておき、既存クラウドアカウントの引き継ぎが必要な期間だけ許可する設計が安全です。Microsoft は、ソフトマッチやハードマッチによるクラウドオブジェクト引き継ぎにはセキュリティ リスクがあるため、不要なら無効化するよう案内しています。なお、BlockSoftMatchEnabled はテナント全体に効く設定なので、切り替えるなら作業時間を絞るべきです。 (Microsoft Learn)
エラー名ごとの判断基準
代表的なエラーは、原因がかなりはっきり分かれます。次の表で見当をつけると、無駄な調査を減らせます。 (Microsoft Learn)
| 表示されやすい症状 | まず疑うこと | 対処の軸 |
|---|---|---|
InvalidSoftMatch | 同じ UPN / 主SMTP はあるが、クラウド側が別の ImmutableId を持っている | 同一人物なら sourceAnchor をそろえる。違う人なら重複属性を消す |
AttributeValueMustBeUnique | UPN、proxyAddresses、mail などが別オブジェクトと重複 | 正しい持ち主を決め、誤った側の値を外す |
ObjectTypeMismatch | ユーザーとグループ/連絡先で同じメール属性を持っている | ユーザーだけでなく、グループ/連絡先まで調べる |
[email protected] のような UPN | 重複属性の回復性で UPN が隔離され、プレースホルダーが振られている | 直ったように見えても、元データの競合は別途解消する |
OnPremiseSecurityIdentifier の競合 | まれだが SID 重複 | UPN/SMTP だけでなく SID 側も調べる |
重複属性の回復性は、UPN や SMTP ProxyAddress の競合時に属性を隔離して一時値を割り当てる仕組みで、根本データを自動修正する機能ではありません。解決後はサービス側のバックグラウンド処理が再評価しますが、元の競合を消さない限り、正しい状態には戻りません。 (Microsoft Learn)
Entra Connectのソフトマッチ重複を復旧する手順
既存クラウドアカウントをオンプレ管理に引き継ぐ場合
- 残したいクラウド属性を先にオンプレへ寄せる
ソフトマッチやハードマッチでオンプレ管理に切り替わると、クラウド側の値はオンプレ値で上書きされます。Express インストールの PHS ではパスワード ハッシュもオンプレ側が優先されます。 (Microsoft Learn) - 管理者ロール付きアカウントなら、先にロールを外す
管理者ロールを持つ既存クラウドユーザーは既定でマッチされません。Microsoft Learn の回避手順は、ロール削除 → 新しくできた競合オブジェクトのハード削除 → 再同期 → 必要ならロール再付与、です。 (Microsoft Learn) - UPN で合わせるなら設定も確認する
Exchange Online を使っておらず主SMTPで照合しにくい環境では、SoftMatchOnUpnEnabledが重要です。ソフトマッチを普段ブロックしている環境では、作業時間だけ許可し、終わったら元に戻します。 (Microsoft Learn)
同じ人を再作成した、または sourceAnchor がずれた場合
- “同一人物か”を先に確定する
同じ人なら、消すべきなのは属性ではなくズレた主キーです。違う人なら、sourceAnchor を合わせようとしてはいけません。 (Microsoft Learn) - sourceAnchor を正しい側に合わせる
Microsoft の公式手順では、既存クラウドユーザーの ImmutableId に合わせて、オンプレ側ユーザーのmS-DS-ConsistencyGuidを更新し、正しいハードマッチへ戻す方法が案内されています。これは特に“同じユーザーを再プロビジョニングしてしまった”ケースで有効です。 (Microsoft Learn) - 件数が多いなら ADSyncTools を使う
“Source anchor has changed” がまとめて出ているなら、ADSyncTools のGet-ADSyncToolsDuplicateUsersSourceAnchorとSet-ADSyncToolsDuplicateUsersSourceAnchorが使えます。前者で対象一覧を出し、後者で元の ImmutableId に合わせたmsDS-ConsistencyGuidの更新修復を行います。 (Microsoft Learn)
Get-ADSyncToolsDuplicateUsersSourceAnchor -ADConnectorName "<AD connector name>"
Get-ADSyncToolsDuplicateUsersSourceAnchor -ADConnectorName "<AD connector name>" |
Set-ADSyncToolsDuplicateUsersSourceAnchorこのコマンドは Microsoft Entra Connect に同梱される ADSyncTools モジュールの公式リファレンスに掲載されています。 (Microsoft Learn)
本当の重複なら、誤っている側の属性を消す
別人なのに同じ UPN や proxyAddresses を持っているなら、正しい持ち主を決めて、誤っている側から重複値を削除します。Microsoft Learn でも、解決の基本は「重複値を特定し、持つべきでないオブジェクトから外し、変更した側のソース ディレクトリで同期する」という流れです。クラウドを直すべきか、オンプレを直すべきかで迷ったら、その属性の権限ソースがどちらかで決めるのが安全です。 (Microsoft Learn)
孤児オブジェクトなら Connect Health の自己修復も候補
削除シグナルが同期されず Source Anchor だけ失った“孤児オブジェクト”では、Microsoft Entra Connect Health の Diagnose / Apply Fix が使えることがあります。これはクラウド側で source anchor を正しいオブジェクトへ更新し、必要なら競合オブジェクトを削除する仕組みですが、孤児オブジェクトのケースに限定され、実行には Azure RBAC の Contributor 権限が最低限必要です。競合ユーザーが soft-delete 状態なら、完全削除するか 30 日経過を待たないと適用できません。 (Microsoft Learn)
変更後の反映と確認
変更を入れたら、まず差分同期を流します。同期規則やフィルタリング、インポート対象属性を変えた場合は、差分では足りず Initial が必要になることがあります。 (Microsoft Learn)
Start-ADSyncSyncCycle -PolicyType Delta
Start-ADSyncSyncCycle -PolicyType InitialMicrosoft Learn では、Connect Health for Sync のエラーレポートは 30 分ごとに更新されると案内されています。Apply Fix を使った場合も、状態はまず Pending Sync になり、次の同期サイクル後に解消される流れです。エラーが消えたら、対象ユーザーのサインイン UPN、主SMTP、ライセンスや元のリソースが想定どおり残っているかまで確認して終わりにしてください。 (Microsoft Learn)
再発を防ぐ運用ポイント
再発防止で効くのは、次の4点です。sourceAnchor を途中で変えないこと、既存の管理者クラウドアカウントを後から同期対象にしないこと、主SMTPをユーザー・グループ・連絡先で一元管理すること、そして通常運用では BlockSoftMatch を有効にしておくことです。いずれも Microsoft Learn の設計制約と推奨運用に沿っています。 (Microsoft Learn)
次にやることは 3 つだけです。Get-MgDirectoryOnPremiseSynchronization で feature を確認する、Connect Health で衝突している 2 つのオブジェクトを特定する、そして同一人物なら sourceAnchor 修正、別人なら重複属性削除のどちらかに絞る。この順で進めると、Entra Connect のソフトマッチ重複はかなり整理しやすくなります。 (Microsoft Learn)
コメント