What is Automatic Identity Management (AIM)?

Summary

• Automatic Identity Management (AIM) is an account-level, just-in-time identity provisioning system that automatically provisions users, service principals, and groups from Microsoft Entra ID into Azure Databricks.
• Entra ID is the authoritative source of identity. Databricks reads identities directly using the Microsoft Graph API and provisions them on first use or login, with no scheduled push required.
• Group memberships flow automatically, including nested (transitive) groups, so permissions always reflect the latest updates from Entra ID.
• Setup is simplified. AIM uses a first-party integration with Microsoft Graph, removing the need to create and manage a separate enterprise application, SCIM tokens, and attribute mappings.
• AIM is generally available for Microsoft Entra ID on Azure Databricks.

What is Automatic Identity Management (AIM)?

Automatic Identity Management (AIM) is an account-level, just-in-time (JIT) identity provisioning system that automatically provisions users, service principals, and groups from Microsoft Entra ID into Azure Databricks. Rather than requiring manual pre-provisioning or scheduled synchronization, AIM treats Microsoft Entra ID as the authoritative source of identity and provisions identities on first use or login. AIM is generally available for Microsoft Entra ID on Azure Databricks. See Automatic identity management now generally available.

How Automatic Identity Management works

• Reads identities directly from Microsoft Entra ID. When AIM is enabled, Databricks uses the Microsoft Entra ID Graph API to keep its identity directory in sync, and provisioning occurs just-in-time on first use or login.
• Provisions users on first sign-in. Users are automatically provisioned in Azure Databricks upon their first login via single sign-on, so no pre-provisioning is required.
• Expands group memberships automatically. Group memberships, including nested groups, flow directly from Entra ID, and Databricks checks group memberships via OIDC claims during sign-in, so permissions reflect the latest updates.
• Provisions service principals on first use. Service principals are provisioned on first authenticated use, and AIM treats all identities consistently across workspaces.
• Sync latency. After a change in Entra ID, updates apply within up to 5 minutes for browser sign-in and up to 40 minutes for non-browser access such as jobs, the CLI, and service principals.

Why Databricks Platform uses AIM

• No pre-provisioning required. Users, groups, and service principals are available in Azure Databricks as soon as they are granted permissions, which also makes actions like sharing an AI/BI dashboard immediate.
• Simplified setup. AIM uses Databricks' own first-party integration with Microsoft Graph, removing the need to create and maintain a separate Entra enterprise application for Databricks or to manage SCIM tokens and attribute mappings.
• Consistent identity model. AIM supports users, groups, and service principals, including service principals inside groups, and treats identities consistently across workspaces.
• Efficient at scale. AIM materializes identities only on first authentication or grant rather than bulk-loading them, which helps avoid account-level user and group quotas.

Getting started

1. Review the Automatic identity management documentation to understand prerequisites and enablement.
2. Enable AIM at the account level so Databricks can read identities from Microsoft Entra ID using the Graph API.
3. If you already provision with SCIM, follow the recommended path to run AIM alongside existing SCIM provisioning, validate that AIM works correctly, and then disable SCIM with existing permissions remaining intact. See Migrate to automatic identity management.

FAQs

Which identities does AIM provision?

AIM provisions users, service principals, and groups from Microsoft Entra ID, including nested group memberships, and treats these identities consistently across workspaces.

When are identities provisioned with AIM?

Provisioning is just-in-time: identities are materialized on first use or login rather than pushed on a schedule, so users and service principals become available as soon as they are granted permissions.

How long do identity changes take to apply?

Changes apply within up to 5 minutes for browser sign-in and up to 40 minutes for non-browser access such as jobs, the CLI, and service principals.