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.