はじめに
Microsoft Entra Connect（旧：Azure AD Connect）を 構成する場合に、いくつかの方法があるため、それを纏めました。
それぞれの目的（オンプレ・クラウド）
オンプレミスドメインコントローラーの目的
オンプレドメインは、ドメイン参加された PC や Server OS、Exchange Server や SharePoint Server、パッケージソフトなどの認証で利用できます。
つまり、オンプレミス専用の認証基盤です。
★Kerberos認証や、NTLM認証 が利用できます（SAML認証 は使えません）
【略称等】※以下、いずれも 同じものを指しています。
- AD DC = Active Directory Domain Controller
- AD DS = Active Directory Domain Services
- AD
- DS
- DC
- ドメコン
本記事では、 "AD DS" の表記で統一します。
AD DS を構成するための方法は、以下に記事化してあります。
Microsoft Entra ID（旧：Azure Active Directory）の目的
Microsoft Entra ID は、Microsoft Entra Join（旧：Azure AD Join）された PC へのログインや、 Microsoft365、Azure、SaaSアプリケーション などの認証で利用できます。
つまり、クラウド専用の認証基盤です。
★SAML認証 が利用できます（Kerberos認証、NTLM認証 は使えません）
【略称等】
- ME-ID（ミーアイディ）= Microsoft Entra ID
- AzureAD = Azure Active Directory
- AAD
テナントを作成するための方法は、以下に記事化してあります。
ME-ID が、 AD DS の上位互換という訳では無く、それぞれ、別の目的のための認証基盤となっていて、利用するアプリケーションに合わせて、それぞれ用意する必要があります。
特に、旧名称で比較すると "Active Directory" と "Azure Active Directory" で、非常に似通った名前になっていて、 Azure で動作する Active Directory だ！ と勘違いされることも多かったです。 そんなことはありません。全くの別モノです。
新名称（Microsoft Entra ID）になった事で、誤解の発生は 多少は減っていくのかなと思います。
比較表
以下を見ていただくと 一目瞭然。まったく 別モノです。
共通点は、"認証基盤" という点と、"Microsoft" が開発＆提供しているという点くらい。
| AD DS | Microsoft Entra ID | |
|---|---|---|
| 目的 | オンプレミス製品への認証 | クラウドサービスへの認証 |
| 目的 (詳細) |
業務パッケージ製品 ドメイン参加 PC へのサインイン Server OS サインイン Exchange Server 認証 SharePoint Server 認証 SQL Server 認証 |
Microsoft 365 Azure Dynamics 他社製クラウド (SaaS) Microsoft Entra Join PC |
| 利用環境 | 社内ネットワーク | インターネット |
| 認証方式 | Kerberos 認証 NTLM 認証 |
SAML 認証 OpenID Connect 認証 Oauth 認証 |
| 基盤 | Windows Server を利用者が構築 AD DS サービスとして稼働 |
クラウドで提供 |
| 費用 | Server OS ライセンス に含まれている 購入型 |
サブスクリプション 月額 または 年額 |
| バックアップ | 運用者自身で構築＆運用 | 自動 |
| 監視 | 運用者自身で構築＆運用 | Azure Monitor を利用可 クラウド提供 |
何のために Microsoft Entra Connect をするのか？
結論から言います。管理者 や 利用者 の利便性を高めるためです。
そして イレギュラー対応の工数を削減し、その結果 企業の 本来業務での生産性を高める効果に繋がります。
仮に、Microsoft Entra Connect を導入しなくても、
それぞれの認証基盤を 別々に管理しながら 運用することもできます。
それでも、問題無く 各アプリケーション を 利用できます。
しかし、運用を続けていると 以下のような 課題 が発生します。
- 利用者は、オンプレ用と、クラウド用 の両方の ID と パスワード の管理が必要
使い分けが必要となり、パスワード失念や勘違い入力によるアカウントロックに見舞われるなどの可能性が高まります。 - 管理者は、ユーザーが追加されるたびに それぞれの認証基盤に対して 追加作業が発生
そのほか 人事異動や 組織からの離脱があるたびに ２か所の認証基盤で 追加・変更・削除の操作が必要であり、単純に ２倍の労力が掛かります。ユーザーに アカウントロックが発生した場合は、電話などで受付を行い本人確認後に ロック解除の操作を行う運用も必要です。
規模の小さな組織であれば、それでも問題ありませんが、大規模な組織になればなるほど、その労力が 作業工数に与える影響が大きくなります。
私が以前に支援で入っていたお客様では、社員数が 1万5千名が在籍していましたが、アカウントロック対応は 毎日数件発生していました。
組織改編の時期になると、数百や 数千名の部署異動の対応が発生して、GW や 正月などの休暇時期に数日掛けてアカウントとグループの紐づけ変更も必要した。
そのような場合に、 Microsoft Entra Connect を使用して AD DS 側から Microsoft Entra テナント側 にアカウントを同期することで、数々の問題を解決する事が可能になります。
- 利用者は、１種類の IDとパスワード を憶えておくだけで オンプレミス側、クラウド側 両方への認証が行えます。
- 管理者は、AD DS へ ユーザーの 追加・変更・削除 を実施するだけで、クラウド側は 同期されたユーザー情報が維持されます。
- Microsoft Entra ID の パスワードライトバック機能を使うと、クラウド側でパスワードを変更した場合でも オンプレミス側へ反映させる事が可能になります。加えて セルフサービスパスワードリセット（SSPR）の機能で アカウントロック時でも 24時間365日 ユーザー自身で デバイスを用いてロック解除を行う事が可能になります。
SSPR によって、アカウントロックの解除が 24時間365日 受付できることは、利用者にとってメリットが大きいです。特に 深夜 や 土日、連休 の際にアカウントロックしてしまった場合でも、翌営業日 まで待つ必要がなくなります。
管理者にとっても、休暇中に 上司から緊急連絡が入って、役員がアカウントロックしてしまったので、休暇中に済まないが対応してくれ・・・と言われて対応するようなシチュエーションも無くすことができます。
さらに、アカウントロック解除は 作業は簡単なのですが、本人確認をしっかり行う必要があり、ここで手を抜くと ハッキングに遭う可能性あるので、厳重に行う必要があります。
以上のような状況に メリットを感じる場合は、Microsoft Entra Connect の導入を検討いただくと良いと思います。
オンプレミス側で必要な サービス や アプリケーション は 段々と クラウドシフトされ、淘汰されていき、いずれは無くなっていくものと考えられます。しかし、１つでも 業務に必要な アプリケーション や サービス が オンプレミス側に ある場合には、AD DS は引き続き必要です。Microsoft Entra Connect は、AD DS が淘汰されるまでの "繋ぎ" のための機能と考えていただけると良いと思います。
２種類の Microsoft Entra Connect
以下のように Connect同期 と クラウド同期 という仕組みがあります。
Connect同期 は、Azure AD の初期の時代から提供されてきた Azure AD Connect の仕組み そのものです。
あとから、クラウド同期 という仕組みが追加されたので、識別するための 従来からある方式を Connect同期 と呼ぶようになったようです。
詳細な違いは、後述する 公開情報のリンク先を見ていただきたいですが、主な違いだけ 以下の表に抜粋しました。
| 機能 | Connect同期 | クラウド同期 | 補足 |
|---|---|---|---|
| オンプレミスドメインへの接続 | 〇 | 〇 | |
| 高可用性のための複数のアクティブなエージェント | ✖ | 〇 | Connect同期は 可用性向上のためには サーバー２台構成が推奨 |
| （ユーザー・グループ・連絡先）オブジェクト のサポート | 〇 | 〇 | |
| デバイスオブジェクト のサポート | 〇 | ✖ | Intuneに必要 |
| パスワードハッシュ同期 | 〇 | 〇 | |
| パススルー認証 | 〇 | ✖ | |
| シームレスシングルサインオン | 〇 | 〇 | |
| オブジェクトの属性値でのフィルター処理 | 〇 | ✖ | OUやグループ名で同期するユーザーを制御。 大規模環境だと使う事がある |
| 属性フローの高度なカスタマイズの許可 | 〇 | ✖ | |
| パスワードライトバック | 〇 | 〇 | |
| デバイスライトバック | 〇 | △ | |
| AD ドメインあたりのオブジェクト数が無制限 | 〇 | ✖ | 拡張性に制限 |
| メンバー数が 50,000 人までのグループ | 〇 | 〇 | |
| メンバー数が 250,000 人までの大規模なグループ | 〇 | ✖ | 拡張性に制限 |
| オンデマンドプロビジョニング | ✖ | 〇 | 構築が楽 |
クラウド同期は、高可用性と オンデマンドプロビジョニング（構築が楽）がメリット大です。
拡張性は低いけど 簡単に始められます。
クラウド同期では やりたいことが実現できない場合に、Connect同期を選択すると良いと思います。
（Microsoft Entra Connect同期 とクラウド同期の比較）
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync?wt.mc_id=mvp_407731#comparison-between-microsoft-entra-connect-and-cloud-sync
同期方式を判断するための支援ツール
以下の URL から、質問に答えていくだけで どちらの同期方式が良いのかをお勧めしてくれるツールを利用できます。
（URL:適切な同期クライアントの選択）
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync?wt.mc_id=mvp_407731#choose-the-right-sync-client
以下のリンクから、ツールのサイトへ遷移できます。
「同期オプションを評価するウィザード」は、「英語」での提供になっていますが、ブラウザの翻訳機能で 十分 日本語でも利用できます。
ウィザード画面を 日本語翻訳 したところです。
AD DS 名と Microsoft Entra テナント 名 を合わせるには？
Microsoft Entra Connect を構成するためには、オンプレミス側のユーザーID（UPN）と クラウド側のユーザーID（UPN）を紐づける必要があります。
しかし、古くから AD DS の運用を続けてきた企業の多くの場合、 Contoso.local のように インターネットでは利用できないドメイン名を使っている場合があります。
しかし、この .local は、インターネット上では利用する事ができないため、Microsoft Entra テナントのドメイン名として採用することができません。
ここで乖離が生まれてしまいます。
逆に、先に Microsoft Entra テナントを所持していて、あとから AD DS を構築する（特に 検証するシチュエーションに多い）場合は、後から AD DS の名前を決められるので、テナント側のドメイン名と一緒にすることができます。一緒にすることができれば、構成を楽に済ませる事が可能になります。
上記の内容は 以下の 公開情報に 判りづらーく書かれています。
これらの判断を 以下の表を参考にして実施しましょう。
以下の表では、AD DS と テナント の状態（左半分）の組み合わせによって、それぞれ どのような対応を行えば良いか（右半分）をまとめてあります。
| AD DS の状態 |
Microsoft Entra テナント の状態 |
AD DS の対応方法 |
Microsoft Entra テナント の対応方法 |
|
|---|---|---|---|---|
| AD DS 名に テナント名を合わせて発行 |
構築済み ※インターネットで利用可能なドメイン名である必要あり |
新規に取得する | 変更なし | カスタムドメイン |
| テナント名に合わて AD DS を構築 |
未構成 | 構築済み | AD DS 名を テナント名 "xxx.onmicrosoft.com" に合わせて構築する |
変更なし |
| AD DS 名とテナント名が異なる① | 構築済み | 構築済み | 代替UPNサフィックスを構成 ユーザーのUPNを代替UPNに変更する |
カスタムドメイン または "xxx.onmicrosoft.com" を利用 |
| AD DS 名とテナント名が異なる② | 構築済み | 構築済み | 代替ユーザーIDを利用 | カスタムドメイン または "xxx.onmicrosoft.com" を利用 |
Microsoft Entra Connect のための ID構成
前章の表で "テナントの対応方法" に記載した対処方法は、以下の通りです。
これらの それぞれの対処方法について 解説していきます。
① カスタムドメイン
② AD DS のドメイン名を Microsoft Entra テナント名に合わせる
③ 代替UPNサフィックス
④ 代替ユーザーID
① カスタムドメイン
Microsoft Entra テナント を作成した直後は "～.onmicrosoft.com" というドメイン名になっています。
このままでも利用する事はできるのですが、メールアドレスは、s.noguchi@contoso.onmicrosoft.com という表記になります。
自社で Webアプリケーションを開発して公開しても、www.contoso.onmicrosoft.com という URL になってしまったりして、対外的に 何の印象も与える事はできません。
技術的な側面では カスタムドメインなんて使わなくても Connect同期は構成できるので、必須ではありません。しかし、ビジネス的な側面では、"必須" ということになります。結局、カスタムドメインを使っての Connect同期も 技術者として１回は 検証して 経験しておいた方が良いでしょうね。
Qiitaだったら "Qiita.com" で判りやすいですね。
"qiita.onmicrosoft.com" なんてドメイン名、誰も使いたいと思いません。
弊社の場合は intellilink.co.jp というドメイン名です。
よろしければ ついでに サイトも参照ください。
※ "i" と "l" が交互に使われてわかりづらいじゃねーか・・・というツッコミは ここだけにしといてくださいね～
冗談はさておき、こういった 企業の価値を高めるための独自ドメイン名を Microsoft Entra テナント で利用するためには、「カスタムドメイン」という機能を使います。
カスタムドメインの詳細や 構成の手順については、以下の記事で解説しています。
② AD DS のドメイン名を Microsoft Entra テナント名に合わせる
この方法は、シンプルです。
既に お持ちの テナント名に合わせて、AD DS を構築する際に 同じドメイン名 にすれば OK です。
AD DS の構築手順は、以下の記事で紹介しています。私の ベストセラー記事です。
是非参照ください。
上記の記事で「ドメインコントローラーを昇格させる」の章で ドメイン名を指定しています。
テナント名が、"xxx.onmicrosoft.com" であれば、それを「ルートドメイン名」へそのまま設定。
テナント名が、"カスタムドメイン名" であれば、それを「ルートドメイン名」へそのまま設定。
★この設定で デキるよ・・・っていう情報は あまり無いと思うので、ぜひ参考にしてください（検証済みです）
「ルートドメイン名」の指定箇所です。
既に AD DS が構築済みの場合でも、それが インターネットで取得可能なドメイン名であれば、後からテナントを取得して カスタムドメインを構成して、同じ名称を構成することも可能です。
③ 代替UPNサフィックス
前章 ② で、AD DS と テナント のドメイン名を 揃える事が出来なかった場合の回避策です。
まずは、この ③ の方法を検討しましょう。
【注意点】
代替UPNサフィックスを使った場合には AD DS 環境でサインインを行う場合の UPN が変更になります。
AD DS 側の UPN が変わるため、利用者に説明をしたり、手順書を変更したり、業務アプリケーションで問題無く動作するか？ などの考慮事項が必要になります。
上記のような注意点はあるものの、 利用者にとっては AD DS 側と クラウド側で 全く同一の ユーザーID（UPN）を使う事ができる・・・というメリットを享受できる方式です。
この構成方法は 以下に 記事を記載していますので、参考にしてみてください。
④ 代替ユーザーID
前章「③ 代替UPNサフィックス」を採用できなかった場合の最後の手段です。
「③ 代替UPNサフィックス」を使った場合には オンプレミスドメイン環境でサインインを行う場合の UPN が変更になってしまいますが、そのような変更が 受け入れられないような場合に、「④ 代替ユーザーID」の方法が適しています。
代替ユーザーID の場合は、AD DS 側のユーザーID は変更する事が無いため、オンプレミス側の利用シーンに変更は一切ありません。
デメリットとしては、利用者は AD DS へのサインイン時と、 Microsoft Entra テナント へサインインする時で 異なった UPN を使い分ける必要が発生します（Connect同期しているので パスワードは同一です）
いずれ、代替ユーザーID の手順解説の記事も執筆したいと思いますが、取り急ぎ 以下の URL を紹介します。
（URL：Microsoft Entra ID の代替ユーザーID の解説ページ）
https://learn.microsoft.com/ja-jp/azure/active-directory/authentication/howto-authentication-use-email-signin?wt.mc_id=mvp_407731
（URL：Windows Server の代替ユーザーID の解説ページ）
https://learn.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/configuring-alternate-login-id?wt.mc_id=mvp_407731
まとめ
本記事で記載させていただいた内容を参考に AD DS と クラウド側のドメイン名 をどう設計するのか？ そして、①～④ のどの仕組みを組み合わせて利用するのか・・・の検討に役立てていただければ幸いです。
Next Step
Microsoft Entra Connect が構成できたら、次は Hybrid Join にチャレンジしてみては如何ですか？