Microsoft SQL Server 2008 R2 Unleashed- P35 ppt

Logins Every principal granted security to SQL Server must have an associated login.. The login provides access to SQL Server and can be associated with principals scoped at the Windows

Some complexity has been introduced, based on the hierarchical nature of some of the

security components Security can be established on these hierarchical components, which

in turn cascades the security to the underlying components In addition, not all the

permission components apply to every securable Many of the securables have a select

number of permissions that apply to them; conversely, many permissions apply only to a

select number of securables For example, SELECT permission is applicable to securables

such as tables and views but would not be appropriate for stored procedures

The following sections discuss the tiers of the security model and their underlying

components

Authentication Methods

The first level of security encountered when accessing SQL Server is known as

authentication The authentication process performs the validation needed to allow a user

or client machine to connect to SQL Server This connection can be granted via a

Windows login or SQL Server login

Windows Authentication Mode

Windows Authentication mode validates the account name and password, using

informa-tion stored in the Windows operating system A Windows account or group must be

estab-lished first, and then security can be estabestab-lished for that account in SQL Server This mode

has the advantage of providing a single login account and the capability to leverage

domain security features, such as password length and expiration, account locking,

encryption, and auditing Microsoft recommends this approach

Mixed Authentication Mode

Mixed authentication allows for both Windows authentication and SQL Server

authentica-tion SQL Server authentication is based on a login that is created in SQL Server and lives

in SQL Server only No Windows account is involved with SQL Server authentication The

account and password are established and maintained in SQL Server SQL Server logins

can be created with stronger password enforcement that help better protect the login

This topic is discussed in more detail in the section “Managing SQL Server Logins,” later

in this chapter

SQL Server authentication is useful in environments in which a Windows domain

controller does not control network access It can also be useful for Web applications or

legacy applications, where it may be cumbersome to establish a Windows user account for

every connection to the database server

Setting the Authentication Mode

You can select the authentication mode when you install SQL Server, and you can change

it after the installation To change the authentication mode after installation, you

right-click the server node in the Object Explorer and choose the Properties option When the

Server Properties dialog appears, you select the Security page (see Figure 11.1) The

Security page allows you to specify Windows Authentication mode or SQL Server and

Windows Authentication mode (that is, mixed authentication) Any changes to the

authentication mode require a restart of SQL Server to make the change effective

FIGURE 11.1 Changing the authentication mode

Managing Principals

Principals are the entities that can request permission to SQL Server resources They are

made up of groups, individuals, or processes Each principal has its own unique identifier

on the server and is scoped at the Windows, server, or database level The principals at

the Windows level are Windows users or groups The principals at the SQL Server level

include SQL Server logins and server roles The principals scoped at the database level

include database users, data roles, and application roles

Logins

Every principal granted security to SQL Server must have an associated login The login

provides access to SQL Server and can be associated with principals scoped at the

Windows and server levels These logins can be associated with Windows accounts,

Windows groups, or SQL Server logins

Logins are stored in the master database and can be granted permission to resources

scoped at the server level Logins provide the initial permission needed to access a SQL

Server instance and allow you to grant access to the related databases Permissions to

specific database resources must be granted via a database user The important point to

remember is that logins and users are directly related to each other but are different

enti-ties It is possible to create a new login without creating an associated database user, but a

new database user must have an associated login

To better understand logins, you can look at the sys.server_principals catalog view

This view contains a row for every server-level principal, including each server login The

following example selects from this view and displays the results:

select left(name,25) name, type, type_desc

from sys.server_principals AS log

WHERE (log.type in (‘U’, ‘G’, ‘S’, ‘R’))

order by 3,1

/*Results from previous query

name type type_desc

-

-bulkadmin R SERVER_ROLE

dbcreator R SERVER_ROLE

diskadmin R SERVER_ROLE

processadmin R SERVER_ROLE

public R SERVER_ROLE

securityadmin R SERVER_ROLE

serveradmin R SERVER_ROLE

setupadmin R SERVER_ROLE

sysadmin R SERVER_ROLE

sa S SQL_LOGIN

DBSVRXP\LocalUser1 U WINDOWS_LOGIN

HOME\Administrator U WINDOWS_LOGIN

NT AUTHORITY\SYSTEM U WINDOWS_LOGIN

*/

The results from the sys.server_principals selection include the name of the server

principal as well as the type of principal The rows that have a type_desc value of

SQL_LOGIN, WINDOWS_GROUP, or WINDOWS_LOGIN are all logins established on the SQL Server

instance A login with a type_desc of SQL_LOGIN represents a login created with SQL

Server authentication Logins with a type_desc of WINDOWS_GROUP or WINDOWS_LOGIN are

Windows groups or individual Windows users granted logins to SQL Server The other

entries with type_desc of SERVER_ROLE are fixed server roles discussed later in this chapter

The logins established for Windows logins or groups can be part of the local domain of

the SQL Server machine, or they can be part of another domain In the previous example,

DBSVRXP\LocalUser1 is a login established for a local user on a database server named

DBSVRXP The HOME\Administrator login is also a Windows login, but it is part of a

network domain named HOME Both logins are preceded by the domain that they are part

of and are displayed this way in SQL Server

NOTE

In SQL Server 2000, logins were stored in the syslogins system table in the master

database The syslogins table is still available for selection as a view, but it is

available only for backward compatibility The catalog views (including

sys.server_principals) are recommended for use instead

You might have noticed in the earlier sys.server_principals output that two other

logins are listed that we have not discussed yet These logins (SA and NT

AUTHORITY\SYSTEM) are system accounts installed by default at installation time

Each of these accounts serves a special purpose in SQL Server

The SA account is a SQL_LOGIN assigned to the sysadmin fixed server role The SA account

and members of the sysadmin fixed server role have permission to perform any activity

within SQL Server The SA account cannot be removed, and it can always be used to gain

access to SQL Server The SA account should always have a strong password to prevent

malicious attacks, and it should be used only by database administrators Users or logins

requiring full administrative privileges can be assigned a separate SQL Server login that is

assigned to the sysadmin fixed server role This improves the audit trail and limits the

amount of use on the SA account

The NT AUTHORITY\SYSTEM login is an account related to the local system account under

which SQL Server services can run It is also added as a member of the sysadmin fixed

server role and has full administrative privileges in SQL Server This account can also be

removed if the SQL Server services are not running with the local system account This

should be done with caution, however, because it can affect applications such as

Reporting Services

One other special account was not listed, but it would have been in SQL Server 2005 The

BUILTIN\Administrators login is a Windows group that corresponds to the local

adminis-trators group for the machine that SQL Server is running on The BUILTIN\Administrators

group is no longer added by default as a SQL Server login during installation In SQL

Server 2005, it was also added as a member of the sysadmin fixed server role, but this is no

longer the case This change improves the security of SQL Server out of the box by

limit-ing the number of people that have access (by default) to the SQL Server instance

NOTE

The BUILTIN\Administrators group can be manually added in SQL Server 2008 if

desired This allows domain administrators and anyone else who has been added to

the local administrators group to have sysadmin privileges Adding this group is not

recommended but can be done if you want to set network privileges that are similar to

past versions of SQL Server

SQL Server Security: Users

Database users are principals scoped at the database level Database users establish a link

between logins (which are stored at the server level) and users (which are stored at the

database level) Database users are required to use the database and are also required to

access any object stored in the database

Generally, the login name and database username are the same, but this is not a

require-ment If desired, you could add a login named Chris and assign it to a user named Kayla

This type of naming convention would obviously cause some confusion and is not

recom-mended, but SQL Server has the flexibility to allow you to do it In addition, a user can be

associated with a single person or a group of people This capability is tied to the fact that

a login can be related to a single account or group For example, a login named training

could be created and tied to a Windows group (that is, domain\training) that contains all

the training personnel This login could then be tied to a single database user That single

database user would control database access for all the users in the Windows group

TIP

The relationship between logins and users can be broken when databases are moved

or copied between servers The reason is that a database user contains a reference to

the associated login Logins are referenced based on a unique identifier called a

secu-rity identifier (SID) When a database is copied from one server to another, the users in

that database contain references to logins that may not exist on the destination server

or that may have different SIDs

You can use the sp_change_users_login system stored procedure to identify and fix

these situations You can run the following command against a newly restored or

attached database to check for orphaned users:

EXEC sp_change_users_login ‘Report’

If orphaned users are shown in the results, you can rerun the procedure and fix the

problems For example, if the results indicate that a user named Chris is orphaned,

you can run the following command to add a new login named Chris and tie the

orphaned database user to this newly created login:

EXEC sp_change_users_login ‘Auto_Fix’, ‘Chris’, NULL, ‘pw’

Refer to SQL Server Books Online for full documentation on the

sp_change_users_login system stored procedure

You can use the sys.database_principals catalog view to list all the users in a given

data-base The following example shows a SELECT statement using this view and the results

from the SELECT:

SELECT

left(u.name,25) AS [Name],

type,

left(type_desc,15) as type_desc

FROM

sys.database_principals AS u

WHERE

(u.type in (‘U’, ‘S’, ‘G’))

ORDER BY 1

/*Results from previous query

Name type type_desc

-

-dbo S SQL_USER

DBSVRXP\LocalUser1 U WINDOWS_USER

guest S SQL_USER

INFORMATION_SCHEMA S SQL_USER

sys S SQL_USER

*/

The SELECT statement in this example returns five rows (that is, five users) This SELECT

was run against the AdventureWorks2008 database, and the only user explicitly added to

the database was the Windows user DBSVRXP\LocalUser1 The other users are special users

who are added by default to each database These users do not have corresponding server

logins named the same These users are discussed in the following sections

The dbo user is the database owner and cannot be deleted from the database Members of

the sysadmin server role are mapped to the dbo user in each database, which allows them

to administer all databases Objects owned by dbo that are part of the dbo schema can be

referenced by the object name alone When an object is referenced without a schema

name, SQL Server first looks for the object in the default schema for the user that is

connected If the object is not in the user’s default schema, the object is retrieved from the

dbo schema Users can have a default schema that is set to dbo

Schemas and their relationship to users are discussed in more detail in the section

“User/Schema Separation,” later in this chapter

The guest user is created by default in each database when the database is created This

account allows users that do not have a user account in the database to access the

data-base By default, the guest user does not have permission to connect to the database To

allow logins without a specific user account to connect to the database, you need to grant

CONNECT permission to the guest account You can run the following command in the

target database to grant the CONNECT permission:

GRANT CONNECT TO GUEST

When the guest account is granted CONNECT permission, any login can use the database

This opens a possible security hole The default permissions for the guest account are

limited by design You can change the permissions for the guest account, and all logins

that use it will be granted those permissions Generally, you should create new database

users and grant permissions to these users instead of using the guest account

If you want to lock down the guest account, you can You cannot drop the guest user,

but you can disable it by revoking its CONNECT permission The following example

demon-strates how to revoke the CONNECT permission for the guest user:

REVOKE CONNECT FROM guest

If you decide to grant additional access to the guest account, you should do so with

caution The guest account can be used as a means for attacking your database

The INFORMATION_SCHEMA user owns all the information schema views installed in each

database These views provide an internal view of the SQL Server metadata that is

inde-pendent of the underlying system tables Some examples of these views include

INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.CHECK_CONSTRAINTS The

INFORMATION_SCHEMA user cannot be dropped from the database

The sys account gives users access to system objects such as system tables, system views,

extended stored procedures, and other objects that are part of the system catalog The sys

user owns these objects Like the INFORMATION_SCHEMA user, it cannot be dropped from the

database

TIP

If you are interested in viewing the specific objects owned by any of the special users

discussed in these sections, you can use a SELECT statement like the following:

Find all objects owned by a given user

SELECT name, object_id, schema_id, type_desc

FROM sys.all_objects

WHERE OBJECTPROPERTYEX(object_id, N’OwnerId’) = USER_ID(N’sys’)

ORDER BY 1

The SELECT in this example shows all the objects owned by the sys user To change

the user, you simply change the parameter of the USER_ID function in the SELECT

statement from ’sys’ to whatever user you want

User/Schema Separation

The changes to schema security introduced in SQL Server 2005 have been carried forward

to SQL Server 2008 Versions of SQL Server before SQL Server 2005 had schemas, but they

did not conform to the American National Standards Institute (ANSI) definition of

schemas ANSI defines a schema as a collection of database objects that one user owns and

that forms a single namespace A single namespace is one in which each object name is

unique and there are no duplicates So, for example, if you have two tables named

customer, they cannot exist in the same namespace

To fully understand the user/schema changes in SQL Server 2008, you need to understand

how schemas were used in prior versions of SQL Server In SQL Server 7.0 and 2000, a

default schema was created for each user, and it had the same name as the user For

example, if you created a new user named Rachael, a corresponding schema named

Rachael would be created as well There was no option in those releases to change the

default schema for a user, and each user was forever bound to a schema with the same

name When the user created new objects, the objects were created by default in that

user’s schema, which is always the name of the user So, if Rachael created an object

named customer, it was placed in the Rachael schema, and the object was owned by

Rachael When Rachael wanted to reference the object, she could use a three-part name

with the format database.owner.object If a linked server was used, according to the SQL

Server 2000 documentation, the object in the linked server could be referenced with the

four-part name linked_server.catalog.schema.object (for example

myserver.AdventureWorks2008.Rachael.Customer) You can see that the schema name is

used prior to the object name when the object is outside the local server The bottom line

is that the schema and owner were basically the same thing in SQL Server 7.0 and 2000

With SQL Server 2005 and SQL Server 2008, the owner and schema have been separated

This is made possible in part by allowing a database user to have a default schema

differ-ent from the name of the user For example, our sample user Rachael could be assigned

the default schema Sales When Rachael creates objects in the database, her objects are

created, by default, in the Sales schema If Rachael wants to reference an object that she

created, she can reference the table in a number of different ways She can use the full

four-part name (server.database.schema.object ) that includes the Sales schema name to

reference the object via a linked server She can simply refer to the object with the object

name alone, and the Sales schema will be searched first for the object She can also use a

three-part name or a two part name If the object name is not found in the Sales schema,

the dbo schema will be searched This concept is illustrated in the following sample

SELECT statements that all retrieve the same rows from the Region table that was created

by Rachael in the Adventureworks2008 database

select * from region

select * from sales.region

select * from AdventureWorks2008.Sales.Region

The important point to remember is that owners and schemas are different from one

another in SQL Server 2008 For example, you can have a customer table created in the

Sales schema, and that table can be owned by a user named Chris The object should be

referenced with the schema name qualifier, such as Sales.Customer, not Chris.Customer

This has the distinct advantage of allowing object ownership to change without affecting

the code that references the object The reason is that database code that references an

object uses the schema name instead of the object owner

The schema enhancements in SQL Server 2008 go well beyond the user/schema

separa-tion Schemas are an integral part of all the database objects that exist in SQL Server As

we delve into more details about SQL Server security and the assignment of permissions,

you will see that schemas play a very important part

Roles

Roles provide a consistent yet flexible model for security administration Roles are

similar to the groups used in administering networks Permissions are applied to a role,

and then members are added to the role Any member of the role has all the permissions

that the role has

The use of roles simplifies the administrative work related to security Roles can be

created based on job function, application, or any other logical group of users With

roles, you do not have to apply security to each individual user Any required changes to

permissions for the role can be made to the role security, and the members of the role

receive those changes

SQL Server has the following three types of roles:

have a predefined set of permissions

permissions for each set of users assigned to it

an application

These roles are discussed in the following sections

Fixed Server Roles

Fixed server roles are scoped at the server level, which means that the permissions for

these roles are oriented toward server-level securables These roles contain a variety of

fixed permissions geared toward common administrative tasks Logins (not users) are

assigned to these roles

The same fixed server roles available in SQL Server 2000 and SQL Server 2005 are also

available in SQL Server 2008 There is, however, one new role named public that has been

added Server principals, by default, are granted the permissions that have been granted to

the public role There are a limited number of permissions that are initially granted to the

public role, but you can change the permissions if you like A complete list of all the

fixed server roles and their related permissions is shown in Table 11.2

A single login can be assigned to one or more of these fixed server roles When multiple

roles are assigned, the combination of all the permissions is allocated to the login

TABLE 11.2 Fixed Server Roles

Role Permission

bulkadmin Allowed to run the BULK INSERT statement

dbcreator Allowed to use CREATE, ALTER, DROP, and RESTORE on any database

diskadmin Allowed to manage disk files that are used by SQL Server

processadmin Allowed to terminate SQL Server processes

public Assigned to all logins Permissions granted to this role are assigned to every

login by default

securityadmin Allowed to use GRANT, DENY, and REVOKE permissions for logins at the server

and database levels Members of this role can reset passwords for SQL Server logins

serveradmin Allowed to change server-wide configuration properties and shut down the

server, if needed

setupadmin Allowed to add and remove linked servers and execute some system stored

procedures

sysadmin Allowed to perform any activity in the server