Course Topics Administering SQL Server 2012 Jump Start 01 | Install and Configure SQL Server04 | Manage Data 02 | Maintain Instances and Databases05 | Implement Security 03 | Performance Optimization and Troubleshooting 06 | High Availability Options

05 | Security Implementation George Squillace | Senior Technical Trainer – New Horizons Great Lakes Richard Currey | Senior Technical Trainer – New Horizons United

Module 5 Overview Server Logins and Server-level Roles Database Users and Database-level Roles Implementing Permissions

Topic: Server Logins and Server- level Roles

Security Scopes Authentication Modes Login Objects Server Roles and Server-level Permissions

Security Scopes Server / instance –Database Schema –Object Scope-specific permissions exist Permission statements –GRANT –REVOKE –DENY

Authentication Modes Two modes SQL logins are protected better by using password policies Set during installation and they can be changed later Switching requires a service restart Functionally only a registry key change

Login Objects Purpose Derived from –Windows Domain Machine local –SQL logins Administration tools –SSMS –CREATE / ALTER / DROP LOGIN –Options

Server Roles and Server-level Permissions Types of server-level roles –Fixed server roles –User-defined server roles Server-scoped permissions Administration tools –SSMS –sp_AddSrvRoleMember –CREATE / ALTER / DROP SERVER ROLE

DEMO Implementing Server-level Security

Topic: Database Users and Database-level Roles

Database Users Database-level Roles Application Roles Contained Databases

Database Users Database users –Derived from logins Types of database-level roles –Fixed –User defined Application roles Database-scoped permissions

Database-level Roles Types of database-level roles –Fixed –User defined Database-scoped permissions Administration tools –SSMS –CREATE / ALTER / DROP ROLE –sp_AddRoleMember

Application Roles The purpose of an Application Role is to protect against making connections to SQL Server outside of front-end application logic (using Excel or Access, for example) Instead an application calls an Application Role that the end-user is unaware of (and that is assigned database permissions) Administration tools –SSMS –CREATE / ALTER / DROP ROLE –sp_AddRoleMember –sp_SetAppRole and sp_UnSetAppRole

DEMO Implementing Database-level Security

Contained Databases A problem with moving and restoring databases is that they have dependencies on login and other objects A possible solution is a contained database Requires a server-level and database-level option –sp_Configure N’Contained Database Authentication’ –ALTER DATABASE DBx Set Containment = Partial Applicable principals –Windows user –Windows group –SQL login

DEMO Creating Users for a Specific Database (Contained Database)

Topic: Implementing Permissions

Object Permissions Code and Module Permissions Applying Permissions Permission Management Strategies “ Principals are assigned Permissions to Securables.”

Object Permissions Applies to tables, views and table-valued user-defined functions Primary permissions –ALTER –CONTROL –SELECT, INSERT, UPDATE, DELETE –VIEW DEFINITION

Code and Module Permissions Applies to scalar user-defined functions and stored procedures Primary permissions –ALTER –CONTROL –EXECUTE –VIEW DEFINITION

Applying Permissions SSMS –Begin with a principal –Begin with a securable T-SQL statements –GRANT –REVOKE –DENY Security model anomaly (prior to SQL Server 2012) –Column-level GRANT override Table-level DENY

Permission Management Strategies Various strategies –Aim for “double abstraction” Leverage roles –Roles can be nested Leverage schemas

DEMO Implementing a Permission Strategy by Assigning a Role Permission to a Schema

©2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Office, Azure, System Center, Dynamics and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.