Managing Databricks Access for Cross Tenant Users

[YashikaAgrawal]

Hi, Need help,

We are working on migrating Power BI tenant from Infy to TATA tenant.
In our current setup (Infy tenant), we have an Azure AD security group used to control access to Databricks. Users raise a ticket, and we manually add them to this group.

As part of a cross-tenant migration, some users are moving to a new TATA tenant. Databricks will continue to reside in the Infy tenant.

Key considerations:
Users from TATA will be B2B guests in Infy.
We want to avoid manual group assignment via tickets.
We still want to control access to the existing Databricks workspace in Infy.

Question:
a. What is the recommended approach to manage Databricks access for users who now belong to the TATA tenant?
b. Is there a best practice for managing this (e.g., Access Packages, dynamic groups, automation)? How can we securely and efficiently provide group-based access for TATA users in this cross-tenant setup?

Thanks

[rohit1991 · Accepted solution]

Hi @YashikaAgrawal 

Since your Databricks environment will stay in the Infy tenant, and the users are moving to the TATA tenant, here’s what I’d suggest based on similar setups:

1. Stick with the existing security group in Infy
No need to change the way Databricks access is currently controlled. Even after the move, users from the TATA tenant can be added as B2B guest users in Infy and then included in the same Azure AD group that manages access to Databricks. So your group structure doesn’t need to be rebuilt.

2. Avoid manual ticketing with Access Packages
If you want to skip the manual part (which I highly recommend), look into Access Packages in Azure AD Entitlement Management (Infy tenant). These let external users (your TATA users) request access via a portal, and you can:

  a. Add approval steps

  b. Set access expiry (e.g. 30/60/90 days)

  c. Run access reviews later if needed

It’s a clean, secure way to give access without relying on ticketing or scripts.

3. A quick note on dynamic groups
Dynamic groups might sound like a good option, but unfortunately, they don’t support guest users at the moment — so they won’t help here.

4. What if you don’t have Entra P2?
If licensing is a blocker, you can still automate group assignments using PowerShell or Graph API, but it does require some custom scripting. That works too — just a bit more effort.

So, in short:

• Keep the Infy security group as the main control point
• Use Access Packages for smooth, self-service onboarding of TATA users
• Avoid dynamic groups for this case
• If needed, use scripts for automation instead