Azure SQL with Microsoft Entra-only authentication for Virto Commerce — zero dev effort, works out of the box

howto
,
1

Azure SQL with Microsoft Entra-only authentication for Virto Commerce — zero dev effort, works out of the box

If you run Virto Commerce on Azure, Microsoft Defender for Cloud has probably shown you this High severity recommendation:

Azure SQL logical servers should have Microsoft Entra-only authentication enabled

image (28)
image (28)1889×859 59.3 KB

We get asked about it a lot — usually right before a security audit or a production go-live.

The short answer: Virto Commerce supports it today, with no code changes, no platform configuration changes and no custom modules. It is already available in Virto Cloud, and self-hosted customers can switch in a matter of minutes. This post explains why Microsoft pushes it, what actually changes, and how to enable it step by step.

Why Microsoft is pushing Entra-only

The idea is simple: all authentication goes through one place — Microsoft Entra ID — so access is managed in one place, not in the direct sense of “one dashboard”, but literally one identity store. Disable an identity in Entra and it is disabled everywhere: SQL, storage, Key Vault, the portal. There is no forgotten SQL login with a password sitting in a connection string somewhere.

When you enable Microsoft Entra-only authentication, SQL authentication is disabled for the whole logical server: SQL admin, logins and users can no longer connect, and only Microsoft Entra principals can. Microsoft Learn

Because Defender rates the recommendation as High, it shows up prominently in secure-score reports and compliance audits — which is why it causes stress even though the fix is small.

What changes in Virto Commerce? Nothing.

Virto Commerce Platform connects to SQL Server through EF Core and Microsoft.Data.SqlClient. Microsoft.Data.SqlClient supports authenticating to Azure SQL by acquiring tokens via managed identity: you specify Active Directory Managed Identity in the connection string and no password is required. Microsoft Learn

So instead of a connection string with a SQL user and a password, you point the platform at a managed identity. The identity gets a token from Entra ID, the token replaces the password, and the driver handles refresh. From the platform’s point of view it is still just a connection string:

  • No platform code changes
  • No appsettings.json changes beyond the connection string itself
  • No extra environment variables or feature flags
  • No custom modules or dependencies
  • Works for any Virto Commerce solution, because every solution talks to Azure SQL the same way

Virto Cloud

In Virto Cloud this is already available. Each environment runs with its own user-assigned managed identity, the SQL server allows Entra authentication only, and the identity is referenced in the connection string. Your application pods connect to the database with a token — there is no SQL password to store, rotate or leak. If your environment still uses SQL authentication, contact the Virto Cloud team and we will switch it.

Self-hosted on Azure: step by step

The sequence matters: get the application connecting through Entra first, then lock the server down. This way there is no downtime if something is misconfigured.

1. Set a Microsoft Entra admin on the SQL server

In the Azure portal open your SQL server resource and select Microsoft Entra ID under Settings. An Entra admin must be set before Entra-only authentication can be enabled. Microsoft Learn

We recommend an Entra security group rather than a single user — all group members inherit the admin role. Microsoft Learn

2. Create a user-assigned managed identity for the platform

Create a User Assigned Managed Identity in the same tenant and attach it to whatever runs Virto Commerce:

  • AKS — via Microsoft Entra Workload ID (this is what Virto Cloud uses)
  • App Service / Container Apps — via Identity → User assigned on the resource

A managed identity is better than a service principal with a secret: the identity is bound to the Azure resource and nothing to copy out. Microsoft Learn

3. Create a database user for the managed identity

Connect to the Virto Commerce database with the Entra admin from step 1 (SSMS, Azure Data Studio or the portal query editor) and run:

CREATE USER [<managed-identity-name>] FROM EXTERNAL PROVIDER;
ALTER ROLE db_owner ADD MEMBER [<managed-identity-name>];

Because the SQL server lives in your Entra tenant, FROM EXTERNAL PROVIDER looks the identity up in Entra ID and creates a contained database user for it. db_owner is required because Virto Commerce Platform applies EF Core migrations on startup; if you run migrations separately, db_datareader + db_datawriter + db_ddladmin is enough. Microsoft’s reference for this step: Managed identity in Microsoft Entra for Azure SQL.

4. Update the connection string

Replace User Id=...;Password=... with the managed identity:

Server=tcp:<server>.database.windows.net,1433;Initial Catalog=<database>;
Authentication=Active Directory Managed Identity;User Id=<client-id-of-the-managed-identity>;
Encrypt=True;TrustServerCertificate=False;

For a user-assigned identity the User Id is the identity’s client ID (Microsoft.Data.SqlClient 3.0+); for a system-assigned identity omit User Id. Microsoft Learn

Tip: Authentication=Active Directory Default works both locally (your developer credentials via Azure CLI / Visual Studio) and in Azure (the managed identity), so the same connection string can be used in every environment. Microsoft Learn

5. Restart and verify

Restart the platform and check the logs: the platform should start, run migrations and serve the Back Office as before. Nothing else changes.

6. Enable Microsoft Entra-only authentication on the server

Now lock it down. In the portal: SQL server → Settings → Microsoft Entra ID → Support only Microsoft Entra authentication for this server → Save. Or with Azure CLI:

az sql server ad-only-auth enable --resource-group <rg> --name <server>

The account doing this needs the SQL Security Manager RBAC role (or higher). Microsoft Learn

For new servers, enable it during creation — that is exactly what the policy in the screenshot audits (aka.ms/adonlycreate → Create server with Microsoft Entra-only authentication enabled). Note the policy only checks the creation-time setting; to enforce that local authentication stays off, assign the Microsoft Entra-only authentication initiative instead. Azure Policy definition

7. Check Defender for Cloud

Within the next assessment cycle the recommendation turns green. Existing SQL logins are not deleted — they simply can no longer connect — so you can remove them at your own pace. Microsoft Learn

Summary

Before After
Credentials SQL login + password in connection string Managed identity, token-based, nothing to store
Revocation Change password, redeploy everywhere Disable identity in Entra, effective everywhere
Defender for Cloud High severity finding Compliant
Virto Commerce changes — None

Entra-only authentication for Azure SQL is one of those recommendations that looks scary in an audit and turns out to be an afternoon of infrastructure work — with zero effort on the Virto Commerce side. If you are on Virto Cloud it is already there; if you self-host, the seven steps above are all you need.

The same applies to Azure Database for PostgreSQL Flexible Server, which has an equivalent policy — we will cover it in a follow-up post.

Further reading