Microsoft SQL Server 2008 R2 Unleashed- P37 doc

The Server Roles page allows you to select one or more fixed server roles for the login to participate in.. The default schema is the schema that will contain the database objects create

With Windows Authentication, you have an option to restrict access to the server for the

new login when it is created If you select Deny Server Access, a command to deny access

to SQL Server is issued immediately after the login is created (for example, DENY CONNECT

SQL TO [DBSVRXP\Chris]) This option can be useful for staging new logins and waiting

until all the appropriate security has been applied prior to allowing the login to access

your SQL Server instance After you completing the security setup for the login, you can

select the login properties and choose the GRANT SERVER ACCESS option

You can use the same new login screen shown in Figure 11.4 to add a login with SQL

Server Authentication Again, you need to provide a login name, but with the standard

SQL Server login, there is no domain associated with the user The login is independent of

any Windows login and can be named as desired The login and password for SQL Server

Authentication are stored and maintained in SQL Server

When SQL Server Authentication is selected, several options related to passwords are

enabled These options, as shown in Figure 11.5, include Enforce Password Expiration,

Enforce Password Policy, and User Must Change Password at Next Login These options are

all associated with a more rigid password policy They are similar to options available with

Windows accounts and provide a more robust security solution for SQL Server logins The

catch is that the new password options are enforced only on the Windows 2003 Server

operating system and versions above You can select these options when running SQL

Server on a machine that has an operating system that is lower than Windows 2003

Server, but the hooks between SQL Server and the operating system are not in place to

enforce the password policy

FIGURE 11.5 Creating a login in SSMS with SQL Server Authentication

The next set of options on the General page of the new login allows you to map the login

to a certificate, asymmetric key, or credential The certificate and asymmetric key

selec-tions allow you to create a certificate-mapped login or an asymmetric key-mapped login

A certificate-mapped login and an asymmetric key-mapped login are used only for code

signing and cannot be used to connect to SQL Server If these options are used, the

certifi-cate or asymmetric key must exist on the server before you map the logins to them The

capability to map the login to a credential on the General page is new to SQL Server

2008 This option simply links the login to an existing credential, but its capabilities may

be expanded

The default database and default language are the final options located on the General

page of the new login screen These options are available regardless of the authentication

method selected The default database is the database that the login will connect to by

default The master database is selected, but it is generally not the best database to select

for your default You should choose the default database that your login will use most

often and avoid using any of the system databases as your default This helps prevent

database users from executing statements against the wrong database, and it also removes

the step of having to change the database every time the user connects You should make

sure that the login is given access to whatever database you select as the default (The

Database Access page is discussed later in this chapter.)

The default language determines the default language used by the login If no default

language is specified and the <default> entry is left in the Language drop-down, the

server’s default language is used The default language for the server can be retrieved or set

by using the sp_configure system stored procedure The language selection affects many

things, including date formats, month names, and names of days To see a list of

languages available on the server and the related options, you use the sys.syslanguages

catalog view

The new login screen has four other pages available for selection when creating your new

login: Server Roles, User Mapping, Securables, and Status The Server Roles page allows you

to select one or more fixed server roles for the login to participate in Figure 11.6 shows

the new login screen with the Server Roles page selected For a more detailed review of the

permissions related to each server role, refer to the section “Fixed Server Roles,” earlier in

this chapter

The User Mapping page allows you to select the databases that the login will have access

to When the Map check box is selected for a database, the Default Schema and User cells

are enabled The default schema is the schema that will contain the database objects

created by the login The login can create objects in schemas other than the default if the

login has permission to use the other schemas If no schema is specified, the default

schema is used The default schema also comes into play when you’re retrieving database

objects If no schema is specified on database retrievals, the default schema is searched

first for the database object If no Default Schema is specified on the Database Access

screen, the default schema is set to dbo The User data entry area allows you to enter a

database username that is different from the login name By default, the database

user-name is the same as the login user-name, but you can change it

ptg FIGURE 11.6 Choosing a server role

The other thing that happens when you select the Map check box on the database is that

the list of database roles is enabled in the bottom portion of the screen You can select one

or more database roles for the login Both fixed and user-defined database roles are

avail-able for selection The public database role is selected by default and cannot be deselected

The Securables page allows you to select server objects for login permissions The server

objects are limited to object types scoped at the server level They include Servers,

Endpoints, Logins, and Server Roles object types The management of all permissions,

including those for Logins, is discussed in detail in the “Managing Permissions” section,

earlier in the chapter

The last page listed for selection is the Status page, which allows you to configure some

authorization and authentication options You can grant or deny access to the database

engine on this page, and you can enable or disable the login You also might need to visit

this page if the login gets locked out If this happens, you have an option on this page to

reenable the login so that it is not longer locked out

To modify a login, you right-click the login in the Security node and select Properties

The same set of property pages available when you create a new login are displayed You

cannot change the authentication mode after the login has been created, but you can

change all the other settings, if desired

To delete a login, you right-click the login and select Delete The Delete Object screen

appears, and you can click OK to delete the login A warning message appears, stating

“Deleting server logins does not delete the database users associated with the logins.” If

the login has associated database users, and the login deletion is performed, database

users are orphaned, and you have to manually delete the users associated with the login

in each database

Using T-SQL to Manage Logins

You can manage logins by using T-SQL statements This approach is generally not as easy

as using the user-friendly GUI screens that come with SSMS, but sometimes using T-SQL is

better For example, with installations and upgrades that involve changes to logins, you

can use T-SQL to script the changes and produce a repeatable process

SQL Server 2008 includes system stored procedures and an ALTER LOGIN statement that

you can use to manage logins The same system stored procedures available in prior

versions are still available in SQL Server 2008, but they have been deprecated and will not

be available in a future version Table 11.5 lists the available system stored procedures and

the basic function and current state of each one The state indicates whether the

proce-dure has been deprecated and whether an alternative exists in SQL Server 2008

TABLE 11.5 System Stored Procedures for Managing Logins

sp_addlogin Add a SQL Server login Deprecated; use CREATE LOGIN

sp_defaultdb Change the default database Deprecated; use ALTER LOGIN

instead

sp_defaultlanguage Change the default language Deprecated; use ALTER LOGIN

instead

sp_denylogin Deny server access to a Windows

login

Deprecated

sp_droplogin Drop a SQL Server login Deprecated; use DROP LOGIN

instead

sp_grantlogin Add a Windows login Deprecated

sp_password Change a login’s password Deprecated; use ALTER LOGIN

instead

sp_revokelogin Drop a Windows login Deprecated; use DROP LOGIN

instead

The system stored procedures have a variety of parameters, which are documented in

Books Online Because they have been deprecated, they are not the focus of this section

Instead, this section focuses on a number of examples that utilize the CREATE, ALTER, and

DROP statements The following example creates a SQL Server login with a password that

must be changed the first time the login connects:

CREATE LOGIN Laura WITH PASSWORD=N’mypassw0rd$’

MUST_CHANGE, CHECK_EXPIRATION=ON

You can then use the following ALTER LOGIN statement to change the default database,

language, and password for the new Laura login:

ALTER LOGIN [Laura] WITH

DEFAULT_DATABASE=[AdventureWorks2008],

DEFAULT_LANGUAGE=[British],

PASSWORD=N’myStr0ngPW’

Finally, you can drop the Laura login by using the following:

DROP LOGIN [Laura]

As you can see, the T-SQL statements for Logins are relatively easy to use To simplify

matters, you can generate T-SQL statements from SSMS To do so, you click the Script

button available on the screen that appears after you specify a login action For example,

if you right-click a login and select Delete, the Delete Object screen appears At the top of

this screen is a Script button When you click this button, SSMS scripts the related T-SQL

statements into a query editor window for you to review and execute

Managing SQL Server Users

The SSMS has a set of friendly user interfaces to manage SQL Server users as well The

screens are similar to the screens for logins and are also launched from the Object

Explorer You can also use a set of T-SQL statements to manage users

Using SSMS to Manage Users

To manage users via SSMS, you open the Object Explorer and expand the Security node

followed by the Users node The Users node contains a list of the current database users

To add a new database user, you can right-click the Users node and select New User

Figure 11.7 shows the Object Explorer window with the option to create a new user

selected for the AdventureWorks2008 database

Figure 11.8 shows the new database user screen displayed after you select the New User

option In this figure, a login named Chris is used, and the database user name is Chris as

well These two names do not need to match but are often the same for consistency The

login must exist before you can create the user You can click the ellipsis button next to

the login name to view a list of available logins After you click the ellipsis, you can click

the Browse button to see the logins that have already been added to SQL Server

FIGURE 11.7 The New User option in Object Explorer

FIGURE 11.8 Using SSMS to create a new user

The default schema must be a valid schema created in the database If the default schema

is left blank, it defaults to dbo After the default schema has been set, it is used as the

default location for storing and retrieving database objects

You can select one or more schemas to be owned by the user, but a given schema can be

owned by only one user in the database When a schema is selected for ownership for a

user, the previous owner loses ownership, and the new user gains ownership The

follow-ing example shows the type of T-SQL statement that you can run to accomplish the

ownership change This example changes the ownership on the Person schema to the

user Laura:

ALTER AUTHORIZATION ON SCHEMA::[Person] TO [Laura]

When you select the Permissions page, you can assign permissions to securables scoped at

the database and schema levels The management of all permissions, including those for

users, is discussed in detail in the “Managing Permissions” section, earlier in the chapter

To modify or delete an existing database user, you can right-click the user in the Object

Explorer and choose the related option To modify the user, you select Properties, and a

screen similar to the one you use to add the user is displayed To delete the user, you select

the Delete option

Using T-SQL to Manage Users

CREATE USER, ALTER USER, and DROP USER are the T-SQL commands you use most often to

manage database users These commands are replacements for the system stored

proce-dures used in prior versions The system stored proceproce-dures, such as sp_adduser,

sp_dropuser, sp_grantdbaccess, and sp_revokedbaccess, have been deprecated and will

be removed in a future version They are still available for use now, but you should avoid

them when possible

The following example demonstrates the use of the CREATE USER statement to create a

new database user named Laura, with a default schema Sales:

CREATE USER Laura FOR LOGIN Laura

WITH DEFAULT_SCHEMA = Sales

You can use the ALTER USE statement to change the default schema or the username The

following example uses the ALTER USER statement to change the name of the database

user currently named Laura to LauraG:

ALTER USER Laura WITH NAME = LauraG

If you want to delete a database user, you use the DROP USER command The following

example demonstrates how to delete the LauraG from the previous example:

DROP USER [LauraG]

When dropping database users, you must keep in mind that you cannot drop them if they

are the owners of database objects An object’s ownership must be transferred to another

database user before that object can be deleted This applies to schemas that can be owned

by the user as well

Managing Database Roles

Database roles are custom roles that you can define to group your users and simplify the

administration of permissions Generally, custom database roles (non-fixed) are created

if the fixed database roles do not meet the security needs of the administrator (The

assignment of logins and users to fixed server and fixed database roles is covered earlier

in this chapter.)

Using SSMS to Manage Database Roles

You can find database roles in the Object Explorer for each database, under the Security

node, which contains a Roles node The Roles node contains a Database Roles node,

which lists both fixed and nonfixed database roles To add a new custom database role

(nonfixed), you right-click the Database Roles node and select New Database Role A new

database role dialog box appears, as shown in Figure 11.9

FIGURE 11.9 The new database role dialog box

You need to enter a name for the role and name for the owner of the role Like a database

user, a database role can also own schemas If you click the Add button, you can add

data-base users from the current datadata-base to the role

If you select the Permissions page, you can define the permission for the database role

This definition includes the selection of database objects scoped at the database and

schema levels These permissions are discussed in detail in the “Managing Permissions”

section, earlier in this chapter

Using T-SQL to Manage Database Roles

Some of the T-SQL system stored procedures used in prior versions to manage roles have

been deprecated, including sp_addrole and sp_droprole The sp_addrolemember and

sp_droprolemember procedures have not been deprecated and are still good choices for

adding members to a role

The CREATE ROLE and DROP ROLE statements are the new replacements for sp_addrole and

sp_droprole The following example uses the CREATE ROLE statement to create a new

data-base role named DevDbRole:

CREATE ROLE [DevDbRole]

To assign a user named Chris to the new DevDbRole role, you can use the following:

EXEC sp_addrolemember N’DevDbRole’, N’chris’

Role membership is not limited to database users It is possible to assign database roles as

members of another role The following adds the TestDbRole database role to the

DevDbRole role created in the previous example:

EXEC sp_addrolemember N’DevDbRole’, N’TestDbRole’

You cannot use sp_addrolemember to add a fixed database role, a fixed server role, or dbo

to a role You can, however, add a nonfixed database role as a member of a fixed

data-base role If, for example, you want to add the DevDbRole database role as a member of

the fixed database role db_dataread, you use the following command:

EXEC sp_addrolemember N’db_datareader’, N’DevDbRole’

The ALTER ROLE statement exists but is limited to changing the name of a role To drop a

database role, you use the DROP ROLE statement Keep in mind that all role members must

be dropped before a role can be dropped

Managing SQL Server Permissions

You can use T-SQL or the visual tools available in SSMS to manage permissions Based on

the number of available permissions and their complexity, it is recommended that you use

the SSMS tools The following sections cover these tools from several different angles and

look at the management of permissions at different levels of the security model You learn

how to use T-SQL to manage the permissions as well

Using SSMS to Manage Permissions

The Object Explorer in SSMS enables you to manage permissions at many different levels

of the permission hierarchy You can manage permissions at a high level, such as the

entire server, or you can manage permissions at the very lowest level, including a specific

object, such as a table or stored procedure The degree of granularity you use for

permis-sions depends on your security needs To demonstrate the scope of permispermis-sions, let’s look

at managing permissions at several different levels, starting at a high level and working

down to the object level

NOTE

There are many different ways to achieve a security goal in SSMS For example, you

can manage permissions for a database user from the database or from the user You

can apply permissions on schema objects for the entire schema or to individual

objects You should always try to choose the permission solution that allows you to

achieve your security goals with the least amount of administrative overhead

Using SSMS to Manage Permissions at the Server Level

Logins can be granted explicit permissions at the server level Earlier we looked at fixed

server roles as one means for assigning permissions, but you can manage individual

server-level securables as well Figure 11.10 shows the Login Properties window for a login

named Chris You launch this window by right-clicking the login and selecting

Properties Figure 11.10 shows the Securables page, which allows you to add specific

secur-ables to the grid

NOTE

You can open a Permissions page like the one shown in Figure 11.10 from many

differ-ent places in the Object Explorer The title of the dialog box and the contdiffer-ent of the grid

vary, depending on the object selected, but the screen is generally the same, no matter

where it is launched This provides consistency and simplifies the overall management

of permissions

You can click the Search button shown toward the top of Figure 11.10 to add objects to

the securables grid When you click this button, the Add Objects window shown in Figure

11.11 is displayed This window allows you to choose the types of objects you want to

add If you select Specific Objects, you are taken directly to the Select Objects window If

you choose All Objects of the Types, you are taken to an intermediate screen that allows

you to select the type of objects you want to assign permissions to

Again, the Add button and the means for adding objects are fairly consistent for all

permissions What varies is the object types available for selection For example, at the

server level, the types of objects available to assign permissions are scoped at the server

level Figure 11.12 shows the Select Object Types window displayed when you choose the