Auditing SQL Server 2012 Server Roles

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

Please do not scroll away - stay informed.
Dear Database Professional,

Did you know that publishes new SQL Server content on a daily basis as well as offers free webinars and tutorials?

We know your day is hectic and you don't necessarily have time to research new topics and solutions every day, but we can keep you informed.

Take 30 seconds to register for our newsletter and look for free educational content to help you grow your career. >> REGISTER HERE <<

Thank you,
Greg Robidoux and Jeremy Kadlec ( Co-Founders)

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?


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;

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.

In SQL Server 2012 we still use the sys.server_principals catalog view to see the roles

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';

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

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, perm.state_desc, perm.class_desc, 
       CASE perm.permission_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.

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

get scripts

next tip button

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

View all my tips

Article Last Updated: 2012-11-14

Comments For This Article

Wednesday, November 14, 2012 - 3:39:08 PM - JC Back To Top (20340)

You might find this script (procedure) helpful

I have used it on sql server 2005


get free sql tips
agree to terms