Yes, we're now running our Spring Sale. All Courses are 30% off until 31st March, 2026
Viewing Roles and Permissions Granted to Users of Azure SQL Server Instance
Last updated: September 7, 2025
1. Introduction
Roles and permissions are essential to securing Microsoft Azure SQL Server databases. Providing users with the appropriate level of access is crucial for compliance and security as businesses grow.
To query and examine the server-level, database-level, and custom roles that Azure SQL Database offers, we can use the Azure Portal, the Azure Active Directory integration, or custom T-SQL statements.
In this tutorial, we’ll present the different types of roles, how to view user permissions, and the best practices for auditing access in Azure SQL Server.
2. Understanding the Roles in Azure SQL Server
Roles are predefined or user-defined security groupings. We can assign users to roles rather than giving them permissions on a case-by-case basis.
We differentiate between server-level and database-level roles:
| Roles | Command | Description |
|---|---|---|
| Server | sysadmin | full control over the SQL Server instance. |
| serveradmin | manage server-wide configurations | |
| securityadmin | manage logins and permissions | |
| setupadmin, processadmin, diskadmin, dbcreator, bulkadmin | specialized roles | |
| Database | db_owner | full database control |
| db_datareader / db_datawriter | read or write data in all user tables | |
| db_ddladmin | execute DDL commands (e.g., create/alter tables) | |
| db_securityadmin | manage database-level permissions | |
| db_backupoperator | manage database backups | |
| public | default role, everyone belongs to this role |
Additionally, organizations can establish custom roles to comply with the least privilege principle. With user-defined custom roles, administrators can customize permissions to meet particular job functions or operational requirements.
This ensures that users only have access to the resources they need for their tasks, reducing the possibility of unintentional or malicious data exposure.
3. Methods for Viewing Roles Using a Query
Azure SQL supports querying system views to retrieve roles and permissions.
3.1. View Database Roles Assigned to Users
Here’s an SQL query that retrieves a list of database roles and their members from the current SQL Server database:
SELECT dp.name AS DatabaseRole,
mp.name AS MemberName,
mp.type_desc AS MemberType
FROM sys.database_role_members drm
JOIN sys.database_principals dp ON drm.role_principal_id = dp.principal_id
JOIN sys.database_principals mp ON drm.member_principal_id = mp.principal_id
ORDER BY dp.name;
The sys.database_role_members view maps database roles to their members, showing which users belong to which roles. The sys.database_role_principals view contains information about all database-level security principals, including users, roles, and application roles.
Here’s what the output typically looks like:
| DatabaseRole | MemberName | MemberType |
|---|---|---|
| db_datareader | app_user | SQL_USER |
| db_datawriter | app_user | SQL_USER |
| db_owner | admin_user | SQL_USER |
| db_owner | dbo | DATABASE_ROLE |
| db_ddladmin | dev_user | SQL_USER |
The actual output depends on our database’s current role assignments. We’ll see all users and roles that are members of other roles, sorted by the role name.
This query is a great way to get a clear snapshot of role memberships. It’s particularly useful when auditing permissions and managing access.
3.2. View Server-Level Roles
Getting server-level role memberships in SQL Server is useful for auditing administrative privileges and understanding access control at the instance level.
Here’s an SQL query that retrieves a list of server roles and their members:
SELECT spr.name AS ServerRole,
spm.name AS MemberName
FROM sys.server_role_members srm
JOIN sys.server_principals spr ON srm.role_principal_id = spr.principal_id
JOIN sys.server_principals spm ON srm.member_principal_id = spm.principal_id
ORDER BY spr.name;
The sys.server_role_members view shows the relationships between server-level roles and their members. The sys.server_principals view lists all server-level security principals, such as logins and server roles, providing metadata about each.
Here’s what the output typically looks like:
| ServerRole | MemberName |
|---|---|
| sysadmin | sa |
| sysadmin | SandipAdmin |
| securityadmin | AuditUser |
| serveradminDBA_TeamLead | DBA_TeamLead |
| setupadmin | InstallerLogin |
The actual output will reflect the logins configured on the SQL Server instance and their assigned server roles. These roles govern various capabilities, such as managing logins, configuring server settings, or executing high-level tasks.
3.3. View Explicit Permissions Granted to a User
In contrast to the query showing role memberships, we’ll now focus on explicit permissions granted directly to users or roles.
When auditing who has access to what, and under whose authority, a detailed view of explicit database-level permissions comes in handy:
SELECT dp1.name AS Grantee,
dp2.name AS Grantor,
perm.permission_name,
perm.state_desc,
obj.name AS ObjectName
FROM sys.database_permissions perm
JOIN sys.database_principals dp1 ON perm.grantee_principal_id = dp1.principal_id
JOIN sys.database_principals dp2 ON perm.grantor_principal_id = dp2.principal_id
LEFT JOIN sys.objects obj ON perm.major_id = obj.object_id
ORDER BY dp1.name, perm.permission_name;
This query serves as an excellent tool to demonstrate granular access control within relational databases.
The following table provide details about the output columns in the query.
| Column | Description |
|---|---|
| Grantee | The principal (user/role) receiving the permission |
| Grantor | The principal who granted the permission |
| permission_name | The specific permission granted (SELECT, EXECUTE, INSERT) |
| state_desc | The state of the permission (GRANT, DENY, REVOKE) |
| ObjectName | The name of the object (table, view, procedure, etc.) the permission applies to |
Here’s how the output typically looks like:
| Grantee | Grantor | permission_name | state_desc | ObjectName |
|---|---|---|---|---|
| app_user | dbo | SELECT | GRANT | Customers |
| dev_user | dbo | EXECUTE | GRANT | usp_GetOrders |
| audit_user | dbo | VIEW DEFINITION | GRANT | Orders |
| guest | dbo | SELECT | DENY | SensitiveData |
Furthermore, this highlight security best practices in enterprise data environments, and clarify the distinctions between role based vs explicit permission assignments.
4. Viewing Roles Using the Azure Portal
The Azure Portal provides a graphical interface for viewing and managing user roles:
The steps to get there are:
- We’ll navigate to the Azure Portal and open the SQL databases section
- Select the target database, then configure the server firewall and set the Active Directory admin for identity mapping
- Within the database view, we’ll access the Access control (IAM) panel to review user roles and permissions.
If the SQL Server is integrated with Azure AD, permissions can also be reviewed through the Azure Active Directory portal. Further, we’ll navigate to enterprise applications, then select users and groups to audit group-based assignments across multiple users.
This is especially useful when auditing group-based assignments across multiple users.
5. Best Practices for Managing and Reviewing Permissions
To ensure secure and scalable access management, it’s essential to follow the principle of least privilege. This is done by assigning only the permissions that are strictly necessary.
For routine audits, we need to use Azure Automation or SQL queries. As a result of these audits, we can detect excessive or out-of-date permissions, ensure adherence to internal policies, and identify potential security threats before they become a problem.
We should also implement role-based access control through Azure AD groups for better scalability, and enable logging via Azure Monitor and SQL Auditing to effectively track access changes.
6. Conclusion
In this article, we discussed about how Azure SQL Server roles and permissions ensures secure and legal database access. T-SQL queries, the Azure Portal, and Azure AD help administrators keep track of who has access and what they can do with it.
The ability to manage roles and permissions in Azure SQL Server is essential for preserving data security, operational integrity, and regulatory compliance.
When onboarding new users, distributing access among teams, or getting ready for an audit, knowing who can do what and why is crucial.