Microsoft SQL Server 2008 R2 Unleashed- P36 docx

ptg
304
CHAPTER 11 Security and User Administration
NOTE
Keep in mind that when a login is assigned to certain fixed server roles, they have
implied permissions that cascade to the database level. For example, if a login is
assigned to the sysadmin role, that login can perform any activity on the server, and it
can also perform any action on any database on that server. Similarly, if a login is
added to the securityadmin role, the login can change permissions at the database
level as well as the server level.
All the fixed server roles are listed in the SQL Server Management Studio (SSMS) Object
Explorer. Figure 11.2 shows the Object Explorer with the Server Roles node expanded.
You can right-click any of the roles and select Properties to display the logins that are
currently members of the role.
Fixed Database Roles
SQL Server provides fixed roles that define a common set of permissions at the database
level. These fixed database roles are assigned to database users. The permissions defined
for the fixed database roles cannot be changed. Table 11.3 shows the fixed database roles
and their permissions.
FIGURE 11.2 Fixed server roles in Object Explorer.
Download from www.wowebook.com
ptg
305
Managing Principals
11
TABLE 11.3 Fixed Database Roles
Role Permission
db_accessadmin
Allowed to add or remove database access for logins.
db_backupoperator
Allowed to back up the database.

db_datareader
Allowed to read all user table data.
db_datawriter
Allowed to change the data in all user tables.
db_ddladmin
Allowed to run any Data Definition Language (DDL) command against the
database. This includes commands to create, alter, and drop database
objects.
db_denydatareader
Denied the right to read all user table data.
db_denydatawriter
Denied the right to change the data in any of the user tables.
db_owner
Allowed to perform any action on the database. Members of the
sysadmin fixed server role are mapped to this database role.
db_securityadmin
Allowed to manage permissions for database users, including member-
ship in roles.
dbm_monitor
Allowed to view the most recent status in the Database Mirroring
Monitor.
NOTE
You can find a more granular b reakdown of perm issions associated with f ixed da tabase
roles in the SQL Server Books Online documentation. Look for the subject
“Permissions of Fixed Database Roles.” The extensive table in this documentation
defines the specific permissions for each role. For example, the table shows that the
db_backupoperator role is granted the BACKUP DATABASE, BACKUP LOG, and
CHECKPOINT permissions. This gives you more insight into what the members of this
role can do. Some fixed database roles have a large number of permission defined for
them, such as db_ddladmin, which has more than 30 individual permissions. The

types of permissions and improved granularity available with SQL Server 2008 are dis-
cussed in the “Managing Permissions” section, later in this chapter.
You can also find a list of fixed database roles in the Object Explorer. Figure 11.3 shows
the fixed database roles for the AdventureWorks2008 database. The roles are found under
the Security node within each database. You can right-click a fixed database role and
select Properties to view the member users.
Download from www.wowebook.com
ptg
306
CHAPTER 11 Security and User Administration
FIGURE 11.3 The fixed database roles in Object Explorer.
Fixed database roles and schemas are related. Figure 11.3 shows the expanded Schemas
node for the AdventureWorks2008 database. You can see that there is a corresponding
schema for each of the fixed database roles. These schemas are automatically created, and
each is owned by the related database role.
The public Role
The public role is a special database role that is like a fixed database role except that its
permissions are not fixed. The permissions for this role can be altered. Every user in a
database is automatically made a member of the public role and in turn receives any
permissions that have been granted to the public role. Database users cannot be removed
from the public role.
The public role is similar in function to the guest user that is installed by default in each
database. The difference is that the permissions granted to the guest user are used by any
login that does not have a user account in the database. In this case, the login is allowed
to enter the database via the guest account. In the case of the public role, the login has
been added as a user of the database and in turn picks up any permissions that have been
granted to the public role.
To view the permissions associated with the public role, you can use a SELECT statement
like the following:
SELECT top 5 g.name,

object_name(major_id) as ‘Object’,
Download from www.wowebook.com
ptg
307
Managing Principals
11
permission_name
from sys.database_permissions p
join sys.database_principals g
on p.grantee_principal_id = g.principal_id
and g.name = ‘public’
order by 1,2
/*Results from the previous select
name Object permission_name

public all_columns SELECT
public all_objects SELECT
public all_parameters SELECT
public all_sql_modules SELECT
public all_views SELECT
*/
This SELECT utilizes two catalog views that contain security information. The SELECT
returns only the first five permissions for the public role, but the TOP clause can be
removed to return all the permissions.
User-Defined Roles
SQL Server enables you to create your own custom database roles. Like the fixed roles,
user-defined roles can be used to provide a common set of permissions to a group of users.
The key benefit behind using user-defined roles is that you can define your own set of
custom permissions that fit your needs. User-defined roles can have a broad range of
permissions, including the more granular set of permissions made available with SQL

Server 2008.
To demonstrate the power of a user-defined database role, let’s look at a simple example.
Let’s say that you have a group of users who need to read all the tables in a database but
should be granted access to update only one table. If you look to the fixed database roles,
you have the
db_datareader and db_datawriter roles, which give you a partial solution.
You can use the db_datareader role to allow the read capability you need, but the
db_datawriter role gives write permission to all the tables—not just one.
One possible solution would be to give every user in the group membership to the
db_datareader group and assign the specific UPDATE permission to each user as well. If the
group contains hundreds of users, you can see that this would be rather tedious. Another
solution might be to create a Windows group that contains every user who needs the
permissions. You can then assign a login and database user to this group and grant the
appropriate permissions. The Windows group is a viable solution but can sometimes be
difficult to implement in a complex Windows domain.
Another approach to this challenge is to use a user-defined database role. You can create
the role in the database that contains the tables in question. After you create the role,
you can include it in the db_datareader role, and you can establish the UPDATE permis-
sion to the single table. Finally, you can assign the individual users or group of users to
Download from www.wowebook.com
ptg
308
CHAPTER 11 Security and User Administration
the role. Any future permission changes for this set of users can be administered through
the user-defined database role. The script in Listing 11.1 steps through a process that
demonstrates and tests the addition of a database role. This is similar to the example we
just walked through. Parts of the script need to be run by an administrator, and other
parts should be run in a query editor window that is connected to the database with the
newly created testuser.
LISTING 11.1 An Example of User-Defined Database Roles

The following statements must be run by an administrator to add
a login and database user with no explicit permissions granted
CREATE LOGIN [TestUser] WITH PASSWORD=N’pw’,
DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
GO
USE [AdventureWorks2008]
GO
CREATE USER [TestUser] FOR LOGIN [TestUser]
go
the following statement fails when executed by the TestUser
which has no explicit permissions defined in the AdventureWorks2008 database
select top 5 * from person.person
UPDATE person.person SET suffix = ‘Jr.’
WHERE FirstName = ‘Ken’
The following statement is run by an administrator to:
1)add a new TestDbRole with permission to UPDATE
2)grant UPDATE permission on the Person.person table
3)add the TestUser to the TestDbRole database role
USE [AdventureWorks2008]
GO
1)
CREATE ROLE [TestDbRole] AUTHORIZATION [dbo]
2)
GRANT UPDATE ON [Person].[Person] TO [TestDbRole]
GRANT SELECT ON [Person].[Person] TO [TestDbRole]
3)
EXEC sp_addrolemember N’TestDbRole’, N’TestUser’
the following statements now succeed when executed
by the TestUser because the role that it

was added to has SELECT and UPDATE permission
on that table
select top 5 * from person.person
UPDATE person.person SET suffix = ‘Jr.’
WHERE ContactID = 1
Download from www.wowebook.com
ptg
309
Managing Securables
11
the following select fails because ‘testdbrole’
does not permit SELECT on any table but person.person
select * from person.ContactType
The following statement is run by an administrator
to add the TestDbRole database role to the db_datareader
fixed-database role
EXEC sp_addrolemember N’db_datareader’, N’TestDbRole’
GO
Finally, the testuser can update the Person.person table
and select from any other table in the database
select * from person.ContactType
Database roles and permissions are discussed in more detail later in this chapter, in the
sections “Managing Database Roles” and “Managing Permissions.”
Application Roles
Unlike other roles, application roles contain no database users. When an application role
is created (see the section “Managing Database Roles,” later in this chapter), rather than
add a list of users who belong to the role, you specify a password. To obtain the permis-
sions associated with the role, the connection must set the role and supply the password.
This is done using the stored procedure sp_setapprole. You set the role to the sales
application role (with the password PassW0rd) as follows:

EXEC sp_setapprole ‘sales’, ‘PassW0rd’
You can also encr ypt the password:
EXEC sp_setapprole ‘sales’, {ENCRYPT N ‘ PassW0rd’}, ‘odbc’
When an application role is set, all permissions from that role apply, and all permissions
inherited from roles other than public are suspended until the session is ended.
So why is it called an application role? The answer is in how it is used. An application role
is used to provide permissions on objects through an application, and only through the
application. Remember that you must use sp_setapprole and provide a password to acti-
vate the role; this statement and password are not given to the users; rather, they are
embedded in the application’s CONNECT string. This means that the user can get the
permissions associated with the role only when running the application. The application
can have checks and balances written into it to ensure that the permissions are being used
for the forces of good and not evil.
Managing Securables
Securables are the entities in SQL Server on which permissions can be granted. In other
words, principals (for example, users or logins) obtain permission to securables. This
chapter describes many examples of securables, including tables, databases, and many
Download from www.wowebook.com
ptg
310
CHAPTER 11 Security and User Administration
TABLE 11.4 SQL Server 2008 Securables
Server Database Schema
Logins User Table
Endpoints Role View
Databases Application role Function
Assembly Procedure
Message Type Queue
Route Type
Service Synonym

Remote Service Binding Aggregate
Fulltext Catalog XML Schema Collection
Certificate
Asymmetric Key
Symmetric Key
Contract
Schema
entities that have been part of the SQL Server security model in past versions. SQL Server
2008’s security model contains a granular set of securables for applying permissions.
Securables are hierarchical in nature and are broken down into nested hierarchies of
named scopes. Three scopes are defined: at the server, database, and schema levels. Table
11.4 list the securables for each scope.
As mentioned earlier, a hierarchy exists within each scope; in addition, relationships cross
scope boundaries. Servers contain databases, databases contain schemas, and schemas
contain a myriad of objects that are also hierarchical. When certain permissions are
granted on a securable at the server level the permissions cascade; meaning permission is
granted at the database and schema levels. For example, if a login is granted control
permission at the server level, control is implicitly granted at the database and schema
levels. The relationships between securables and permissions can be complicated. The next
section details the different types of permissions and sheds some light on how these
permissions affect securables.
Download from www.wowebook.com
ptg
311
Managing Permissions
11
Managing Permissions
Database security is mainly about managing permissions. Permissions are the security
mechanisms that tie principals (for example, logins) to securables (for example, tables).
With SQL Server 2008, permissions can be applied at a granular level that provides a great

deal of flexibility and control.
Permissions in SQL Server 2008 revolve around three commands: GRANT, REVOKE, and DENY.
These three commands were also used in SQL Server 2005 and SQL Server 2000. When
permission is granted, the user or role is given permission to perform an action, such as
creating a table. The DENY statement denies permission on an object and prevents the prin-
cipal from gaining GRANT permission based on membership in a group or role. The REVOKE
statement removes a permission that was previously granted or denied.
When specifying permissions, you need to carefully consider the hierarchy that exists
between GRANT, REVOKE, and DENY. This is particularly important when the principal (for
example, user or login) is part of a group or role and permissions have been granted on
securables at different scopes of the security model. Following are some examples of the
precedence that exists between these statements:
. A GRANT of a permission removes any REVOKE or DENY on a securable. For example, if
a table has SELECT permission denied on it and then the SELECT permission is
granted, the DENY permission is then removed on that table.
. DENY and REVOKE remove any GRANT permission on a securable.
. REVOKE removes any GRANT or DENY permission on a securable.
. Permissions denied at a higher scope in the security model override grants on that
permission at a lower scope. Keep in mind that the security model has the server
scope at the highest level, followed by database and schema. So, if INSERT permis-
sion is denied on tables at the database level, and INSERT on a specific table in that
database is granted at the schema level, the result is that INSERT is denied on all
tables. In this example, a database-level DENY overrides any GRANT at the lower
schema level.
. Permissions granted at a higher scope in the security model are overridden by a DENY
permission at a lower level. For example, if INSERT permission is granted on all tables
at the database scope, and INSERT is denied on a specific table in the database
(schema scope), INSERT is then denied on that specific table.
The assignment of a permission includes the GRANT, DENY, or REVOKE statements plus the
permission that these statements affect. The number of available permissions increased in

SQL Server 2005 and has been carried forward to SQL Server 2008. Familiar permissions
such as EXECUTE, INSERT, and SELECT that were available in SQL Server 2000 are still
around, plus the new permissions that were added in SQL Server 2005. Following are some
of the new types that were added in SQL Server 2005:
Download from www.wowebook.com
ptg
312
CHAPTER 11 Security and User Administration
. CONTROL—This type confers all defined permissions on the securable. This owner-
ship-like capability also cascades to any lower-level objects in the security hierarchy.
. ALTER—This type confers the capability to change the securable’s properties but
does not include the capability to make ownership changes. If ALTER is applied on a
scope such as a database or a schema, the capability to use ALTER, CREATE, or DROP on
any object in the scope is allocated as well.
. IMPERSONATE—This type allows the principal to impersonate another user or login.
. VIEW DEFINITION—This type allows access to SQL Server metadata. This type of
data is not granted by default in SQL Server 2008; therefore, the VIEW DEFINITION
permission was added to manage access.
The combination of available permissions and the securables that they can be applied to is
extensive. The permissions that are applicable depend on the particular securable. SQL
Server Books Online lists the permissions for specific securables. You can use the index
feature at Books Online to look for “permissions [SQL Server].” There, you will find a
section named “Permissions Applicable to Specific Securables” as well as a section named
“SQL Server Permissions” that lists each securable and its related permissions.
You can also view the available permissions by using system functions and catalog views.
The following example uses the sys.fn_builtin_permissions function to retrieve a partial
listing of all the available permissions:
SELECT top 5 class_desc, permission_name, parent_class_desc
FROM sys.fn_builtin_permissions(default)
order by 1,2

/* Results from previous query
class_desc permission_name parent_class_desc

APPLICATION ROLE ALTER DATABASE
APPLICATION ROLE CONTROL DATABASE
APPLICATION ROLE VIEW DEFINITION DATABASE
ASSEMBLY ALTER DATABASE
ASSEMBLY CONTROL DATABASE
*/
The granularity with which permissions can be applied with SQL Server 2008 is impressive
and, to some degree, challenging. When you look at all the available permissions, you will
see that some planning is needed to manage them. In the past, fixed database roles were
simple to use but in many cases provided permissions that went beyond what the user
needed. Microsoft has supplied the tools to facilitate the concept of “least privileges,”
which means providing only the privileges that are needed and nothing more. The tools
to help you manage permissions are discussed later in this chapter, in the section
“Managing SQL Server Permissions.”
Download from www.wowebook.com
ptg
313
Managing SQL Server Logins
11
Managing SQL Server Logins
You can create and administer logins easily using SSMS. You can use T-SQL as well, but the
GUI screens are often the best choice. The GUI screens present the configurable properties
for a login, including the available options, databases, and securables that can be assigned
to a login. The number of configurable options is extensive and can be difficult to manage
with T-SQL.
Using SSMS to Manage Logins
The visual tools for managing logins in SSMS are accessible via the Object Explorer. You

need to expand the Security node in Object Explorer and right-click the Logins node. Then
you select the New Login option, and the new login screen, shown in Figure 11.4, appears.
The default authentication mode for a new login is Windows Authentication. If you want
to add a login with Windows Authentication, you need to type the name of your
Windows user or group in the Login Name text box. You can also click the Search button
to search for Windows logins. In either case, the login entered for Windows
Authentication should be in the form <DOMAIN>\<UserName> (for example, mydomain\Chris)
or in the form
FIGURE 11.4 Creating a login in SSMS with Windows Authentication.
Download from www.wowebook.com