Microsoft Entra ID（旧 Azure AD）でユーザーを作った後に、オンプレミス Active Directory にも同じユーザーが必要になるケースがあります。本記事では「逆同期（書き戻し）」の可否と、既存クラウドユーザーをオンプレ管理へ移すための現実的な手順・注意点をまとめます。
結論：Entra ID で新規作成したユーザーをオンプレ AD に「逆同期（書き戻し）」はできない
まず結論から言うと、Microsoft Entra Connect Sync（旧 Azure AD Connect）は、基本的に「オンプレ AD → Entra ID」の方向でユーザー情報を同期する仕組みであり、Entra ID 側で新規作成したユーザーをオンプレ AD に作成してくれる “ユーザー書き戻し（User writeback）” は提供されていません。
過去には User writeback（プレビュー）という機能が存在しましたが、Microsoft の公式ドキュメント上、2015年8月のアップデートで削除されたことが明記されています。つまり、現行の Entra Connect 系（Connect Sync / Cloud Sync）で「クラウドで作ったユーザーをオンプレに自動生成」するのは前提としてできません。
さらに公式ドキュメントでは、クラウド主体で始めた組織が「Entra のデータを元にオンプレ AD を作りたい」と考えた場合でも、Entra Connect はオンプレにユーザーを作れない／オンプレ側のパスワードを Entra と同一に設定する能力もない、と明確に整理されています。
「同期」と「書き戻し」の前提：どちらが “正（Source of Authority）” になるか
ハイブリッド構成で混乱しやすいのが、「同期＝双方向」と誤解してしまう点です。Entra Connect の考え方はシンプルで、1つのオブジェクトは “クラウド管理” か “オンプレ管理” のどちらかであり、同一ユーザーを「一部はオンプレ、別の一部はクラウド」といった分割管理は基本的にできません。
そのため、オンプレ AD が必要なユーザーは、原則としてオンプレ AD が “正” になり、Entra ID はそこから同期される側になります。逆に、クラウドだけで完結するユーザーは Entra ID 側でクラウド管理として作っても運用できます（ただし後述の注意点あり）。
| パターン | ユーザー作成場所 | 管理の主体（正） | 向いているケース | 注意点 |
|---|---|---|---|---|
| ハイブリッド（オンプレ主体） | オンプレ AD | オンプレ AD | ファイルサーバー、社内アプリ、GPO、従来型認証が必要 | UPN/メール属性設計、同期範囲、例外運用の統制が重要 |
| クラウド主体 | Entra ID | Entra ID | M365 や SaaS 中心で、オンプレ依存がほぼない | 後からオンプレ要件が出ると “作り直し/紐付け” が必要になり得る |
| 混在運用 | ユーザーによって異なる | ユーザーごとに異なる | 現場職はクラウド、バックオフィスはオンプレ等 | 同名ユーザーやアドレス設計の衝突、権限管理が難しくなる |
「書き戻し（Writeback）」でできること・できないこと
「書き戻し」という言葉は幅が広いですが、Microsoft が提供する writeback は主に パスワード、デバイス、グループ、そして一部の Exchange ハイブリッド属性などに限定されます。ユーザーオブジェクトそのものをオンプレ AD に生成する “ユーザー書き戻し” とは別物です。
| 種類 | 何がオンプレに反映されるか | 代表的な用途 | 主な提供形態 | ポイント |
|---|---|---|---|---|
| パスワード書き戻し（SSPR Password Writeback） | クラウドでのパスワード変更/リセット結果をオンプレ AD に反映 | 自己パスワードリセット（SSPR）をオンプレ AD ユーザーにも展開 | Connect Sync / Cloud Sync の双方で対応 | “ユーザー作成” ではなく、あくまで “パスワード変更イベント” の反映 |
| デバイス書き戻し（Device Writeback） | デバイス情報をオンプレへ（特定シナリオ向け） | AD FS 連携や WHfB（方式による）等の要件 | Connect Sync で案内あり（Cloud Sync 側は推奨方式の記載あり） | 環境/目的によっては別方式（Cloud Kerberos trust 等）を推奨する旨の記載あり |
| グループ書き戻し（Group Writeback） | クラウド側のグループをオンプレ AD に作成/反映（主にセキュリティグループ等） | オンプレアプリのアクセス制御にクラウドグループを使いたい | Cloud Sync で案内が強い（v2 の扱いに注意） | “ユーザーをオンプレへ作る” のではなく “グループをオンプレへ作る” |
| Exchange ハイブリッド書き戻し | Exchange 関連属性の一部 | Exchange ハイブリッド運用 | Connect Sync / Cloud Sync 両方に記載あり | 組織の Exchange 構成に依存するため設計が重要 |
| ユーザー書き戻し（User Writeback） | クラウドユーザーをオンプレ AD に作成 | （想定としては）クラウド主導でオンプレも必要 | 現在提供なし（過去のプレビューは削除） | “できない” が前提。運用で回避策を取る |
なぜ「ユーザー書き戻し」がないのか：現場で起きる事故パターン
ユーザー書き戻しが実装されない理由は、単に機能不足というより、ハイブリッド ID の前提（どちらが正か）と衝突しやすいからです。クラウドで作ったユーザーをオンプレに自動生成すると、少なくとも次のような運用事故が起きやすくなります。
- 属性の衝突：UPN、メールアドレス、proxyAddresses、SID など “一意であるべき値” の衝突が発生しやすい
- 権限境界の崩壊：クラウド管理者の操作がオンプレのセキュリティ境界に影響する（逆も同様）
- どちらの変更が優先されるか不明瞭：誤ってクラウド側の編集がオンプレを上書きしてしまう/その逆
- 既存テナントとの整合性問題：すでにクラウドで値が更新されていると、同期開始時に想定外の上書きが発生しやすい
実際、Microsoft の公式ドキュメントでも「同期を開始すると、オンプレに値がある属性はクラウド側の値が上書きされる」点を警告しています。クラウド側でメールアドレス等を運用していたのにオンプレ側で管理していない場合、同期開始でクラウドの値が失われる可能性があります。
オンプレ AD にユーザーが必要なら「オンプレで作成→Entra ID に同期」が基本
オンプレ AD にユーザーが必要（＝オンプレの認証や権限管理、SID、GPO、従来アプリ連携が必要）なら、運用の基本は次の流れに寄せるのが安全です。
- オンプレ AD でユーザーを作成
- UPN、メール、proxyAddresses 等の設計を揃える
- Microsoft Entra Connect Sync（または Cloud Sync）で Entra ID へ同期
- Entra 側のユーザーは “同期済み” としてオンプレ管理（SoA がオンプレ）に統一
この時、同期対象 OU のフィルタリングや、UPN/メールの命名規則、役職異動や退職時のライフサイクルを「オンプレで完結」させる設計にしておくと、後からの事故が激減します。
オンプレ作成時に最低限そろえたい項目チェック
| 項目 | 例 | 理由 | 注意点 |
|---|---|---|---|
| UPN（userPrincipalName） | [email protected] | 同期・マッチングの主要キーになり得る | 同一 UPN が存在すると同期が破綻する |
| primary SMTP（proxyAddresses の SMTP:） | SMTP:[email protected] | soft-match で参照される（主にメール運用） | 評価されるのは “SMTP:” の主アドレスのみという前提がある |
| 表示名・部署・役職など | 山田 太郎 / 営業部 | 同期開始時にクラウド側が上書きされ得る | クラウド側で先に整備している場合は特に要注意 |
| sourceAnchor（ms-DS-ConsistencyGuid / objectGUID） | 自動/設計で決定 | hard-match の最重要キー（immutableId） | 一度決めると基本的に変えられない前提で設計 |
すでにクラウド側に同名ユーザーがいる場合：消さずに「オンプレ管理へ移す」発想
現場で多いのは、先に Entra ID（Microsoft 365 管理センター等）でユーザーを作って運用を始めてしまい、後から「オンプレ AD 連携が必要だった」と判明するケースです。この場合、単純に “オンプレに同名を作って同期すればOK” とは限らず、既存クラウドユーザーとオンプレユーザーを同一人物として紐付ける（＝クラウド管理 → オンプレ管理へ移管）という設計が必要になります。
公式ドキュメントでは、同期開始時に Entra 側が「新しく入ってきたオンプレオブジェクト」を見て、既存クラウドオブジェクトと一致するものがあれば “取り込み（take over）” を行う仕組みが説明されています。この一致判定がいわゆる ソフトマッチ（soft-match） と ハードマッチ（hard-match） です。
まず整理：選べる選択肢とおすすめ
| 選択肢 | 何をするか | メリット | デメリット/リスク | おすすめ度 |
|---|---|---|---|---|
| クラウド管理のまま残す | オンプレ AD は作らず、クラウドのみで運用 | 移行作業が不要 | オンプレ依存のアプリ/権限管理が必要になると詰む | オンプレ要件が無いなら有力 |
| オンプレにユーザーを作り、既存クラウドユーザーへ紐付け | ソフトマッチ/ハードマッチでクラウドユーザーをオンプレ管理へ移管 | 既存の M365 データやライセンスを維持しやすい | 属性上書き・衝突リスク、事前準備が必須 | オンプレが必要なら基本これ |
| 別ユーザーとして作成（2つのIDを併存） | クラウド用とオンプレ用を分ける | 衝突回避はしやすい | 利用者が混乱、権限/メール/Teams が破綻しやすい | 原則おすすめしない |
ソフトマッチとハードマッチを理解する：どの属性で “同一人物” を判定しているか
Microsoft の公式ドキュメントでは、同期開始時に既存クラウドユーザーとの一致判定に使われる属性が明確に示されています。新しく流入してくるオンプレオブジェクトに対して、Entra 側は次の属性で一致を試みます。
- userPrincipalName（UPN）
- proxyAddresses（ただし SMTP: の主メールアドレスのみ）
- sourceAnchor / immutableId（onPremisesImmutableId）
そして、UPN または主 SMTP で一致するのがソフトマッチ、sourceAnchor（immutableId）で一致するのがハードマッチです。重要なのは、この一致判定は “オンプレから新規に入ってくるオブジェクト” に対して評価される点です。後からクラウド側/オンプレ側の既存オブジェクトを無理に一致させようとすると、エラーや競合が起きやすくなります。
ソフトマッチ（UPN/SMTP）での紐付け：条件と落とし穴
ソフトマッチは一見ラクに見えますが、特に「UPN マッチング」には制約があります。公式のトラブルシューティング/手順ドキュメントでは、UPN マッチングの前提や制約が整理されています。
- UPN マッチングは、SMTP マッチング（主メール一致）が失敗する状況で実行される前提がある
- 一度オンプレ管理へ移管されると、UPN ではなく “immutable な値（immutableId）” で紐付く
- 処理中にクラウド側 UPN は更新できない（UPN がリンクに使われるため）
- UPN は一意である必要があり、重複すると同期が失敗する
また、同期開始時に “取り込み” が成功すると、クラウド管理だったユーザーはオンプレ管理へ変わり、オンプレに値がある属性はクラウド側が上書きされます。クラウドで先に住所録情報やメール属性を整備していた場合、オンプレ側へ正しい値を先に反映しておかないと、同期開始で値が失われる可能性があります。
ソフトマッチで進める時の実務手順（例）
- クラウド側ユーザーの UPN と主メール（primary SMTP）を棚卸しする
- オンプレ AD にユーザーを作成し、UPN（または主メール）を一致させる
- 同期対象 OU/フィルタにそのユーザーが入るように調整する
- 同期を実行し、Entra 側で “同期済み（on-premises managed）” に変わるか確認する
- クラウドで先に更新していた属性があれば、オンプレ側へ補完してから同期する
ハードマッチ（sourceAnchor / immutableId）での紐付け：より確実だが設計が重要
ハードマッチの核になるのが sourceAnchor（immutableId） です。sourceAnchor は「同一オブジェクトであることを示す不変の識別子」として定義され、いったん設定されると “変えられない（immutable）” 前提で設計すべき、と公式ドキュメントでも強調されています。
同期の文脈では、オンプレ AD 側の mS-DS-ConsistencyGuid（構成によっては objectGUID）を Base64 化した値が、Entra 側の immutableId（onPremisesImmutableId）として扱われます。Entra 側がこの値で一致を見つけると、クラウド管理ユーザーをオンプレ管理へ “取り込み” できます。
オンプレ AD で immutableId 相当値（Base64）を算出する例
以下は「オンプレ AD ユーザーの ObjectGUID を Base64 文字列に変換する」代表例です（環境で sourceAnchor に何を採用しているかは必ず確認してください）。
# 例：ObjectGUID を Base64（immutableId相当）に変換
$u = Get-ADUser -Identity "taro.yamada" -Properties ObjectGUID
$immutableId = [System.Convert]::ToBase64String($u.ObjectGUID.ToByteArray())
$immutableIdハードマッチは “確実に同一人物を結びたい” 場面で強力ですが、テナント側の安全装置や運用設計も重要です。公式ドキュメントには、必要に応じてハードマッチ/ソフトマッチ自体をテナント設定でブロックする機能（Graph PowerShell による設定例）まで示されています。必要な期間だけ有効化し、終わったら再度ブロックする、という運用が推奨されています。
管理者ロールが付いたクラウドユーザーは “勝手に紐付かない” ことがある
もうひとつ重要な注意点として、Microsoft は「信頼できないオンプレユーザーから保護するため」、管理者ロールを持つクラウドユーザーとオンプレユーザーを自動的にマッチさせない挙動があることを説明しています。既存クラウドユーザーが管理者ロールを持っている場合は、移管手順や一時的なロール解除などの検討が必要になります。
パスワードはどちらが正になる？PHS / PTA / フェデレーションで考え方が変わる
ユーザーをオンプレ管理へ移すと、次に悩むのが「パスワードの正はどちらか」です。公式ドキュメントでは、PHS（パスワードハッシュ同期）を使う場合、クラウド側のパスワードハッシュはオンプレから上書きされるため、利用者はオンプレのパスワードを使うことになる、という注意が明記されています。
一方で、SSPR（自己パスワードリセット）をクラウドで提供したい場合は、パスワード書き戻しを有効化することで、クラウドで変更した結果をオンプレ AD にリアルタイムで反映できます。これは “ユーザー作成の書き戻し” ではなく、あくまで “パスワード変更イベントの書き戻し” です。
| 認証/同期方式 | サインインの中心 | パスワードの正（基本） | SSPR と相性 | 設計上のメモ |
|---|---|---|---|---|
| PHS（Password Hash Sync） | クラウド | オンプレ（ハッシュがクラウドへ同期） | 書き戻し有効化でオンプレへ反映可能 | 同期開始時にクラウド側ハッシュがオンプレで上書きされ得る |
| PTA（Pass-through Authentication） | オンプレへ検証 | オンプレ | 書き戻し有効化で運用しやすい | オンプレ可用性が重要 |
| フェデレーション（例：AD FS） | オンプレ（フェデ） | オンプレ | 構成次第（運用要件を整理） | トラブルシュートの難易度が上がる傾向 |
「クラウドで作ったユーザーをオンプレにも出したい」要求への現実的な代替案
ユーザー書き戻しが無い以上、現実的な落とし所は次のどれかになります。
代替案：既存クラウドユーザーを “オンプレ管理へ移管（take over）” する
多くの組織で実務的なのがこのパターンです。ポイントは「オンプレ AD にユーザーを作り、既存クラウドユーザーと紐付ける」こと。これにより、M365 の利用実績（OneDrive、Teams、メールボックス等）やライセンスを維持しながら、オンプレ要件にも対応できます。
代替案：Microsoft Entra Domain Services を検討する
もし “オンプレ AD を追加する理由” が「従来型アプリが LDAP / Kerberos / NTLM を要求する」などで、かつインフラとしての AD DS を自前で持ちたくない場合、公式ドキュメントでも Microsoft Entra Domain Services を検討する流れが示されています。Domain Services は Entra ID の ID 情報を複製し、マネージドなドメインサービス（ドメイン参加、LDAP、Kerberos/NTLM、グループポリシー等）を提供します。
オンプレに DC を立てるよりも運用負荷を下げられる反面、従来の AD DS と完全に同じ自由度ではないため、要件（LDAP の用途、GPO の使い方、ネットワーク、既存アプリ）を照らして判断するのが現実的です。
よくあるトラブルと切り分け：同期で詰まるポイントを表で把握する
| 症状 | ありがちな原因 | 確認ポイント | 対処の方向性 |
|---|---|---|---|
| 同名ユーザーが2つできた | soft-match/hard-match が成立せず新規作成された | UPN / primary SMTP / immutableId の一致状況 | 属性の整合を取り、必要なら hard-match を検討 |
| 同期開始でクラウド側の属性が消えた | オンプレ側の値でクラウドが上書きされた | オンプレ AD に必要な属性が入っていたか | 同期前にオンプレへ値を移植してから実施（設計を見直す） |
| AttributeValueMustBeUnique / 競合エラー | UPN / proxyAddresses など一意属性の衝突、sourceAnchor 不整合 | 既存クラウドユーザーの immutableId とオンプレの sourceAnchor | sourceAnchor を揃えて hard-match を成立させる設計を検討 |
| パスワードが想定と違う | PHS でオンプレのハッシュがクラウドへ上書きされた | 認証方式（PHS/PTA/フェデ）、SSPR 書き戻し設定 | 利用者周知、SSPR 書き戻しの有効化、運用ルール明確化 |
再発防止：クラウドで “先に作ってしまう” を防ぐ運用設計
ユーザー書き戻しが無い以上、運用で「クラウドで安易にユーザーを作らない」仕組み化が最重要です。おすすめは次のような統制です。
- ユーザー作成の手順を一本化：オンプレ AD での作成を正規ルートにし、チケット/申請フローに組み込む
- Entra 側の権限を最小化：不要な管理者権限（ユーザー作成権限）を付けない
- 例外ユーザーの基準を明文化：クラウド管理で良いユーザー（外部委託、短期アカウント等）を定義し、命名規則も分ける
- UPN/メール設計の標準化：UPN・SMTP の重複を起こさないルールを先に決める
まとめ：逆同期が無い前提で「作成場所」と「紐付け」を設計する
- Entra ID で作った新規ユーザーをオンプレ AD に自動で書き戻す（User writeback）はできない
- 過去の User writeback（プレビュー）は 2015年8月更新で削除済み
- 書き戻しはパスワード/グループ/デバイスなど “限定的な対象” であり、ユーザーオブジェクト生成とは別
- オンプレが必要なら「オンプレ作成→同期」が基本。既存クラウドユーザーがいるなら soft-match / hard-match で移管を検討
- クラウド主体で従来アプリ要件だけを満たしたい場合は Microsoft Entra Domain Services も選択肢になり得る
参考資料
- Microsoft Entra Connect: Features in preview（User writeback の記載）
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-preview - Microsoft Entra Connect: When you have an existing tenant（soft-match/hard-match、上書き警告、オンプレ作成不可の記載）
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant - Microsoft Entra Connect: Design concepts（sourceAnchor / immutableId）
https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-design-concepts - How to use UPN matching for identity synchronization（UPN マッチングの制約）
https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/user-prov-sync/use-upn-matching-identity-sync - How does self-service password reset writeback work?（SSPR パスワード書き戻し）
https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-writeback - What is Microsoft Entra Cloud Sync?（対応機能一覧）
https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync - Overview of Microsoft Entra Domain Services（Entra DS の概要）
https://learn.microsoft.com/en-us/entra/identity/domain-services/overview
コメント