Reassurance sought about behaviour of Databricks account SCIM connector

[Kayl669]

In my org we've got workspaces with a mixture of SCIM-provisioned and non-SCIM groups. These are all 'workspace local' groups. My identity provider is AAD.

I've created a new workspace and want users in this workspace to be provided access only via account-level SCIM groups - new AD groups just for this workspace (which is acting as a proof of concept/demo workspace for switching to unity catalog in combination with account-level AD groups).

I'll follow these steps next:

1. Create a new SCIM app in AAD with the details of the account-level URL/token.
2. In the app, add only the new AD group.
3. Do a provisioning run

My concern is that this provisioning run will have some impact on all of the business' users who are not part of the new AD group. Could somebody please confirm that this will not happen? I've read the relevant documents and can't find anything definitive and specific on this particular point.

I know that the SCIM connector can delete users - but is its deletion behaviour limited to the users it itself has provisioned - the scenario being that an AD user was once in an AD group but now isn't?

Many thanks!

[Debayan]

Hi, Please refer to https://learn.microsoft.com/en-us/azure/databricks/administration-guide/users-groups/users and https://learn.microsoft.com/en-us/azure/databricks/administration-guide/users-groups/groups.

Also, please note if you already have SCIM connectors that sync identities directly to your workspaces and those workspaces are enabled for identity federation, you should disable those SCIM connectors when the account-level SCIM connector is enabled. If you have workspaces that are not using identity federation, you should continue to use any SCIM connectors you have configured for those workspaces, running in parallel with the account-level SCIM connector.

Please let us know if this helps. Also, I would suggest reaching out to Microsoft on specific AAD queries.

[Kayl669]

Thanks for your help. Had missed one of the documents you'd linked.

In some places the documentation urges you to disable any workspace-level SCIM connectors before enabling an account-level connector and similarly suggests you should have an AD group plugged in to the account-level connector which encompasses all of your existing workspace-level users.

Personally I think those points need further clarification because actually you don't if you're using intending to use NEW AD groups via an account-level connector within a NEW workspace (i.e. with no existing users). We turned our account-level connector on and it's had no impact on any of our existing workspaces / users despite those relying on an active workspace-level connector. Other parts of the documentation do point towards this outcome but it would be good if there was a document about what to expect when in each scenario.