SQL Server Permissions Database Roles

EZ PZ Permission Squeezee

Given the critical level of importance related to permissions, one may think it is a concept that is well understood by all who are given the charge of protecting the data.

There is a great responsibility when the keys to the data kingdom are granted to a DBA. The DBA is responsible for ensuring the integrity and security of the data. To ensure the security of the data, the DBA has the responsibility of granting, revoking, or denying access, at various levels, to the data and objects within the database.

Despite this high visibility and critical nature of this concept, understanding permissions and assigning permissions does not seem to be as straight forward as it should be. Evidence of this is something I see far too frequently in the wild as illustrated by the following image.

This screenshot is only a part of the problem that I wish tobreak down and discuss in this article.

SQL ServerPermissions

A fundamental component of SQL Server is the security layer. A principle player in security in SQL Server comes via principals. In a previous article, I outlined the different flavors of principals while focusing primarily on the users and logins. You can brush up on that article here . While I touched lightly, in that article, on the concept of roles, I will expound on the roles a bit more here but primarily in the scope of the effects on user permissions due to membership in various default roles.

Let’s reset back to the driving issue in the introduction. Frequently, I see what I would call a gross misunderstanding of permissions by way of how people assign permissions and role membership within SQL Server. The assignment of role membership does not stop with database roles. Rather it is usually combined with a mis-configuration of the server role memberships as well. This misunderstanding can really be broken down into one of the following errors:

The belief that a login cannot access a database unless added specifically to the database. The belief that a login must be added to every database role. The belief that a login must be added to the sysadmin role to accessresources in a database.

The experienced professional will likely note that there is a direct conflict between a few of these beliefs. That said, all too often I see all three of these misconceptions implemented in every instance for nearly every user.

Let’s start looking at these misconceptions. To investigate these problems, I will create a login. After creating the login, I will add that login as a member to the sysadmin role. Once the login is added to the sysadmin role, I will then run some simple tests within my DBA database.

Sysadmin

The creation of a server principal (login)and adding the principal to the sysadmin role is fairly simple. The next couple of screenshots are followed by a quick script that will perform the same actions.

As was promised, here is the script that will do the same thing as illustrated in the GUI above.

USE [master] GO CREATE LOGIN [superuser] WITH PASSWORD=N'ihavethepower', DEFAULT_DATABASE=[DBA], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF GO ALTER SERVER ROLE [sysadmin] ADD MEMBER [superuser] GO

With the user now in place, let’s test. The primary test here would be that a server principal cannot access the database since explicit database permissions have not been granted. Here is the first batch of tests that I will run.

/* can i access the DBA database? */ EXECUTE AS LOGIN = 'superuser' USE DBA; GO SELECT * FROM sys.objects o WHERE o.name = 'MySuperTable'; SELECT * FROM sys.database_principals dp WHERE name = 'superuser'; SELECT SUSER_NAME(),* FROM fn_my_permissions(NULL,NULL); /* one more check for giggles */ EXECUTE sys.SP_HELPROTECT @username = 'superuser'

The first statement is to allow me to impersonate the superuser login. From the impersonated connection, I first check to see I can query the sys.objects system catalog. Then I test the database_principals system catalog. Next in line is to check the list of permissions that have been granted to the superuser account. Each of these queries executes successfully without error. Here is a screen grab for these first three tests.

Notice the first two queries returned an empty set. This is not a failure, rather evidence that the select statement ran successfully. In the third result set, we can see that the superuser account has all sorts of server level permissions. In the result set there was not a single database level permission.

The last query that utilized sp_helprotect returned the following error:

Msg 15330, Level 11, State 1, Procedure sys.SP_HELPROTECT, Line 302

There are no matching rows on which to report.

This is confirmation that there is no database user called superuser.

So I can query a database without my server principal being given direct access to the database (it is worth reiterating here that this principal is in the sysadmin server role), but can I do other things such as create objects? Let’s test that with the following script.

/* can i create a table? */ DROP TABLE IF EXISTS MySuperTable; CREATE TABLE MySuperTable(superid BIGINT IDENTITY(1,1), SuperHero VARCHAR(128)) SELECT SCHEMA_NAME(o.schema_id) AS SchemaName, o.name AS ObjectName FROM sys.objects o WHERE o.name = 'MySuperTable';

This script is straight forward. All it does is check for a table. If that table exists, then drop it and recreate it. The last little bit will check to confirm the successful creation of the table. This script succeeds as illustrated in the following image.

That should be pretty convincing that if you add a server principal to the sysadmin server role then that user has access to the databases. These tests have illustrated that it is not necessary to add a server principal as a database principal when that server principal is in the sysadmin role (an erroneous configuration often seen). If the database principal is not necessary in this case, then what will happen if a database principal does exist? Database Principal in Every Database Role

The next logical step in the sequence is to create a database principal for the already created superuser server principal. Once created, we will test to see what effects if any can be observed by having this database principal in every database role as well as the sysadmin role. This will help to test the first two bullet items from the list of common configurations I have seen in the wild. Let’s start with the script that will help create the principal to be used during the next iteration of tests.

/* now let's do something that people love to do when assigning permissions */ USE [DBA] GO CREATE USER [superuser] FOR LOGIN [superuser] GO USE [DBA] GO ALTER ROLE [db_accessadmin] ADD MEMBER [superuser] GO USE [DBA] GO ALTER ROLE [db_backupoperator] ADD MEMBER [superuser] GO USE [DBA] GO ALTER ROLE [db_datareader] ADD MEMBER [superuser] GO USE [DBA] GO ALTER ROLE [db_datawriter] ADD MEMBER [superuser] GO USE [DBA] GO ALTER ROLE [db_ddladmin] ADD MEMBER [superuser] GO USE [DBA] GO ALTER ROLE [db_denydatareader] ADD MEMBER [superuser] GO USE [DBA] GO ALTER ROLE [db_denydatawriter] ADD MEMBER [superuser]