Disable local user creation when using SCIM Provisioning

[ThePussCat]

We have implemented SCIM Provisioning using Azure AD (MS Entra) to Azure Databricks.

All is good.

Except, we would like to know if it is possible to disable the ability to create users within Azure Databricks, so that none can be "accidentally" created?

Many thanks

[NandiniN]

To disable the ability to create users directly within Azure Databricks to prevent accidental user creation, you can configure your identity provider (IdP) setup.

When SCIM is in use, Azure AD becomes the source of truth for identities. Any users or groups that need access to Azure Databricks must be provisioned through Azure AD.

https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/scim/

[ThePussCat]

Thanks for the reply, but this is what we are already doing. However it does not actually "disallow" the creation of users within Databricks itself, which is what we really want to achieve.

[Louis_Frolio]

Greetings @ThePussCat , I would like to add what my colleague posted above. 

Yes—there are a couple of ways to prevent “accidental” user creation so identities only arrive via your SCIM provisioning flow.

Recommended controls

• Disable auto user creation (JIT) on SSO. This stops Databricks from creating a user the first time someone signs in via SSO; only users you provision (e.g., via SCIM) can exist in the workspace.
• Use account‑level SCIM with identity federation, and turn off any workspace‑level SCIM connectors you might still have. This centralizes identity creation at the account, reduces drift, and avoids duplicate paths for user creation.
• In Microsoft Entra (Azure AD), set the enterprise app’s Assignment required to Yes if you want only explicitly assigned users to be able to sign in. This prevents unassigned users from authenticating to Databricks (and therefore from being created), which complements disabling JIT in Databricks.
  Note: Entra group assignment doesn’t cascade to nested groups, so only direct members of assigned groups can sign in.

Where to click

• Databricks SSO setting: In each workspace, go to Admin settings > Authentication/SSO and disable the setting labeled “Auto user creation,” “Add users on first login,” or similar wording.
• Account‑level SCIM: Configure the Azure Databricks SCIM connector at the account, then shut down any workspace‑level SCIM connectors you previously used, per the migration guidance.
• Entra Assignment required: Entra admin center > Enterprise applications > Azure Databricks SCIM/SSO app > Properties > set Assignment required = Yes (be mindful of the nested‑group behavior).

Optional: monitoring and verification

• Audit unexpected sign‑ins and user appearances using system tables (for example, system.access.audit) after you change the controls, so you can confirm that no new users are being created outside your SCIM flow.

Hope this added information helps, Louis.

[ThePussCat]

Louis, Many thanks! I really appreciate this reply. However perhaps you could provide more info on this statement:

Databricks SSO setting: In each workspace, go to Admin settings > Authentication/SSO and disable the setting labeled “Auto user creation,” “Add users on first login,” or similar wording.

I know the Databricks UI is forever changing, but I have looked around and cannot find anything that looks like what you describe.Is this perhaps a legacy setting that we have disabled?

Thanks again - I'll be talking to our MS Entra admin in the morning!

[Louis_Frolio]

Are you a workspace admin?

[ThePussCat]

I'm the Account Admin.

We try to avoid workspace specific configuration settings where we can, other than allowing some beta/preview on our DEV workspaces.

[Louis_Frolio]

Got it. I found a little more information that might help. Give this a read and let me know if it helps.

You're right that the UI has evolved, and the wording I used maps to newer account-level controls rather than a visible workspace toggle.

What changed

• The legacy workspace-level SSO page and its “Add users on first login / auto user creation” toggle only appears when unified login is disabled. For most accounts today, unified login is enabled, so you won’t see that workspace SSO toggle in Admin Settings. This is expected UI behavior.
• The capability behind “auto user creation” is now called just-in-time (JIT) provisioning at the account level. JIT automatically creates a Databricks user on first successful SSO login when enabled.

Where to check it now

• In the account console, go to Security > User provisioning and look for “Create new identities during first-time authentication.” That’s the JIT toggle that replaces the old workspace-level “auto user creation.”
• Defaults have changed over time: for accounts created after May 1, 2025, JIT is ON by default once SSO is configured; earlier accounts can enable/disable it in the same place.

Azure/Microsoft Entra specifics

• On Azure Databricks, single sign-on with Microsoft Entra ID is the default for both the account console and workspaces, which is why most customers don’t interact with separate workspace SSO settings anymore.
• If your account uses automatic identity management, JIT is always enabled and cannot be turned off; new users are provisioned on first login automatically. This is by design in that mode.

Practical ways to control who can be created/onboarded

• Use SCIM provisioning from Microsoft Entra to sync only the users/groups you intend into the Databricks account; this is the recommended pattern for managed onboarding.
• In Microsoft Entra, set the enterprise app’s Assignment required property to “Yes” so only assigned users can sign in to the Databricks app; unassigned users will be blocked from obtaining tokens and won’t be created via JIT.

Why you couldn’t find the workspace toggle

Because unified login is enabled for most accounts (and cannot be disabled for accounts created after June 21, 2023 or that hadn’t configured workspace SSO before Dec 12, 2024), workspace-level SSO settings—including the old “add users on first login” toggle—are hidden and considered legacy.

Let me know if this helps.

Cheers, Louis.

[ThePussCat]

Thank you! Thats really clear now, and hopefully helpful to others.

Ours is set to (default) OFF - we do not want JIT provisioning enabled.