Before we dive deep into the security
topic, it’s important to first define some key concepts. To help in
this discussion, imagine the scenario where you want to access your
valuables that are in a safety deposit box. Safety deposit boxes, if
you’re not familiar, are metal boxes of different sizes that store
valuables and are located in a vault at a bank. They usually require a
key to open them. In addition, a bank will often ask for identification
before allowing you to get your box.
Authentication
The bank needs to make sure you are who you
claim you are. They do this by asking for identification, traditionally
a driver’s license. This action is called authentication. SQL
Server makes sure you are who you claim you are by asking for
credentials. You give SQL Server credentials in one of two ways. You
can give SQL Server a username and password combination. SQL Server
will take a hash of the password you supplied and compare it with a
hash of the password that is stored in its internal tables. If the two
hashes match for the given username, you are authenticated. This type
of authentication is known as SQL Server authentication.
The other way to authenticate to SQL Server is
through Windows authentication. With this type, you do not need to type
in a password; rather, since you are logged into Windows, SQL Server
asks Windows to verify your identity via your Windows security token.
Authentication Mode
In an ideal world, you would use only Windows
authentication. The main advantage with a pure Windows authentication
environment is a streamlined administration experience—you don’t have
to manage yet another set of credentials. To tell SQL Server what
authentication modes to support, there is a server property called
Server Authentication. It has one of two possible settings: Windows
Authentication and SQL Server and Windows Authentication mode (which is
also referred to as Mixed Mode). When SQL Server is in Windows
Authentication mode, users will not be able to log in using SQL Server
authentication. If Mixed Mode is selected, SQL Server will accept both
Windows-authenticated and SQL Server–authenticated logins. Since it is
easier to show examples using SQL Server–authenticated accounts than to
create a Windows user, this book’s examples will use SQL Server in SQL
Server and Windows Authentication mode. To see which authentication
mode your server is using, launch the Server Properties dialog box in
SSMS by selecting Properties from the context menu of a SQL Server
instance. Click the Security page within the Server Properties dialog
box to see the authentication mode setting, as shown in Figure 1.
Figure 1. Portion of the Server Properties dialog box showing the Security page
Authorization
Getting back to the safety deposit box example,
now that the bank has validated your identity using your driver’s
license, you are given the box. The box is locked with a key.
Possessing this key authorizes you to open the box. In SQL Server, just
because you have authenticated yourself and have a SQL Server login
account, you do not necessarily have access to items contained within
the server. The DBA has to explicitly authorize a user’s access to
objects within SQL Server. The DBA can grant access to one or more
objects to a group of users or to a single user. You will learn more
about granting permissions later in this chapter.
Server Instance vs. the Database
Databases within SQL Server are their own
unique entities. SQL Server databases are designed to be easily
detached from one server environment and reattached to another server
without any extra work being done by a DBA. This concept is slightly
different from what other database vendors implement, which is
typically to marry the database and server instance more closely. With
this independence come some additional security concepts to understand.
Databases have their own users called database users and their own roles called database roles.
You will learn more about database roles later in this chapter. To
authorize a SQL Server login access to a particular database, DBAs need
to create a database user within the requested database, which maps to a
SQL Server login. Database users are not shared among any databases on
the server instance, but a single SQL Server login can map to one or
more database users with each database user being in a different
database.
Note
In SQL Server 2012, database users can be directly provisioned within
the database without an associated SQL Server login. You can read more
about this concept in the “Contained Databases” section of this chapter.
In Figure 2, there is a single SQL Server login called Howard_Login. This login is mapped to two different database users. In the Sales database, Howard_Login is mapped to Howard_Sales_User. In the HR database, Howard_Login is mapped to Howard_HR_User.
Figure 2. Representation of server login and database users
Since databases are their own unique entities, the permissions defined for Howard_Sales_User and Howard_HR_User can be different. In Figure 2’s
scenario, Howard logs in to SQL Server just once. He then has access to
both the Sales and HR databases, with whatever permissions he has been
given on each of those.
