What securityadmin Role Members Can and Cannot Do

Based on the name, you probably can guess that members of the securityadmin role can make dangerous changes to the permissions of other server principals. What many folks don’t realize is that this role is simultaneously less dangerous and more dangerous than you might think.

Allow me to explain, or better yet show you what that means.

As you can guess by the name, the securityadmin role is designed for server principals (logins and groups) who will administer security. Members of this role can not only create or drop nearly any logins, but they can also grant or deny nearly any permission to nearly any principal.

Noticed how I used “nearly any” a few times there. Here are the exceptions.

This is an instance-level role, so the exception of “nearly any permission” means members of this role can grant instance level permissions, but they can’t grant database level permissions without themselves belonging to a role within a database.

And the big exception of “nearly any principal” applies to members of the sysadmin role. A member of the securityadmin role cannot drop or alter any permissions for any member of the sysadmin role. Moreover, members of the securityadmin role are not able to add any members to the sysadmin role.

So, what makes the securityadmin role more dangerous than one might expect?

Well, having members of this role is still considered a big vulnerability for your SQL Server instances because they can create logins and assign them permissions greater than their own. Although securityadmin members cannot assign CONTROL SERVER permissions to themselves, they can assign them to another login. Because of this, members of this role can be leveraged for escalating privileges those with bad intentions.

Here’s how this would work in an attack. Assume you have a login who is a member of the securityadmin role, and their login has been compromised. The attacker could connect to the SQL SERVER instance with this login and create a new login.

CREATE LOGIN EvilLogin WITH PASSWORD = 'UpToNoGood';
GO

Then, with one more command, they could assign the CONTROL SERVER permissions to that login.

GRANT CONTROL SERVER TO [EvilLogin];
GO

Now this “EvilLogin” can be used to impersonate any member of the sysadmin role, and do anything in your SQL Server instance from creating backups to opening a command shell for downloading malware.

For this reason, we recommend restricting membership of the securityadmin role to only necessary members, or no one if possible. Quite frankly, there are very few situations where you might need a member of this role, as most of the time permissions are typically assigned by a member of the sysadmin role. In fact, when reviewing security for instances we often discover any members of this role are also members of the sysadmin role, so the permissions are redundant.

Check your instances today for any enabled members of the securityadmin role with the following T-SQL:

SELECT [name]
FROM master.sys.syslogins
WHERE securityadmin = 1
AND [denylogin] = 0;