SQL Server provides a number of settings for controlling access to data, metadata, and other SQL Server resources. For those who are new to SQL Server security or don’t manage security routinely, configuring these settings can seem a complex and confusing process. If you get the settings right, everybody is happy, but if you get them wrong, your users might not be able to access the data they need or, worse still, unauthorized users might be able to get at sensitive information or carry out malicious attacks.
To effectively protect SQL Server, you must be able to provide approved users with the access they need to specific SQL Server resources, without compromising those or other resources, a process that involves the use of three important types of components:
Principals: Entities that can be authenticated to access the SQL Server resources. For example, your windows login can be configured as a principal that allows you to connect to a SQL Server database. SQL Server supports three types of principals: logins, users, and roles. Logins exist at the server level, users exist at the database level, and roles can exist at either level. Securables: SQL Server resources that can be accessed by a principal. Securables are the actual resources you’re trying to protect, whether at the server level (e.g., availability groups), database level (e.g., full-text catalog), or the schema level (e.g., table or function). Permissions: Types of access granted on a securable to a specific principal. For example, you can grant a Windows login (the principal) the ability to view data (the permission) in a specific database schema (the securable).Together, these three types of components can help you protect a SQL Server environment and its data at every level, from the availability groups down to the individual database objects. Generally, the process used for providing access to SQL Server resources is to create the principals you need and then configure them with the necessary permissions to access specific securables.
Server login principalsLogins provide a mechanism for users to connect to the SQL Server platform at the server level. A login serves as a user’s initial entry point into the system. Generally, your first step in providing access for your users is to set up the necessary logins so they can make the initial connections to the server. The database engine supports two types of logins: Windows and SQL Server.
A Windows login can be based on a Windows domain account―either an individual user account or a group account―or on a Windows local account. If based on a group account, any permissions granted to that login apply to all members of the group, which can be a handy approach to configuring security for multiple users who require the same level of access.
To create a login, you can use SQL Server Management Studio (SSMS) or use the CREATE LOGIN T-SQL statement. For example, the following statement creates a login based for a local Windows user account ( WinUser1 ) on the srv01b Windows computer:
CREATE LOGIN [srv01b\WinUser1] FROM WINDOWS;The FROM WINDOWS clause indicates that the login should be mapped to a Windows account. In this case, we’ve specified the computer name and account name for a local user, but we could have instead specified a domain user, following the same format, as in WinDomain1\WinUsr1 . The CREATE LOGIN statement supports more options of course, depending on the type of user account being specified, but overall the statement is fairly straightforward. You’re merely creating an object that exists at the server level to provide access to the SQL Server environment.
If you’re SQL Server installation is configured to run in mixed mode―that is, it supports both Windows and SQL Server authentication methods―you can also create SQL Server logins, which are specific to a SQL Server instance and not tied to Windows accounts in any way. Although Windows logins are generally the recommended approach, you might need to support SQL Server logins in specific situations, such as providing access to users who are not tied to a Windows domain. The built-in sa account, the bane of many in IT, is a type of SQL Server login.
When users try to connect to SQL Server, the database engine validates their logins against the master database. This allows them to connect to the SQL Server instance, although they won’t have the permissions necessary to do much else. In fact, to be able to access database resources, the login must be tied to a specific database user principal, which is then granted the permissions necessary to access the database objects.
Database user principalsA login’s scope applies to the database engine as a whole, but it does not provide access to the individual database components. For the users associated with those logins to be able to access database resources, you must create users within the target databases and map those principals back to the server logins. You can create a database user with the same name as its associated login or with a different name. You can also map a login to users in multiple databases; however, a login can be mapped to only one user within a database at any given time.
As with server-level logins, you can use SSMS or T-SQL to create a database user, but you must do so within the context of the specific database. For example, we can create a database user named DbUser1 within the AdventureWorks2014 database, based on the srv01b\WinUser1 login
USE AdventureWorks2014; GO CREATE USER DbUser1 FOR LOGIN [srv01b\WinUser1];The FOR LOGIN clause provides the necessary mapping back to the server login. We could have created the user with the same name as the login, but I used a different name here to demonstrate how easy it is to choose whatever name you like, as long as it is unique within the database. This approach also allows us to simplify the qualified name being used for the login.
As you can see, creating a database user that maps back to a server login is a fairly straightforward process. The two principals work in conjunction with each other to enable a user to access the server and database, assuming the necessary permissions have also been configured for that user.
Note that you can also create database users that do not map back to a server login. In other words, you can create users without creating logins. These types of users are generally used for contained databases that can be easily moved between SQL Server instances. For this reason, a database’s containment feature must be enabled before you can create these types of users.
Server and database rolesAfter you create a login or user principal, you can configure permissions on either one to control access at the server or database level. Before you do that, however, consider that SQL Server also supports a third type of principal, referred to as a role . A role can exist at either the server or database level and can help manage user access to securables more efficiently.
You can think of a role as a type of container for holding one or more logins, users, or other roles, similar to how a Windows group can hold multiple individual and group accounts. This can make managing multiple principals easier when those principals require the same type of access to SQL Server. You can configure each role with permissions to specific resources, adding or removing logins and users from these