Microsoft Entra principals for Azure SQL: managed identity vs service principal, users and groups
Verdict: For workloads connecting to Azure SQL, prefer a managed identity: it is passwordless and stores no secret. Service principals with a client secret are supported but carry credential risk. Entra groups simplify user access management.
| Criterion | Managed identity | Service principal (client secret) | Entra user | Entra security group |
|---|---|---|---|---|
| Identity type | Workload identity | Workload identity | Human user | Collection of principals |
| Secret handling | Passwordless, no stored secret | Client secret to store and rotate | Interactive, supports MFA | Not applicable |
| Guidance | Recommended for Azure resources | Supported but not recommended | Named DBA access | Simplifies access by group membership |
Rules
- Managed identities are the recommended passwordless option for Azure resources; a service principal with a client secret is supported but not recommended.
- Entra users, security groups and applications (managed identities or service principals) can all be database principals; on-prem accounts must first sync to Entra.
- Supported service and workload identity methods are managed identities (system- and user-assigned) and a service principal with a client secret.
- Creating a database user for an Entra group requires the server's identity to hold the GroupMember.Read.All Microsoft Graph permission.
Traps
- An Entra identity that belongs to more than 2048 security groups cannot log in to the database.
- Application.Read.All covers service principals and managed identities, not groups; a group user needs GroupMember.Read.All.