Latest / M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語） / Microsoft Entra Cloud Sync をわかりやすく解説：Active Directory と Entra ID を軽量に同期する方法（AI吹き替え）

Transcript

Microsoft Entra Cloud Sync をわかりやすく解説：Active Directory と Entra ID を軽量に同期する方法（AI吹き替え） · M365.FM – Microsoft 365・Copilot・AI ポッドキャスト（日本語）

0:00
マイクロソフト365、コパイロット、AI、Azure、そして働き方の未来を築く人々と過ごす10日間の準備はできていますか?
0:07
この1月、M365カンファレンスが帰ってきます。さらに規模を拡大して開催します。
0:12
世界中のMVPや業界の専門家によるライブセッション、実践的なデモ、役立つ知識をぜひ体験してください。
0:18
ありきたりなスライドや空虚な専門用語の羅列はありません。
0:22
コパイロットスタジオ、AIエージェント、ファブリック、セキュリティ、ガバナンス、自動化など、真の課題に取り組みます。
0:29
ITプロフェッショナル、開発者、ビジネスリーダーの皆様、それぞれのニーズに合わせたセッションをご用意しています。
0:35
10日間という充実した期間で、多様な技術を探求し、世界中のコミュニティとつながることができます。
0:40
ライブで視聴し、組織に持ち帰れる実践的な洞察を得ましょう。
0:45
2027年1月、10日間、一つのマイクロソフトコミュニティ、登録受付を開始しました。
0:52
今すぐお申し込みを。
0:54
ウェブサイトは、メートル365コンドットネットです。
0:59
メートル365コンドットネットから今すぐ参加登録を、1月のライブでお会いしましょう。
1:05
皆さんこんにちは。
1:06
M365でお届けする、マイクロソフトナレッジナゲッツ、へようこそ。
1:10
FM、EOWTMNM、ミルコピーターズです。
1:13
マイクロソフトエントラクラウドシンクとは一体何でしょうか?
1:15
エントラコネクトの別名なのか、それとも別の問題を解決するものなのでしょうか?
1:19
多くの企業では、今も従業員のアカウントを社内ネットワーク内のアクティブディレクトリで管理しています。
1:23
しかし、従業員はマイクロソフト365で業務を行っています。
1:26
彼らにはチーム、エクスチェンジオンラインのメール、ワンドライブのファイル、そしてクラウドアプリが必要です。
1:30
その結果、ID管理が重要な場所が2つ存在することになります。
1:33
両者を結びつけるものがないと、アクティブディレクトリには存在しても、
1:35
マイクロソフト365のクラウド受付デスクであるエントラIDには存在しないという状況が起こり得ます。
1:39
パスワードが一致しません。
1:41
アクセスが遅れます。
1:42
IT担当者は同じ作業を2度行うことになります。
1:45
エントラコネクトは、この2つの場所を結びつけるおなじみのローカルツールとなりました。
1:49
クラウドシンクは、同期作業の多くをマイクロソフトエントラ側で処理するという異なるアプローチを取っています。
1:54
最後には、この機能の役割存在する理由、そして2026年に何が変わったのかを深く理解できるはずです。
1:58
しかし、あなたの会社に適しているかどうかを決める境界線が1つだけ存在します。
2:02
なぜID同期にシンプルなモデルが必要なのか、新しい従業員の例から始めましょう。
2:06
人事部からIT部門へ、月曜日にマヤが入社するという連絡が入ります。
2:09
誰かがアクティブディレクトリにマヤのアカウントを作成します。
2:12
多くの企業で、これは今も社内のスタッフ台帳として使われています。
2:15
彼女の名前、仕事用メール、部署、上司、グループ所属、そしてパスワードの詳細がすべてそこから始まります。
2:21
しかし、マヤは社内ネットワークの中だけで働くわけではありません。
2:24
彼女は自宅からチームにサインインする必要があります。
2:26
彼女はエクスチェンジオンラインのメールボックスも必要です。
2:28
彼女のチームはシェアポイントにファイルを保存しており、初日が終わるまでに給与、CRM、研修、その他のクラウドアプリへのアクセスが必要になるかもしれません。
2:34
一人の人間には、一つの機能するIDが必要です。
2:37
そのアイデンティティは、両方の場所で同じマヤであることを示さなければなりません。
2:41
サインイン名は一致させる必要があります。
2:42
グループ情報もクラウドに届ける必要があります。
2:45
アクティブディレクトリでパスワードが変更された際、Microsoft 365もそのパスワードを安全に確認できる必要があります。
2:51
それがID同期の役割です。
2:53
アクティブディレクトリをオフィスビルの地下にあるファイリングキャビネットだと考えてください。
2:57
そこには、会社がすでに信頼しているスタッフの記録が保管されています。
3:00
エントラIDは上の階の受付に座り、誰がMicrosoft 365に入り、どの部屋を使えるかを決定します。
3:06
ファイリングキャビネットと受付が情報を共有できなければ、マヤはドアで止められてしまいます。
3:11
20年前、その断絶が多くの手作業を生んでいました。
3:14
ITチームはローカルでアカウントを一つ作成し、さらにクラウドサービスで別のアカウントを作成していました。
3:18
マヤが改名したり、チームを移動したり、退職したりするたびに、誰かが彼女のデータがある全ての場所を覚えておく必要がありました。
3:25
人は忘れるものです。
3:26
ID同期によるその新しい連携が、IT担当者の日常業務を一変させました。
3:30
アクティブディレクトリでの変更がエントラIDに反映されるようになり、クラウド上のアカウントは別個の記録ではなく、ローカルアカウントに推奨するようになりました。
3:36
長い間、エントラコネクトがその作業を担ってきました。
3:39
エントラコネクトは社内ネットワーク内のサーバーで実行されます。
3:42
アクティブディレクトリを読み取り、ローカルの同期ルールを適用し、独自のローカルデータストアを保持して、承認された変更をエントラIDに送信します。
3:48
特に企業がデータの流れを詳細に制御する必要がある場合、多くのことが可能です。
3:53
その柔軟性には責任が伴います。
3:55
誰かがサーバーを管理しなければなりません。
3:57
誰かがパッチを適用しなければなりません。
3:58
ユーザーの同期認証が期待通りにいかない場合、誰かがローカルのルールを理解しなければなりません。
4:02
そして、メインの同期サーバーが停止すれば、IT部門が問題を修正するか復旧計画を実行するまで、変更がMicrosoft 365に届かなくなる可能性があります。
4:08
マヤにとって、それはアカウントが使用できない状態を意味するかもしれません。
4:11
数百、数千の従業員を抱える企業では、新入社員がクラウドアプリに表示されなかったり、無効化したアカウントのアクセス権削除に時間がかかったりして、サポートへの問い合わせが殺到する可能性があります。
4:21
問題は、エントラコネクトという製品そのものが失敗したわけではありません。
4:24
ローカルのエンジンには、必ずローカルでの作業が伴うということです。
4:27
多くの企業は、自社のサーバー上の稼働要素を減らしたいと考えています。
4:30
クラウド同期はその考えに基づいています。
4:32
巨大な同期エンジンや詳細な処理、ルールの大部分を社内ネットワークに置くのではなく、マイクロソフトエントラがその作業の多くをクラウドで行います。
4:39
ローカルネットワークには、アクティブディレクトリを読み取って安全に外部と通信できる、より小さな接続ポイントだけを残します。
4:44
ファイリングキャビネットは元の場所に残ります。
4:46
処理は受付デスクの近くに移動するのです。
4:48
これにより、チームが管理すべきローカルソフトウェアの量を削減しつつ、従業員情報の起点としてアクティブディレクトリを維持できます。
4:55
また、特に複数のオフィスや複数のディレクトリがある場合や、最近合併があった企業では、リカバリに対する考え方も変わります。
5:01
では、同期の主要な処理がクラウドで行われるのであれば、社内ネットワークには一体何が残るのでしょうか。
5:07
それこそが、マイクロソフトエントラクラウドシンクの正体です。
5:10
マイクロソフトエントラクラウドシンクは、アクティブディレクトリから特定のユーザー、グループ、連絡先をエントラIDにコピーするためのクラウド管理型サービスです。
5:17
安全な宅配サービスだと考えてください。
5:20
アクティブディレクトリは、社内ネットワーク内にスタッフの記録を保持しています。
5:23
エントラIDは、ユーザーがマイクロソフト365にサインインできるように、それらの記録のうち承認された部分を必要とします。
5:28
クラウドシンクはプロビジョニングエージェントという小さな宅配人をネットワーク内に配置し、両者の間で情報を安全に運びます。
5:34
この宅配人は、別のファイルシステムを保持することはありません。
5:37
承認されたディレクトリ情報を読み取り、暗号化し、アウトバウンド接続を通じてマイクロソフトエントラへ送信します。
5:43
アウトバウンド接続とは、エージェント側からクラウドへの通信を開始することを意味します。
5:46
ネットワークを開放して、外部からの不明な接続を待機する必要はありません。
5:50
これは、非常に有用なセキュリティの詳細です。
5:52
エージェントは社内ネットワーク内に存在するため、アクティブディレクトリにアクセスできます。
5:56
エージェントがデータをクラウドへ安全に送信するため、マイクロソフトエントラはデータを処理できます。
6:00
両者は、自社サーバー上に巨大な同期エンジンを設置することなく、連携して動作できます。
6:04
裏側では、エントラが作業の大半を処理します。
6:07
そのユーザーがエントラIDにすでに存在するかを確認します。
6:10
選択したスコープを適用します。
6:12
設定したフィールドマッピングに従います。
6:14
そして、情報がルールに一致すれば、クラウド上のオブジェクトを作成または更新します。
6:18
これらの選択肢は、エントラポータルで管理します。
6:21
エントラコネクトをご存知の方にとっては、大きな変化となります。
6:23
エントラコネクトでは、ロジックやトラブルシューティングの多くは、同期ツールを実行しているサーバー上で行われます。
6:28
クラウドシンクでは、ポータルで構成を作成し、同期するものを選び、フィールドをマッピングし、結果をクラウド上の一箇所で確認します。
6:35
ローカルエージェントは軽量なままです。
6:37
クラウドシンクには、ローカルSQLデータベースを備えた巨大な同期エンジンは存在しません。
6:42
基本的なマッピングを確認するたびに、ローカルのルールエディターを開く必要はもうありません。
6:47
マイクロソフトがエージェントの更新を処理し、チームはビジネスに重要なアイデンティティルールに集中できます。
6:53
これは、コントロールを失うという意味ではありません。
6:55
エントラIDに参加させるユーザーやグループは、引き続きあなたが選択します。
6:59
表示名、部署、電話番号、マネージャーなどのフィールドを選択できます。
7:03
マッピングとは、アクティブディレクトリレコードのどのラベルをエントラIDのどのラベルに反映させるか、という単純な問いに答えるものです。
7:09
多くの企業では、規定のマッピングで通常のスタッフアカウントに対応できます。
7:13
アクティブディレクトリの表示名がマヤパテルであれば、エントラIDもマヤパテルを受け取れます。
7:17
部署が営業部からカスタマーサクセス部に変更された場合、その更新がクラウドのアカウントにも反映されます。
7:21
グループメンバーシップによってマイクロソフト365リソースへのアクセス権が付与されている場合、グループ情報も同期されます。
7:26
一部のセットアップでは、小さな変更が必要になることがあります。
7:29
クラウド同期には、移動中に値を調整する必要がある場合に備えて、シンプルな式が含まれています。
7:33
例えば、特定のいくつかのアカウントの表示名に設備時を追加したい場合があるかもしれません。
7:37
ローカルの同期ルールを複雑に構築するのではなく、クラウドの設定でそれを指定できます。
7:41
その違いを心に留めておいてください。
7:43
クラウド同期は、一般的なID管理業務に対して適切な制御を提供します。
7:47
これは、長期運用されているエントラコネクトセットアップに含まれるすべての高度なカスタマイズを自動的にコピーするように設計されているわけではありません。
7:53
この決定については後ほど触れますが、単に新しいという理由だけでツールを選択してしまう事態を防ぐためです。
7:58
パスワードに関する質問が最も多く寄せられます。
8:01
クラウド同期では、パスワードハッシュ同期を使用できます。
8:03
この言葉は、実際よりも少し警戒心を抱かせる響きがあります。
8:06
読み取り可能なパスワードがマイクロソフトエントラに送信されることはありません。
8:10
その代わり、アクティブディレクトリが保護されたパスワード検証情報を作成し、エントラIDがそれを使用して安全にサインインを確認します。
8:17
そのため、マヤは会社のパスワードを使用してマイクロソフト365にサインインできます。
8:21
彼女のパスワードの管理元は依然としてアクティブディレクトリです。
8:23
彼女がアクティブディレクトリでパスワードを変更すると、更新された検証情報がエントラIDに同期されます。
8:28
これにより、マイクロソフト365はパスワードの家読コピーを保存することなく、サインインを確認できます。
8:33
一つの所有権ルールが全てを明確に保ちます。
8:36
ユーザーがアクティブディレクトリから同期される場合、同期の詳細を編集する場所はアクティブディレクトリのままとなります。
8:41
マヤやティムの部署や役職を変更する必要がある場合、アクティブディレクトリで変更すれば、クラウド同期がその変更をエントラIDに反映します。
8:47
多くの場合、クラウド側のこれらのフィールドは編集できないようにロックされています。
8:51
これは問題ではありません。
8:52
アカウントの管理元がどこにあるかを示しているのです。
8:54
後に計画的な権限ソースの変更を通じて所有権を変更することは可能ですが、クラウド同期がローカルアカウントを勝手にクラウド管理アカウントに変換することはありません。
9:01
エージェントの存在がクラウド同期を軽量に感じさせる理由ですが、次のパートではサーバーが1台オフラインになっても動作し続ける理由を説明します。
9:08
サーバー障害時にクラウド同期が動作し続ける仕組み。
9:11
同期ツールはアクティブディレクトリに到達できる間しか役に立ちません。
9:14
月曜の朝、サーバーの緊急再起動が必要になったり、警告なしにリスクが故障したりする状況を想像してみてください。
9:19
マネージャーがアクティブディレクトリで新入社員を登録しても、その人がマイクロソフト365に表示されないことがあります。
9:24
退職した従業員を無効にしても、クラウドのアカウントに変更が反映されるまで時間がかかります。
9:29
こうした遅延は、IT部門にとって大きな負担となります。
9:31
従来のエントラコネクト構成では、企業は多くの場合、1台のアクティブな同期サーバーを運用し、もう1台をバックアップとしてステージングモードで待機させています。
9:38
そのバックアップには計画とテストが必要であり、アクティブなサーバーが故障した際の明確な引き継ぎプロセスが求められます。
9:43
クラウドシンクは異なるアプローチを取ります。
9:45
同じアクティブディレクトリドメイン内に複数のプロビジョニングエージェントをインストールできます。
9:49
各エージェントはマイクロソフトエントラの同じクラウドシンク構成に接続し、それぞれが同じディレクトリ情報を読み取ることができます。
9:54
どれか1つのエージェントを高級的なリーダーとして扱う必要はありません。
9:58
マイクロソフトエントラが利用可能なエージェントを監視します。
10:01
もし1台のエージェントがオフラインになっても、クラウドサービスは稼働中の別のエージェントを使用して処理を継続できます。
10:06
これが組み込みの効果要請であり、1台のサーバーが単一障害点になることを防ぐシンプルな仕組みです。
10:12
同じスタッフ名簿を使う2つのヘルプデスクを想像してみてください。
10:15
一方のデスクが閉まっていても、もう一方のデスクで電話対応や受付を継続できます。
10:19
社内の人間は、どちらのデスクがリクエストを処理したかを知る必要はありません。
10:22
彼らにとって重要なのは、アクセスが正常に機能することだけです。
10:25
それが実用的なメリットです。
10:27
大規模なローカル同期エンジンを中心に手動のフェールオーバー計画を立てる代わりに、軽量なエージェントを複数インストールし、エントラに稼働中のエージェントを使用させるのです。
10:35
それでも、エージェントの健全性の監視、サーバーのサポート維持、復旧計画のテストは引き続き必要です。
10:39
組み込みのフェールオーバーがあるからといって、責任あるIT管理が不要になるわけではありません。
10:43
ただ、一台の危機にかかるプレッシャーを軽減することはできます。
10:46
クラウドシンクは、企業が複数のアクティブディレクトリフォレストを持っている場合にも役立ちます。
10:49
フォレストとは、独立したアクティブディレクトリ環境のことです。
10:52
企業買収などによって、このような環境が生じることがあります。
10:55
2つの企業は異なるドメインやネットワークを使用しており、ローカルディレクトリ同士が直接通信できない場合があるからです。
11:02
これは合併後によくある状況です。
11:04
クラウドシンクなら、各フォレストの近くにエージェントをインストールできます。
11:08
各エージェントは自身のローカルアクティブディレクトリを読み取り、外部の同じマイクロソフトエントラテナントへと接続します。
11:13
ローカルのディレクトリが分離したままでも、クラウドが共通の接続先となります。
11:17
この構成では、フォレスト間の直接的なネットワークパスは必要ありません。
11:21
ロンドンの企業がトロントの企業を買収したと仮定します。
11:24
両チームが同じマイクロソフト365テナントを利用する必要がありますが、従来のディレクトリネットワークを接続するには数ヶ月かかり、セキュリティ上の懸念も生じます。
11:30
ロンドンのエージェントでロンドンのアカウントを同期し、トロントのエージェントでトロントのアカウントを同期することができます。
11:35
どちらのユーザー群も同じエントラーIDに集約可能です。
11:38
これにより、チーム、メール、クラウドアプリへのアクセスを妨げることなく、大規模なディレクトリ作業を計画する時間を確保できます。
11:43
それでも実用上の要件は存在します。
11:45
各エージェントには、ローカルのアクティブディレクトリへの信頼性の高い接続が必要です。
11:48
また、Firewallやプロキシを経由して、マイクロソフトUTMSクラウドサービスへの送信アクセスも必要です。
11:53
エージェントを適当なコンピューターに配置して、うまくいくことを期待してはいけません。
11:57
サポートされているサーバー上に配置し、適切なローカルアクセス権を与え、本番環境のセットアップでは複数のエージェントをインストールしてください。
12:03
可用性が接続を維持します。
12:04
しかし、どの接続でどのアカウントを同期させるかという判断は、何を同期し、どのように管理を維持するかという点において同様に重要です。
12:11
クラウドシンクがアカウントをエントラーIDへ移動し始める前に、同期範囲に誰を含めるかを正確に決定してください。
12:17
範囲とは、クラウドシンクが読み取りおよびコピーを許可されているアクティブディレクトリの部分を指します。
12:21
ドメイン内のサポートされているすべてのオブジェクトを選択できます。
12:24
これは、整理されたディレクトリと明確な従業員アカウントを持つ小規模企業に適している場合があります。
12:28
大規模な企業では通常、より注意が必要です。
12:31
アクティブディレクトリには、古いテストユーザー、サービスアカウント、トレーニング用アカウント、そして誰もMicrosoft 365で表示したくないグループが含まれている可能性があるからです。
12:38
小規模から始めれば驚くような事態を防げます。
12:41
クラウドシンクでは、組織単位、Oと呼ばれることが多い、またはセキュリティグループによって範囲を制限できます。
12:46
Oは、アクティブディレクトリ内のラベル付きホルダーのようなものです。
12:49
従業員という名の王や契約社員という名の王、あるいはITテストアカウントという名の王などがあるかもしれません。
12:57
あるいは、従業員の王だけをMicrosoft 365に反映させたい場合は、その王を選択できます。
13:03
グループベースの範囲指定も別の選択肢として用意されています。
13:05
ホルダー全体を選択する代わりに、セキュリティグループを選択し、テストしたいユーザーだけを追加します。
13:10
これは、ディレクトリ内のアカウントを移動させずに小規模なパイロット運用を行いたい場合に有効です。
13:13
まずはテストグループから始めてください。
13:15
エントラーIDに表示されても安全な数名の基地のユーザーを選びます。
13:18
彼らのサインイン名、部署の詳細、グループメンバーシップを確認してください。
13:21
正しいアカウントが表示されることを確認してから、結果を信頼できる段階で範囲を拡大します。
13:24
その小さな確認作業が、後に発生する非常に長いクリーンアップ作業を回避してくれます。
13:27
誰を同期するかを決めたら、次にどの詳細情報を一緒に同期するかを決定します。
13:31
これは属性マッピングと呼ばれますが、意味するところは単純です。
13:33
アクティブディレクトリアカウントのどのフィールドを、エントラーIDアカウントのどのフィールドに割り当てるかということです。
13:38
ユーザーレコードには、名、姓、表示名、電話番号、オフィス、かみつかさ、部署などが含まれる場合があります。
13:43
クラウドシンクには、一般的なセットアップ向けのデフォルトマッピングが含まれています。
13:47
多くの場合、最初はそれらのデフォルト設定をそのままにしておくべきです。
13:50
それらはほとんどの企業が必要とする標準的なフィールドをカバーしており、結果が正しくない場合でも何が変更されたのかを把握しやすくなります。
13:55
明確なビジネス上の理由がある場合は、マッピングを調整できます。
13:59
例えば、企業が電話番号をローカルフィールドに保存しており、それがエントラーの目的のフィールドと一致していない場合などです。
14:04
クラウドシンクなら、そのフィールドをマッピングできます。
14:07
また、複雑なローカルルールを構築せずに値に小さな変更を加えるための簡易的な式もサポートしています。
14:11
しかし、正常なセットアップを自動的にパズル化してはいけません。
14:14
IDプロセスが真相的で特殊なロジックに依存している場合は、マッピングを変更する前にその要件を書き留めておきましょう。
14:20
通常のアカウントについては、6ヶ月後に誰も理解できなくなるような巧妙なルールよりも明確なデフォルト設定の方が優れています。
14:24
クラウドシンクは、広範囲な動機を有効にする前に安全にテストする方法を提供します。
14:28
オンデマンドプロビジョニングと呼ばれる機能を自動化します。
14:30
ユーザーを一人選び、クラウドシンクにこのアカウントをどう処理しますか?と尋ねるのです。
14:34
オンデマンドプロビジョニングの結果は、エージェントがユーザーを見つけたか、そのユーザーがスコープ内にあるか、エントラーIDが一致するアカウントを見つけたか、そしてクラウドシンクがそれを作成または更新するかを示します。
14:43
他のすべての人に影響が及ぶ前に、その判断を確認できます。
14:46
ITチームがクラウドシンクテストというパイロットグループを作成したと想像してください。
14:50
誰かが誤ってその中に大きなグループを追加し、その大きなグループには数百人の従業員が含まれていたとします。
14:55
オンデマンドプロビジョニングを使えば、数百ものアカウントがテナントに出現した後ではなく、チームが一人をテストしている段階でスコープの問題を明らかにできます。
15:01
私にとって、そのようなミスは早期に発見すべきものなのです。
15:04
クラウドシンクには、誤削除保護機能も含まれています。
15:08
構成が突然大量のユーザーやグループを削除しようとした場合、サービスは実行を停止し、その被害をそのままエントラIDにコピーする代わりに構成を隔離状態にできます。
15:16
管理者はアラートを受け取り、調査を行うことができます。
15:19
エントラポータルでは、プロビジョニングログも確認できます。
15:22
ユーザーを検索すれば、何が起こったのか、オブジェクトが一致したか、フィールドでエラーが発生したか、エージェントが接続したか、構成が正常に保たれているかを確認できます。
15:30
ID同期がうまく機能しているときは、静かなものです。
15:33
何か問題が発生したときは、推測に頼ることなく、ログがどこを見るべきかを教えてくれます。
15:37
クラウドシンクはより幅広いニーズをカバーするようになりましたが、すべてのエントラコネクト設定を置き換えるわけではありません。
15:43
クラウドシンクとエントラコネクト、そして2026年の移行について考えてみましょう。
15:47
では、すべての企業がエントラコネクトからクラウドシンクに移行すべきなのでしょうか。
15:50
いいえ、クラウドシンクは新しいツールですが、新しいからといって必ずしもあなたの環境に適しているとは限りません。
15:54
重要なのは、どの製品がよりモダンに聞こえるかではなく、現在のIDシステムに何が求められているかという点です。
15:59
クラウドシンクは、ローカル環境を簡素化し、同期設定をクラウドで管理したい企業に適しています。
16:04
アクティブディレクトリのユーザー、グループ、連絡先を主にエントラIDへ同期したい場合に非常に有効です。
16:09
また、ネットワークを事前に統合することなく、各拠点を同じエントラテナントに接続できるため、フォレストが分かれている企業にも最適です。
16:16
グループベースのスコープ設定も利用できます。
16:18
これは、特定のビジネスユニットや新しいオフィス、あるいは少数のユーザーグループから先行して移行したい場合に便利です。
16:24
エントラポータルで同期設定を維持し、エージェントを監視できるため、中央サーバーで大規模な同期エンジンを動かす必要がありません。
16:30
エントラコネクトも依然として重要な役割を担っています。
16:33
パススルー認証やフェデレーションなど、クラウドシンクが同様の方法でサポートしていないサインイン方式を利用している企業も存在します。
16:39
パススルー認証は、ユーザーのサインイン時にアクティブディレクトリでパスワードを直接検証します。
16:43
フェデレーションは、サインイン要求を企業が既に利用している別のIDシステムへ送信します。
16:48
こうした構成には慎重な計画が必要です。
16:50
エントラコネクトは、高度なローカル同期ルールを持つ企業にも適しています。
16:54
特殊なフィールドのデータを組み合わせたり、詳細なフィルタリングを適用したり、長年かけて構築した複雑なカスタムルールに依存している場合などです。
17:00
すべてのルールを精査せずに、よりシンプルなツールへ置き換えると問題が発生する可能性があります。
17:05
エクスチェンジハイブリッド構成も選択に影響します。
17:07
エクスチェンジオンラインを利用しながら、一部のエクスチェンジ環境をオンプレミスで運用し続けている企業もあります。
17:11
エクスチェンジのタスクによっては、アクティブディレクトリへの詳細な書き戻しが必要なものがあります。
17:15
これにより、マイクロソフト365とエクスチェンジ環境の間で、メール関連情報の整合性を保つことができます。
17:20
クラウドシンクがニーズを満たせるかどうかは、現在のエクスチェンジ構成次第です。
17:23
しかし、2026年にその状況が変わりました。
17:26
クラウドシンクは、ハイブリッドエントラID参加のためのデバイス同期に対応しました。
17:29
これは、社内のWindowsデバイスがローカルのアクティブディレクトリに所属しつつ、クラウドでのアクセスと管理のためにエントラIDでのIDも必要な場合に重要となります。
17:35
多くの企業にとって、デバイス同期の必要性がエントラコネクトを使い続ける理由となっていました。
17:39
今やクラウドシンクでもそれが可能になったことで、導入を見送っていたチームにとっての大きな壁が一つ取り除かれました。
17:44
引き続きデバイス設定やWindowsの計画、Intuneの運用状況を精査する必要はありますが、選択の基準はもはやユーザーやグループだけではありません。
17:50
さらにマイクロソフトは、エクスチェンジハイブリッド属性の書き戻し機能もパブリックプレビューで追加しました。
17:54
簡単に言うと、クラウドシンクがクラウド上の特定のエクスチェンジ関連情報をアクティブディレクトリへ書き戻せるようになったということです。
17:59
パブリックプレビューとは、マイクロソフトが正式リリース前に実際の利用状況やフィードバックを収集している段階を指します。
18:04
そのため、長期間運用されている機能よりも慎重に扱う必要があります。
18:08
製品アップデートのわずか1分を根拠に、エクスチェンジ環境を自動的に移行しないでください。
18:12
最新のマイクロソフトドキュメントを読み、基本版環境のアカウントでテストを行い、自社に必要な属性を正確に確認しましょう。
18:18
エクスチェンジはIDの詳細が一致しない場合に非常に厳格な挙動を示すことがあります。
18:22
クラウド同期を利用することで、使い慣れた安全管理機能をポータル上で活用できます。
18:26
パスワードハッシュ同期を使用できます。
18:27
問題が発生した際に適切な担当者へ通知が届くよう設定できます。
18:31
ご操作による削除を防止する保護設定も可能です。
18:33
ローカルの同期サーバーを全ての中心にするのではなく、エントラから構成を管理できるようになります。
18:38
両ツールの機能範囲は近づきつつあります。
18:40
とはいえ、全ての企業でクラウド同期がエントラコネクトの代替になるとは限りません。
18:44
この選択は車両選びのように考えてみてください。
18:46
小型バンは小回りが効いて駐車しやすいため、近距離の配送ルートに適しているかもしれません。
18:51
大型トラックはバンでは運べない荷物を扱えるため、別の業務に適しています。
18:54
どちらの選択も間違いではありません。
18:56
決断を下す前に、いくつかの直接的な質問をしてみましょう。
18:59
アクティブディレクトリフォレストは一つですか?
19:00
それとも複数の独立したフォレストがありますか?
19:10
現在の同期サービスが失敗した場合、どの程度迅速に復旧できますか?
19:13
それらの回答を書き留めておきましょう。
19:14
最終決定を、一斉以降で始めるべきではありません。
19:17
まずは小規模で制御されたテストから始め、クラウド同期が実際のユーザーアカウントや要件を扱えるかを確認してください。
19:23
それが企業にとって安全な第一歩です。
19:26
まずはシンプルなIDマップを書くことから始めましょう。
19:29
すべてのアクティブディレクトリフォレストとドメインをリストアップします。
19:31
現在エントラコネクトを実行しているか、どのユーザーを同期しているか、どのデバイスにハイブリッドIDが必要か、そしてメールシステムがどこでローカルアクティブディレクトリに依存しているかを記録します。
19:38
単純な構成にしておきましょう。
19:39
次に、現在のクラウド同期のサポート状況と自社のニーズを比較します。
19:42
まずはサインイン方法を確認してください。
19:44
エクスチェンジの要件を確認します。
19:45
デバイス、書き戻し、そして数年前に誰かが作成し、以来誰も確認していないカスタムマッピングもチェックしましょう。
19:50
そのリストが隠れた依存関係を明らかにすることがあります。
19:52
クラウド同期が適していると判断したら、本番環境には少なくとも2つのプロビジョニングエージェントをインストールしてください。
19:56
テスト環境では1つのエージェントでも動作するかもしれませんが、本番環境のID同期は可能であれば1台のサーバーに依存すべきではありません。
20:02
次に、限定的な構成を作成します。
20:04
テスト用の組織単位を、や小さなセキュリティグループを選択してください。
20:07
変更すべき明確な理由がない限り、デフォルトのマッピングを使用します。
20:10
次に、特定のユーザーを選択し、定期的な同期を有効にする前にオンデマンドでプロビジョニングを実行してください。
20:14
その結果を注意深く確認しましょう。
20:16
エントラが適切な人物を見つけ、想定通りのアカウントを作成し、期待されるフィールドを送信しているかを確認してください。
20:21
ポータルのログも確認してください。
20:22
ステータスが緑色であるというだけでは、ビジネスルールが正しく機能しているとは証明できないからです。
20:26
移行中に注意すべき警告が1つあります。
20:29
であると思い込まないでください。