Microsoft Entra IDで他テナントのDatabricksユーザーとグループを同期してみた

はじめに

こんにちは、データエンジニアをしているMaruです。
近年、データ分析・AI基盤としてDatabricksを採用する企業が増える一方で、Azureテナント構成やID連携の運用管理が複雑化しています。特に、複数のAzureテナントを横断して運用する場合、「Azure Aテナントで組織のID管理を統一しつつ、技術検証用のBテナント上に構築されたDatabricks環境へユーザーやグループを同期したい」というニーズもあるかと思います。

しかし、このようなテナントを跨いだ同期については、事例や技術記事などでほとんど取り上げられていません。そこで本記事では、Microsoft Entra IDのSCIMプロビジョニング機能を利用して、クロステナントでのユーザー・グループ同期を実際に検証し、その結果を紹介します。

本記事の対象者

• 複数テナントをまたいでAzure Databricks環境を運用している/運用を検討している方
• Microsoft Entra IDやSCIMプロビジョニングを活用してID管理を自動化したい方

記事の構成

記事の構成は以下の通りです。

1. Azure Databricksでのユーザー・グループ同期
2. 検証概要
3. 検証準備
4. 検証結果
5. まとめ

1. Azure Databricksでのユーザー・グループ同期

Azure Databricksでは、Microsoft Entra ID（以降Entra IDと略称）と連携してユーザーやグループを自動的に同期する2つの主要な方法があります。
自動ID管理は、同一テナント内のID同期を前提とする「中央集権型」の仕組みであるのに対し、SCIMプロビジョニングは、テナントをまたいだ「分散管理型」の仕組みです。Databricksでは同一テナント内であれば自動ID管理を推奨しています。

特徴	自動ID管理	SCIMプロビジョニング
ユーザーの同期	○（可能）	○（可能）
グループの同期	○（可能）	○（可能）
入れ子になったグループの同期	○（可能）	×（不可）
サービスプリンシパルの同期	○（可能）	×（不可）
Entra IDアプリケーション構成管理	○（不要）	×（必要）
Entra ID Premiumエディション	○（不要）	×（必要）
テナント外のDatabricksへの同期	△（テナント間同期経由であれば可能）	○（可能）

1-1. 自動ID管理

自動ID管理とは、同一テナント内でEntra IDのユーザー・グループをDatabricksに自動的に同期できる仕組みです。アプリケーション登録やSCIM設定を行わなくても、Entra IDを「信頼できるIDソース」として扱い、ユーザーの追加・削除やグループ構成の変更をDatabricksに自動反映できます。
自動ID管理は基本的に同一テナント内で完結しますが、Azureテナント間同期を利用することで、他テナントからユーザーやグループを同期し、結果的にDatabricksとの自動同期を間接的に実現することも可能です。
ただし、Azureテナント間同期ではグループの入れ子構造が維持されず、同期時にフラット化される点に注意が必要です。

自動ID管理は、2025年8月1日以降に作成されたアカウントに対して既定で有効になっています。アカウント管理者は、アカウントコンソールで自動ID管理を有効にすることができます。

https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/automatic-identity-management

1-2. SCIMプロビジョニング

SCIM（System for Cross-domain Identity Management）とは、複数のIDプロバイダー間でユーザーやグループの作成・削除・更新を自動化するためのオープン標準仕様です。Databricksでは、このSCIM標準を採用しており、Entra IDのSCIMコネクタを利用することで、ユーザーやグループをDatabricksに自動同期できます。
SCIMプロビジョニングでは、ユーザーやグループを直接Databricksに同期できるため、テナント間で同期する場合にB2B連携やAzureテナント間同期のようにユーザーを複製・招待する必要がありません。その結果、ユーザー・グループを管理しているテナントのEntra IDを主としたシンプルかつ一貫したID管理を実現できます。
ただし、SCIMプロビジョニングでは、入れ子構造の同期は公式ドキュメント上サポートされていないため、Entra IDで階層構造を持つグループがある場合でも、Databricks上ではフラット構造として同期されます。
https://learn.microsoft.com/ja-jp/azure/databricks/admin/users-groups/scim/

2. 検証概要

実案件の中で、Aテナントのユーザー・グループ情報を、Bテナント上のDatabricks環境に連携したいという要望がありました。
ただし、AテナントとBテナントの間には既存の同期設定はなく、完全に独立した構成となっていました。そのため、1-1で紹介した自動ID管理はテナント内での同期しか対応しておらず、Azureテナント間同期を併用する場合も、Bテナントでは既に多くのITシステムやユーザー・グループが稼働しており、同期による影響が不明瞭であったため、この構成の採用には慎重な検討が必要でした。
そこで、1-2で紹介したEntra IDのSCIMプロビジョニングを利用すれば、テナントを跨いだユーザーやグループを直接同期でき、複雑な構成を回避しつつ、よりシンプルな運用が実現できると考えました。また、過去の社内検証では、公式ドキュメント上では非対応とされている入れ子構造のグループが同期されていた事例も確認されており、実際の挙動を改めて検証する価値があると判断しました。

以上を踏まえ、SCIMプロビジョニングを用いたクロステナント同期が公式ドキュメント通りに動作するか、さらに入れ子構造のグループが本当に同期されるかを検証しました。

2-1. 検証イメージ図

同期連携イメージは以下の通りです。AzureはAテナントとBテナントを用意し、BテナントにDatabricksを配置しています。

2-2. ユーザー同期に関する検証観点

ユーザー項目では、プロビジョニング時の既存/新規ユーザーの挙動や、認証、属性（メールアドレス）の変更などを項目として入れました。期待結果は、公式ドキュメントの内容をベースに記載しています。

No.	カテゴリ	検証観点	検証内容	期待結果
1	ユーザー状態	同一ユーザー存在時	SCIMプロビジョニング同期前にDatabricks上に同一ユーザーがいる場合、同一ユーザーとして認識されるか	既存ユーザーとして認識され、重複登録されない
2		新規ユーザー登録	SCIMプロビジョニング同期前にDatabricks上に同一ユーザーがいない場合、新規でユーザーが登録されるか	新規ユーザーとして自動登録される
3	同期対象	非同期対象ユーザー	同期対象外に設定したユーザーは同期されないか	同期対象外ユーザーはDatabricks上に作成されない
4	ユーザー認証	既存ユーザー認証	Bテナントにすでにユーザーが登録されている場合、Entra IDによるSSO認証が利用できるか	Entra IDで正常にSSOログイン可能
5		未登録ユーザー認証	Bテナントにまだユーザーが登録されていない場合、Entra IDによるSSO認証が利用できないか	ユーザー未登録のためSSO認証不可（アクセス拒否）
6	ユーザー属性	メールアドレス変更	ユーザーのメールアドレスが変更された場合、変更が反映されるか	Databricks上のメールアドレスは更新されない

2-3. グループ同期に関する検証観点

グループ同期項目では、プロビジョニング時の既存/新規グループの挙動や、入れ子構造、メンバーの変更などを項目として入れました。期待結果は、公式ドキュメントの内容をベースに記載しています。

No.	カテゴリ	検証観点	検証内容	期待結果
7	グループ状態	同一グループ存在時	SCIMプロビジョニング同期前にDatabricks上に同一グループがある場合、同一グループとして認識されるか	既存グループとして認識され、重複登録されない
8		新規グループ登録	SCIMプロビジョニング同期前にDatabricks上に同一グループがない場合、新規でグループが登録されるか	新規グループとして自動登録される
9	同期対象	非同期対象グループ	同期対象外に設定したグループは同期されないか	同期対象外グループはDatabricks上に作成されない
10	入れ子構造	組織階層の継承	Entra IDの組織の入れ子構造が、Databricksに同期されるのか	入れ子構造は同期されず、フラットな構造で同期される
11	グループ属性	グループ名変更	グループ名の変更が反映されるか	Databricks上のグループ名は更新されない
12		メンバー変更	グループメンバーの変更が反映されるか	メンバー変更がDatabricksに同期される

3. 検証準備

本章では、検証に向けた準備についてお伝えします。

• 3-1. ユーザーとグループ準備
• 3-2. 属性マッピング設定
• 3-3. プロビジョニング対象の設定

詳しいSCIMプロビジョニング設定手順は本記事では省きますが、以下の記事が参考になります。

https://qiita.com/taka_yayoi/items/95672f67f3e2c3304a6f

3-1. ユーザーとグループの準備

AzureのAテナントとBテナント、およびBテナント内のDatabricksアカウントにユーザーおよびグループを登録します。

3-1-1. AテナントのEntra ID

Aテナントでは、以下のユーザーとグループ階層を準備しておきます。

ユーザー名	所属グループ階層	Bテナント存在有無	同期対象有無	Databricks存在有無
豊洲 太郎	サンプル株式会社/営業部	〇	〇	×
豊洲 次郎	サンプル株式会社/営業部/法人担当	×	〇	×
豊洲 花子	サンプル株式会社/マーケティング部	〇	〇	〇
豊洲 三郎	サンプル株式会社/人事部	〇	×	×
豊洲 智子	-	×	×	×

3-1-2. BテナントのEntra ID

Bテナントでは、以下の3名を登録しておきます。グループは作成しません。

ユーザー名	所属グループ階層
豊洲 太郎	-
豊洲 花子	-
豊洲 三郎	-

3-1-3. Bテナント内のDatabricksアカウント

Databricksアカウントでは、既存ユーザーとして以下の1名をグループ所属とともに登録しておきます。

ユーザー名	所属グループ階層
豊洲 花子	サンプル株式会社/マーケティング部

3-2. 属性マッピング設定

SCIMプロビジョニングでは、Entra IDとDatabricks間でユーザー属性を同期する際に、属性マッピングを設定します。

3-2-1. ユーザー属性

デフォルトでは、Entra ID側のuserPrincipalNameがDatabricks側のuserNameにマッピングされていますが、本検証では、メールアドレス同士でユーザーを照合するため、以下のようにEntra ID側の属性をmailに変更しました。

Entra ID属性	Databricks属性	照合の優先順位	備考
mail	userName	1	マッピング時に利用する属性。Entra ID属性をデフォルトのuserPrincipalNameからmailに変更。
Not([IsSoftDeleted])	active	-	マッピング後に更新される属性。ユーザーの有効/無効状態を同期。デフォルト設定。
displayName	displayName	-	マッピング後に更新される属性。表示名を同期。デフォルト設定。
objectId	externalId	-	マッピング後に更新される属性。一意のIDを維持。デフォルト設定。

3-2-2. グループ属性

グループ属性は、デフォルト設定のままとしました。

Entra ID属性	Databricks属性	照合の優先順位	備考
objectId	externalId	1	マッピング時に利用する属性。グループの一意識別子として使用され、既存グループとの照合に利用。デフォルト設定。
displayName	displayName	2	マッピング時に利用する属性。表示名で照合。デフォルト設定。
members	members	-	マッピング後に更新される属性。グループメンバーの追加・削除を同期。デフォルト設定。

3-3. プロビジョニング対象の設定

AzureのAテナントのプロビジョニング設定にて、プロビジョニング対象とするユーザーおよびグループを設定します。グループ単位で設定すると、グループ直下に所属するユーザーも同期対象となります。今回は、「人事部」グループを除いた以下の4つのグループを同期対象としました。

• サンプル株式会社
• 営業部
• 法人担当
• マーケティング部

4. 検証結果

本章では、SCIMプロビジョニングを有効化し、ユーザーおよびグループで各検証観点ごとに検証した結果をお伝えします。

4-1. ユーザー同期

ユーザー同期における検証結果は以下の通りです。すべて期待通りの結果となりました。

No.	カテゴリ	検証観点	検証内容	検証結果	期待通りか
1	ユーザー状態	同一ユーザー存在時	SCIMプロビジョニング同期前にDatabricks上に同一ユーザーがいる場合、同一ユーザーとして認識されるか	既存ユーザーとして認識され、重複登録されなかった	〇
2		新規ユーザー登録	SCIMプロビジョニング同期前にDatabricks上に同一ユーザーがいない場合、新規でユーザーが登録されるか	新規ユーザーとして自動登録された	〇
3	同期対象	非同期対象ユーザー	同期対象外に設定したユーザーは同期されないか	同期対象外ユーザーはDatabricks上に作成されなかった	〇
4	ユーザー認証	既存ユーザー認証	Bテナントにすでにユーザーが登録されている場合、Entra IDによるSSO認証が利用できるか	Entra IDで正常にSSOログイン可能であった	〇
5		未登録ユーザー認証	Bテナントにまだユーザーが登録されていない場合、Entra IDによるSSO認証が利用できないか	SSO認証不可であった	〇
6	ユーザー属性	メールアドレス変更	ユーザーのメールアドレスが変更された場合、変更が反映されるか	Databricks上のメールアドレスは更新されなかった	〇

検証結果：No.1-3

「豊洲 太郎」、「豊洲 次郎」、「豊洲 花子」がユーザーとして一意に登録されている。同期対象外の「豊洲 三郎」と「豊洲 智子」は登録されていない。

検証結果：No.4-5

Bテナントに存在する「豊洲 太郎」はログインできた。初期ログイン時はワークスペースの権限が割り振られていない可能性があるため、SCIMプロビジョニング後に適切な権限を割り振ること。

Bテナントに存在しない「豊洲 次郎」はログインできない。

検証結果：No.6

「豊洲 花子」のメールアドレスを変更したが、Databricksへ変更は反映されなかった。※画像内のメールアドレスはマスキング

4-2. グループ同期

グループ同期における検証結果は以下の通りです。No.9とNo.10のみ期待とは異なる結果が得られました。
No.9の非同期対象グループについては、親グループが同期対象となっていたため、それに紐づく子グループも同期対象となってしまうことが分かりました。ただし、同期されるのはグループのみでグループ直下のメンバーは同期されないようです。
No.10の入れ子構造については、同期されることが分かりました。この結果について、Microsoftの技術サポートに問い合わせたところ、一部のアプリケーションでは入れ子構造の同期が利用可能な場合があるとのことでした。したがって、今回はそれに該当した可能性があると考えられます。ただ、公式ドキュメント上は不可という記載のため、十分に検証およびサポートへの確認のもと、慎重に適用を判断する必要があります。

No.	カテゴリ	検証観点	検証内容	検証結果	期待通りか
7	グループ状態	同一グループ存在時	SCIMプロビジョニング同期前にDatabricks上に同一グループがある場合、同一グループとして認識されるか	既存グループとして認識され、重複登録されなかった	〇
8		新規グループ登録	SCIMプロビジョニング同期前にDatabricks上に同一グループがない場合、新規でグループが登録されるか	新規グループとして自動登録された	〇
9	同期対象	非同期対象グループ	同期対象外に設定したグループは同期されないか	親グループが同期対象の場合、子グループも同期された（ただし子グループのメンバーは同期されない）	×
10	入れ子構造	組織階層の継承	Entra IDの組織の入れ子構造が、Databricksに同期されるのか	入れ子構造は同期された	×
11	グループ属性	グループ名変更	グループ名の変更が反映されるか	Databricks上のグループ名は更新されなかった	〇
12		メンバー変更	グループメンバーの変更が反映されるか	メンバー変更がDatabricksに同期された	〇

検証結果：No.7-10

既存グループがある場合は外部グループとして上書きされ、既存グループがない場合は新規でグループが作成された。
同期対象外としていた「人事部」が同期されてしまっている。（ただしメンバーは0人）
また、入れ子構造も同期されている。

検証結果：No.11

「法人担当」を「第一法人担当」に変更したが、SCIMプロビジョニングによる更新後、変更はDatabricksへ反映されなかった。

検証結果：No.12

「豊洲 太郎」を「営業部」直下から「マーケティング部」に移行させたところ、Databricksへ反映された。

5. まとめ

今回の検証では、Microsoft Entra IDのSCIMプロビジョニングを利用することで、クロステナント間でもユーザー・グループ同期が可能であることを確認しました。また、公式ドキュメント上は非対応とされるグループの入れ子構造も同期されるケースがあることを確認しました。
一方で、一部の非同期対象グループが同期されてしまう挙動や、グループ名変更がDatabricks上に反映されないといった仕様上の制約も確認できました。
そのため、命名規則の統一や手動でのメンテナンスを含め、実際のユーザー・グループ管理要件に合わせた慎重な設計・検証が求められます。

最後までお読みいただき、ありがとうございました。