ptg 324 CHAPTER 11 Security and User Administration FIGURE 11.10 Server-level permissions. FIGURE 11.11 The Add Objects window. All Objects of the Types option at the server level. You can see that the available objects are all scoped at the server level. If the endpoints objects are selected, the securables grid is populated with all the available endpoints that have permissions to manage. Figure 11.13 shows the Login Properties window with the endpoints securables populated. The TSQL Named Pipes securable is selected, which allows you to specify the explicit permissions for the securable in the bottom grid. In this example, the Grant and With Grant check boxes have been selected for the control permission. This gives the login named Chris the right to control the Named Pipes endpoint and also allows him to grant this control right (because With Grant is selected) to other logins. The examples we just walked through are related to the assignment of explicit permission on a specific instance of a securable. You can also apply server permissions at a higher Download from www.wowebook.com ptg 325 Managing SQL Server Permissions 11 FIGURE 11.12 Server-level object types. FIGURE 11.13 Server-level securables. level. For example, you might want to specify permissions for a login to allow that login to control all server endpoints instead of specific endpoints. You can accomplish this in several ways. One way to do it is to select the Server object from the list of object types when adding permissions for a specific login. Another way is to right-click the server name in the Object Explorer and select Properties. The Server Properties window that appears has a Permissions page that lists all the logins for the server, along with the macro-level permissions scoped for the server. Figure 11.14 shows the Server Properties window with the login Chris selected. The explicit permissions listed in this case are at a higher level and are not just for one instance. The example shown in Figure 11.14 allows Download from www.wowebook.com ptg 326 CHAPTER 11 Security and User Administration FIGURE 11.14 The Server Properties window’s Permissions page. the login Chris to alter any database or any endpoint on the server. This is based on the Grant check boxes selected. Using SSMS to Manage Permissions at the Database Level The same type of hierarchy exists with permissions at the database level as at the server level. You can apply permissions at a high level to affect many objects of a particular type, or you can apply them on a specific object. You can also manage the permissions at the database level on a specific database user, or you can manage them on the database across many users. To demonstrate the differences between object types available at the database level, let’s first look at managing permissions for a specific database user. As with logins, you can right-click a database user and select Properties. On the Properties window that appears, you select the Securables page, and you get a screen to assign permissions that is very similar to the login permissions screen. The difference at the database level is in the object types available for selection. Figure 11.15 shows the object types available when you choose the All Objects of Types choice during the addition of securables for a database user. When a low-level object type such as a table or stored procedure is selected, you are able to apply explicit permissions to a specific object instance. Figure 11.16 shows an example of low-level securables available when the Table object type is selected. Download from www.wowebook.com ptg 327 Managing SQL Server Permissions 11 FIGURE 11.15 Database-level object types. FIGURE 11.16 Low-level database securables. Download from www.wowebook.com ptg 328 CHAPTER 11 Security and User Administration FIGURE 11.17 High-level database securables. To apply permissions at a higher level in the database, you choose the object type Databases. With this securable added to the permissions grid, you can apply permissions to a group of objects by selecting a single permission. Figure 11.17 shows the AdventureWorks2008 database selected as the securable and the related permissions avail- able. In this example, the login Chris has been granted INSERT, SELECT, and UPDATE permissions to all the tables in the AdventureWorks2008 database. Using SSMS to Manage Permissions at the Object Level The last permission assignment we look at is the object level. SSMS enables you to select a specific object instance in the Object Explorer and assign permissions to it. This method allows you to navigate to the object you want via the Object Explorer tree and assign permissions accordingly. Figure 11.18 shows the Object Explorer tree expanded to the Stored Procedures node. A specific stored procedure has been right-clicked, and the Properties option has been selected. The Properties window has a page dedicated to permissions. You can select the Permissions page and then select the users or roles you want to add for the specific object, such as a stored procedure. Figure 11.19 shows the Permissions page with a user named Chris added to the Users or Roles window at the top of the page. The bottom portion of the page shows explicit permissions for the user Chris, which includes a DENY permission on the stored procedure selected. Download from www.wowebook.com ptg 329 Managing SQL Server Permissions 11 FIGURE 11.18 Object-level permissions selected via Object Explorer. FIGURE 11.19 Object-level permissions. Download from www.wowebook.com ptg 330 CHAPTER 11 Security and User Administration NOTE The methods described here for managing permissions in SSMS are by no means the only ways you can manage permissions in SSMS. You will find that the assignment of permissions pervades SSMS and that SSMS allows you to assign permissions in many different ways. The point to keep in mind is that database roles, application roles, schemas, and other objects in the security model all have similar methods for assign- ing permissions. Using T-SQL to Manage Permissions As you saw in the SSMS Permissions pages, three options exist for assigning every permis- sion: GRANT, DENY, and REVOKE. Each option has its own T-SQL statements that can be used to manage permissions as well. The simplified syntax for the GRANT command is as follows: GRANT { ALL [ PRIVILEGES ] } | permission [ ( column [ , n ] ) ] [ , n ] [ ON [ class :: ] securable ] TO principal [ , n ] [ WITH GRANT OPTION ] [ AS principal ] This basic GRANT syntax is similar to that in SQL Server 2000, but the addition of many permissions and securables in SQL Server 2005 and SQL Server 2008 has expanded the scope of the command. SQL Server 2005 also introduced the WITH GRANT option which allows a permission to be granted to a principal and allows the principal to grant that permission to another principal. The WITH GRANT option has been carried forward to SQL Server 2008 and is a good way to delegate administrative functions to others. The simplified syntax for the DENY and REVOKE commands is as follows: DENY { ALL [ PRIVILEGES ] } | permission [ ( column [ , n ] ) ] [ , n ] [ ON [ class :: ] securable ] TO principal [ , n ] [ CASCADE] [ AS principal ] REVOKE [ GRANT OPTION FOR ] { [ ALL [ PRIVILEGES ] ] | permission [ ( column [ , n ] ) ] [ , n ] } [ ON [ class :: ] securable ] { TO | FROM } principal [ , n ] [ CASCADE] [ AS principal ] You can see that the simplified syntax for DENY and REVOKE is similar in structure to the GRANT statement. All the statements must identify the permission, securable, and principal that will receive the permission. Download from www.wowebook.com ptg 331 The Execution Context 11 The ALL clause has been deprecated in SQL Server 2008. If ALL is specified, it does not affect all permissions on the object; it affects only a subset of the permissions related to the securable. The subset of permissions is dependent on the securable. The following examples demonstrate several different types of permissions you can manage by using T-SQL commands: Grant permissions to create a table to a user named Chris GRANT CREATE TABLE TO Chris Grant ALL permissions on a stored procedure to a database role named TestDBRole GRANT ALL ON dbo.uspGetBillOfMaterials TO TestDBRole DENY UPDATE permission on the Customer table to user named Laura DENY UPDATE ON OBJECT::sales.customer TO Laura REVOKE UPDATE permissions on the Customer table to user named Laura. REVOKE UPDATE ON OBJECT::sales.customer TO Laura There are many different flavors of the GRANT, DENY, and REVOKE statements, depending on the securable they are affecting. Books Online outlines the syntax for each securable and the permissions that can be applied. Remember that you can use the Script option to generate the T-SQL from SSMS. The Script button is available when you’re managing permissions, and using it is a great way to familiarize yourself with the T-SQL that is used to effect changes. You can select the permissions you want to apply via the GUI screen and then click the Script button to generate the T-SQL. The Execution Context The execution context determines what permissions are checked when statements are executed or actions are performed on the database server. By default, the execution context is set to the principal connected to the server or database. If a user named Chris connects to the AdventureWorks2008 database, the permissions assigned to Chris are checked. In SQL Server 2008, you can change the execution context so that permissions are checked for a principal other than that to which you are connected. You can make this change in execution context (called context switching) explicitly or implicitly. Download from www.wowebook.com ptg 332 CHAPTER 11 Security and User Administration Explicit Context Switching With explicit context switching, you can use the EXECUTE AS statement to change the user or login used to check permissions. This is similar to the SET USER statement available in SQL Server 2000 and SQL Server 2005. It is extremely useful for administrators who are testing the permissions they have set for users or logins. The following example demon- strates the use of the explicit EXECUTE AS statement: Assume that you are connected as an administrator (DBO) and want to prevent members of the Public role from selecting from the Sales.Customer table DENY SELECT ON sales.customer TO Public We can check that user Laura cannot select from the Sales.Customer table using the EXECUTE AS statement EXECUTE AS USER = ‘laura’ SELECT TOP 1 * FROM sales.customer Revert to the previous execution context. REVERT You can also do explicit context switching at the login level. You can use the EXECUTE AS statement to switch the execution context to another login instead of a user. Context switching is linked to the IMPERSONATE permission. As an administrator, you can grant IMPERSONATE to a login or user to enable that user to execute as that user. For example, an administrator can temporarily enable another login to run in the same execu- tion context by using the IMPERSONATE permission and EXECUTE AS statement. The follow- ing example demonstrates the assignment of the IMPERSONATE permission to a login named Laura: Chris grants the right to Laura to impersonate him GRANT IMPERSONATE ON LOGIN::[chris] TO [laura] GO Laura can then connect with her login and use the EXECUTE AS command to run commands that normally only Chris has permission to run EXECUTE AS Login = ‘Chris’ DBCC CHECKDB (AdventureWorks2008) SELECT USER_NAME() Revert back to Laura’s execution context REVERT SELECT USER_NAME() Laura can now use EXECUTE as Chris, who is an administrator. This capability can be particularly useful when a user or login has many custom permissions that would take a lot of time to establish for another user or login. Download from www.wowebook.com ptg 333 The Execution Context 11 Implicit Context Switching With implicit context switching, the execution context is set within a module such as a stored procedure, trigger, or user-defined function. The EXECUTE AS clause is placed in the module and is set to the user that the module will be run as. The context switch is implicit because the user who runs the module does not have to explicitly specify the context before running the module. The context is set within the module. The EXECUTE AS clause has several different options to establish the execution context. All modules are able to set the context to a specific user or login. Functions, stored proce- dures, and Data Manipulation Language (DML) triggers can also execute as CALLER, SELF, or OWNER. DDL triggers can run as CALLER or SELF. Queues can run as SELF or OWNER. The CALLER option is the default, and it runs the module in the context of the user who called the module. The SELF option causes the module to run in the context of the user or login that created the procedure. The OWNER option causes the module to run in the context of the current owner of the module. The following example demonstrates the creation and execution of a stored procedure with the EXECUTE AS clause on a specific user named Chris: CREATE PROCEDURE dbo.usp_TestExecutionContext WITH EXECUTE AS ‘chris’ AS SELECT USER_NAME() as ‘User’ Set the user to someone other than chris to test the implicit EXECUTE AS SETUSER ‘DBO’ EXEC usp_TestExecutionContext /*Results of the prior execution User chris */ This example shows that the USER_NAME retrieved in the stored procedure is Chris, regard- less of who executed the procedure. Implicit execution context can be particularly useful in situations in which permissions cannot be granted to a user directly. For example, TRUNCATE TABLE permissions cannot be granted explicitly to a user, but a database owner can run this command. Instead of grant- ing dbo rights to a user needing TRUNCATE permissions, you can create a stored procedure that does the truncation. You can create the stored procedure with the execution context of dbo, and you can grant the user rights to execute the stored procedure that does the truncation. When you use this method, the user can perform the truncation but does not have any of the other permissions related to a database owner. Download from www.wowebook.com . similar to that in SQL Server 2000, but the addition of many permissions and securables in SQL Server 2005 and SQL Server 2008 has expanded the scope of the command. SQL Server 2005 also introduced. You can also apply server permissions at a higher Download from www.wowebook.com ptg 325 Managing SQL Server Permissions 11 FIGURE 11.12 Server- level object types. FIGURE 11.13 Server- level securables. level principal connected to the server or database. If a user named Chris connects to the AdventureWorks2008 database, the permissions assigned to Chris are checked. In SQL Server 2008, you can change