自動ID管理

自動ID管理機能により、IDプロバイダーからDatabricksにユーザーとグループをシームレスに追加できます。Microsoft Entra IDを使用する場合、サービスプリンシパルとネストされたグループも同期されます。自動 ID 管理が有効になっている場合、ID フェデレーションワークスペースでユーザーとグループを直接検索し、ワークスペースに追加できます。 DatabricksはIDプロバイダーを記録のソースとして使用するため、グループメンバーシップの変更はDatabricksにも反映されます。

ワークスペースからMS Entra IDグループを追加

ユーザーは、IDプロバイダー内の任意のユーザーまたはグループとダッシュボードを共有することもできます。共有すると、それらのユーザーとグループのメンバーは、ログイン時にDatabricksアカウントに自動的に追加されます。それらは、ダッシュボードが配置されているワークスペースのメンバーとして追加されません。ワークスペースへのアクセス権を持たないユーザーには、共有データ権限で公開されたダッシュボードの閲覧専用コピーへのアクセス権が付与されます。ダッシュボードの共有に関する詳細については、「ダッシュボードを共有する」を参照してください。

自動ID管理が有効になっている場合、ジャストインタイム（JIT）プロビジョニングは常に有効になり、無効にすることはできません。新規ユーザーは、初回ログイン時にDatabricksに自動的にプロビジョニングされます。ユーザーの自動プロビジョニング（JIT）を参照してください。

ID管理機能のないフェデレーションワークスペースでは、自動的なID管理はサポートされていません。ID フェデレーションの詳細については、「ID フェデレーション」を参照してください。

注記

Identity Attribute Control List 機能プレビューを有効にすると、自動 ID 管理によって、title、department、costCenter などの固定された ID 属性セットも ID プロバイダーから Databricks アカウントユーザーに同期されます。これらの属性はベータ版です。詳細については、「ID 属性」を参照してください。

ユーザー、サービスプリンシパル、およびグループの状態

自動ID管理が有効になっている場合、IDプロバイダーのユーザーとグループがアカウントコンソールとワークスペース管理者設定ページに表示されます。Microsoft Entra IDを使用する場合、サービスプリンシパルも表示されます。それらのステータスは、IDプロバイダーとDatabricks間の活動状況と状態を反映しています。

ステータス	意味
非アクティブ：使用されていません	ユーザーおよびサービスプリンシパルの場合：まだDatabricksにログインしていないIDプロバイダーのID。グループの場合: グループはワークスペースに追加されていません。
アクティブ	DatabricksではID管理が有効になっています。
アクティブ: [IdP]から削除されました	以前はDatabricksでアクティブでしたが、IDプロバイダーから削除されました。Databricksは、次回のID同期時にこれらのユーザーを自動的に無効化します。APIsにログインまたは認証できません。
無効化済み	IDプロバイダーでIDが無効化されたか、IDプロバイダーから削除された後にDatabricksが自動的にIDを無効化しました。APIsにログインまたは認証できません。
拒否済み	アカウントへのアクセス拒否リストに、該当のIDが追加されました。DatabricksはIDを非アクティブに設定します。ログインできない、個人アクセストークンを使用できない、または共有ダイアログに表示されない。アカウントへのアクセスを拒否する方法について参照してください。

ステータス	意味
非アクティブ：使用されていません	ユーザーおよびサービスプリンシパルの場合：まだDatabricksにログインしていないIDプロバイダーのID。グループの場合: グループはワークスペースに追加されていません。
アクティブ	DatabricksではID管理が有効になっています。
アクティブ: [IdP]から削除されました	以前はDatabricksでアクティブでしたが、IDプロバイダーから削除されました。Databricksは、次回のID同期時にこれらのユーザーを自動的に無効化します。APIsにログインまたは認証できません。
無効化済み	IDプロバイダーでIDが無効化されたか、IDプロバイダーから削除された後にDatabricksが自動的にIDを無効化しました。APIsにログインまたは認証できません。
拒否済み	アカウントへのアクセス拒否リストに、該当のIDが追加されました。DatabricksはIDを非アクティブに設定します。ログインできない、個人アクセストークンを使用できない、または共有ダイアログに表示されない。アカウントへのアクセスを拒否する方法について参照してください。

アクティブ: [IdP]から削除済みステータスラベルには、IDプロバイダーの名前が含まれています。 例えば、 アクティブ：EntraIDから削除 。

ヒント

セキュリティのベストプラクティスとして、Databricksは、無効 化された ユーザーおよび [IdP]から削除されたアクティブ ユーザーの個人アクセストークンを失効させることを推奨します。IDプロバイダーからユーザーが削除されると、Databricksは自動的にそのユーザーのアカウントを無効化しますが、トークンは自動的に失効させません。

自動ID管理を使用して管理されているIDは、Databricksでは 「外部」 として表示されます。外部IDはDatabricksのUIを使用して更新することはできません。

権限の共有と割り当て

自動ID管理が有効になっている場合、Databricks全体で権限を共有または割り当てる際に、IDプロバイダーからユーザーを選択できます。Microsoft Entra IDを使用する場合、サービスプリンシパルも利用可能です。

グループにおける共有行動は、資産の種類によって異なります。

アカウントレベルのアセット：Databricks Apps、Unity Catalogオブジェクト、AI/BIダッシュボード、Genieエージェント、ワークスペース割り当てなどのアカウントレベルのアセットを共有または権限を割り当てる際に、グループが利用可能です。
ワークスペースレベルの資産: ワークスペースレベルの資産 (ノートブック、ジョブ、 SQLウェアハウス、アラート、ファイルなど) をグループと共有するには、ワークスペース管理者はまずグループをワークスペースに直接追加する必要があります。

自動 ID 管理 vs SCIMプロビジョニング

自動 ID 管理が有効になっている場合、すべてのユーザー、グループ、およびグループメンバーシップが ID プロバイダーからDatabricksに同期されるため、 SCIMプロビジョニングは必要ありません。 SCIMプロビジョニングを並行して実行し続ける場合、 SCIM SCIMを使用して追加された ID を引き続き管理します。 SCIMプロビジョニングを使用して追加されなかった ID は管理されません。

Databricksは、自動ID管理の利用を推奨しています。以下の表は、自動 ID 管理の機能とSCIMプロビジョニングの機能を比較しています。

機能	自動ID管理	SCIMプロビジョニング
ユーザーを同期する	✓	✓
同期グループ	✓	✓ （直接会員限定）
ネストされたグループを同期する	✓ （Microsoft Entra IDのみ）
同期サービスプリンシパル	✓ （Microsoft Entra IDのみ）
Databricks内でデフォルトで利用可能	✓
IDフェデレーションが必要です	✓

機能	自動ID管理	SCIMプロビジョニング
ユーザーを同期する	✓	✓
同期グループ	✓	✓ （直接会員限定）
ネストされたグループを同期する	✓ （Microsoft Entra IDのみ）
同期サービスプリンシパル	✓ （Microsoft Entra IDのみ）
Databricks内でデフォルトで利用可能	✓
IDフェデレーションが必要です	✓

自動ID管理によるIDの照合方法

自動ID管理がIDを同期する際、そのIDはIDプロバイダー内の正しいユーザー、Service Principal、またはグループと照合されます。Databricksが照合に使用する情報は、同期がどのようにトリガーされるかによって異なります。

以下に、Microsoft Entra ID のマッチングについて説明します。DatabricksはすべてのIDプロバイダーに対して同じ原則を適用します。つまり、IDプロバイダーから安定した識別子が利用可能な場合はそれに基づいてマッチングを行い、利用できない場合はDatabricksのユーザー名に基づいてマッチングを行います。以下のユーザープリンシパル名（UPN）、Eメール、およびB2Bゲストの詳細は、Microsoft Entra ID固有のものです。

サインイン時のマッチング

ユーザーがSingle Sign Onを通じてサインインすると、DatabricksはIDプロバイダーからトークンを受け取ります。トークンにユーザーのオブジェクトIDが含まれている場合、Databricksは安定した一意の識別子であるオブジェクトIDに基づいてマッチングを行います。これが最も信頼性の高い一致です。

サインイントークンにオブジェクトIDが含まれるかどうかは、Single Sign Onの構成によって異なります。Databricksでは、サインイン時に安定した識別子で照合できるように、トークンクレームにオブジェクトIDを含めるようSingle Sign Onアプリケーションを構成することをお勧めします。トークンにオブジェクトIDが含まれていない場合、Databricksはトークン内のユーザー名にフォールバックし、「ユーザー名による照合」で説明されているように、UPNまたはEメールによってMicrosoft Entra IDユーザーを照合します。

ユーザー名による一致

権限コンテキストの作成や更新、個人用アクセストークン認証、アカウントコンソールでの操作、バックグラウンドでのID同期など、一部のフローにはサインイントークンが含まれません。これらのフローでは、DatabricksはDatabricksのユーザー名に基づいてマッチングを行います。Microsoft Entra IDで、ユーザープリンシパル名（UPN）またはEメールがDatabricksのユーザー名と一致するユーザーを検索し、Eメールの一致よりもUPNの一致を優先します。

たとえば、Databricksユーザーのユーザー名が alice@contoso.com である場合、DatabricksはまずUPNが alice@contoso.com であるMicrosoft Entra IDユーザーを検索します。UPNが一致しない場合、Eメールが alice@contoso.com であるユーザーを検索します。

ユーザーの解決および作成時の照合

Databricksにまだ存在しないMicrosoft Entra IDのIDとオブジェクトを共有する場合、またはResolve User API（resolveByExternalId）が呼び出された場合、DatabricksはまずUPNまたはEメールによって既存のDatabricksユーザーとのマッチングを試みます。一致するユーザーがいない場合、Databricksはジャストインタイムでユーザーを作成し、Microsoft Entra IDにおけるユーザーの存在形式に基づいてユーザー名を設定します：

テナント内に作成されたユーザー：Databricks では UPN をユーザー名として使用します。たとえば、UPN が bob@contoso.com である Microsoft Entra ID ユーザーは、ユーザー名 bob@contoso.com を持つ Databricks ユーザーになります。
B2B コラボレーションを通じて招待または同期されたユーザー（ゲスト）：Databricks ではユーザー名として Eメールを優先し、ゲストオブジェクトに Eメールがない場合は UPN を使用します。たとえば、UPN が carol_fabrikam.com#EXT#@contoso.onmicrosoft.com で Eメールが carol@fabrikam.com であるゲストは、ユーザー名 carol@fabrikam.com を持つ Databricks ユーザーになります。

自動ID管理で解決できないケース

一部のIDプロバイダー構成では、Databricksが意図したユーザーを確実にマッチングできない場合があります。以下のケースを回避するために、IDを設定してください。

複数のユーザーが同じEメールに一致しています

Databricksのユーザー名と一致するEメールを持つMicrosoft Entra IDユーザーが複数存在し、かつ一致するUPNを持つユーザーがいない場合、Databricksは意図されたユーザーを特定できません。順序は保証されず、そのうちの1つと一致するため、誤ったユーザーが同期される可能性があり、時間の経過とともに同期対象のユーザーが切り替わる可能性があります。

たとえば、Databricksユーザーのユーザー名はdana@contoso.comです。Microsoft Entra IDにおいて、2人のユーザーがEメールdana@contoso.comを持っています。1人はUPNがd.lee@fabrikam.comのメンバーアカウント、もう1人はUPNがdana_contoso.com#EXT#@fabrikam.onmicrosoft.comのゲストアカウントです。ユーザー名は両方のユーザーのEメールと一致しますが、どちらのUPNとも一致しないため、Databricksはそれらを区別できず、任意にそのうちの1つとマッチングします。

このケースを回避するには、対象のMicrosoft Entra IDユーザーのUPNがDatabricksユーザー名と一致していることを確認し、同じEメールを共有する複数のMicrosoft Entra IDオブジェクトを保持しないようにしてください。

ユーザー名は別のテナントから取得されています

ゲストユーザーは、ホームテナントのユーザー名を含むトークンでサインインできますが、テナント内のゲストオブジェクトには、そのユーザー名と一致するUPNもEメールもありません。サインイン時でもこれは機能します。なぜなら、トークンベースの照合ではユーザー名ではなくオブジェクトIDからユーザーを解決するためです。トークンを使用しないフローは代わりにDatabricksユーザー名で照合されるため、同期するゲストオブジェクトを見つけることができず、解決や共有によって予期しないユーザー名を持つDatabricksユーザーが作成される可能性があります。

たとえば、Databricksユーザーのユーザー名がerin@fabrikam.comである場合、これはユーザーのホームテナントから引き継がれたものです。テナント内では、ゲストオブジェクトのUPNは erin_fabrikam.com#EXT#@contoso.onmicrosoft.com であり、一致するEメールはありません。トークンベースのサインインではオブジェクトIDによってこのユーザーが解決されますが、UPNもEメールも erin@fabrikam.com と一致しないため、ユーザー名ベースのマッチングではユーザーが見つかりません。

このケースを回避するには、ゲストオブジェクトのEメールがDatabricksのユーザー名と一致していることを確認してください。

グループメンバーシップの同期の仕組み

自動ID管理が有効になっている場合、Databricksは、ブラウザへのログイン、トークン認証、ジョブの実行など、認証および認可チェックをトリガーするアクティビティ中に、IDプロバイダーからユーザーグループメンバーシップを更新します。これにより、Databricksにおけるグループベースの権限設定が、IDプロバイダーで行われた変更と常に同期されるようになります。

Databricksがグループメンバーシップを更新する際、IDプロバイダーから推移的（ネストされた）グループメンバーシップを取得します。これは、ユーザーがグループ A のメンバーであり、グループ A がグループ B のメンバーである場合、 Databricksユーザーが両方のグループのメンバーシップを持っていると認識することを意味します。 Databricksは、Databricksに追加されたグループのメンバーシップ情報のみを取得します。IDプロバイダーから親グループの階層構造全体を同期または再構築することはありません。

ネストされたグループ同期には、Microsoft Entra IDが必要です。Oktaはネストされたグループ同期をサポートしていません。

Databricksは、アクティビティに応じて異なるスケジュールでグループメンバーシップを更新します。

ブラウザログイン : 前回の同期から5分以上経過している場合、グループメンバーシップが同期されます。
その他のアクティビティ （トークン認証やジョブの実行など）：Databricksは、前回の同期から経過した時間に基づいてグループメンバーシップを更新します：
- 10分未満 ：更新は行われません。
- 10～40分 : Databricksはバックグラウンドで非同期更新をTriggerします。更新をトリガーする要求では、以前のグループメンバーシップが引き続き使用される可能性があります。更新されたメンバーシップは、後続の要求に適用されます。
- 40分以上 ：Databricksは、リクエストを完了する前にグループメンバーシップを更新します。

ネストされたグループとサービスプリンシパル

自動ID管理が有効になっている場合、ネストされたグループのメンバーは、プロビジョニングされたグループから権限を継承します。親グループに割り当てられた権限は、グループに直接追加されたユーザーと、ネストされたグループメンバーシップを通じて所属するユーザーを含め、そのグループに属するすべてのユーザーとサービスプリンシパルに適用されます。ただし、グループ内の入れ子になったグループとサービスプリンシパルは、ダッシュボード共有を除き、アカウント内で自動的に参照できません。

サービスプリンシパルの同期とネストされたグループの同期には、Microsoft Entra IDが必要です。Oktaは、サービスプリンシパルまたはネストされたグループの同期をサポートしていません。

ネストされたグループの可視性

ネストされたグループはDatabricksで表示されます。親グループGroup-Pのメンバーである子グループGroup-Cを考えます。ワークスペースにGroup-P追加すると、 Group-PとGroup-Cの両方に含まれるすべてのIDがそのワークスペースにアクセスできるようになります。アカウント管理者およびワークスペース管理者のUIでは、 Group-Cグループメンバーの詳細ページでGroup-Pメンバーとして表示されます。グループの詳細ページには、ネストされた階層の第一階層のみが表示されます。

入れ子になったグループに関する考慮事項

ワークスペースへのアクセス: アクセスを取得するために、ネストされたグループとサービスプリンシパルをワークスペースに直接追加する必要はありません。ワークスペースに親グループを追加すると、そのグループのすべてのメンバーがワークスペースにアクセスできるようになります。
アカウントレベルのアセット：Databricks Apps、Unity Catalogオブジェクト、AI/BIダッシュボード、Genieエージェント、ワークスペース割り当てなどのアカウントレベルのアセットを共有または権限を割り当てる際に、グループが利用可能です。
アカウントグループおよびサービスプリンシパルの制限: アカウントに直接プロビジョニングされていない入れ子になったグループおよびサービスプリンシパルは、アカウントグループの制限にはカウントされません。アカウントに明示的にプロビジョニングされたグループのみが、制限の対象となります。

例えば、IDプロバイダーには次のようなグループ構造があります。

Marketing-All （親グループ）
- Marketing-US （子どもグループ）
- Marketing-EU （子どもグループ）
- Marketing-APAC （子どもグループ）

ワークスペース管理者がワークスペースにMarketing-Allを追加した場合：

アクセスが許可されました: Marketing-Allのすべてのメンバーと、そのすべての子グループ ( Marketing-US 、 Marketing-EU 、 Marketing-APAC ) はワークスペースにアクセスできます。例えば、 Marketing-APACのユーザーとサービスプリンシパルは認証を行い、ワークスペースを使用できます。
アカウントプロビジョニング: Marketing-AllのみがDatabricksアカウントに対するプロビジョニングであり、アカウントグループの制限にカウントされます。子グループは、明示的にプロビジョニングしない限り、制限の対象にはなりません。
アカウントレベルのアセット: Marketing-Allとそのすべての子グループ ( Marketing-US 、 Marketing-EU 、 Marketing-APAC ) は、ダッシュボードやUnity Catalogのオブジェクトなどのアカウントレベルのアセットへのアクセス許可を共有または割り当てるときに使用できます。

自動ID管理を有効にする

設定手順については、ご利用のIDプロバイダーのガイドを参照してください。

自動ID管理を無効にする

自動ID管理が無効になっている場合：

ユーザーとサービスプリンシパルは引き続き存在します。アクセス権は保持されますが、IDプロバイダーとの同期は行われなくなります。自動ID管理を無効にした後、アカウントコンソールでユーザーとサービスプリンシパルを手動で削除または無効化できます。
グループがメンバーシップを失う: グループはDatabricksに残りますが、すべてのグループメンバーが削除されます。
IDプロバイダーとの同期が行われていません：IDプロバイダーでの変更（ユーザーの削除やグループの更新など）は、Databricksに反映されません。
権限の継承なし：自動ID管理によって管理されるユーザーは、親グループから権限を継承できません。これは、ネストされたグループベースのアクセス許可モデルに影響します。

自動 ID 管理を無効にする予定がある場合、 Databricks 、フォールバックとして事前にSCIMプロビジョニングを設定することをお勧めします。 SCIMはその後、IDとグループの同期を引き継ぐことができる。

アカウント管理者として、アカウントコンソールにログインします。
サイドバーで 「セキュリティ」 をクリックします。
「 ユーザープロビジョニング」 タブで、 「自動ID管理」を 「無効」 に切り替えます。

アカウントへのアクセスを拒否する

アカウントアクセス拒否リストは、ID プロバイダーのどの ID がDatabricksアカウントへのアクセスを許可されるかを制御します。アカウント管理者は、特定のユーザー、グループ、またはサービスプリンシパルを拒否リストに追加して、それらのアクセスをブロックできます。拒否リストのメンバーシップは推移的です。グループを拒否すると、ネストされたグループ内のメンバーを含むすべてのメンバーも拒否されます。

設定手順および拒否リストの動作の詳細については、「アカウントへのアクセスを拒否する」を参照してください。

自動ID管理イベントを監査する

自動ID管理が有効になっている場合、監査ログを使用して、自動ID管理プロセスによって実行されたID操作を追跡できます。

自動ID管理イベントの監査ログタグ

自動ID管理では、既存の監査ログイベントを利用しますが、ID同期プロセスによって自動的に実行される操作を識別するためのタグを追加します。

エンドポイント: "autoUserCreation" - イベントが自動ID管理プロセスから発行されたことを示します。このタグは、ユーザー操作 ( add 、 activateUser 、 deactivateUser 、 updateUser )、グループ操作 ( createGroup 、 updateGroup 、 removeGroup )、およびグループメンバーシップ操作 ( addPrincipalToGroup 、 removePrincipalFromGroup ) に表示されます。
groupMembershipType: "IdentityProvider" - グループメンバーシップ操作 ( addPrincipalToGroup 、 removePrincipalFromGroup ) に表示され、グループメンバーシップが ID プロバイダーから同期されたことを示します。

クエリ自動ID管理監査イベント

system.access.auditテーブルを照会することで、自動ID管理操作を追跡できます。例えば：

自動ID管理によって作成されたユーザーを追跡する：

SQL
SELECT
  request_params.targetUserName,
  event_time
FROM
  system.access.audit
WHERE
  action_name = "add"
  AND request_params.endpoint = "autoUserCreation"

IDプロバイダーから同期されたグループメンバーシップを追跡します。

SQL
SELECT
  request_params.targetGroupName,
  request_params.targetUserName,
  event_time
FROM
  system.access.audit
WHERE
  action_name IN ("addPrincipalToGroup", "removePrincipalFromGroup")
  AND request_params.groupMembershipType = "IdentityProvider"

system.access.auditテーブルの詳細については、「監査ログシステムテーブルリファレンス」を参照してください。

既知の挙動と制限事項

このセクションでは、自動ID管理を使用する際に、すぐには明らかにならない可能性のある動作について説明します。

グループの作成とワークスペースへの割り当て

自動ID管理機能がIDプロバイダーからグループを同期すると、アカウントレベルで自動的にグループが作成されます。これらのイベントは、監査ログにcreateGroup操作として表示され、 endpoint: "autoUserCreation"というタグが付けられています。アカウントレベルのグループ作成は自動ですが、ワークスペースの割り当ては別の手動ステップです。同期されたグループのメンバーは、アカウント管理者がグループをワークスペースに割り当てた後にのみ、ワークスペースへのアクセス権を取得できます。自動ID管理はグループメンバーシップを制御し、管理者はワークスペースへのアクセスを制御します。

グループ名の同期はプロアクティブではありません

IDプロバイダーでグループ名を変更しても、Databricks上のグループ名はすぐに更新されません。グループ名は、アカウント管理者がアカウントコンソールでグループの詳細ページを開いた場合にのみ同期されます。それまでは、同グループはDatabricks内で以前の名称を維持する。

自動ID管理では、SCIMで同期されたメンバーシップは削除されません

自動 ID 管理では、最初にSCIMプロビジョニングを使用して同期されたグループメンバーシップは削除されません。これは、これらのメンバーシップに依存する既存のジョブや権限が壊れるのを避けるための意図的な設計です。SCIMと同期された古いメンバーシップを削除するには、 SCIM APIを使用して手動でクリーンアップしてください。

初回使用時のService Principalのプロビジョニング

Microsoft Entra IDを使用する場合、サービスプリンシパルを含むグループをDatabricksに追加しても、それらのサービスプリンシパルはプロビジョニングされません。Databricksは、トークン認証やジョブ実行など、初回使用時のみサービスプリンシパルをプロビジョニングします。サービスプリンシパルが認証を行うかジョブを実行するまで、Databricksには表示されません。

APIおよびTerraformを通じたネストされたグループとService Principal

このセクションは、Microsoft Entra IDを使用する場合にのみ適用されます。Oktaは、ネストされたグループまたはサービスプリンシパルの同期をサポートしていません。

Databricksアカウントに直接プロビジョニングされていない入れ子になったグループとサービスプリンシパルは、アカウントコンソール UI に表示されますが、 Databricks APIsやTerraformを介して取得または管理することはできません。プログラムで管理するには、アカウントに明示的にプロビジョニングする必要があります。

SCIMから自動ID管理へ移行する際、権限は引き継がれます

SCIMプロビジョニングから自動 ID 管理に移行すると、グループは同じ内部Databricksオブジェクトのままになります。 Unity Catalog権限、ワークスペースの割り当て、その他の設定は自動的に引き継がれます。移行中に権限が失われることはありません。

ユーザー、サービスプリンシパル、およびグループの状態​

権限の共有と割り当て​

自動 ID 管理 vs SCIMプロビジョニング​

自動ID管理によるIDの照合方法​

サインイン時のマッチング​

ユーザー名による一致​

ユーザーの解決および作成時の照合​

自動ID管理で解決できないケース​

グループメンバーシップの同期の仕組み​

ネストされたグループとサービスプリンシパル​

ネストされたグループの可視性​

入れ子になったグループに関する考慮事項​

自動ID管理を有効にする​

自動ID管理を無効にする​

アカウントへのアクセスを拒否する​

自動ID管理イベントを監査する​

自動ID管理イベントの監査ログタグ​

クエリ自動ID管理監査イベント​

既知の挙動と制限事項​