Using AD groups for object ownership

[dpc]

Databricks has a general issue with object ownership in that only the creator can delete them.

So, if I create a catalog, table, view, schema etc. I am the only person who can delete it.

No good if it's a general table or view and some other developer wants to delete it.

Or if you create it within a notebook and want to test that the notebook works e.g. a notebook that creates or replaces a view that you change. SO, what do you do if another dev needs to work on it

Also, what happens if the individual leaves after historically creating a number of tables that the own.

Some time ago I asked the question and was told that databricks was looking at AD group ownership (or some other form of grouped ownership) i.e. the groups owns the object, so if you are in that group you have the same ownership rights rights.

Is that still in progress as I cannot find anything further.

Either I am missing a point or the whole ownership area is still not very good.

Thanks

[Raman_Unifeye]

@dpc - you can alter the table ownership to a group using ALTER command which means all the members in that group (Sayd dev) will be able to delete it as needed.

In case of a leaver, those tables can still be deleted or ownership transfer can be done by Admin.

[dpc]

Thanks.

I'll give this a go.

Didn't think it was an option previously

[KrisJohannesen]

I believe the MANAGE permission on the object(s) would give you this ability as well. Not that using groups in in any way a bad idea - just for your information 

[emma_s]

Hi, to add some further context to this, the Manage permission, as Kris says, is the way of achieving this, and giving it to a group would be the recommended way. At the moment, though, the manage permission also allows the users to share the table with other members too. Within the next year, there will be further permissions available that also give drop-only permissions to users.

[pradeep_singh]

I had the problem with another client at a much larger scale.This is what we did .

At the end of each pipeline that we ran in the development environment we had an AlterOwnership task.When a user runs a pipeline with his/her credentials all the objects he or she creates will get altered to the user group permission of the schema ( the user group that have access to create objects in the schema) dynamically . So we didn't have to hard code the user group . It would pick it from the defined permissions on the schema . This task would run irrespective of the case if any other task in the pipeline succeeded or not . 

For other objects created outside of the pipelines we asked users to have a pipeline with their id as run as and the tech lead with full permission over the pipeline . This pipeline would run the alter ownership task to fix the ownership in case the user left . 

[dpc]

Hi

So, I've just tested this

If I create a schema and somebody else creates a table in that schema, I can drop their table

If they create a schema along with a table in that schema

Then grant me All privileges on the table, I cannot drop it as it says I am not the owner

We also have a lot of tables that have been created and are owned by a service account

Under permissions there are a couple of AD groups and all privileges is set against them

I am in both the groups yet I cannot drop the table, nor can I control (grant) privileges

So, it is not giving me the same rights over the table

Am I doing something wrong here as it's just not working as I would expect

[SteveOstrowski]

Hi @dpc,

Unity Catalog does support group ownership of objects, including groups synced from Azure AD (Entra ID) or other identity providers. This is fully available today and addresses each of the scenarios you described.

TRANSFERRING OWNERSHIP TO A GROUP

Any securable object in Unity Catalog (catalog, schema, table, view, volume, etc.) can be owned by a user, service principal, or account group. You can transfer ownership using:

ALTER TABLE my_catalog.my_schema.my_table OWNER TO `my-ad-group`;

ALTER SCHEMA my_catalog.my_schema OWNER TO `my-ad-group`;

When a group owns an object, all members of that group effectively share ownership privileges, including the ability to drop, rename, and manage grants on that object.

WHO CAN TRANSFER OWNERSHIP

The following principals can transfer ownership of an object:

- The current owner
- A metastore admin
- The parent container owner (e.g., a catalog owner can transfer ownership of schemas within it, a schema owner can transfer ownership of tables within it)
- Any principal with the MANAGE privilege on the object

One restriction to be aware of: for views, functions, and models, only a metastore admin can transfer ownership to any principal. Current owners and MANAGE holders can only transfer ownership to themselves or to a group they belong to.

SYNCING AD GROUPS VIA SCIM

To use your AD groups in Unity Catalog, sync them to your Databricks account using a SCIM provisioning connector. Once synced, they appear as account-level groups (or "external groups") and can be used for ownership, privilege grants, and workspace access. The documentation for setting this up is here:

https://docs.databricks.com/aws/en/admin/users-groups/groups

USING THE MANAGE PRIVILEGE AS AN ALTERNATIVE

If you want multiple principals to have administrative control over an object without changing ownership, consider the MANAGE privilege. It allows the grantee to manage privileges, transfer ownership, drop, and rename the object. Unlike ownership (which is limited to a single principal), MANAGE can be granted to multiple groups or users:

GRANT MANAGE ON TABLE my_catalog.my_schema.my_table TO `my-ad-group`;

Note that MANAGE does not automatically grant all data access privileges on the object, but the holder can grant themselves those privileges.

HANDLING DEPARTING EMPLOYEES

For the scenario where an employee leaves and owns many objects: a metastore admin or the parent container owner can transfer ownership of those objects to a group. To do this proactively, consider establishing a convention where a team or service principal group owns all production objects from the start, rather than individual users.

RECOMMENDED APPROACH

1. Sync your AD groups to the Databricks account via SCIM.
2. Set up a convention where production schemas, tables, and views are owned by an AD group rather than individual users.
3. Use ALTER ... OWNER TO to transfer existing objects to the appropriate group.
4. For broader administrative flexibility, grant MANAGE to additional groups as needed.

Full documentation on ownership:
https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/ownership

Full documentation on privileges including MANAGE:
https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/privileges

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

If this answer resolves your question, could you mark it as "Accept as Solution"? That helps other users quickly find the correct fix.