Jan
20

Move SQL Permissions from Users to Roles

Andrew Ing T-SQL Add comment

For ease of maintenance all object permissions should be granted to SQL Server roles and users simply made members of one role or another.    If you’re using SSDT, roles assigned to users don’t work at all well.  I find it best to create users in a post-deployment script outside of the model. This only permits role-based permissions (in any manageable sense, controlled by the SSDT model).

It’s all too easy for permissions to become directly assigned to users.  This code (executed step by step) finds permissions assigned to users, assigns the same permissions to roles, checks that the new and old permissions match, deletes the permissions from users.

Locate permissions assigned directly to users

The process begins with an audit of permissions directly assigned to users.  The results are saved to a table; they could have been simply printed or inserted into a temporary table for the period of the operation; however, it’s important to keep the results of the original audit to ensure that all existing object access is maintained.  It also allows for rollback.

First create a schema for this work and tables for the audit results.

/*
   Create new schema ddl_work for user permission audit tables.
*/
CREATE SCHEMA ddl_work AUTHORIZATION dbo
GO

EXEC sys.sp_addextendedproperty @name = N'MS_Description'
	,@value = N'Objects used during database updates and re-factorings; for example, views, procedures and temporary tables used to manage and confirm data updates. '
	,@level0type = N'SCHEMA'
	,@level0name = N'ddl_work'

/*
   table DirectGrantedPermissions
*/
--DROP TABLE ddl_work.DirectGrantedPermissions
CREATE TABLE ddl_work.DirectGrantedPermissions (
	grantee_name VARCHAR(255)
	,permission VARCHAR(100)
	,state_desc VARCHAR(100)
	,major_object_name VARCHAR(255)
	,[minor_id] INT
	,[replacement_role_name] VARCHAR(100) NULL CONSTRAINT [PK_DirectGrantedPermissions] PRIMARY KEY CLUSTERED (
		grantee_name
		,permission
		,state_desc
		,major_object_name
		,minor_id ASC
		)
	)
GO

EXEC sys.sp_addextendedproperty @name = N'MS_Description'
	,@value = N'Contains permissions directly granted to users. Used for transferring permissions to Roles, and then for confirming. '
	,@level0type = N'SCHEMA'
	,@level0name = N'ddl_work'
	,@level1type = N'TABLE'
	,@level1name = N'DirectGrantedPermissions'
GO

/*
    table RolePermissions
*/
-- DROP TABLE ddl_work.RolePermissions
CREATE TABLE ddl_work.RolePermissions (
	role_name VARCHAR(255)
	,permission VARCHAR(100)
	,state_desc VARCHAR(100)
	,major_object_name VARCHAR(255)
	,[minor_id] INT CONSTRAINT [PK_RolePermissions] PRIMARY KEY CLUSTERED (
		role_name
		,permission
		,state_desc
		,major_object_name
		,minor_id ASC
		)
	)
GO

EXEC sys.sp_addextendedproperty @name = N'MS_Description'
	,@value = N'Contains of role permissions. used for checking the transfer of permissions from Users to Roles.'
	,@level0type = N'SCHEMA'
	,@level0name = N'ddl_work'
	,@level1type = N'TABLE'
	,@level1name = N'RolePermissions'

Find the Errant Permissions

This script finds all permissions granted directly to users and inserts them into the newly-created table.  It then does a few row counts and summarises the situation for you.

/*
Load existing directly-applied permissions into table.
Look up the object name. 
minor_id can contain reference to column; I am assuming that there is no column-level security; if there is alert the user.

grantee.type:  sys.database_principals.type.  S = SQL_USER, U = WINDOWS_USER, G = WINDOWS_GROUP (all types of principal that we _don't_ want to assign direct permissions to.)
*/
DECLARE @ErrorCount INT = 0

PRINT 'Clearing DirectGrantedPermissions table.'

DELETE
FROM ddl_work.DirectGrantedPermissions

PRINT 'Inserting all direct-assigned permissions into DirectGrantedPermissions.'

INSERT INTO [ddl_work].[DirectGrantedPermissions] (
	[grantee_name]
	,[permission]
	,[state_desc]
	,[major_object_name]
	,[minor_id]
	)
SELECT GranteeName = grantee.NAME
	,dp.permission_name
	,dp.state_desc
	,ObjectName = OBJECT_NAME(major_id)
	,dp.minor_id
FROM sys.database_permissions dp
INNER JOIN sys.database_principals grantee ON dp.grantee_principal_id = grantee.principal_id
INNER JOIN sys.database_principals grantor ON dp.grantor_principal_id = grantor.principal_id
WHERE grantee.type IN (
		'S'
		,'U'
		,'G'
		)
	AND dp.permission_name <> 'CONNECT'
ORDER BY grantee.NAME

PRINT 'Checking whether any permission is assigned to a minor object.'

DECLARE @Count AS INT = 0

SELECT @Count = Count(*)
FROM ddl_work.DirectGrantedPermissions
WHERE minor_id <> 0

IF (@Count > 0)
BEGIN
	SET @ErrorCount += 1

	PRINT 'One or more permission(s) have been assigned to a minor object - e.g. a column. Check'
END

DECLARE @UniqueLoginCount INT = 0
DECLARE @PermissionCount INT = 0

PRINT 'Counting number of Users.'

SELECT @UniqueLoginCount = Count(*)
FROM ddl_work.DirectGrantedPermissions
GROUP BY grantee_name

PRINT 'Counting all rows.'

SELECT @PermissionCount = Count(*)
FROM ddl_work.DirectGrantedPermissions

PRINT 'There are ' + CAST(@PermissionCount AS VARCHAR) + ' Permissions assigned to ' + CAST(@UniqueLoginCount AS VARCHAR) + ' different Users.'

Set the replacement Roles

We want to assign every user-permission to a role.  Note the column [replacement_role_name] in the DirectGrantedPermissions table.  We simply have to enter the name of the role into each row.

That might be a tall order.  If there are a heaps of user-permissions, the best we might be able to do is create a role per user and then tidy the roles later.  The main aim is to get the permissions off of the users !

Special value: set replacement_role_name to <DELETE>  to ignore a particular row; no role-based permission will be created.

One or more simple updates like the following will be needed

PRINT 'Setting replacement role MyUserRole for user MyUser.'

UPDATE ddl_work.DirectGrantedPermissions
SET replacement_role_name = 'MyUserRole'
WHERE grantee_name = 'MyUser'

Grant Permissions to Roles

The first thing this next script does is check that all rows in DirectGrantedPermissions have a replacement_role_name value.

In my database any ‘WITH GRANT OPTION’ was a mistake caused by ticking too many options in the SSMS permissions UI!  This script removes any WITH GRANT options.  Of course, WITH GRANT may be intentional.

The script then loops through all rows in DirectGrantedPermissions adding each permission to the specified replacement role (it generates and executes the GRANT DDL statements).  The roles must already exist, naturally.

PRINT 'Checking that all users have a replacement role defined.'

DECLARE @blank_replacement_role_name_count INT = 0

SELECT @blank_replacement_role_name_count = Count(*)
FROM ddl_work.DirectGrantedPermissions
WHERE replacement_role_name IS NULL
GROUP BY grantee_name

IF @blank_replacement_role_name_count > 0
BEGIN
	SET @ErrorCount += 1

	PRINT 'No replacement role has been specified for ' + CAST(@blank_replacement_role_name_count AS VARCHAR) + ' user name(s).'
END

/*
Handle the GRANT_WITH_GRANT_OPTION oddity. 
Comment this out if WITH GRANT is required

Some permissions may have been assigned as GRANT_WITH_GRANT_OPTION.
Replace these with simple GRANT.  

*/
PRINT 'Replacing GRANT_WITH_GRANT_OPTION with GRANT in DirectGrantedPermissions.'

UPDATE ddl_work.DirectGrantedPermissions
SET state_desc = 'GRANT'
WHERE state_desc = 'GRANT_WITH_GRANT_OPTION'

/*
   Add permissions to the replacement roles
*/
PRINT 'Add permissions to replacement roles'

DECLARE @sql NVARCHAR(255)

DECLARE @SetPermissionCursor CURSOR SET @SetPermissionCursor = CURSOR
FOR
SELECT state_desc + ' ' + [permission] + ' ON [' + major_object_name + '] TO ' + replacement_role_name
FROM ddl_work.DirectGrantedPermissions
WHERE replacement_role_name <> '<DELETE>'

OPEN @SetPermissionCursor

FETCH NEXT
FROM @SetPermissionCursor
INTO @sql

WHILE @@FETCH_STATUS = 0
BEGIN
	PRINT @sql

	EXECUTE sp_executesql @sql

	FETCH NEXT
	FROM @SetPermissionCursor
	INTO @sql
END

CLOSE @SetPermissionCursor

DEALLOCATE @SetPermissionCursor

Confirm that we have functionally-equivalent replacement permissions

So now we have created all the permissions on roles.  Have any been missed out?

This next script fills the second table we created (RolePermissions) with all the permissions granted to each role.   It then checks that all the permissions we said we wanted to create in DirectGrantedPermissions actually exist on the role.

If any don’t exist the script gives you the SQL to run to locate the missing permissions.   Again I had fun with “WITH GRANT OPTION” permissions – and you can see the effect in the script.

/*
 Check for each user that all directly-assigned permissions exist on the replacement role.

 Insert all Role permissions into ddl_work.RolePermissions
*/
PRINT 'Clearing RolePermissions table.'

DELETE
FROM ddl_work.RolePermissions

INSERT INTO [ddl_work].RolePermissions (
	role_name
	,[permission]
	,[state_desc]
	,[major_object_name]
	,[minor_id]
	)
SELECT grantee.NAME
	,dp.permission_name
	,dp.state_desc
	,ObjectName = OBJECT_NAME(major_id)
	,dp.minor_id
FROM sys.database_permissions dp
INNER JOIN sys.database_principals grantee ON dp.grantee_principal_id = grantee.principal_id
INNER JOIN sys.database_principals grantor ON dp.grantor_principal_id = grantor.principal_id
WHERE grantee.type IN ('R')
	AND dp.permission_name <> 'CONNECT'
ORDER BY grantee.NAME

/*
Replace any GRANT_WITH_GRANT_OPTION with GRANT
(otherwise the comparison will fail for such permissions)
*/
PRINT 'Replacing GRANT_WITH_GRANT_OPTION with GRANT in RolePermissions.'

UPDATE ddl_work.RolePermissions
SET state_desc = 'GRANT'
WHERE state_desc = 'GRANT_WITH_GRANT_OPTION'

/*
Do the users have any direct permissions that are not in their replacement roles?
*/
DECLARE @MissingPermissionCountr INT = 0

SELECT @MissingPermissionCountr = Count(*)
FROM ddl_work.DirectGrantedPermissions AS DGP
LEFT JOIN ddl_work.RolePermissions AS RP ON DGP.permission = RP.permission
	AND DGP.state_desc = RP.state_desc
	AND DGP.major_object_name = RP.major_object_name
	AND DGP.minor_id = RP.minor_id
	AND DGP.replacement_role_name = RP.role_name
WHERE (RP.role_name IS NULL)
	AND DGP.replacement_role_name <> '<DELETE>'

IF (@MissingPermissionCountr = 0)
BEGIN
	PRINT 'SUCCESS.  All directly assigned permissions now exist on the relevant replacement roles.'
	PRINT 'Next step: remove all permissions from users.'
END
ELSE
BEGIN
	PRINT 'FAILURE. ' + CAST(@MissingPermissionCountr AS VARCHAR) + ' permission(s) exist on user but not on replacement role.
run following query to discover which.'
	PRINT '
SELECT     DGP.grantee_name, DGP.permission, DGP.state_desc, DGP.major_object_name, DGP.minor_id, DGP.replacement_role_name, RP.role_name
FROM         ddl_work.DirectGrantedPermissions AS DGP LEFT OUTER JOIN
 ddl_work.RolePermissions AS RP ON DGP.permission = RP.permission AND DGP.state_desc = RP.state_desc AND 
 DGP.major_object_name = RP.major_object_name AND DGP.minor_id = RP.minor_id AND DGP.replacement_role_name = RP.role_name
WHERE     (RP.role_name IS NULL)
AND DGP.replacement_role_name <> ''<DELETE>''
'
END

Lastly – Revoke the User Permissions

Still with me?   So now we have re-created all users’ permissions on roles (of which the users must, of course, be members – but that’s outside this script), and we’ve verified them (i.e. the result of the preceding script was SUCCESS).

At last we can do what we’ve wanted to do all along:  revoke the user permissions.

This script uses the DirectGrantedPermissions table again to create Revoke statements for every user-permission, then executes it.

Once again, WITH GRANT OPTION permissions are so fiddly to script that I have left those for manual deletion – you can run the very first script again to detect any user-permissions that have escaped this cull.

/*
If above code succeeded, REVOKE permissions assigned to users.

We also delete the permissions whose replacement role is '<DELETE>'
- basically, we want to delete ALL user-based permissions.

Any GRANT_WITH_GRANT_OPTION permissions will have to be removed manually
(the syntax is hard work to create for the couple of occasions it appears!)

*/
PRINT 'Revoke permissions from users.'

DECLARE @sql NVARCHAR(255)

DECLARE @RevokePermissionCursor CURSOR SET @RevokePermissionCursor = CURSOR
FOR
SELECT 'REVOKE ' + [permission] + ' ON [' + major_object_name + '] TO ' + grantee_name
FROM ddl_work.DirectGrantedPermissions

OPEN @RevokePermissionCursor

FETCH NEXT
FROM @RevokePermissionCursor
INTO @sql

WHILE @@FETCH_STATUS = 0
BEGIN
	PRINT @sql

	EXECUTE sp_executesql @sql

	FETCH NEXT
	FROM @RevokePermissionCursor
	INTO @sql
END

CLOSE @RevokePermissionCursor

DEALLOCATE @RevokePermissionCursor

PRINT 'Done'

Finally

So that’s done.  You now have the pleasure of a database with no permissions directly assigned to users.   You may drop the two tables and the ddl_work schema (or leave it around for a while as evidence of the previous state in case of any permission-related problems).

A few slight changes could script the DDL statements, rather than executing them directly.  I think I couldn’t wait.

The manual labour part is deciding on the roles that will be used for each user or permission.   The degree of difficulty depends on how extensive the user-permission allocation was in the first place.