【AD検証ラボ】デバイス管理編 〜 Hybrid Entra Join・SID History を整理する

ごきげんよう、IDチームのわかなです！

AD 検証ラボシリーズ第 3 弾です。

• 第 1 弾: AWS / Azure で Active Directory 構築ガイド — ラボ環境の構築
• 第 2 弾: ユーザー管理編 〜 Entra ID へ移行を見据えた設計と検証 — OU・UPN・グループ・パスワード同期

前回はユーザー同期にフォーカスしましたが、今回は デバイス管理 です。「Hybrid Entra Join って結局何？」「SID History はいつ使うの？」など、AD 廃止を考えるとき、デバイスまわりが一番ややこしいところを整理していきます！

この記事のゴール

• Windows 端末の「参加状態」の違いと、移行における影響を理解する
• Hybrid Entra Join を検証ラボで構成し、動作フローを確認する
• SID History の仕組みと移行時の落とし穴を把握する

1. デバイスの「参加状態」を整理する

Windows 端末は AD やクラウドに対してどのような「参加状態」を持てるのか。移行を考えるには、まずここを理解する必要があります。

ポイントは、Hybrid Entra Join は「両方に所属している」だけで、AD を廃止すると AD 側の機能（GPO、Kerberos 認証）が使えなくなる ということです。AD を将来廃止したいなら、新規端末は最初から Entra Join にしておくのが理想です。

2. Hybrid Entra Join とは？

「ドメイン参加 + Entra ID にデバイス登録 + PRT 取得」が Hybrid Entra Join です。既存のドメイン参加端末をクラウドにも対応させる、移行期の構成として使われます。

必要なコンポーネント

• オンプレ AD（ドメイン参加先）
• Entra Connect（デバイスオブジェクトの同期）
• SCP（Service Connection Point）— 端末が Entra ID テナントを見つけるための設定
• Entra ID（デバイス登録先）

→ Hybrid Entra Join には Computers OU を同期対象に含める ことが必須。これを忘れるとデバイスが Entra ID に同期されない

SCP の設定

SCP は AD に登録される設定オブジェクトで、Windows 端末が「自分はどの Entra ID テナントに登録すべきか」を判断するために参照します。

動作フロー

1. 端末が AD にドメイン参加
2. Entra Connect がデバイスオブジェクトを Entra ID に同期
3. 端末が SCP を参照して Entra ID テナントを特定
4. Entra ID にデバイス登録
5. PRT（Primary Refresh Token）発行
6. クラウドサービスへの SSO が可能に

検証ラボで Hybrid Entra Join を構成し、dsregcmd /status で AzureAdJoined: YES + DomainJoined: YES の両方が表示されることを確認します。

→ Hybrid Entra Join 前の状態。デバイスはドメイン参加だけ

→ デバイス側の Hybrid Entra Join 成功

→ Entra ID 側でも Hybrid Entra Join 端末として認識されている

同期されていないユーザーは PRT が取れない

Hybrid Entra Join はデバイス単位で成立しますが、SSO（PRT）はユーザー単位です。Entra ID に同期されていないユーザーでログインしても、PRT は取得できません。

→ labadmin は Entra ID に同期されていないため PRT が取れない。「デバイスは Hybrid Entra Join できているのに SSO が動かない」のはこのパターン

Entra Connect で同期されているユーザー（tyamada）でログインすると、PRT が発行されます。

→ 同期済みユーザーで初めて PRT が取れる

Entra Join と Hybrid Entra Join の違い

AD を将来なくしたいなら、新規端末は Entra Join 一択。 Hybrid Entra Join は既存端末を段階的に移行するための過渡期の構成です。

3. SID History 〜 ドメイン移行で避けて通れないもの

ドメインを移行するとき、ファイルサーバーのアクセス権が壊れる問題に直結します。

SID とは

SID（Security Identifier）は、AD 上のユーザーやグループに割り当てられる一意の ID です。ファイルやフォルダの ACL（アクセス制御リスト）は SID で管理されています。

→ ユーザーやグループには S-1-5-21-... 形式の SID が割り当てられている

ドメインが変わると SID が変わる

ユーザーが別のドメインに移行すると、新しい SID が割り当てられます。すると、旧ドメイン時代に設定された ACL と一致しなくなり、ファイルにアクセスできなくなります。

• 旧ドメイン：SID: S-1-5-21-OLD-1234
• 新ドメイン：SID: S-1-5-21-NEW-5678
• ファイルサーバーの ACL：S-1-5-21-OLD-1234 に読み取り許可
  • 新 SID では一致しないためアクセス拒否

SID History で解決する

SID History は、旧ドメインの SID を新アカウントに付与する仕組みです。Windows が ACL を評価するとき、SID History に含まれる旧 SID も照合するため、旧 ACL のままアクセスが通ります。

制約と注意点

• SID Filtering：フォレスト信頼経由のアクセスでは、SID History が除去される場合がある。EnableSIDHistory の設定が必要
• FSLogix：FSLogix のプロファイルフォルダは PRIMARY SID のみで検索するため、SID History ではマッチしない。フォルダ名と VHDX 名のリネーム + ProfileData.reg の SID 書換が必要
• 移行完了後のクリーンアップ：理想は ACL を新 SID に書き換えて SID History を削除すること。長期間残すとセキュリティリスクになる

4. デバイス同期の全体像

Entra Connect がデバイスオブジェクトを同期する仕組みを整理します。

同期される情報

• cn（コンピューター名）
• objectSid（デバイスの SID）
• operatingSystem / operatingSystemVersion
• userCertificate(Hybrid Entra Join の証明書）

dsregcmd /status の読み方

5. 移行パターン別の考慮事項

パターン A：オンプレ AD → Entra Join（完全クラウド移行）

• 端末のドメイン離脱 → Entra Join のやり直しが必要（ユーザープロファイルの再作成が発生する場合あり）
• Autopilot を使えば新規端末はスムーズ
• GPO に依存している設定がある場合は、事前に Intune 等への移行検討が必要

パターン B：オンプレ AD → MEDS（マネージド AD 移行）

• Kerberos/NTLM が必要なアプリが残る場合の選択肢
• SID History の移行、FSLogix のリネーム、フォレスト信頼の構築が必要（前回の記事で検証済み）
• MEDS は一方向 Outbound 信頼のみサポートという制約あり

パターン C：VDI 環境の移行

• 永続 VDI → 通常端末と同じ考え方
• 非永続 VDI → stale デバイスの増殖に注意（定期的なクリーンアップが必要）
• VMware Horizon / Citrix 固有の設定（BlockAADWorkplaceJoin レジストリなど）
• RDSH のドメイン変更、プロファイル対応が必要

まとめ

• 新規端末は Entra Join、既存端末は Hybrid Entra Join で共存させながら段階的に移行
• ユーザーが Entra ID に同期されていないと、Hybrid Entra Join 端末でも PRT が取れない
• SID History は移行時に必須だが、長期間残さないこと

次は GPO 周りも整理したい・・・！

FAQ

Q. Hybrid Entra Join から Entra Join に変更できる？
A. はい、ただしドメイン離脱 → Entra Join のやり直しが必要です。ユーザープロファイルが再作成される場合があるため、データのバックアップを忘れずに！

Q. 非永続 VDI の stale デバイスはどうやってクリーンアップする？
A. Entra ID のデバイス管理で「最終アクティビティ日時」を基準に、一定期間アクセスのないデバイスを定期削除するスクリプトを組むのが一般的です。