自動身分識別管理

自動身份管理讓你能無縫地將 Microsoft Entra ID 中的使用者、服務主體和群組加入 Azure Databricks。 啟用自動身份管理後，你可以直接在身份聯邦工作空間中搜尋使用者、服務主體和群組，並將他們加入你的工作空間。 Azure Databricks 使用 Microsoft Entra ID 作為記錄來源，因此群組成員的變更在 Azure Databricks 中會被尊重。

預設情況下，自動身分管理會針對 2025 年 8 月 1 日之後建立的帳戶啟用。

使用者也可以與身份提供者中的任何使用者、服務主體或群組共享儀表板。 共享時，那些使用者、服務主體和群組成員會在登入時自動被加入 Azure Databricks 帳號。 他們不會被新增為儀錶板所在工作區的成員。 無法存取工作區的使用者，則可存取僅檢視的儀表板副本，該儀表板以共享資料權限發佈。 如需儀錶板共用的詳細資訊，請參閱 共用儀錶板。

開啟自動身分識別管理時，一律會啟用 Just-In-Time （JIT） 佈建，而且您無法將其關閉。 新使用者在首次登入時會自動配置 Azure Databricks。 請參閱 自動佈建使用者 （JIT） 。

非身分識別同盟工作區不支持自動身分識別管理。 欲了解更多身份聯邦的資訊，請參見 身份聯邦。

使用者、服務主體與群組狀態

啟用自動身分識別管理時，帳戶控制台和工作區系統管理員設定頁面中會顯示來自 Microsoft Entra 識別碼的使用者、服務主體和群組。 其狀態會反映其Microsoft Entra ID 與 Azure Databricks 之間的活動和狀態：

啟用中：已從 [IdP] 移除 狀態標籤包含您身分識別提供者的名稱。 例如， Active：從 EntraID 中移除。

使用自動身分識別管理管理的身分識別會在 Azure Databricks 中顯示為 外部 。 無法使用 Azure Databricks UI 來更新外部身分識別。

權限共享與分配

啟用自動身份管理後，您可以在 Azure Databricks 中分享或分配權限時，從 Microsoft Entra ID 中選擇使用者與服務主體。

對於群組，分享行為會依資產類型而異：

• 帳戶層級資產：在分享或分配帳戶層級資產權限時，群組可用，例如 Databricks 應用程式、Unity 目錄物件、AI/BI 儀表板、Genie 代理程式及工作區指派。
• 工作區層級資產：若要與群組分享工作區層級資產（如筆記本、工作、SQL 倉庫、警示與檔案），工作區管理員必須先將該群組加入工作區。

自動身分識別管理與 SCIM 布建

啟用自動身份管理後，所有使用者、群組及群組成員會從你的身份提供者同步到 Azure Databricks，因此不需要 SCIM 配置。 如果你讓 SCIM 配置同時執行，SCIM 會繼續管理用 SCIM 配置新增的身份。 它不管理未透過 SCIM 配置新增的身份。

SCIM 配置需要雲端應用程式管理員角色及獨立的 Microsoft Entra ID 應用程式。

Azure Databricks 建議使用 automatic identity management。 下表比較自動身分識別管理功能與 SCIM 布建的功能。

Azure Databricks 外部識別碼和 Microsoft Entra ID 物件識別碼

Azure Databricks 會使用 Microsoft Entra ID ObjectId 作為同步身分識別和群組成員資格的權威性連結，並自動更新 externalId 欄位以符合每日循環流程中的欄位 ObjectId 。 Databricks 建議不要混合配置方法。 透過自動身份管理與 SCIM 配置加入相同身份，會導致重複條目及權限衝突。 使用自動身份管理作為唯一真實來源，群組成員資格則與 Microsoft Entra ID 相符。

您可以在 Azure Databricks 中提供其外部識別碼，以合併這些重複的身分識別。 使用帳戶使用者、帳戶服務主體或帳戶群組 API 來更新主體，以在objectId欄位中新增其Microsoft Entra 識別碼externalId。 若要尋找其 externalId 與 Microsoft Entra ID 不相符的主體，請執行 自動身分管理整備報告。

因為 externalId 會隨時間更新，Azure Databricks 強烈建議不要使用依賴 externalId 欄位的自訂工作流程。

自動身份管理如何匹配身份

當自動身份管理同步身份時，會將該身份與身份提供者中的正確使用者、服務主體或群組匹配。 Azure Databricks 用來尋找匹配的資訊取決於同步的觸發方式。

登入時比對

當使用者透過單一登入登入時，Azure Databricks 會從你的身份提供者那裡接收一個令牌，從該令牌讀取使用者名稱，並將登入使用者與 Azure Databricks 帳號使用者依使用者名稱配對。

Microsoft Entra ID 登入令牌同時包含使用者的物件 ID 與租戶 ID。 Azure Databricks 會將帳戶使用者的物件 ID 記錄為其externalId，並在同步作業以外部 ID 為索引鍵時，將其作為權威性連結，例如使用外部身分識別 API或從帳戶主控台新增使用者時。 不過，在登入時，系統是根據權杖中的使用者名稱來識別使用者。

以用戶名配對

有些流程會以 Azure Databricks 使用者名稱來識別使用者，而非外部 ID，例如建立或刷新權限上下文或個人存取權杖認證。 這些流程不包含 Microsoft Entra ID 令牌，或是沒有完整資料的令牌。 Azure Databricks 會在 Microsoft Entra ID 中搜尋其使用者主體名稱（UPN）或電子郵件與 Azure Databricks 使用者名稱相同的使用者，且比起電子郵件相符結果，更優先採用 UPN 相符結果。 接著會使用相符身分中的外部 ID 來更新帳號使用者。

例如，如果 Azure Databricks 使用者的使用者名稱為 alice@contoso.com，Azure Databricks 會先尋找 UPN 為 alice@contoso.com 的 Microsoft Entra ID 使用者。 如果沒有 UPN 匹配，它會尋找電子郵件地址為 alice@contoso.com的使用者。

在解析和創建使用者時的配對

當你與尚未在 Azure Databricks 中的 Microsoft Entra ID 身份共享物件，或是呼叫外部使用者 API 時，Azure Databricks 會透過外部 ID 與現有的 Azure Databricks 使用者匹配。 若無用戶匹配，Azure Databricks 會即時建立一個使用者名稱，並根據使用者在 Microsoft Entra ID 中的狀態設定使用者名稱：

• 在你的租戶中建立的使用者：Azure Databricks 使用 UPN 作為使用者名稱。 例如，擁有 UPN bob@contoso.com 的 Microsoft Entra ID 使用者會變成擁有 Username bob@contoso.com的 Azure Databricks 使用者。
• 透過 B2B 協作邀請或同步的使用者（訪客）：Azure Databricks 偏好以電子郵件作為使用者名稱，當訪客物件沒有電子郵件時，則會退回到 UPN。 例如，UPN 為 carol_fabrikam.com#EXT#@contoso.onmicrosoft.com 且電子郵件地址為 carol@fabrikam.com 的來賓，會成為 Azure Databricks 使用者，使用者名稱為 carol@fabrikam.com。

自動身份管理無法解決的案件

某些身份提供者設定會阻礙 Azure Databricks 可靠地匹配預期使用者。 請設定您的身份以避免以下情況。

多位使用者符合相同的電子郵件地址

如果有多個 Microsoft Entra ID 使用者的電子郵件與 Azure Databricks 使用者名稱相符，且沒有人擁有匹配的 UPN，Azure Databricks 就無法判斷你打算使用哪個使用者。 它會配對其中一個，且沒有保證順序，所以可能會同步錯誤的使用者，且同步可能會在配對中使用者之間反覆切換。

例如，Azure Databricks 使用者的使用者名稱為 dana@contoso.com。 在 Microsoft Entra ID 中，有兩個使用者擁有電子郵件dana@contoso.com：一個成員帳號 UPN 為 d.lee@fabrikam.com，訪客帳號 UPN 為 dana_contoso.com#EXT#@fabrikam.onmicrosoft.com。 使用者名稱和兩個使用者的電子郵件都吻合，但 UPN 都不符，所以 Azure Databricks 無法分辨兩者，只能隨機匹配其中一人。

為避免這種情況，請確保預期的 Microsoft Entra ID 使用者的 UPN 與 Azure Databricks 使用者名稱相等，且不要同時保留多個共用電子郵件的 Microsoft Entra ID 物件。

用戶名稱來自另一個租戶

訪客用戶可以用帶有其主租戶用戶名稱的令牌登入，而你的租戶中的訪客物件既沒有 UPN 也沒有與該使用者名稱相符的電子郵件。 在登入時，這仍然可行，因為權杖會攜帶該主租用戶的使用者名稱，而 Azure Databricks 會依此比對帳戶使用者。 如果流程與 Azure Databricks 使用者名稱相符，例如會話整理，然後在 Microsoft Entra ID 搜尋 UPN 或電子郵件與使用者名稱相符的使用者，卻找不到來賓物件同步。若流程與外部 ID 相符，例如透過外部身份 API 或帳號主控台解析或分享，可能會建立第二個 Azure Databricks 使用者，該使用者共享訪客的外部 ID，這點你應該避免。

例如，Azure Databricks 使用者的使用者名稱是 erin@fabrikam.com，這是從該使用者的主租用戶沿用而來。 在你的租戶中，訪客物件有 UPN erin_fabrikam.com#EXT#@contoso.onmicrosoft.com ，但沒有匹配的電子郵件。 登入時，權杖的使用者名稱等於 erin@fabrikam.com，因此 Azure Databricks 會依使用者名稱比對使用者。 但在沒有權杖的流程中，Azure Databricks 會搜尋與 erin@fabrikam.com 相符的 UPN 或電子郵件，但找不到任何使用者。

為避免這種情況，請確保訪客物件的電子郵件與 Azure Databricks 使用者名稱相等，且該郵件在租戶內是唯一的，避免與其他 Microsoft Entra ID 物件碰撞。

群組成員同步的運作方式

啟用自動身份管理後，Azure Databricks 會在觸發驗證與授權檢查的活動中，從你的身份提供者那裡刷新使用者群組成員資格，例如瀏覽器登入、權杖驗證或工作執行。 這確保 Azure Databricks 中的群組權限能與身份提供者的變更保持同步。

當 Azure Databricks 重新整理群組成員資格時，會從您的身分提供者擷取遞移（巢狀）群組成員資格。 這表示如果使用者是 Group A 的成員，而 Group A 是 Group B 的成員，Azure Databricks 會辨識該使用者同時擁有兩個群組的成員身份。 Azure Databricks 只會取得已加入 Azure Databricks 的群組成員資格。 它不會同步或重建身份提供者的完整父群組階層結構。

Azure Databricks 會根據活動的不同排程更新群組成員資格：

• 瀏覽器登入：若距離上次同步超過5分鐘，群組成員資格會同步。
• 其他活動（例如權杖認證或執行工作）：Azure Databricks 會根據上次同步的時間來刷新群組成員資格：
  • 少於 10 分鐘：不會刷新。
  • 10 到 40 分鐘：Azure Databricks 會在背景觸發非同步刷新。 觸發刷新的請求可能仍使用先前的群組成員資格。 更新後的會員資格可適用於後續申請。
  • 超過 40 分鐘：Azure Databricks 會在完成請求前刷新群組成員資格。

巢狀群組與服務主體

啟用自動身份管理時，巢狀群組的成員會繼承已配置群組的權限。 分配給父群組的權限適用於所有屬於該群組的使用者與服務主體，包括直接加入群組的使用者及透過巢狀群組成員身份加入的使用者。 然而，群組內巢狀的群組與服務主體並非帳戶中自動可參考，儀表板分享除外。

巢狀群組可見性

巢狀群組在 Azure Databricks 中可見。 考慮一個子群，Group-C它是父群的成員。 Group-P 如果你將 Group-P 加入工作區，則 Group-P 和 Group-C 中的所有身份都能存取該工作區。 在帳號管理與工作區管理員的 UI 中，Group-C 會以成員 Group-P 的身分出現在群組成員詳細頁面中。 群組詳細頁面上只顯示第一層次的巢狀結構。

巢狀群組的注意事項

• 工作區存取權：巢狀群組與服務主體不必直接加入工作區即可取得存取權限。 如果將父群組加入工作區，該群組的所有成員都能存取該工作區。
• 帳戶層級資產：在分享或分配帳戶層級資產權限時，群組可用，例如 Databricks 應用程式、Unity 目錄物件、AI/BI 儀表板、Genie 代理程式及工作區指派。
• 帳號群組與服務主體限制：巢狀群組與服務主體若未直接配置到帳號，則不計入帳號群組限制。 只有明確配置到帳號的群組才會被計算在限制範圍內。

例如，在 Microsoft Entra ID 中，你有以下群組結構：

• Marketing-All （家長團體）
  • Marketing-US （兒童團體）
  • Marketing-EU （兒童團體）
  • Marketing-APAC （兒童團體）

如果工作區管理員在他們的工作區新增 Marketing-All ：

• 已授權存取：所有成員Marketing-All及其子群組（，Marketing-USMarketing-EU ， Marketing-APAC）皆可存取工作空間。 例如，使用者 Marketing-APAC 與服務主體可以驗證並使用工作空間。
• 帳號配置：僅 Marketing-All 配置至 Azure Databricks 帳號，並計入帳號群組限制。 子群組不計入限制，除非你明確設定。
• 帳戶層級資產：Marketing-All及其所有子群組（Marketing-US，Marketing-EU，Marketing-APAC）在共享或分配帳戶層級資產的權限時皆可用，例如 Unity Catalog 中的儀表板和物件。

啟用自動身分識別管理

預設情況下，自動身分管理會針對 2025 年 8 月 1 日之後建立的帳戶啟用。 帳戶管理員可以在帳戶主控台中啟用自動身分管理。

1. 身為帳戶管理員，登入帳戶主控台。

2. 在側邊欄中，按一下「安全性」。

3. 在 身份提供者設定 標籤中，於 身份管理中切換自動 身份管理 為 啟用。

   變更需要五到十分鐘才能生效。

啟用後，若要從身份提供者新增或移除使用者、服務主體和群組，請依照以下指示操作：

• 將使用者新增至您的帳戶
• 將服務主體新增至您的帳戶
• 將群組新增至您的帳戶

要從 SCIM 配置遷移，請參見「遷移至 Microsoft Entra ID 自動身份管理」。

停用自動身分識別管理

停用自動身分識別管理時：

• 使用者與服務主體依然存在：他們保留存取權，但不再與你的身份提供者同步。 停用自動身分管理後，您可以在帳戶主控台中手動移除或停用使用者和服務主體。
• 群組會失去成員資格：群組會保留在 Azure Databricks 中，但會移除所有群組成員。
• 與身份提供者無法同步：身份提供者的變更（例如使用者移除或群組更新）不會反映在 Azure Databricks 中。
• 無權限繼承：由自動身分識別管理管理的使用者無法繼承父群組的權限。 這會影響巢狀群組型權限模型。

如果您打算停用自動身分識別管理，Databricks 建議您事先設定 SCIM 布建作為後援。 然後，SCIM 可以接管身分識別和群組同步處理。

1. 身為帳戶管理員，登入帳戶主控台。
2. 在側邊欄中，按一下「安全性」。
3. 在 身份提供者設定 標籤中，於 身份管理中，將 自動身份管理 切換為 停用。

禁止身分存取您的帳戶

帳號存取拒絕名單會控制你身份提供者中哪些身份可以存取你的 Azure Databricks 帳號。 帳號管理員可以將特定使用者、群組或服務主體加入拒絕名單，以阻擋他們的存取。 封鎖名單成員資格具有傳遞性：如果你將某個群組加入封鎖名單，則所有成員（包括巢狀群組中的成員）也都會一併遭到封鎖。

如需設定指示及拒絕清單運作方式的完整說明，請參閱 拒絕身分識別存取您的帳戶。

自動身份管理事件的稽核

啟用自動身份管理後，您可以使用稽核日誌追蹤自動身份管理程序執行的身份操作。

自動身份管理事件的稽核日誌標籤

自動身份管理使用現有的稽核日誌事件，但加入標籤以識別身份同步程序自動執行的操作：

• 端點：「autoUserCreation」 - 表示事件是由自動身份管理程序發出的。 此標籤出現在使用者操作（add， ， activateUserdeactivateUser， updateUser）、群組操作（createGroup， updateGroupremoveGroup， ）及群組成員操作（addPrincipalToGroup， removePrincipalFromGroup）。
• groupMembershipType：「IdentityProvider」— 出現在群組成員操作（，addPrincipalToGroupremovePrincipalFromGroup ）中，表示群組成員身份已從你的身份提供者同步。

查詢自動身份管理稽核事件

你可以查詢 system.access.audit 表格來追蹤自動身份管理操作。 例如：

追蹤使用者登入：

SELECT
  DISTINCT user_identity.email
FROM
  system.access.audit
WHERE
  action_name = "aadBrowserLogin"

追蹤由自動身份管理建立的使用者：

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

追蹤與你的身份提供者同步的群組成員：

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 ，請參閱 稽核記錄系統數據表參考。

已知行為與限制

本節描述在自動身份管理時可能不易察覺的行為。