Skip to content

Latest commit

 

History

History
49 lines (35 loc) · 6.63 KB

Tenant-collab-GALSync.md

File metadata and controls

49 lines (35 loc) · 6.63 KB

Azure AD テナント間の連絡先交換の実装方法

概要

異なる Office 365 (Azure AD) テナントを保持する組織が相互に連絡先を交換し、それぞれの Outlook アドレス帳でお互いの連絡先情報を参照したいという要件があります。この要件に対する現時点で実装可能な方式をこの記事で共有します。

実装方式

現在技術的に実装可能かつ Microsoft がサポートする方法として以下のパターンが存在します。それぞれについて内容を後述します。どのパターンが最適か、という点については利用される環境や要件に依存します。以下にポイントを記載しますので皆様の環境で最適な方式を選択してください。

  1. オンプレミス AD 間の GAL　Sync を実装する
  2. 招待された External User をアドレス帳に表示する
  3. Azure AD テナント間の GAL Sync を実装する

この記事では連絡先情報をアドレス帳に載せる方法にフォーカスした解説を行います。Exchange Online 同士の予定表共有の実装方法については別途確認してください。

パターン１：オンプレミス AD 間の GAL Sync を実装する

このパターンは従来通りの方式で、Azure AD と Azure AD Connect を通じて同期されているオンプレミス Active Directory 同士で相互にユーザーを連絡先に変換して交換する方式です。オンプレミス間で交換された連絡先オブジェクトを Azure AD Connect を通じてさらに各 Azure AD へ同期します。

参考：https://technet.microsoft.com/ja-jp/library/aa998597(v=exchg.150).aspx

Microsoft Identity Manager 2016 (MIM) では GALSync 実装用の Management Agent (MA) が標準で用意されており、ユーザー to 連絡先への変換、および Exchange で有効な連絡先として必要な属性の同期フローや最終化のための PowerShell 実行などが自動でセットアップされます。
この方式は国内での実績も多い方式ですが、以下のような考慮点があります。

  • たくさんの (例えば 10 個以上の) オンプレミス AD が Azure AD と同期しているといった環境の場合、MIM の GALSync 用 MA を AD の数だけ作成する必要がある。また、どの AD フォレストの連絡先をどのフォレストに連携させるか、という設定を行うためにコードのカスタマイズが必要となる。(標準では GALSync MA で接続されるすべての AD 間でメッシュで連絡先の交換が行われる仕様)
  • 先に B2B によるユーザー招待が行われていた場合、B2B ユーザーの SMTP アドレスに招待時に利用されたメールアドレスがセットされた状態で出来上がるため、後に GAL Sync を行おうとした際に SMTP アドレスの重複によりエラーとなり作成処理が失敗してしまう。これを回避するためには同一ユーザーに対して必ず 1) GAL Sync 実行 2) B2B 招待という順序を守る必要があり、運用上大きな考慮点となる。

パターン２：招待された External User をアドレス帳に表示する

このパターンはテナント間で B2B 招待を行うことが想定される場合に有効な手段です。B2B で招待したユーザーを Azure AD または Exchange Online の PowerShell コマンドを利用してアドレス帳に表示させるという方法で、もともと B2B での招待を実施済みの場合には手間なく連絡先をアドレス帳に表示させることが可能です。
参考：https://support.office.com/en-us/article/guest-access-in-office-365-groups-bfc7a840-868f-4fd6-a390-f347bf51aff6?storagetype=live#PickTab=FAQ

前提として表示したい全てのユーザーがテナント間で招待されていることが挙げられますが、この操作に関しては以下のような方法で自動化実装されている事例が存在しています。

  • B2B invitation API を自動で Call し External User を招待、その後必要な属性情報を付与する PowerShell スクリプトを作成し実行する
  • Microsoft Identity Manager の Graph API Connector および PowerShell Connector を用い External User を招待し追加の属性書き込みを実施するよう構成する

この方式では、連絡先オブジェクトを作成するのではなく External User オブジェクトをアドレス帳表示に対しても用いることになります。つまり、招待したユーザーオブジェクトと連絡先として機能するアドレス帳上のオブジェクトが同じライフサイクルで管理されるということです。
一部のお客様では上記 2 つのオブジェクトを別々のライフサイクルで管理したい(※)というケースがあり、そのような場合にはこの方式は適さない、ということになります。
※例えばこんな理由が考えられます。

  • External User を管理する Identity 管理責任者と、アドレス帳の情報を管理する Exchange Online 管理者が別の組織に属している。
  • 双方のシステムの管理者は同じであるが、それぞれのオブジェクトのセキュリティ上の意味合いが異なるため、ライフサイクルは分けることが望ましい。External User は自組織のアプリケーションへのアクセス権を付与するのに利用するのに対し、連絡先はアドレス帳上に表示されるだけの情報である。例えば External　User に対してのアクセス権が不要になったため削除したいが、連絡をとる仲ではあり続けるためアドレス帳に表示はさせ続けたい。など

パターン３：Azure AD テナント間の GAL Sync を実装する

このパターンはオンプレミス環境同士で実施するのが通例であった GAL Sync を Azure AD テナント間で実装する方式です。 MIM GAL Sync のようなプリセットされた製品は Microsoft から提供されてはいないので、PowerShell や MIM Graph/PS Connector を用いたスクラッチ実装となります。多数のオンプレミス AD が Azure AD に接続しているケースなどで有効な方式です。

現在マイクロソフトコンサルティングサービスにてこのパターン 3 をサービスとして提供する準備が進んでいます。詳細は担当の Microsoft サービス営業までお問い合わせください。