Module 1

SQL Server Security

Module Overview

• Authenticating Connections to SQL Server

• Authorizing Logins to Connect to Databases
• Authorization Across Servers
• Partially Contained Databases
Lesson 1: Authenticating Connections to SQL
Server

• Overview of SQL Server Security

• SQL Server Authentication
• Azure SQL Database Firewall
• Managing Logins and Policies
• Demonstration: Authenticating Logins
Overview of SQL Server Security

• Securables
• Objects to which access must be secured
• Principals
• Security identities that access securables and perform actions
• Permissions
• The actions principals can perform on securables

Principal Permissions Securable

• Security Hierarchies:
• Securables can contain other securables
• Principals can contain other principals
• Permissions are inherited unless overridden
SQL Server Authentication

• Authentication is the process of verifying that an

identity is valid:
• Windows authentication—only principals authenticated
by Windows can connect
• SQL Server (mixed) authentication—principals
authenticated by Windows or SQL Server can connect
• Azure AD authentication—Azure principals are
managed in a single place
• Authentication Protocols—Kerberos
Managing Logins and Policies

• Logins:
• Create in SQL Server Management Studio (SMSS)
• Create using the CREATE LOGIN statement:
CREATE LOGIN [ADVENTUREWORKS\SalesReps]
FROM WINDOWS
WITH DEFAULT_DATABASE =[salesdb];

• Create and set security policy for SQL Server Logins:

CREATE LOGIN DanDrayton
WITH PASSWORD = 'Pa$$w0rd', CHECK_POLICY = ON,
DEFAULT_DATABASE = [salesdb];

• Disable logins:
ALTER LOGIN DanDrayton DISABLE;

• Delete logins:
DROP LOGIN DanDrayton;
Demonstration: Authenticating Logins

In this demonstration, you will see how to:

• Set the authentication mode
• Create logins
• Manage server-level roles
• Manage server-level permissions
Lesson 2: Authorizing Logins to Connect to
Databases

• Granting Access to Databases

• Managing dbo and guest Access
• Authorizing Logins and User Tokens
• Demonstration: Authorizing Logins and User
Tokens
Granting Access to Databases

• Logins cannot access a database to which they

have not been granted access
• Grant access to a login by creating a database
user for it using SSMS or Transact-SQL

CREATE USER SalesReps

FOR LOGIN [ADVENTUREWORKS\SalesReps];
WITH DEFAULT_SCHEMA = Sales;

CREATE USER DanDrayton Not the same

FOR LOGIN DanDrayton; as AD Schema

CREATE USER WebUser

FOR LOGIN [ADVENTUREWORKS\WebAppSvcAcct];
Schema

• A Schema is:
• A collection of database objects
• Associated with a particular username
• Username = Schema Owner
• A Schema can contain:
• A single table
• Multiple tables
• Lots of objects (no limit by default)

Table Name: category

Schema: user.category
Managing dbo and guest Access

• dbo (Database Owner) database user:

• Default schema in SQL Server
• sa (server administration) login, members of sysadmin
role, and owner of the database map to the dbo
account

• guest database user:

• Enables logins without user accounts to access a
database
• Disabled by default in user databases
• Enabled by using the GRANT CONNECT statement
 Authorizing Logins and User Tokens

• Security Token Service:

• Allows a single sign-on for multiple services and applications
• Login tokens
• Identify server-wide logins (server principles)
• Identifies and authorizes login tokens:
SELECT * FROM sys.login_token;
• User tokens
• Identify database objects (database principles)
• Users are recipients of database permissions
• Identifies and authorizes user tokens:
SELECT * FROM sys.user_token;
Demonstration: Authorizing Logins and User
Tokens

In this demonstration, you will see how to:

• Create a server role
• Create a login
• Alter server roles
• Create a user
• View the results
Lesson 3: Authorization Across Servers

• Linked Servers Security

• Typical "Double-Hop" Problem
• Impersonation vs. Delegation
• Working with Mismatched Security Identifiers
• Demonstration: Working with Mismatched
Security IDs
Linked Servers Security

• Authenticated access to external data sources

• Such as other SQL instances, Excel, Oracle, Access

• Link server objects:

• Provider - DLL managing connections to data source
• Data sources – Object you want to connect to

• Configuration:
• Client, server, database server tiers
• Definitions EXEC sp_addlinkedserver@server='RemoteServer',
@srvproduct='',
@provider='SQLOLEDB',
@datasrc='r:\datasource\RemoteServer';
Linked Server Security

• For linked server connections to work, you must:

• Create a login at the Data Source
• Logins should authenticate using Windows Authentication
• Some data sources don’t support this
EXEC sp_addlinkedsrv login 'RemoteServer’, ‘false’, ‘Domain\Username’,
‘RemoteUserName’, ‘Password’;

• Syntax above:
• ‘RemoteServer’ = Server you’re connecting to
• ‘false’ = Are you authenticating with the current login?
• ‘Domain\Username’ = If I have to explain this one…
• ‘RemoteUserName’ = Username on the other machine
• ‘Password’ = The password of the RemoteUserName
Typical "Double-Hop" Problem

Needs to issue • Win Authentication Login for S1 and S2

Client
query on Server2 • TCP/IP or Named Pipes
Application • Accounts cannot be delegated
(logged in as User1)

Hop1

• Domain: Requires SPN

• Delegation: On
Server S1
• TCP/IP or Named Pipes
• Linked: S2 must be registered on S1

Hop2

Query fails because

User1 Windows • Domain: Requires SPN
Server S2 • TCP/IP / Named Pipes
authentication fails
on S2
Impersonation vs. Delegation

• Delegation:
• Identity passed to remote servers

• Impersonation:
• Identity used within a domain
• Windows Authentication
• Service-For-User (S4U) – Used when clients are non-Windows
• LogonUser API – Access requested but no delegation trust
• Impersonate users and logins within a SQL Server
instance using EXECUTE AS
Working with Mismatched Security Identifiers

• Orphaned users created by mismatched SIDs

• Sometimes happens when moving SQL DB
• Security principles that existed locally on the SQL
Server do not exist on the new server
• Resolve using CREATE LOGIN … WITH SID…

CREATE LOGIN DomainName\Username with SID = <enter SID>;

• Use ALTER AUTHORIZATION to restore dbo

• Guest account not mapped to a login
• Consider Windows authenticated accounts
Demonstration: Working with Mismatched
Security IDs

In this demonstration, you will see how to:

• Test for orphaned users
• Fix broken logins
• Show that the logins have been corrected
Lesson 4: Partially Contained Databases

• Introduction to Partially Contained Databases

• Considerations for Using Partially Contained
Databases
• Demonstration: Creating a Partially Contained
Database
Introduction to Partially Contained Databases

• Contained databases do not have a hierarchical

dependency on server logins
• Use contained databases to:
• Move databases between different SQL Server
instances without having to migrate server-level
dependencies
• Develop databases when the developer does not know
which instance will ultimately host the database
• Enable failover in a high-availability scenario without
having to synchronize server-level logins
• Users in a contained database include:
• Users mapped to Windows accounts (users or groups)
• Users with passwords
Considerations for Using Partially Contained
Databases
• Benefits:
• Migration
• Failover, including Always On Group Availability
• Administration
• Development

• Considerations:
• Change Tracking, replication not allowed
• Password policy, CREATE USER does not
WHAT?
support bypassing the password policy
• Connection strings must be explicit
• Cross database queries
Lab: Authenticating Users

• Exercise 1: Create Logins

• Exercise 2: Create Database Users
• Exercise 3: Correct Application Login Issues
• Exercise 4: Configure Security for Restored
Databases

Logon Information
Virtual machine: 20764C-MIA-SQL
User name: ADVENTUREWORKS\Student
Password: Pa55w.rd

Estimated Time: 60 minutes