Now that you have been introduced to
the difference between a server instance and database with respect to a
database user, it is time to dive into more detail around the security
at the server instance level. A SQL Server login is also known as a principal, which is a generic term used to describe any entity that can request server resources.
Creating a SQL Server Login
To create a new SQL Server login from SQL
Server Management Studio (SSMS), navigate down the Object Explorer tree
to the Logins node, which is a child of the Security node. Right-click,
and select the New Login context menu item. This will launch the Login
– New dialog box, shown in Figure 1.
Figure 1. Login – New dialog box
The Login – New dialog box
allows you to create four different types of logins. They are as
follows: Windows authentication, SQL Server authentication, Mapped to
certificate, and Mapped to asymmetric key. If you wanted to create a
SQL Server login mapped to a Windows account, you select the “Windows
authentication” radio button and type the Windows user account in the
text box provided. This option does not require you to provide any
password for the user. If you wanted to create a SQL
Server–authenticated login, simply supply a login name and type a
password. When you select the SQL Server Authentication radio button,
you will notice three additional check boxes become available. “Enforce
password policy” tells SQL Server to honor any Active Directory group
policy configuration for passwords. “Enforce password expiration” tells
SQL Server to remind users to change old passwords and to lock out
expired logins. “Users must change password at next login” is
self-explanatory. SSMS has a nice dialog box that pops up for the user
if this option is selected and it’s the first time the user has logged
into SQL Server. The two other options, “Mapped to certificate” and
“Mapped to asymmetric key”, are used in advanced security scenarios
like signing stored procedures.
SQL Server provides the ability to securely
store credentials. These credentials are used for SQL Server Agent
proxy accounts or for use with a cryptographic provider. The Map to
Credential check box allows the DBA to add credentials that will be
available to a given login for use with these specific features. If you
are still wondering why you would ever want to store credentials to be
used by a SQL Server login, consider this scenario. When you connect to
SQL Server using SQL Server authentication, you have no identity to the
Windows OS. If you want this SQL Server login to do something on the
server that requires a Windows identity, using a credential solves the
problem.
The dialog box in Figure 1
contains four other pages that have additional options. Using these
other pages, you can add the login you are creating to server roles,
map the login to database users, and configure other settings.
If you click OK on the General page, the login will be created. The T-SQL statement that creates a login is CREATE LOGIN
. An example of creating the TestLo
.gin
login is as follows:
USE [master]
GO
CREATE LOGIN [TestLogin] WITH PASSWORD=N'PaSsWoRd!'
MUST_CHANGE, DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=ON, CHECK_POLICY=ON
GO
Server Roles
At the server instance level, there are nine fixed server roles that you can assign to a SQL Server login. Fixed
means that you, as a DBA, cannot create your own server roles; rather,
you have only the nine to choose from. In SQL Server 2012, database
administrators can create their own server level roles. Assigning a
principal to a server role allows that principal certain privileges
within the SQL Server instance. Table 1 describes the nine fixed server roles.
Before you start assigning logins to various
roles, it is important to know that, in reality, you probably will use
very few of these roles. The most popular is the sysadmin
role. The functionality of these roles has been superceded with the
introduction of server permissions. Server roles are still relevant to
learn and use, because in some cases, it is not possible to create a
SQL Server login with enough server permissions to mimic a server role.
To add a SQL Server login to a server role, you can use the Server Roles tab in the Login – New dialog box (shown earlier in Figure 1). To add roles to a SQL Server login using T-SQL, you can use the sp_addsrvrolemember
system stored procedure. For example, to give the dbcreator role to the Test,Login login, you can use the following script:
USE [master]
GO
EXEC sys.sp_addsrvrolemember @loginame = N'TestLogin', @rolename = N'sysadmin'
GO
Note It is not a best practice to arbitrarily give sysadmin
access to SQL Server logins. Being a sysadmin
is the highest elevated privilege within SQL Server, and its use should be highly discretionary.