278 Hands-On Microsoft SQL Server 2008 Integration Services 25. You will see an error message saying that there were errors while loading the package, which prompts you to see the Error List for more details. Click OK to proceed further. 26. The package will be loaded. Open the Error List window, and you will see an error explaining that the package will be loaded without the encrypted information: Error loading Downloading zipped files.dtsx: Failed to decrypt an encrypted XML node because the password was not specified or not correct. Package load will attempt to continue without the encrypted information. Press 5 to run the package, which will fail, specifying that the password was not allowed in the Execution Results pane. Click Stop Debugging. 27. In the Connection Managers area, double-click the FTP Connection Manager and specify the password in the credentials area. Click OK to close this window. Press 5 to run the package. The package won’t run; instead it returns an error similar to the one shown in Figure 7-3. Close the error notifications. You get this error because you are still using the EncryptSensitiveWithPassword protection level and haven’t provided a package Figure 7-2 A password is required to open packages saved with the EncryptSensitiveWithPassword option. Figure 7-3 Error returned on saving a package without specifying a package password Chapter 7: Securing Integration Services Packages 279 password to encrypt the sensitive information. Until you supply the package password, you can’t save the package and subsequently can’t execute it. Click Stop Debugging. 28. At this time, you can supply a new package password to save the package, and as you’ve already provided the sensitive information, that is, the FTP server password, you should be able to save and execute the package. Type yY56789zZ in the PackagePassword field and press 5 to run the package. The package executes successfully this time. Exercise (Encrypting All Information in the Package Using a User Key) Using the EncryptAllWithUserKey option in the ProtectionLevel property encrypts all the metadata of a package with the user key so that no one else can load or run the package. 29. Switch to the package Properties window and change the ProtectionLevel property to EncryptAllWithUserKey. 30. Switch to the XML View Code tab to see that all the code of the package has been encrypted. 31. Save the package, close all the applications, and log off. 32. Log back on with the ISUser01 account and open the Downloading zipped files solution using BIDS. 33. Double-click the Downloading zipped files.dtsx package under the SSIS Packages folder to load the package. 34. The package still doesn’t load. Instead, it returns an error saying that the package could not be loaded and the package might be corrupted. This is because BIDS could not remove the package encryption. Click OK, and then go on to read the detailed error message from the Error List window (Figure 7-4). As you can see, the Error List window displays the much-detailed error messages. This is unlike the EncryptSensitiveWithUserKey option, in which the sensitive information is replaced with blank information when other users try to load the package and then the other users can use the package by providing the sensitive information. Using the EncryptAllWithUserKey option, the other users can’t load the package at all. This is the most restrictive protection level possible in SSIS. However, use of this protection level should be done with great care, as it ties down the package to the creator’s profile; if the creator loses access to his or her profile, the package is rendered useless. The most eligible uses of this protection level may be ad hoc or short-term deployment of highly security sensitive packages. 280 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (Encrypting All Information in the Package Using a Package Password) In this exercise, you will learn that the EncryptAllWithPassword option of the ProtectionLevel property is the most secure option that allows sharing your package with other users. 35. Continuing from the previous steps, close all the applications and log off, as we cannot use the encrypted package with the previous encryption method. Log on using the administrator account and open the Downloading zipped files solution and the package using BIDS. 36. Open the package properties and scroll down to the Security category and change the ProtectionLevel property to EncryptAllWithPassword. 37. Click in the PackagePassword property and then click the ellipsis button, which appears when you click in the field. Provide the password bB12345cC in the Property Editor window, confirm it, and then click OK. 38. View the package code and notice that this time the encryption method used is TripleDES with the CBC algorithm. Press -- to save all the files. Close all the applications and log off. Figure 7-4 Error loading package with the EncryptAllWithUserKey protection level Chapter 7: Securing Integration Services Packages 281 39. Log on as the ISUser01 user and open the Downloading zipped files solution in BIDS. 40. The package may not load by itself; double-click the package in the Solution Explorer to load it. You will be asked to provide a password because the package is encrypted. If you provide the password, the package will load and you can successfully execute the package. But, for the sake of testing what happens otherwise, click Cancel here. 41. An error message will tell you that the package could not be loaded, as it might be corrupted, and asks you to see Error List for details. Click OK. 42. The package will not load and you will receive an error message on the Designer saying that Microsoft Visual Studio is unable to load the document, as the password was not specified or not correct. Almost similar errors appeared in the Error List: Error loading 'Downloading zipped files.dtsx' : Failed to remove package protection with error 0xC0014037 "The package is encrypted with a password. The password was not specified, or is not correct.". This occurs in the CPackage::LoadFromXML method. This exercise shows that using the EncryptAllWithPassword protection level option doesn’t let other users use the package until they specify the correct package password. If the other users use a wrong password or do not specify a password, the package is simply not loaded and hence not available. This is quite useful feature, as it allows you to share your packages within a team yet keep it encrypted to avoid any unauthorized access. 43. Close the error message tab and open the package again by double-clicking the package file. Specify the correct password this time and the package will be loaded. You can further test this package by clicking Start Debugging to see that it executes successfully. Review You have used five out of six available ProtectionLevel property options in this exercise. You first learned that you could choose to exclude the sensitive information from a package using the DontSaveSensitive option. Then you learned the two options EncryptSensitiveWithUserKey and EncryptAllWithUserKey that use a user key to encrypt the sensitive or complete information in a package respectively. Later, you studied two more options to encrypt sensitive data or the complete package using an encryption password that has to be specified in the PackagePassword property: EncryptSensitiveWithPassword for encrypting sensitive information and EncryptAllWithPassword for encrypting the complete package. These options let you share packages with other users while keeping them secure from unauthorized access. The ServerStorage option that you have not used in this exercise is covered next. Note that when you create and save a package, your package may use other miscellaneous files that may reside outside the package. Using the preceding protection options may 282 Hands-On Microsoft SQL Server 2008 Integration Services lead to a false impression that all the data is secured. So you should carefully consider all the files you refer to in a package and where these files are saved. These files may include checkpoint files, configuration files, or log files. You need to control access to these files using access control list permissions depending upon where they have been stored. Using Integration Services Fixed Database-Level Roles Integration Services enables you to control access to SSIS packages by providing three fixed database-level roles: db_ssisadmin, db_ssisltduser, and db_ssisoperator. These are available in the MSDB database and can be applied only to the packages that are saved to the MSDB database in SQL Server. Fixed Database-Level Roles and Their Permissions When you use the ServerStorage option for the ProtectionLevel property, the access to the packages saved to MSDB is controlled by fixed database-level roles. This is an additional security option you get when saving packages into SQL Server (as opposed to saving in File System) and gives you much more control for access permissions on the packages. Any user who needs access to a package must be a member of at least one of the three fixed database-level roles—db_ssisadmin, db_ssisltduser, or db_ ssisoperator. By default, these roles have been assigned read or write privileges on the packages as described next: e db_ssisoperator role c is is the weakest role among the three available roles. You generally assign this role to users who need to execute the packages. is role cannot perform any write operation—i.e., it cannot import or create packages and has only read permissions. It can list, view, execute, and export all the packages stored within a storage area. It can also schedule package execution using the SQL Server Agent service. e db_ssisltduser role c is role is designed to give user access to developers who need to create and manage their own packages. As the name suggests, this role can perform functions limited to owned packages and can delete only owned packages and manage owned package roles, although they can import any package. And for the read functions, this role can view, execute, or export only the owned packages but can list all packages. e db_ssisadmin role c is role is designed for administrators to manage packages and package roles. ey have all the read and write permissions to Chapter 7: Securing Integration Services Packages 283 perform any operation on the SSIS packages. e role can list, view, execute, and export owned or other users’ packages. is role can perform the write operations for importing, deleting, and managing package roles for owned or other users’ packages. Last, to highlight that the server-level role sysadmin can also perform all the functions that of a db_ssisadmin role. Other than these fixed database-level roles, Windows administrators can view execution details of all running packages in Management Studio and can also stop the running packages. Let’s save the Downloading zipped files package to MSDB and see how these roles affect the access to this package. Hands-On: Control Access to a Package with User-Defined Roles A user-defined role is another access control method that can be used in SQL Server 2008 Integration Services. The three fixed database-level roles can be used to create access control for user-defined roles to Integration Services packages. In this exercise, we will study how these roles work together and how they can be configured to control access. Method This is a three-step method, depending upon how much control you want. Configure the ServerStorage ProtectionLevel. c To use database-level roles to protect SSIS packages, you first have to enable this by telling Integration Services to use the ServerStorage ProtectionLevel. Add a user-defined role into the database-level roles. c After you’ve selected to store your package to SQL Server, you can add your user-defined role into the fixed database-level role to assign it preconfigured access permissions. Assign package roles. c For finer control, you can further assign package roles to your user- defined roles. e packages stored in the MSDB storage area in Integration Services are saved in sysssispackages table of the MSDB database. e sysssispackages table has three columns—readrolesid, writerolesid, and ownersid—that define the access permissions for the packages saved in the table. If you’ve been assigned the Reader role on a package, your user SID will appear in the readrolesid column and you can do read operations on the package such as open, execute, and export the package. Of course, with the Writer role, you have write access to the package such as delete, rename, edit, and save a package. ese roles are assigned while connected to Integration Services in SQL Server Management Studio. 284 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (Applying ServerStorage ProtectionLevel to the Package) You will start this Hands-on with server storage protection level. In this part, you will save a package to SQL Server, and will choose to rely on the server storage and the roles for access control. 1. Make sure you are logged on as administrator. Open the Downloading zipped files.sln solution using BIDS, and provide the package password when asked. 2. Choose File | Save Copy Of Downloading zipped files.dtsx As. This will open the Save Copy Of Package dialog box. Provide the following details in the dialog box, as we will be storing our package to SQL Server: Package Location SQL Server Server Localhost or provide your SQL Server name Authentication Type Windows Authentication Package Path /Downloading zipped files Click the ellipsis button in the Protection Level field and choose “Rely on server storage and roles for access control” for the Package Protection Level, as shown in Figure 7-5. Then click OK. Click OK again to close the Save Copy Of Package dialog box. 3. Choose File | Close Project and exit from BIDS. 4. Open SQL Server Management Studio and connect to Integration Services. 5. In the Object Explorer, expand the Stored Packages folder and then expand the MSDB folder. You will see a list of packages stored in the MSDB storage area. Right-click the Downloading zipped files package and choose Package Roles from the context menu. Figure 7-5 Selecting the ServerStorage option while saving a package Chapter 7: Securing Integration Services Packages 285 6. This will open Package Roles window, showing the package name and the default settings for the Reader role and the Writer role (see Figure 7-6). First of all, if your screen is showing the same dialog box as is shown in Figure 7-6, you have hit a bug in SQL Server 2008 Integration Services. This bug has been reported: The default roles shown in Figure 7-6 are actually the names of SQL Server 2005 Integration Services roles. However, this is just a display issue and has not caused any functional issues to date. Also, note that by default, the Reader role is assigned to the db_ssisadmin and db_ssisoperator fixed database-level roles and the creator of the package, while the Writer role is assigned to db_ssisadmin and the creator of the package. Exercise (Using Fixed Database-Level Role to Assign Execute Permissions to the Package) The detailed permissions for the fixed database-level roles define that the db_ssisoperator is able to execute any package. Also, db_ssisoperator role is assigned a Reader role on the package by default. So, we can assign our user-defined role permissions to execute the package by adding it to the db_ssisoperator role. In this exercise, we will assign execute package permission to a user-defined role team and will execute our test package Downloading zipped files. The steps of the process are as follows: Create a login for the ISUser02 user account and a user-defined role team. c Add the user to the team. c Assign the team group to db_ssisoperator role. c Figure 7-6 Reader and Writer role assignments to default package roles 286 Hands-On Microsoft SQL Server 2008 Integration Services In real life, to assign permissions to a group of users, you will create a user-defined role, make users members of this role, and assign permissions to this role to access the package and the database objects the package needs to access to run successfully. Finally, you will add the user-defined role to the pertinent fixed database-level role. 7. In SQL Server Management Studio, connect to the database engine, open a new query tab, and type the following query: USE msdb CREATE ROLE Team EXEC sp_addrolemember 'Team' , 'W8KR2\ISUser02' This script creates a user-defined role Team and adds ISUser02 as a member to the role Team. We have already created a login and a user account for ISUser02 in the MSDB database in Chapter 6. Refer back if you’ve missed those steps. (Note that W8KR2 is the computer name used in my setup environment. You need to replace this name with the name of your computer or Domain name if working on Active Directory.) 8. Run the command prompt as user ISUser02 using Runas command on your operating system. I’ve used the following method on my Windows 2008 server; type the following command in the Run dialog box: Runas.exe /user:W8KR2\ISUser02 cmd Enter the password when prompted and a cmd window opens up that is running as W8KR2\ISUser02. 9. Now run our test package as ISUser02 to check if this user has permissions to execute the package. Type the following at the command prompt and press : DTEXEC /SQL "Downloading zipped files" The package fails with the following error: Could not load package "downloading zipped files" because of error 0xC0014062. Description: The LoadFromSQLServer method has encountered OLE DB error code 0x80040E09 (The EXECUTE permission was denied on the object 'sp_ssis_getpackage', database 'msdb', schema 'dbo'.). The SQL statement that was issued has failed. This is okay, as the ISUser02 user account doesn’t have rights to execute the package yet. 10. Now, add the Team role to database-level db_ssisoperator role; this should be sufficient to assign the ISUser02 execute permissions, as the db_ssisoperator role has Reader Role privileges by default. Switch to SQL Server Management Studio and run the following T-SQL in the query pane: EXEC sp_addrolemember 'db_ssisoperator', 'Team' This will add Team as a member to the fixed database-level db_ssisoperator role. Chapter 7: Securing Integration Services Packages 287 11. Switch to the command prompt opened earlier for user ISUser02. Try to execute the Downloading zipped files package again. You will get a success message this time: DTExec: The package execution returned DTSER_SUCCESS (0). Exercise (Using Package Roles for Granular Access Control to the Package) By now you understand that you can quite easily assign permissions to user-defined roles and hence users or groups in your database using three fixed database-level roles. This is due to the fact that the fixed database-level roles have permissions on each package by default. If you need more control on packages and want to change Reader Role or Writer Role as per your needs, you can do so by removing default permissions from the package and assign the user-defined role directly. 12. Check the sysssispackages table in the MSDB database for the Reader role and the Writer role by running the following T-SQL command: USE msdb SELECT name, readrolesid, writerolesid from sysssispackages WHERE name = 'Downloading zipped files' You will get NULL for both the readrolesid and writerolesid fields. If the Reader role and the Writer role have default fixed database-level roles assigned, you will see Nulls in these fields. 13. Go to the Integration Services Connection in SSMS, right-click the “Downloading zipped files” package under the MSDB folder and select Package Roles from the context menu. Select the Team in the Reader Role from the drop-down list as shown in Figure 7-7 and click OK. 14. Now, execute the same T-SQL used in Step 1 again to see the roles in the sysssispackages table. You will see the SID for role Team added in the readrolesid field. 15. Switch to the command prompt opened for user ISUser02 and execute the Downloading zipped files package. You will see a success message, as you’ve added the user-defined role directly in the Reader role after removing the default permissions for database-level roles. Review In this Hands-On exercise, you learned how to assign a group a reader role. You first created a user-defined role, then added the required database user to the role, and then linked that role to the fixed database-level role db_ssisoperator. Similarly, you can . assigned while connected to Integration Services in SQL Server Management Studio. 284 Hands-On Microsoft SQL Server 2008 Integration Services Exercise (Applying ServerStorage ProtectionLevel. have hit a bug in SQL Server 2008 Integration Services. This bug has been reported: The default roles shown in Figure 7-6 are actually the names of SQL Server 2005 Integration Services roles reside outside the package. Using the preceding protection options may 282 Hands-On Microsoft SQL Server 2008 Integration Services lead to a false impression that all the data is secured. So you