Tài liệu Sams Microsoft SQL Server 2008- P9 doc

ptg 381 Reporting Services Security Model 20 This is the same model used in NTFS. Every child item of a folder automatically inherits the parent folder’s permissions. Whenever an item’s permissions need to change, just break the inheritance and SSRS starts a new policy with that item. Overview of Built-In Roles For most organizations, the built-in roles should suffice. If they do not, keep in mind that the Report Server administrators can create custom role definitions. If you need to create a custom role definition, it might be helpful to stage that role definition in a development environment. Tables 20.2 and 20.3 describe the predefined roles and their corresponding tasks. Keep in mind that when a task is called “Manage .,” that it implies the ability to create, modify, and delete. TABLE 20.2 Item-Level Roles Role Name Description Browser Allows users to browse through the folder hierarchy, view report proper- ties, view resources and their properties, view models and use them as a data source, and finally, execute reports, but not manage reports. It is important to note that this role gives Report Viewer the ability to subscribe to reports using their own subscriptions. Content Manager Allows users to manage folders, models, data sources, report history, and resources regardless of who owns them. This role also allows users to execute reports, create folder items, view and set properties of items, and set security for report items. Report Builder Allows users to build and edit reports using Report Builder and manage individual subscriptions. My Reports Allows users to build reports and store the reports in their own personal folder. They can also change the permissions of their own My Reports folder. Publisher Allows users to publish content to the Report Server, but not to view it. This role is helpful for people who are allowed to develop reports against a development or test data source, but are not allowed to view reports against the production data source. TABLE 20.3 Tasks Assigned to Item-Level Roles Browser Content Manager My Reports Publisher Report Builder Consume reports X X Create linked reports X X X From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 382 CHAPTER 20 Securing Report Server Items TABLE 20.4 System-Level Roles Role Name Role Description System Administrator Allows members to create and assign roles, set systemwide settings (Report Server properties and Report Server security), share schedules, and manage jobs System User Allows members to view system properties and shared schedules There are two built-in, system-level roles. These roles follow the same pattern as the item- level roles in that one role allows view access to systems settings, and the other allows them to be modified. Keep in mind that you can also create new system-level roles. Tables 20.4 and 20.5 break down the system-level roles and tasks. TABLE 20.5 Tasks Assigned to System-Level Roles System Administrator System User Execute report definitions X X Generate events Manage jobs X TABLE 20.3 Continued Browser Content Manager My Reports Publisher Report Builder Manage all subscriptions X Manage data sources X X X Manager folders X X X Manage individual subscriptions XXX X Manage models X X Manage resources X X X Set security for individual items X View data sources X X View folders X X X X View models X X X View reports X X X X View resources X X X X From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 383 Reporting Services Security Model 20 After the Report Server is installed, the local Administrators group is assigned two roles. The first role is the Content Manager, and the second is the System Administrator role. Individually, the roles limit access to certain areas. The Content Manager role can manage everything within the Report Server catalog. System Administrators can manage the Report Server. With the combination of these two roles, local administrators are able to do anything to the Report Server. Assigning Built-In Roles First, to use any method of authorization, you need to create some principals. As an example, you will use some Windows groups: AdventureWorksSalesManagers and AdventureWorksSalesPeople. Go ahead and create these Windows groups on your Report Server and place some users in them. The examples assume that the Adventure Works sample reports have been published to the Report Server and that there are two folders. There might be three folders if you have published the sample report model. You can assign roles to an object either through the Report Manager website or through SQL Server Management Studio. The following sections cover steps to assign roles through the Report Manager. Assigning Roles Through Report Manager Role assignments can be done through either Report Manager or SQL Server Management Studio. Complete the following steps to assign roles through management studio: 1. Navigate to the Adventure Works Sample Reports folder. 2. Click the Properties tab. Then select Security from the left menu. The screen should resemble Figure 20.1. 3. Click the Edit Item Security button. A dialog box opens that looks similar to Figure 20.2. Click OK in this dialog box. 4. Click the New Role Assignment button, as shown in Figure 20.3. 5. Enter AdventureWorksSalesManagers in the Group or User Name text box, and select the Content Manager role, as shown in Figure 20.4. 6. Click OK. To revert back to the parent security, click the Revert to Parent Security button, as shown in Figure 20.5. Manage Report Server properties X Manage Report Server security X Manage roles X Manage shared schedules X View Report Server properties X X View shared schedules X X TABLE 20.5 Continued System Administrator System User From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 384 CHAPTER 20 Securing Report Server Items FIGURE 20.1 Item security on the Properties tab. FIGURE 20.2 Confirmation dialog box to break security inheritance. FIGURE 20.3 New Role Assignment button. To modify an item’s security, select a user or group by clicking the Edit check box next to the assigned principal under Security (on the left). This returns you to the role assignment screen, where roles can be added or removed. To delete a role assignment, select the check boxes next to the principals to delete, and click the Delete button. Figure 20.6 illustrates how this can be done. A confirmation box appears asking users to confirm deletion of the items. Click OK. To give Adventure Works’s sales managers some visibility into the inner workings of the Report Server, let’s outline the steps required to give the group the System Users role: 1. Click Site Settings. 2. Select Security from menu on the left. Figure 20.7 shows the resulting screen. From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 385 Reporting Services Security Model 20 FIGURE 20.4 Granting AdventureWorksSalesManagers Content Manager roles. FIGURE 20.5 Revert to Parent Security button. FIGURE 20.6 How to delete a role assignment. From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 386 CHAPTER 20 Securing Report Server Items 3. From here, it is very similar to setting item-level security. Click the New Role Assignment button. 4. Enter AdventureWorksSalesManagers in the Group or User Name text box, and select the System User role, as shown in Figure 20.8. 5. Click OK. To modify a role assignment, follow the steps to get to the appropriate property window. From the property window, select Permissions and update the lists of tasks. To delete a role assignment, select the role from the property window and click the Remove button. Defining Custom Roles SSRS allows administrators to create custom-defined roles to suit individual needs. This can be a helpful feature for organizations that desire a finer degree of granularity, or if the built-in roles simply do not suffice. Administrators can also modify any existing role. Before jumping into creating new roles, a quick word of caution: It is very easy to get carried away with creating custom roles. There might only be 25 tasks altogether (16 item level and 9 system level), but there are many different combinations you could FIGURE 20.7 System Role Assignments screen. From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 387 Defining Custom Roles 20 FIGURE 20.8 Adventure Works Sales Managers as System Users. create. At this point, the management of roles might be just as cumbersome as managing individual tasks. Creating/Modifying a Custom Role One of the roles SSRS lacks is a true “view-only” type of role. The following steps outline how you could use Report Manager to create such a role. Later, you will use SQL Server Management Studio to do the same thing. The following steps create a new View Only Role using SQL Server Management Studio: 1. Open SQL Server Management Studio. 2. Click File and then Connect Object Explorer. 3. Change the server type to Reporting Services. 4. Click the Connect button. 5. In Object Explorer, open the Security folder. At this point, if you want to create a system-level role, open the System Roles folder; otherwise, open the Roles folder. 6. Right-click the Roles folder and select New Role from the context menu. 7. Enter View Only Role in the Name text box and May view reports but not subscribe to them in the Description field. From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 388 CHAPTER 20 Securing Report Server Items 8. Select View Folders, View Reports, View Models, and View Resources from the tasks. Figure 20.9 shows the resulting dialog box. 9. Click OK. To modify a role, right-click any role and select Properties. The same screen appears as for adding a new role. Update the task list or description and click OK. To delete a role, select the role from Object Explorer, right-click the role, and select Delete from the context menu. Summary SSRS uses role-based security in a similar fashion as Windows itself. Roles are groups of tasks. SSRS contains two different types of tasks: system-level tasks and item-level tasks. Item-level tasks are actions that affect the catalog, such as View or Browse. System-level tasks are actions that can be taken on items outside the catalog, but are global in Report Server scope such as shared schedules. The combination of principal, item, and role is called a policy. Every item in the catalog can either have a policy defined for it explicitly or will inherit the parent item’s policy. If the built-in roles do not suffice, administrators are free to make their own. FIGURE 20.9 Creating a custom role with SQL Server Management Studio. From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg CHAPTER 21 Report Execution and Processing IN THIS CHAPTER . Managing Schedules . Report Execution and Processing . Report-Execution History I n this chapter, you explore some of the information that can be captured at runtime, and learn how to set up shared schedules that can be used to coordinate actions within the Report Server. Managing Schedules Schedules are used within SSRS to trigger executions of subscriptions and snapshots, generally classified as events. Schedules can trigger a one-time event, or cause events to run continuously at specified intervals (monthly, daily, or hourly). Schedules create events on the Report Server. Actions within the Report Server, such as expiring a snapshot or processing a subscription, are triggered by the event. What SSRS actu- ally does is create a scheduled job on the database server that hosts the SSRS database. The SQL Agent then runs the jobs, which usually contain nothing more than the command to execute a stored procedure to trigger an event. The other half of the scheduling and delivery processor within SSRS is the Report Server Windows Service referred to as SQL Server Reporting Services under Services in the Control Panel. This service is responsible for querying the database server for events and running the processes that those events trigger. Both sides of the scheduling and delivery processor must be enabled for it to work. If the SQL Agent on the database server is turned off, the jobs do not run, and there- fore the events do not fire and the corresponding actions From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. ptg 390 CHAPTER 21 Report Execution and Processing TABLE 21.1 Shared Versus Report-Specific Schedules Shared Schedule Report-Specific Schedule Permissions needed to create/modify Needs system-level permissions Can be created by individual users Can be temporar- ily disabled? Can temporarily pause and then resume shared schedules Have to be modified to change the time Manageability Are managed centrally from the Site Settings tab in the Report Manager or Object Browser Have to be managed by the individual items Customizable Cannot be customized for a specific item Can be easily modified without any other down-stream implica- tions are not taken. If the Report Server Service is down, the jobs show that they ran success- fully, but no processing actually occurs. Types of Schedules There are two types of schedules used in SSRS: a shared schedule and a report-specific schedule. The relationship is analogous to the relationship between a shared data source and a custom data source. The shared schedule can be used to trigger a number of events throughout the Report Server. A report-specific schedule is used for one and only one specific event. A second event might occur at exactly the same time, but as far as SSRS is concerned, it is a different schedule. Because they are so similar, the question often brought up is “When should you use a report-specific schedule over a shared schedule?” In general, create a report-specific schedule if a shared schedule does not provide the frequency or recurrence pattern that you need. Table 21.1 details the difference between shared schedules and report-specific schedules. Creating/Modifying Schedules The process of creating/modifying schedules is generally the same whether it is a shared or report-specific schedule. The only difference is the scope. For the shared schedule, it is created once and can be referenced in a subscription or property page when you need to specify schedule information. From Report Manager or Object Explorer, administrators can specify which items use the shared schedule. Report-specific schedules are created and referenced by only that one report, subscription, or report-execution operation to determine cache expiration or snap- shot updates. From the Library of STEPHEN EISEMAN Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Files> \Microsoft SQL Server\ MSRS10.MSSQLSERVER\Reporting Services\Report Server\ bin The two sections in the configuration file to pay particular attention to as far as tracing is concerned are DefaultTraceSwitch and RSTrace They are shown here: . use SQL Server Management Studio to do the same thing. The following steps create a new View Only Role using SQL Server Management Studio: 1. Open SQL Server. To remedy this, Microsoft has distributed a SQL Server Integration Services package that can be used to port the data from the Report Server s internal