Auditing SQL Server 2012 Server Roles

By: K. Brian Kelley   |   Updated: 2012-11-14   |   Comments (1)   |   Related: > Auditing and Compliance

Problem

My organization is looking at SQL Server 2012 and I know that the ability to create roles at the server level is a new feature. Since this is new and impacts security, how do I handle them and how do I audit them?

Solution

Handling server roles in SQL Server 2012 doesn't differ much from handling permissions for logins in SQL Server 2005, 2008, and 2008R2. The catch is we have a level of abstraction because of the role.

Let's start by creating a test role to demonstrate our audit scripts with:

-- Creating a new server role
CREATE SERVER ROLE Example_Server_Role;
GO 

In SQL Server 2012 we still use the sys.server_principals catalog view to see the roles. There is a new column, is_fixed_role, that tells us whether the role is a traditional fixed server role or a user created one. The one exception is public, which is not marked as a fixed role for some reason.

Knowing this, we can query to see what roles exist, when they were created, and whether or not they were user created.

-- Seeing which server roles are "fixed"
SELECT principal_id, [name], create_date, is_fixed_role 
FROM sys.server_principals
WHERE [type] = 'R';
GO  

If we just want to filter to the user created server roles, the following query gets that information:

-- See created server roles only
SELECT principal_id, [name]
FROM sys.server_principals
WHERE [type] = 'R'
  AND NOT [name] = 'public'; 

Now let's add some permissions to our example server role so we can see them in our audit queries:

-- Grant example permissions
GRANT ALTER ANY SERVER ROLE TO Example_Server_Role;
GRANT IMPERSONATE ON LOGIN::sa TO Example_Server_Role; 

Now we can query and see permissions. Note that in the case of IMPERSONATE, we'll need to determine who exactly the role is allowed to impersonate, so there's some additional work that's required.

-- See permissions assigned to server roles
SELECT prin.name, perm.state_desc, perm.class_desc, 
       CASE perm.permission_name 
         WHEN 'IMPERSONATE' THEN 'IMPERSONATE ON [' + imp.name + ']'
         ELSE perm.permission_name END COLLATE SQL_Latin1_General_CP1_CI_AS AS [permission]
FROM sys.server_permissions perm
  JOIN sys.server_principals prin
    ON perm.grantee_principal_id = prin.principal_id
  LEFT JOIN sys.server_principals imp
    ON perm.major_id = imp.principal_id
WHERE prin.[type] = 'R'; 

This clearly reveals that Example_Server_Role has permissions we definitely want to be aware of.

Finally, we'll want to see who is a member of each role:

-- See who the members for each server role are
SELECT roles.[name] AS 'Role', prin.[name] AS 'Member'
FROM sys.server_role_members mem
  JOIN sys.server_principals roles
    ON mem.role_principal_id = roles.principal_id
  JOIN sys.server_principals prin
    ON mem.member_principal_id = prin.principal_id
ORDER BY roles.[name], prin.[name];

Next Steps

• Learn more about managing server roles in SQL Server 2012.
• Prepare for a disaster by capturing information on server roles.
• Understand how to audit server-level permissions in general.

About the author

K. Brian Kelley is a SQL Server author and columnist focusing primarily on SQL Server security.

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips