enable databricks in azure for the whole tenant

[satycse06]

Hi,

We have to enable the databricks in azure cloud for the whole organisation in azure.

I want to know the very 1st level i.e how to enable or integrate the databricks account with azure tenant and after that how I can enbale it for selected subscription and apply the compliance and policies.

As per the databricks documetation Azure Databricks appears as an Enterprise application in Entra ID then how to control the policies for each workspace from the central level and whether need to control the network also i.e vnet injection or it can be taken care as per the azure resource group of vnet .

Need the initial setup process as per the admin perspective 

Regards,

Satya 

[satycse06]

is anyone can give some reference documents to plan it well

[szymon_dybczak · Accepted solution]

Hi @satycse06 ,

Azure Databricks should be onboarded through a combination of Azure tenant/subscription controls, the Azure Databricks account console, and standardized workspace deployments. There is not one tenant-wide “Enable Databricks” switch that automatically governs every workspace.

1. Initial tenant and account setup

1. Select the Azure subscriptions that are permitted to host Databricks.

   Register the Microsoft.Databricks resource provider only in the approved subscriptions. Registration is performed per subscription, not once for the entire tenant. Microsoft recommends registering resource providers only when they are ready to be used.

2. Create the first controlled Databricks workspace.

   The deployment identity needs Azure Contributor/Owner at subscription level,

3. Establish the Databricks account administrators.

   For the initial account bootstrap, a Microsoft Entra Global Administrator signs in to the Databricks account console and becomes the first Databricks account administrator. That person should then delegate the Account Admin role to two or three dedicated platform administrators and remove the Global Administrator from routine Databricks administration.

4. Use Microsoft Entra ID for authentication and Conditional Access.

   Microsoft Entra ID single sign-on is available by default for both the Databricks account console and workspaces. MFA and Conditional Access should therefore be enforced through Entra ID.

About the Enterprise Application

The AzureDatabricks enterprise application, whose standard resource/application ID is 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d, is the Microsoft first-party Databricks service identity. It should not be treated as the main mechanism for assigning access to individual workspaces. Workspace access is managed through Databricks account-level identities, groups and workspace assignments.

For a new account, use Automatic Identity Management, which is enabled by default for accounts created after August 1, 2025. It uses Entra ID as the source of record and supports users, service principals, groups and nested groups. If Automatic Identity Management is unavailable for a legacy account, configure the separate Azure Databricks SCIM Provisioning Connector enterprise application at account level.

Users should be assigned to workspaces through these account-level groups rather than individually.

2. Enabling Databricks only in selected subscriptions

Resource-provider registration alone is not sufficient as a security boundary because Azure Contributor and Owner roles include the permission to register resource providers.

The recommended control is:

1. Place approved Databricks subscriptions under a dedicated Azure management group.
2. Apply an Azure Policy at the parent or root management-group level that denies Microsoft.Databricks/workspaces.
3. Exclude only the approved Databricks management group or subscriptions from that deny assignment.
4. Grant workspace deployment permissions only to the central platform team or deployment service principal in those subscriptions.
5. Deploy workspaces exclusively through an approved Terraform, Bicep or ARM module.

If my answer was helpful, please consider marking it as accepted solution.

 

[satycse06]

@szymon_dybczak Thanks for the response and well explanation.

I have another question related to vnet injection architecture. So as per you we can create a management group and include all the subscription in that management group and will apply the polices at root level. But what about network shall I assign each vnet for each of the subscription which will be part of the mangement group or a hub spoke architecture so that we can manage the network policies centrally like not allowing the public IP accessibility of databricks workspace