【AD検証ラボ】ユーザー管理編 〜 Entra ID へ移行を見据えた設計と検証

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

前回の記事では、AWS と Azure に AD の検証ラボを構築しました。今回はそのラボを使って、AD → Entra ID 移行で避けて通れない「ユーザー同期」 を実際に動かしていきます！

「AD をなくしたい」— それなりに歴史のある会社に勤めていると、誰しも考えるのではないでしょうか。Entra Connect 入れてハイブリッドまでは来たけど、次は？ LDAP 捨てられなくて結局 MEDS に行くしかないのか？ GPO どうする？

この記事では、検証ラボで手を動かしながら「移行前に何を押さえておけばいいのか」を整理します。

この記事のゴール

• AD から Entra ID のユーザー同期を、設計（OU・UPN・グループ・パスワード）から実際の同期まで一気通貫で確認すること
• Entra Connect による Entra ID への同期と、MEDS（Microsoft Entra Domain Services）への同期を動かすこと

1. AD をやめたい、でもやめられない

AD → Entra ID に移行したいけど、何から手をつけるのか。まずは「本当に AD を廃止できるのか」の判断が必要です。

AD DS がまだ必要な場面

• Kerberos/NTLM 認証が必須のレガシーアプリがある
• GPO でしかできないデバイス制御がある
• VDI がドメイン参加を前提としている
• ファイルサーバーの Kerberos/NTLM アクセス制御を使っている

これらが全部不要なら、Entra ID だけで完結できます。必要なものが残るなら MEDS という選択肢があります。

移行パターン

どのパターンを選ぶにしても、移行で影響を受けるのは OU 構成・UPN・グループ・パスワード の 4 つです。順番に見ていきます。

2. OU 設計 〜 Entra ID に何を同期するかを決める

OU（Organizational Unit）は AD のユーザーを整理する仕分けと考えます。GPO の適用単位としても使われますが、移行においてもうひとつ重要な役割があります。

Entra Connect は OU 単位で同期範囲を制御します。 つまり、OU 設計 = Entra ID に何を同期するかの設計です。

たとえば、サービスアカウントや共有メールボックスを一般ユーザーと同じ OU に入れていると、Entra ID に不要なアカウントまで同期されてしまいます。移行前に「同期するもの / しないもの」を OU で分けておくのがポイントです。

検証ラボでは以下の OU を作りました：

• Users-Sync — Entra ID に同期するユーザー（tyamada, hsuzuki）
• Users-NoSync — 同期しないサービスアカウント（svc-backup）
• Groups — セキュリティグループ

3. UPN 設計 〜 クラウドのログイン ID になる

UPN（User Principal Name）は user@company.com 形式のログイン ID です。AD のデフォルト UPN は .local（例: user@corp.local）ですが、.local はクラウドでは使えません。

Entra Connect はユーザーを UPN で照合します。AD 側の UPN と Entra ID のドメインが一致しないと、同期時に user@tenant.onmicrosoft.com に自動変換されてしまい、ユーザーが混乱します。

移行前にやること

1. AD に UPN サフィックスを追加する
2. ユーザーの UPN を .local からカスタムドメインに変更する
3. Entra ID 側にも同じドメインを検証済みで登録しておく

検証ラボでは wakana2.sudoadmin.dev を UPN サフィックスとして追加し、ユーザーの UPN を tyamada@wakana2.sudoadmin.dev に変更しました。

4. グループ設計 〜 Entra ID に同期されないグループがある

AD のグループを Entra ID に同期するとき、すべてのグループが同期されるわけではありません。 ここを知らないと「同期したはずのグループが Entra ID にない」というトラブルになります。

AD のグループには「種類」と「スコープ」の 2 軸があります。

種類

• セキュリティグループ — アクセス制御に使う → Entra ID に同期される
• 配布グループ — メール配信リストに使う → セキュリティグループとは扱いが異なる（Exchange Hybrid 環境ではメール有効な配布グループは同期されますが、Microsoft 365 グループとの使い分けに注意が必要）

スコープ

• グローバル — 同じドメイン内のメンバーのみ → 同期される
• ユニバーサル — フォレスト全体のメンバー可 → 同期される
• ドメインローカル — 同じドメイン内でのアクセス制御用 → 検証ラボでは Entra ID 側で確認できず（仕様上は同期可能だが制約あり、後述）

検証ラボでは 3 種類のセキュリティグループを作って確認しました：

検証ラボでは DL-FileAccess（ドメインローカル）が Entra ID 側で確認できませんでした。Entra Connect の既定構成では 3 スコープとも同期可能とされていますが、ドメインローカルにはメンバーシップ評価などの制約があり、運用面では グローバルまたはユニバーサルに統一しておくのが安全 です。ファイルサーバーのアクセス制御でドメインローカルグループを使っている場合、移行前にスコープの見直しを検討してください。

※ Entra ID 側で確認すると、SG-AllUsers と UG-M365Users は同期されていますが、DL-FileAccess（ドメインローカル）は同期されていません。

5. パスワード同期 〜 移行方式の分岐点

AD → クラウドで「パスワードをどうするか」が移行方式の分岐点になります。

AD を廃止したいなら PHS 一択です。 PTA やフェデレーションは AD / ADFS が残る前提なので、廃止の目標と矛盾します。

また、後述する MEDS を使う場合も PHS が必須 です。Entra ID にパスワードハッシュがないと、MEDS にハッシュが同期されません。

6. Entra Connect で同期を動かす

OU・UPN・グループ・パスワードの設計ができたら、いよいよ Entra Connect で同期を実行します。設計が正しければ、同期はスムーズに動きます。

検証ラボで確認したこと：

• Users-Sync OU の tyamada / hsuzuki が Entra ID に同期された
• UPN が tyamada@wakana2.sudoadmin.dev のまま正しく反映された
• Users-NoSync OU の svc-backup は同期されていない（OU フィルタリングが効いている）

同期がうまくいかない場合のよくある原因：

• OU フィルタリングで対象 OU を選択し忘れている
• UPN サフィックスが Entra ID 側で検証されていない → onmicrosoft.com に変換される
• 同じ UPN のユーザーが既に Entra ID に存在する（UPN 重複エラー）

※ Entra ID のユーザー一覧で「svc-backup」を検索しても表示されません。Users-NoSync OU に配置したユーザーが正しくフィルタリングされています。

7. MEDS（Entra Domain Services）への同期

AD を廃止したいが Kerberos/NTLM がまだ必要 — そんなときの選択肢が MEDS です。DC の管理が不要なマネージド AD サービスで、Entra ID から自動的にユーザーが同期されます。

同期の流れ

AD → Entra Connect → Entra ID → MEDS（自動）

ここからは MEDS 固有の落とし穴がいくつかあります。

パスワードハッシュが同期されない問題

MEDS の Kerberos/NTLM 認証にはパスワードハッシュが必要ですが、Entra ID 側で PHS が有効になっていても、ユーザーがパスワード変更/リセットを一度もしていないとハッシュが MEDS に同期されません。

つまり MEDS を新規構築した直後は、全ユーザーのパスワードリセットが必要です。これを知らないと「ドメイン参加しようとしたら The user name or password is incorrect で失敗する」という事態になります（実際にハマりました）。

さらに、AAD DC Administrators グループのユーザーでも、MEDS 作成後にパスワードリセット → 20-30 分の同期待ち が必要です。

sAMAccountName のハッシュサフィックス問題

MEDS に同期されたユーザーの sAMAccountName には、ハッシュサフィックスが付与される場合があります（例: tyamada → tyamada (8BF56C07)）。公式ドキュメントによると、サフィックスは以下の条件で自動生成されます：

• 複数ユーザーで mailNickname 属性が重複している場合
• mailNickname または UPN プレフィックスが 20 文字を超える場合（sAMAccountName の 20 文字制限）

検証ラボでは Entra Connect 経由で同期したユーザー（AD → Entra ID → MEDS）の sAMAccountName にサフィックスは付きませんでした（MEDS\tyamada のまま）。上記の条件に該当しなかった（重複なし・20 文字以下）ためと考えられます。

ユーザー数が多い環境や mailNickname が長いユーザーがいる場合はサフィックスが付く可能性があるため、必ず事前に確認してください。FSLogix のプロファイルフォルダ名など、sAMAccountName を前提とした設定がある場合は特に注意が必要です。

8. フォレスト信頼 〜 複数 AD を統合するとき

M&A でドメインが増えた、ユーザー管理用とデバイス管理用で AD を分けている — こういった環境では、フォレスト信頼が必要になります。

信頼関係の種類

• フォレスト信頼 — フォレスト全体を信頼（最も一般的）
• ドメイン信頼 — 特定ドメイン間のみ
• 外部信頼 — 別組織の AD との信頼

方向とスコープ

• 双方向 vs 一方向（どちらがどちらを信頼するか）
• 推移的 vs 非推移的（信頼が連鎖するか）

MEDS を使う場合もフォレスト信頼は関係あります。 AD 廃止後に VDI のデバイスドメインと MEDS の間で認証を通すには、MEDS とデバイスドメインの間にフォレスト信頼が必要です。ただし、MEDS は 一方向の Outbound 信頼のみサポート（MEDS → オンプレ AD 方向）という制約があるため、信頼の方向設計には注意してください（参考）。

検証ラボでは、corp.lab と dev.lab の 2 フォレスト間で双方向信頼を構築しました。手順は以下の通りです：

1. DNS 条件付き転送を双方に設定（お互いの名前を解決できるようにする）
2. netdom trust で双方向フォレスト信頼を作成
3. nltest /trusted_domains で信頼関係を確認

9. 認証フローを確認する 〜 信頼経由のログイン

フォレスト信頼を張ったら、実際にログインして認証の流れを確認します。

corp.lab のメンバーサーバーに、dev.lab のユーザー（DEV\devuser）で RDP ログインしてみました。

ログイン成功に必要な 5 つの条件

1. ユーザーが dev.lab に存在する
2. マシンが corp.lab にドメイン参加している
3. DNS で双方のドメインが解決できる
4. フォレスト信頼が正しく構成されている
5. ユーザーに RDP 権限が付与されている

ログイン成功後に klist を実行すると、krbtgt/DEV.LAB と krbtgt/CORP.LAB の両方の Kerberos チケットが確認できます。これがフォレスト信頼経由の認証が動いている証拠です。

まとめ

• AD DS がまだ必要かどうかの判断が移行の出発点
• 移行パターンは 3 つ: 完全クラウド / ハイブリッド / MEDS
• Entra Connect の OU フィルタリングで「何を同期するか」を制御できる
• MEDS はパスワードハッシュの前提条件や sAMAccountName サフィックスなど落とし穴がある

マスタを Entra ID に寄せることもできるので、こちらの記事も参考にしてみてください！

https://blog.cloudnative.co.jp/29854/

「こういう構成で試してみてほしい」「ウチの環境だとこうなんだけど・・・」などあれば、お気軽にコメントください。

次回は Hybrid Join や VDI 周りをラボでしっかり動かしていこうと思います！

FAQ

Q. DC は何台必要？
A. 本番は 2 台（冗長化）、検証は 1 台で OK です。

Q. フォレスト機能レベルとは？
A. AD の機能バージョンです。一度上げると下げられないので注意してください。

Q. MEDS の SKU の違いは？
A. Standard と Enterprise があり、Enterprise はレプリカセット（複数リージョン展開）に対応しています。