Entra Authentication for Azure SQL
Configure Microsoft Entra ID authentication for Azure SQL Database, Managed Instance, and SQL Server. Create database users from Entra identities and manage hybrid authentication.
Authentication in Azure SQL
Think of authentication like showing your ID at a building entrance.
SQL authentication is like a visitor badge — you hand over a username and password stored inside the database. Simple, but the database is responsible for checking credentials.
Microsoft Entra authentication is like your corporate badge — the identity system (Entra ID) vouches for you. The database trusts Entra, and Entra handles MFA, Conditional Access, and password policies. One identity, every database.
Microsoft recommends Entra authentication as the primary method for Azure SQL. The exam tests it heavily.
Entra authentication across platforms
| Feature | SQL Database | Managed Instance | SQL on VMs |
|---|---|---|---|
| Entra authentication | Yes (native) | Yes (native) | Yes (with setup) |
| Entra-only mode | Yes | Yes | No |
| Entra admin | One user or group per server | One user or group per instance | N/A (configured via T-SQL) |
| Entra users in DB | CREATE USER ... FROM EXTERNAL PROVIDER | CREATE USER ... FROM EXTERNAL PROVIDER | CREATE LOGIN ... FROM EXTERNAL PROVIDER |
| Managed identity auth | Yes | Yes | Yes (SQL 2022+) |
| Service principal auth | Yes | Yes | Yes (SQL 2022+) |
| MFA support | Yes (via Entra) | Yes (via Entra) | Yes (via Entra) |
| Windows authentication | No | Yes (Kerberos via Entra) | Yes (native) |
Setting up Entra authentication
Azure SQL Database
Amara configures Entra auth for Harbour Health’s Azure SQL Database:
Step 1: Set the Entra admin
- In the Azure portal, navigate to the SQL server (logical server)
- Under Settings, select Microsoft Entra admin
- Choose a user or group as the admin
- Only ONE Entra admin per logical server (use a group for multiple admins)
Step 2: Create contained database users
-- Connect as the Entra admin
CREATE USER [amara@harbourhealth.com] FROM EXTERNAL PROVIDER;
CREATE USER [dba-team@harbourhealth.com] FROM EXTERNAL PROVIDER;
CREATE USER [app-managed-identity] FROM EXTERNAL PROVIDER;
-- Grant permissions
ALTER ROLE db_datareader ADD MEMBER [amara@harbourhealth.com];
ALTER ROLE db_owner ADD MEMBER [dba-team@harbourhealth.com];Step 3 (optional): Enable Entra-only authentication
- Disables SQL authentication entirely — only Entra identities can connect
- Most secure option, but ensure all applications use Entra auth first
Azure SQL Managed Instance
Kenji’s MI setup is similar, with one key difference:
- MI supports instance-level logins (like on-prem SQL Server)
- You can create Entra logins at the instance level, then map to database users
-- Instance-level login (MI only)
CREATE LOGIN [kenji@northstar.com] FROM EXTERNAL PROVIDER;
-- Then in each database
CREATE USER [kenji@northstar.com] FROM LOGIN [kenji@northstar.com];SQL Server on Azure VMs
For SQL Server 2022+ on Azure VMs, Entra authentication requires:
- Azure Arc registration or Azure extension for SQL Server
- Configure the SQL Server instance to trust Entra ID
- Create logins from Entra identities
-- SQL Server 2022+ with Entra configured
CREATE LOGIN [kenji@northstar.com] FROM EXTERNAL PROVIDER;Windows Authentication via Entra (MI)
Azure SQL Managed Instance supports Windows Authentication through Microsoft Entra ID using Kerberos:
- On-prem clients authenticate via Kerberos against Active Directory
- AD syncs with Entra ID (via Entra Connect)
- MI trusts the Kerberos ticket through Entra
This enables legacy applications to connect to MI without changing authentication code — they still use Windows auth, but the identity flows through Entra.
Authentication types for applications
| Auth Type | How It Works | Best For |
|---|---|---|
| Entra interactive | User signs in with browser prompt, supports MFA | Admin tools (SSMS, Azure Data Studio) |
| Entra integrated | Uses cached Windows/Entra credentials (SSO) | Desktop applications on domain-joined machines |
| Entra service principal | App ID + secret or certificate | Application-to-database (app registrations) |
| Entra managed identity | Azure-managed identity, no secrets to manage | Azure services (App Service, Functions, VMs) |
| SQL authentication | Username + password in connection string | Legacy apps, third-party tools without Entra support |
Priya’s approach at ScaleWave: All microservices use managed identities — no connection string passwords. The operations team uses Entra interactive with MFA. SQL authentication is disabled (Entra-only mode).
Exam tip: managed identity is always the preferred answer
When the exam asks “which authentication method should an Azure-hosted application use?”, the answer is almost always managed identity:
- No secrets to manage or rotate
- No credentials in code or config
- Automatically managed by Azure
- Works with system-assigned and user-assigned identities
Service principals are the second-best option (for non-Azure hosted apps). SQL auth is the last resort.
Amara wants to ensure that no one can connect to Harbour Health's Azure SQL Database using a username and password. Only Entra identities should be allowed. What should she configure?
Priya's microservice running on Azure App Service needs to connect to Azure SQL Database without storing any credentials. What authentication method should she use?
🎬 Video coming soon
Next up: Security Principals, Permissions, and T-SQL — configure database and object-level permissions using both GUI tools and T-SQL.