Microsoft SQL Server 2008 R2 Unleashed- P37 doc

ptg 314 CHAPTER 11 Security and User Administration 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. Download from www.wowebook.com ptg 315 Managing SQL Server Logins 11 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 name, but you can change it. Download from www.wowebook.com ptg 316 CHAPTER 11 Security and User Administration 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. Download from www.wowebook.com ptg 317 Managing SQL Server Logins 11 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 Store Procedure Function Status 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. Download from www.wowebook.com ptg 318 CHAPTER 11 Security and User Administration 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. Download from www.wowebook.com ptg 319 Managing SQL Server Users 11 FIGURE 11.7 The New User option in Object Explorer. FIGURE 11.8 Using SSMS to create a new user. Download from www.wowebook.com ptg 320 CHAPTER 11 Security and User Administration 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 procedures, 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] Download from www.wowebook.com ptg 321 Managing Database Roles 11 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. Download from www.wowebook.com ptg 322 CHAPTER 11 Security and User Administration 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 database 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 Download from www.wowebook.com ptg 323 Managing SQL Server Permissions 11 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 permissions, 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 c an open a Permissions pa ge like t he one sho wn in F igure 11.10 from many d iffer- ent places in the Object Explorer. The title of the dialog box and the content 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 Download from www.wowebook.com . 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. 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. whether an alternative exists in SQL Server 2008. TABLE 11.5 System Stored Procedures for Managing Logins Store Procedure Function Status sp_addlogin Add a SQL Server login. Deprecated; use CREATE