Module 2

Assigning Server and Database

Roles
Module Overview

Working with Server Roles

Working with Fixed Database Roles
User-Defined Database Roles
Lesson 1: Working with Server Roles

Server-Scoped Permissions
Typical Server-Scoped Permissions
Overview of Fixed Server Roles
Public Server Role
Working with User-Defined Server Roles
Demonstration: Assigning Fixed and User-Defined
Server Roles
Server-Scoped Permissions

Control access to server resources

Organized as a hierarchy
CONTROL SERVER at the top of the hierarchy
Granting a permission to a server principal implicitly
grants its child permissions
Can only be granted to server principals (not to
database principals)
Typical Server-Scoped Permissions

CONTROL SERVER
ADMINISTER BULK OPERATIONS
ALTER ANY DATABASE
CREATE ANY DATABASE
ALTER ANY LINKED SERVER
ALTER ANY LOGIN
ALTER SERVER STATE
VIEW SERVER STATE
ALTER SETTINGS
ALTER TRACE
Overview of Fixed Server Roles

sysadmin
serveradmin
securityadmin
processadmin
setupadmin
bulkadmin
diskadmin
dbcreator
public
Public Server Role

All logins are members of public; the public role

defines default permissions granted to all logins
By default, public has the permissions:
CONNECT
VIEW ANY DATABASE

Controlling access to server-level securables by

granting permissions to public is not best
practice
Working with User-Defined Server Roles

Managing User-Defined Roles

CREATE SERVER ROLE
DROP SERVER ROLE

Managing Permissions
GRANT, DENY and REVOKE

Managing Membership
ALTER SERVER ROLE
By default, members of user-defined server roles
cannot make other principals members of the role
Demonstration: Assigning Fixed and User-Defined
Server Roles

In this demonstration, you will see how to work

with:
Server-scoped permissions
Fixed server roles
User-defined server roles
Lesson 2: Working with Fixed Database Roles

Database-Scoped Permissions
Overview of Fixed Database Roles
Assigning Database Principals to Database Roles
Database Owner
Demonstration: Managing Database Roles and
Users
Database-Scoped Permissions

Control access to database resources

Organized as a hierarchy
CONTROL at the top of the hierarchy
CREATE DATABASE is independent of the hierarchy
Granting a permission to a database principal implicitly
grants it child permissions
Can only be explicitly granted to database
principals
Some server permissions implicitly grant
database permissions
Overview of Fixed Database Roles

Fixed roles common to all databases:

db_owner db_datawriter
db_securityadmin db_datareader
db_accessadmin db_denydatawriter
db_backupoperator db_denydatareader
db_ddladmin public

msdb has additional fixed roles for SSIS, Data Collection,

Mirroring, Policy-Based Management and server groups
In Azure SQL Database, master includes the
loginmanager and dbmanager fixed roles
Assigning Database Principals to Database Roles

Add and remove members from a role using the

ALTER ROLE statement
A role member may be a user or a user-defined
role
Fixed database roles cannot be members of
other roles
Membership of database roles can only be
assigned to database principals. Server principals
cannot be assigned membership of database
roles
Database Owner

dbo
The login that owns a database
Default schema dbo

db_owner
Fixed database role with administrative permissions for
a database
dbo is a member of db_owner
Demonstration: Managing Database Roles and
Users

In this demonstration, you will see how to work

with database roles and users.
Lesson 3: User-Defined Database Roles

Working with User-Defined Database Roles

Applying Roles in Common Scenarios
Demonstration: User-Defined Database Roles
Defining Application Roles
Demonstration: Application Roles
Working with User-Defined Database Roles

Managing User-Defined Roles

CREATE ROLE
DROP ROLE

Managing Permissions
GRANT, DENY and REVOKE

Managing Membership
ALTER ROLE
Applying Roles in Common Scenarios

Controlling access to database objects

Object level
Schema level
Database level

Controlling access to database-level actions

For example, SHOWPLAN

As an abstraction layer
When details of users are not knownfor example,
during development
Demonstration: User-Defined Database Roles

In this demonstration, you will see how to work

with user-defined database roles.
Defining Application Roles

Security context of the user is replaced by the

application role
Creating Application Roles
Use CREATE APPLICATION ROLE
Password must meet Windows password policy

Using Application Roles

Use sp_setapprole
Use a secure network connection to avoid leaking the
application role password
Exit application role by closing connection or using
sp_unsetapprole (requires stored cookie)
Limited to guest access to other databases
Demonstration: Application Roles

In this demonstration, you will see how to work

with application roles.
Lab: Assigning Server and Database Roles

Exercise 1: Assigning Server Roles

Exercise 2: Assigning Fixed Database Roles
Exercise 3: Assigning User-Defined Database Roles
Exercise 4: Verifying Security

Logon Information
Virtual machine: 20764B-MIA-SQL
User name: ADVENTUREWORKS\Student
Password: Pa$$w0rd

Estimated Time: 60 minutes

Lab Scenario

Adventure Works Cycles is a global manufacturer,

wholesaler, and retailer of cycle products.
Following an internal security audit, the company
aims to simplify the administration of database
security by making security controls more
consistent. You are a database administrator for
Adventure Works, tasked with implementing the
new security controls through server-level and
database-level roles.
Lab Review

In this lab, you have worked with different methods

to implement server-level and database-level roles,
including assigning group permissions and
managing group membership. You have also tested
the configuration of server-level and database-level
roles.
Module Review and Takeaways

In this module, you have learned how to implement

role-based security in a SQL Server Database Engine
instance.
When implementing role-based security in SQL Server,
consider the following best practices:
Use Windows group logins linked to roles to simplify
ongoing management where possible.
Aim to grant the minimum number of explicit
permissions possible to meet the security requirements,
and use membership of roles and inheritance to ensure
the correct effective permissions.
Ensure every database user has only the permission they
actually require.