Azure Databricks should get its users and groups from Microsoft Entra ID

When accounts are created manually inside a workspace, they drift away from the directory. A person who leaves the company, or moves to another team, can keep a working Databricks login because nobody remembered to remove it there. Group membership has the same problem: access granted through a group in Databricks may no longer match the group in your identity provider.

Provisioning from Microsoft Entra ID keeps one place where joiners, movers and leavers are handled. Microsoft documents how to sync users and groups to Databricks with SCIM provisioning in the Microsoft Learn and Databricks pages listed under sources.

In the Azure Databricks account console or workspace, open the admin settings and look at the list of users and groups. Entries that arrive through provisioning carry an external identifier from Entra ID; entries without one were created manually. In the Microsoft Entra admin center, go to Enterprise applications, open the Databricks provisioning application, and check that Provisioning is switched on and shows recent successful cycles.

A read-only way to look at the Entra side is to list the synchronization jobs of the provisioning application (replace the placeholder with the application's service principal ID):

az rest --method get --url "https://graph.microsoft.com/v1.0/servicePrincipals/<service-principal-id>/synchronization/jobs"

An empty list means no provisioning is configured. Run this on a test environment first if you are unsure about permissions.

Set up provisioning once, then let it run:

• In the Microsoft Entra admin center, add the Azure Databricks SCIM provisioning application under Enterprise applications.
• Generate a personal access token for a Databricks admin (or use the account-level SCIM endpoint) and enter the tenant URL and token on the application's Provisioning page.
• Assign the groups that need Databricks access to the application, then set Provisioning to On.
• Wait for the first cycle to finish and compare the Databricks user list with the assigned groups.

If you prefer to start a cycle from the command line once the job exists, a Graph call does it:

az rest --method post --url "https://graph.microsoft.com/v1.0/servicePrincipals/<service-principal-id>/synchronization/jobs/<job-id>/start"

ConfigCobra only reports this setting. It never changes your Azure or Entra configuration; you or your administrator apply the fix.

Only people in groups assigned to the provisioning application will exist in Databricks afterwards. Users who were added by hand but are not in an assigned group can lose access once provisioning takes over, so compare the two lists before the first cycle and add anyone who still needs access to a group.

Workspace administrators gain a single process for access changes, and security teams can rely on the directory as the record of who has access. Existing group-based permissions on notebooks, clusters and data keep working as long as the group names stay the same. Plan a short communication to data teams, because removed or renamed accounts will see sign-in failures.