Technical documentation
Azure Databricks 开启账户级同步后，必须手动关掉工作区旧连接：防幽灵账号实操
Azure Databricks 开启账户级同步后，必须手动关掉工作区旧连接：防幽灵账号实操
Azure Databricks 账户级同步关闭工作区连接，是指强制禁用直接指向工作区的旧版同步通道，以确立单一账户级 SCIM 管理路径并消除数据治理风险。
为什么启用账户级同步必须切断旧版工作区连接？
启用账户级同步必须切断旧版工作区连接，是因为这是微软基于安全架构设定的强制性约束，旨在防止出现重复供给路径导致的安全隐患。
微软在 Azure Databricks 的官方配置指南中划出了一条红线：一旦你启用了账户级 SCIM 连接器，就必须立刻禁用那些直接指向工作区的旧版同步通道。[1] 这绝非一项可选项的优化建议，而是基于安全架构的强制性约束。
供给面与认证面的分离逻辑
许多管理员存在一个误区，认为“开启新连接”就能自动覆盖或忽略旧设置。然而底层的架构逻辑在于“供给面与认证面的彻底分离”。同一位员工的目录供给拓扑，完全可能与其认证拓扑不同步。[1]
当你同时保留账户级和 Workspace 级的同步配置时，系统内部会并存多个数据入口。这种多路并行的状态会让对象来源变得模糊不清，导致同步范围彻底混乱，最终形成重复的供给路径。[1] 厂商将这种状态列为必须避免的配置，因为 Azure Databricks 数据治理的根基在于维护“单一事实来源”。[1]
这里有一个新手极易忽视的实战细节：很多团队在迁移时，为了图省事，只是简单地在账户层面新建了连接器，却忘了去检查每个工作区下是否还残留着旧的”Workspace-level”配置。你以为只开了一条新路，实际上系统里是两条路同时在跑。正确的做法是，在启用账户级连接器的同一时刻，立即遍历所有受管工作区，逐一确认旧连接器的状态，确保它们被显式地标记为“已禁用”，而不是仅仅依赖新配置的生效来覆盖旧配置。这种“先立后破”的操作顺序，能避免在切换窗口期出现权限状态的短暂冲突。
重复供给路径带来的数据治理风险
如果不切断旧版连接，员工权限将在多条路径下被错误地重复处理。试想一下，当一名员工离职时，账户级连接器发送了删除指令，而旧的工作区级连接器却仍在后台运行，它可能无法感知上游的变化，甚至反向覆盖了新的状态。[1]
结果就是，该员工的账号在系统中既被标记为“已移除”，又保留了访问权限，甚至产生所谓的“幽灵账户”。[1] 这种权限残留不是偶发的系统故障，而是架构设计缺陷导致的必然风险。你必须通过手动关闭旧连接器，确保所有身份变更只走一条确定的路径，才能守住数据治理的底线。[1]
Azure Databricks 账户级同步如何关闭工作区连接：具体操作指南
具体操作指南要求用户在 Azure Databricks 控制台手动取消勾选直接连接选项，从而确保仅保留账户级同步路径并彻底规避数据治理隐患。
读完本文，你将能够独立在 Azure Databricks 控制台完成旧版连接的禁用，确保仅保留账户级同步路径，从根本上规避数据治理隐患。
确认操作前提与配置分离
别急着动手，先核对环境。这一步仅在已启用“账户级 SCIM connector”的场景下执行。如果尚未开启账户级同步，或者你使用的是其他 SaaS 场景的通用规则，此处无需操作。
微软文档明确区分了“认证”与“供给”。你的集成中，用户登录通常依靠 OpenID Connect（OIDC），而账号的创建、更新或删除则走的是 SCIM 流程。[1] 很多管理员容易把这两者混为一谈，以为改个登录设置就万事大吉。请记住，这个强制要求仅针对 Azure Databricks 与 Microsoft Entra ID 的特定组合，切勿将其套用到所有 SaaS 系统上。[1]
当账户级和 Workspace 级两个连接器同时存在时，同一个员工会收到两份身份指令。厂商要求你关掉其中一条，就是为了消除这种重复供给带来的混乱。[1]
界面操作：禁用旧版连接器
打开 Azure Databricks 管理控制台，进入目标工作区的“访问控制”或”SCIM 配置”页面。找到那个指向当前工作区的直接同步选项。
为了帮助你快速定位，以下是关键配置项的对比说明：
| 配置层级 | 典型路径特征 | 风险等级 | 推荐操作 |
|---|---|---|---|
| Workspace-level | 直接绑定到特定工作区 ID | 高 (需禁用) | 立即关闭/删除 |
| Account-level | 绑定到租户根节点 | 低 (主路径) | 保持启用 |
操作合格标准清单：
- [ ] 定位到”Workspace-level SCIM connector”相关区域
- [ ] 取消勾选“启用此连接器”或直接点击“禁用/删除”按钮
- [ ] 保存更改并等待系统刷新状态
操作完成后，界面应显示该连接器处于“未激活”状态。此时，只有账户级的入口是亮的。这就好比切断了从大门直接进房间的捷径，现在所有人必须经过大厅（账户层）才能到达房间。
验证：SCIM DELETE 不等于撤权完成
关掉连接器只是第一步。很多团队误以为发了一条 SCIM DELETE 请求，对方服务器回了个”200 OK”，权限就彻底收回了。这是个大坑。
SCIM DELETE 成功只代表目录接口收到了删除指令，并不代表后端资源真的清除了授权。现有 RFC 摘要、软删除草案及厂商文档均未证明这一动作会自动清除下游缓存、活跃会话或长期令牌。[2][3][4][1]
验证生效的必查项：
- [ ] 检查是否有旧令牌仍在工作区有效
- [ ] 探测被移除用户的资源访问权限是否确实失效
- [ ] 确认没有活跃的后台会话维持着连接
端到端的撤权需要额外验证。你不能只看目录侧的成功响应，必须亲自去测会话终止和资源访问情况。缺少这些证据前，千万别把“接口接受操作”当成“权限完全回收”。[1]
本章执行检查清单
- [ ] 确认已启用账户级 SCIM connector
- [ ] 在 Workspace 设置中找到并禁用直接同步的 SCIM 选项
- [ ] 验证界面显示旧连接器已失效
- [ ] 手动测试被移除用户的会话与令牌是否已失效
- [ ] 记录验证结果，确保无残留权限
忽略此配置步骤可能引发的实际故障
忽略此配置步骤会导致目录侧账号显示删除成功但实际仍能登录操作数据的故障，造成离职员工权限未及时回收的严重安全风险。
离职流程走完，HR 系统里员工状态已变“终止”，但后台的 Azure Databricks 工作区却还留着他的访问权限。这就是未关闭旧版连接器最典型的故障：账号在目录侧显示删除成功，实际上仍能登录并操作数据。[2]
很多团队误以为 SCIM DELETE 请求返回 200 OK 就是万事大吉。事实并非如此。即使目录服务端确认收到了删除指令，现有的 RFC 标准、软删除草案及厂商文档都明确指出，这一动作并不自动触发下游缓存的清除或资源侧授权的撤销。[3][4] 这就好比银行柜台帮你销了户，但你手里那张没被回收的磁条卡，依然能刷开保险柜。
当账户级同步与旧版工作区连接器并存时，风险被进一步放大。SCIM DELETE 消息可能只触发了主路径的清理，而那条未被禁用的旧连接器路径，仍在后台维持着活跃会话或长期令牌的有效性。[1] 后端资源授权状态如果没有被显式切断，离职员工的账号就会变成“隐形幽灵”，继续持有对敏感数据集的读写能力。这种状态无法通过简单的目录查询来验证，必须依赖会话终止日志或令牌撤销记录作为证据，而这些恰恰是目录侧响应中缺失的一环。[2][4]
不要指望系统会自动处理这种“断头路”。强制手动禁用旧版连接器，是阻断重复供给路径的唯一可靠手段。只有切断了旧连接，才能确保从目录到计算资源的整个链条上，访问权限被彻底、干净地移除，满足审计合规要求。[1]
本章行动检查清单
- [ ] 确认 HR 系统已标记员工为离职
- [ ] 检查 SCIM DELETE 响应状态是否为 200 OK（仅作第一步参考）
- [ ] 关键动作：进入 Azure Databricks 管理控制台，手动找到并禁用直接连接到工作区的旧版 SCIM connector
- [ ] 验证该用户是否仍拥有活跃会话或有效令牌（需查看后端日志而非仅看目录状态）
- [ ] 确认无残留授权后，方可结束撤权流程
常见问题解答 (FAQ)
Q: 我是否可以暂时保留两个连接器并行运行？ A: 绝对不行。虽然短期内系统可能不会报错，但这会导致“重复供给”问题，使得员工权限状态在不同路径间冲突，严重破坏 Azure Databricks 数据治理的一致性。厂商明确要求必须禁用旧版连接。
Q: 禁用工作区级连接器会影响现有的 OIDC 登录吗？ A: 不会。如文中所述，认证（OIDC）与供给（SCIM）是分离的。禁用 SCIM 连接器只影响账号的创建和删除流程，不会影响用户正常的登录验证过程。
Q: 如果我已经禁用了连接器，但发现还有幽灵账号怎么办？ A: 这说明旧的会话或令牌未被清理。你需要手动检查后端日志，撤销活跃会话，并强制刷新令牌缓存，不能仅依赖 SCIM DELETE 的响应。
参考来源
- Configure SCIM provisioning using Microsoft Entra ID (Azure Active Directory) - Azure Databricks | Microsoft Learn · https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/scim/aad（B级）
- RFC 7644 - System for Cross-domain Identity Management: Protocol · https://datatracker.ietf.org/doc/html/rfc7644（S级）
- draft-ansari-scim-soft-delete-00 · https://datatracker.ietf.org/doc/html/draft-ansari-scim-soft-delete-00（A级）
- draft-schreiber-scim-ipsie-profile-00 - SCIM 2.0 IPSIE Profile · https://datatracker.ietf.org/doc/draft-schreiber-scim-ipsie-profile/（A级）