はじめに
こんにちは！クラウドネイティブの kaito です。最近は急に冷え込んでいるので、電気毛布を引っ張り出してきました。
さて、これまでEntra Domain Services（以下 Entra DS）とオンプレの AD をつなぐ話を書いてきました。最初の記事はこちらです。今回はその流れで、気になったことをラボで確かめてみました。
オンプレの AD から同期しているユーザーの「管理元」を Entra ID に移したら、Entra DS のパスワード ハッシュはどうなるのか、という話です。
先に結論を書きます。私のラボでは、管理元を移しても Entra DS のハッシュはそのまま残り、元のパスワードでログオンできました。この動作は公開ドキュメントには明記されていませんが、検証のあとで Microsoft サポートに確認したところ、サポートされる動作だという回答でした（2026 年 11 月時点）。この点は後で詳しく書きます。
SOA の移管とは
Entra ID には、同期ユーザーの管理元（Source of Authority、以下 SOA。Microsoft Learn の日本語版では「信頼元」）をオンプレの AD からクラウドに移す機能があります。やり方は、Microsoft Graph で onPremisesSyncBehavior の isCloudManaged を true にする PATCH を 1 回送るだけです。ただし、ハイブリッド管理者ロール、User-OnPremisesSyncBehavior.ReadWrite.All の権限への同意、Entra Connect Sync 2.5.76.0 以上（クラウド同期なら 1.1.1370.0 以上）が前提です。これで、そのユーザーはクラウドで管理されるユーザーに切り替わります。
PATCH https://graph.microsoft.com/v1.0/users/{ID}/onPremisesSyncBehavior
{ "isCloudManaged": true }
公式ドキュメントによると、移管すると isCloudManaged が true、onPremisesSyncEnabled が null になります。ラボでも、移管後に Graph で読むと、そのとおりの値になっていました。以後、オンプレ側の変更はそのユーザーに流れなくなります。
オンプレの AD を減らしていきたい組織にとっては、ユーザーを作り直さずにクラウドへ寄せられるのがうれしいところです。
なぜ Entra DS のハッシュが気になるのか
Entra DS でユーザーが Kerberos や NTLM で認証するには、そのためのパスワード ハッシュが Entra DS に届いている必要があります。オンプレから同期しているユーザーの場合、このハッシュはオンプレの AD で作られ、Entra Connect のパスワード ハッシュ同期で Entra ID を経由して Entra DS に届きます。
SOA を移管すると、オンプレ側の変更はそのユーザーに流れなくなります。パスワードも止まるはずですが、これは後の結果 3 で確かめます。では、すでに Entra DS にあるハッシュはどうなるのか。消えて、全員がパスワードを変えるまでログオンできなくなるのか。それとも残るのか。
ビルの入館証に例えると、「入館証の発行元が本社から新しい管理会社に変わったら、いま持っている入館証はそのまま使えるのか」という疑問です。私が探した範囲では、SOA のドキュメントにも Entra DS のドキュメントにも、この組み合わせの説明は見つかりませんでした。Entra DS のドキュメントには、クラウドのみの環境ではユーザーがパスワードをリセットまたは変更する必要がある、と書かれています。ただしこれは、Entra DS 用のハッシュがまだ作られていないクラウド ユーザーの話です。オンプレから同期済みで、ハッシュがすでに Entra DS に届いているユーザーを移管した場合については、書かれていません。全員のパスワード変更が要るかどうかで移行当日の段取りが大きく変わるので、試してみることにしました。
検証のしかた
ラボは、Entra DS（Enterprise）、オンプレ役の AD と Entra Connect、そして Entra DS のユーザーでリモート デスクトップ（RDP）するサーバーで組みました。検証は 2026 年 10 月です。被験者は、オンプレで作って同期したテスト ユーザーを 2 人使いました。
見たのは次の 2 つです。
- 移管前のパスワードのまま RDP できるか。ログオンのたびに
klistを実行し、initialとpre_authentの付いた TGT が新しく発行されていることを確かめました。前のセッションに再接続しただけでは、認証が通った証拠にならないためです - Entra DS のパスワードの属性が書き換わったか。Entra DS の DC 2 台それぞれに対して、属性ごとの変更時刻を読みました
$dn = (Get-ADUser -Filter "UserPrincipalName -eq '<UPN>'" -Server '<DC1 の IP>').DistinguishedName
foreach ($dc in '<DC1 の IP>','<DC2 の IP>') {
Get-ADReplicationAttributeMetadata -Object $dn -Server $dc |
Where-Object { $_.AttributeName -in 'unicodePwd','supplementalCredentials','pwdLastSet','ntPwdHistory' } |
Select @{n='DC';e={$dc}}, AttributeName, LastOriginatingChangeTime, Version
}
最初は whenChanged を見ていましたが、初回ログオンで lastLogonTimestamp が書き換わっただけでも動いてしまい、目印になりませんでした。属性ごとの変更時刻で追うほうが確実です。
結果
1. 移管しただけでは、ハッシュは書き換わらなかった
| 被験者 | 条件 | 移管後に試した時点 | 結果 |
|---|---|---|---|
| 1 人目 | 同期元の AD の DC を停止した状態で移管（移管後に差分同期を 1 回実行） | 数分後〜約 23 時間後 | 毎回、元のパスワードで新しく認証できた |
| 2 人目 | 同期元の AD を動かし、差分同期と完全同期を挟んだ | 数分後〜約 41 時間後 | 毎回、元のパスワードで新しく認証できた |
どちらも、Entra DS の DC 2 台で unicodePwd や supplementalCredentials の変更時刻と Version は、移管の前から変わっていませんでした。消えたり空になったりした様子もありません。
2. クラウドでパスワードを変えると、すぐに入れ替わった
1 人目で、マイ サインインの「セキュリティ情報」の Web 画面からパスワードを変えました。約 24 秒後には、Entra DS の DC 2 台とも unicodePwd、supplementalCredentials、pwdLastSet が更新されていました。約 2 分半後には新しいパスワードで RDP でき、元のパスワードは失敗しました。
3. 移管後にオンプレでパスワードを変えても、届かなかった
2 人目で、移管後にオンプレの AD 側でパスワードを変えました。Entra Connect サーバーの Windows アプリケーション ログ（ソース：Directory Synchronization）には、次の 2 つのイベントが残っていました。
- イベント 656（ログ本文は Password Change Request）：変更を検知して、送ろうとした
- イベント 657（ログ本文は Password Change Result）：
Result : Failed: User is CloudManaged.
Entra Connect は約 1 分で送ろうとしましたが、移管済みであることを理由に受け付けられませんでした。Graph の lastPasswordChangeDateTime も Entra DS の属性も変わらず、RDP は元のパスワードでしか通りませんでした。「まだ届いていないだけ」ではなく、届かない動きだと判断しています。なお、657 の User is CloudManaged という文言は今回のラボのログに出たもので、公開ドキュメントには載っていません。
4. 移管直後の同期で、警告が 1 回出た
2 人目の移管直後に、差分同期を回しました。すると、Entra Connect の Microsoft Entra ID 向けコネクタで、Delta Import が completed-warnings になりました。中身は、移管したユーザーの exported-change-not-reimported です。次の完全同期では出ず、同期そのものも止まりませんでした。
注意点
一番大事なのはここです。
- 公開ドキュメントには明記されていない動作です。 ラボでは 2 人について、移管から約 41 時間後まで確かめました。そのうえで Microsoft サポートに確認したところ、移管前に同期されたハッシュは移管後も Entra DS で使えてサポート対象であること、パスワード変更以外のきっかけで消えたり無効になったりすることはないこと、という回答でした（2026 年 11 月時点）。移管後に Entra Connect をアンインストールしても影響しない、という回答もありました（アンインストールはラボでは試していません）。個別の問い合わせへの回答で、公開ドキュメントの記載ではありません。今後仕様が変わる可能性もあるので、採用前にはご自身の環境でも確かめてください
- 移管後のパスワード変更はクラウドで行います。 オンプレで変えた分はクラウドに届かないので、移管後もオンプレのパスワードを使う場面が残っていると、2 つのパスワードがずれます
- 同期の警告とイベントに慌てないこと。 移管直後の
exported-change-not-reimportedと、移管済みユーザーの 657 の Failed は、今回の検証では想定どおりの動きでした。監視の設定によっては障害に見えるので、手順書に一言書いておくと安心です。なお公式ドキュメントでは、移管済みのため同期しないオブジェクトについてイベント 6956 が案内されています（今回は見ていません）
ラボの観測だけで決めずにサポートへ確認したことで、ようやく安心して前提にできるようになりました。ドキュメントにない挙動を頭に入れるときは、実態と公式確認をセットにするのが良いと考えています。
さいごに
管理元を移しても、Entra DS のハッシュは残り、元のパスワードで認証できました。サポートの回答でも、パスワードを変えない限り消えることはないとのことです。一方で、オンプレでのパスワード変更はもう届かず、クラウドで変えると（今回の Web からの変更では）約 20 秒で入れ替わりました。入館証で言えば、いまの入館証はそのまま使えて、再発行の窓口だけが新しい管理会社に移った、というイメージです。移管の前後で「パスワードの正がどこにあるか」が変わる、と整理しておくと迷いにくいと思います。
まだ勉強中の身ですが、同じように Entra DS への移行を検討している方の参考になればうれしいです。ここまで読んでくださってありがとうございました！
※ 画面の表記や手順は今後変わる可能性があります。設定前に公式ドキュメントで最新の情報を確認してください。
