Azure Arc for SQL Server: “Least Privilege” Mode Still Relies on sysadmin

Azure Arc for SQL Server comes with a so-called “least privilege mode.”

But certain Azure Arc components still execute SQL Server operations with sysadmin authority, which can expose that authority to database-scoped code.

Fabiano Amorim recently demonstrated how a database-scoped principal can take advantage of exactly this privileged execution context to escalate to sysadmin through a database-level DDL trigger: How Azure Arc allows a DB admin to become SQL Server sysadmin – the vulnerability explained

Fabiano covers the exploit itself in detail. What I want to put under the magnifying glass here is the “least privilege” mode itself – a topic I have written about extensively:

The Principle of Least Privilege (POLP) / (Mirror)

Least privilege – except for Deployer.exe

With least privilege enabled, the regular Azure Extension service runs under the restricted identity:

NT SERVICE\SqlServerExtension

But there is a separate component involved: Deployer.exe.

Deployer.exe runs as NT AUTHORITY\SYSTEM and impersonates the SQL Server Database Engine service account when connecting to SQL Server.

And Microsoft requires that service account to be a member of the SQL Server sysadmin fixed server role for this operation: Operate SQL Server enabled by Azure Arc with least privilege

That is a clear deviation from the default security best practice.

So even in “least privilege” mode, certain Arc operations still reach SQL Server with full sysadmin authority.

The attack vector

Having a privileged setup component is not automatically a vulnerability.

The problem is that Arc performs DDL inside user databases while retaining that privileged execution context.

A database user with permission to create database-level DDL triggers can prepare a trigger and wait for an Azure Arc operation to fire it.

The trigger then executes under the privileged caller’s context – in this case with sysadmin authority – and can perform server-level operations that the database user could never execute directly.

Membership in db_ddladmin is sufficient to create such a trigger, can therefore become a path to sysadmin. Db_ddladmin is a powerful role and should be granted carefully. But it is not sysadmin.

Otherwise, why would the distinction exist at all?

Roles exist precisely to group defined permissions and make least-privilege administration practical.

Saying that db_ddladmin is dangerous does not remove that distinction.

This is where “least privilege” becomes questionable

If a component needs sysadmin for a server-level task, that may be justified if SQL Server does not provide a more granular permission.
But when it enters a user database and executes database-scoped DDL, it should not carry more authority than that operation requires.

That is especially important in SQL Server because DDL can invoke database-controlled code such as triggers.

Microsoft’s own SQL Server documentation warns about this class of permission hijacking: Manage trigger security. And Erland Sommarskog has written about this extensively here: Don’t Let Your Permissions be Hijacked!.

But other than telling administrators to be aware of the risk, SQL Server does not provide a practical general solution for eliminating the threat posed by such privilege-hijacking scenarios.

And with Azure Arc, we now have a prominent Microsoft first-party example of exactly this problem.

Unfortunately, SQL Server’s permission and role model still contains many exceptions where least privilege is difficult or impossible to implement cleanly.

I am trying to maintain an accurate list here: The challenges for least privilege: When sysadmin is still required in Microsoft SQL Server.

While I worked at Microsoft, a significant part of my role focused on improving the SQL Server permission model, defining more granular permissions and roles, and making sure new functionality adhered to the Principle of Least Privilege.

So I am familiar with both sides of the problem: the engineering challenges behind the scenes, and the practical difficulties customers and DBAs have encountered with SQL Server permissions over the past two decades.

A wish to the SQL Server Security team

I would urge Microsoft not to lose sight of these fundamentals while investing in new areas such as AI.

There are still plenty of situations where ordinary users and DBAs cannot implement proper least privilege without workarounds, excessive permissions, or undocumented exceptions.

And as this Azure Arc example shows, even Microsoft’s own components can struggle with the same problem.

With AI agents increasingly accessing databases, this becomes even more important. We can no longer assume that privilege-escalation paths require a human administrator who understands the system well enough to discover and exploit them manually.

Please keep investing in the SQL Server permission model, more granular permissions, and better-defined security boundaries.

There is still considerable work to do. Before I left Microsoft, I had already prepared specification work around more granular SQL Server permissions and least-privilege improvements that could serve as a starting point for some of this work.

Stay secure!

Andreas