Database Engine permissions are managed at the server level through logins and fixed server roles, and at the database level through database users and user-defined database roles.
Logins are individual user accounts for logging on to the SQL Server Database Engine. SQL Server supports logins based on Windows authentication and logins based on SQL Server authentication. For information about the two types of logins, see
Choosing an Authentication Mode
Fixed Server Roles
Fixed server roles are a set of preconfigured roles that provide convenient group of server-level permissions. Logins can be added to the roles using the sp_addsrvrolemember procedure.
Logins are granted access to a database by creating a database user in a database and mapping that database user to login. Typically the database user name is the same as the login name, though it does not have to be the same. Each database user maps to a single login. A login can be mapped to only one user in a database, but can be mapped as a database user in several different databases.
Fixed Database Roles
Fixed database roles are a set of preconfigured roles that provide convenient group of database-level permissions. Database users and user-defined database roles can be added to the fixed database roles using the sp_addrolemember procedure.
User-defined Database Roles
Users with the CREATE ROLE permission can create new user-defined database roles to represent groups of users with common permissions. Typically permissions are granted or denied to the entire role, simplifying permissions management and monitoring.
The following example represents a common and recommended method of configuring permissions.
In Active Directory:
In SQL Server:
Most permission statements have the format :
AUTHORIZATION PERMISSION ON SECURABLE::NAME TO PRINCIPAL
Sample grant statement: GRANT UPDATE ON OBJECT::Production.Parts TO PartsTeam
Permissions are granted to security principals (logins, users, and roles) by using the
statement. Permissions are explicitly denied by using the
command. A previously granted or denied permission is removed by using the
statement. Permissions are cumulative, with the user receiving all the permissions granted to the user, login, and any group memberships; however any permission denial overrides all grants.
A common mistake is to attempt to remove a
. This can cause problems when a user receives permissions from multiple sources; which is quite common. The following example demonstrates the principal.
permissions on the
table through the statement
GRANT SELECT ON OBJECT::OrderStatus TO Sales.
is a member of the
role. Ted has also been granted
permission to the
table under his own user name through the statement
GRANT SELECT ON OBJECT::OrderStatus TO Ted
. Presume the administer wishes to remove the
Permissions have a parent/child hierarchy. That is, if you grant
permission on a database, if includes
permission on all (child) schemas in the database. If you grant
permission on a schema, it includes
permission on all the (child) tables and views in the schema. The permissions are transitive; that is, if you grant
permission on a database, it includes
permission on all (child) schemas, and all (grandchild) tables, and all views.
Permissions also have covering permissions. The
permission on an object, normally gives you all other permissions on the object.
Because both the parent/child hierarchy and the covering hierarchy can act on the same permission, the permission system can get complicated. For example, let's take a table (
), in a schema (
), in a database (
permission on the
table can be achieved through any of these three statements:
Grant the Least Permissions
The first permission listed above (
GRANT SELECT ON OBJECT::Region TO Ted
) is the most granular, that is, that statement is the least permission possible that grants the
. No permissions to subordinate objects come with it. Always grant the least permission possible, but grant at higher levels in order to simplify the granting system. So if Ted needs permissions to the entire schema, grant
once at the schema level, instead of granting
at the table of view level many times. The design of the database has a great deal of impact on how successful this strategy can be. This strategy will work best when your database is designed so that objects needing identical permissions are included in a single schema.
List of Permissions
SQL Server 2008 R2 has 195 permissions. SQL Server Code-named 'Denali' has 214 permissions. The following graphic shows the permissions and their relationships to each other. Some of the higher level permissions (such as
) are listed many times.
Permissions vs. Fixed Server and Fixed Database Roles
The permissions of the fixed server roles and fixed database roles are similar but not exactly the same as the granular permissions. For example, members of the
fixed server role have all permissions on the instance of SQL Server, as do logins with the
permission. But granting the
permission does not make a login a member of the
fixed server role, and making adding a login to the
fixed server role does not explicitly grant the login the
permission. Sometimes a stored procedure will check permissions by checking the fixed role and not checking the granular permission. For example detaching a database requires membership in the
fixed database role. The equivalent
permission is not enough. These two systems operate in parallel but rarely interact with each other. Microsoft recommends using the newer, granular permission system instead of the fixed roles whenever possible.
The following views return security information.
The following statements return useful information about permissions.
To return the explicit permissions granted or denied in a database, execute the following statement in the database.
perms.state_desc AS State,
permission_name AS [Permission],
obj.name AS [on Object],
dPrinc.name AS [to User Name],
sPrinc.name AS [who is Login Name]
FROM sys.database_permissions AS perms
JOIN sys.database_principals AS dPrinc
ON perms.grantee_principal_id = dPrinc.principal_id
JOIN sys.objects AS obj
ON perms.major_id = obj.object_id
LEFT OUTER JOIN sys.server_principals AS sPrinc
ON dPrinc.sid = sPrinc.sid
To return the members of the server roles, execute the following statement.
SELECT sRole.name AS [Server Role Name] , sPrinc.name AS [Members]
FROM sys.server_role_members AS sRo
JOIN sys.server_principals AS sPrinc
ON sRo.member_principal_id = sPrinc.principal_id
JOIN sys.server_principals AS sRole
ON sRo.role_principal_id = sRole.principal_id;
To return the members of the database roles, execute the following statement in the database.
SELECT dRole.name AS [Database Role Name], dPrinc.name AS [Members]
FROM sys.database_role_members AS dRo
JOIN sys.database_principals AS dPrinc
ON dRo.member_principal_id = dPrinc.principal_id
JOIN sys.database_principals AS dRole
ON dRo.role_principal_id = dRole.principal_id;
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.