はじめに

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 にチャレンジしてみては如何ですか？