By: K. Brian Kelley | Updated: 2012-11-14 | Comments (1) | Related: More > Auditing and Compliance
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; 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];
- 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.
Last Updated: 2012-11-14
About the author
View all my tips