Learn how managed identities in SQL Server 2025 enhance security by eliminating passwords and enabling seamless Microsoft Entra authentication for Azure resources.

Those who have worked with SQL Server will understand the need to avoid storing passwords for accessing resources. Windows-based identities are fine for on-premises SQL Server systems, including those on cloud-based virtual machines (VMs), but are of no use when you need to access cloud-based resources like those in Azure.

Some Azure-based resources (including storage accounts) offer other access methods, such as shared access signatures (SAS), but these aren’t much of a step-up from passwords.

What’s really needed is for SQL Server to have its own Microsoft Entra based identity. These can be used directly with Azure-based resources – and that’s exactly where managed identities come in.

What are managed identities?

A managed identity is a Microsoft Entra identity that Azure creates and manages for a resource. This allows the resource to obtain tokens for other Azure services without the need for storing passwords, client secrets, or certificates in code or configuration. Two types of managed identities are available.

First, a system-assigned managed identity, which is specific to a resource. For example, I could add a system-assigned managed identity to an Azure Data Factory (ADF). The ADF could then use the identity when making connections to, or accessing, other resources. When the ADF is deleted, the system-assigned managed identity is also removed.

Then there’s a user-assigned managed identity. This is created independently of any specific resource and can be applied to a resource, in addition to any system-assigned managed identity. User-assigned managed identities are very powerful because a single identity can be assigned to multiple resources.

For example, I might have a single identity for a group of data factories. This simplifies the configuration of access and, importantly, if I need to recreate the data factory, I can use the same identity. Even when all the data factories are deleted, the user-assigned managed identity can survive. Another common use for these is to assign the same identity to a group of web servers.

The official Microsoft documentation for managed identities can be found here.

Why managed identities are not just service principals

Under the covers, managed identities are a special kind of service principal, but there are important differences. The major one is that service principals expire, whereas Azure manages the lifecycle and credential rotation of managed identities for you.

I’m always concerned when I see solutions built using service principals without plans for what would happen when they expire. These are like time-bombs at many sites today, but using managed identities avoids these issues. The credential expires after 90 days and is rolled over after 45 days.

The biggest contrast is operational. With a service principal, someone must create an app registration, issue and protect a secret or certificate, and periodically rotate that credential. That might also require updating dependent systems.

What’s needed to use a managed identity?

To be able to use managed identities, you need two things:

You might think that anything that can have a managed identity could also use it for connections, but that’s not the case.

For example, you can assign either or both a system-assigned managed identity and a user-assigned managed identity to an Azure Analysis Services (AAS). However, AAS does not currently provide any way to use that identity when connecting to an Azure-based resource or service.

We currently have AAS servers making connections to Azure SQL Database using logins and passwords, but I wish we didn’t have to do this. It wouldn’t be required at all if we could just specify the managed identity in the connection details.

How do managed identities apply to SQL Server 2025?

It’s increasingly common for SQL Server to need to connect to Azure-based resources. This not only happens with SQL Server in Azure VMs, but also with on-premises SQL Server installations. However, SQL Server is not a native Azure resource or service.

From SQL Server 2025 onwards, it’s possible to both configure and use a system-assigned managed identity when SQL Server is enrolled in Azure Arc. To enable this, the SQL Server instance must be connected to Arc and run on Windows Server. It must also use the latest Azure Extension for SQL Server.

Currently, the documentation notes that SQL Server must have access to Azure public cloud for Microsoft Entra authentication, and that failover cluster instances are not supported for this managed-identity setup. We also can’t (yet) use user-assigned managed identities with SQL Server.

So, we only have part of what we need right now – but it’s a great start.

How to configure and use the managed identity in SQL Server 2025

Once the SQL Server instance is Arc-enabled, you can assign the server’s primary managed identity. You do this from the Azure portal while configuring the properties of the Arc-enabled SQL Server resource, under the Microsoft Entra ID and Purview settings. This primary managed identity is what SQL Server 2025 uses when making outbound connections to Azure-based resources.

You also need to grant the identity permission to the target resource in Azure. The role required is a role-based access control (RBAC) configuration, and will usually be different for each service type.

As part of making an outbound connection, you need to use a database-scoped credential like this:

Some credentials will also require you to specify a ‘secret’, for example when making a connection to an Azure OpenAI endpoint. Here, you not only specify IDENTITY = ‘Managed Identity’, but also a JSON secret identifying the token audience.

Note that it’s common to name the credential after the scope of the resource you’re accessing:

This credential can then be used when executing calls like CREATE EXTERNAL MODEL. Once this is done, calls to the external model can use that credential to authenticate without the need to supply an API key.

In summary: managed identities in SQL Server 2025

We still have limitations with how we can configure and use managed identities with SQL Server, but what’s been provided so far is a great start. It lets traditional on-premises (and cloud VM-based) SQL Server instances participate in modern Microsoft Entra-based authentication patterns, and in turn reduce potential issues like credential leakage.