Hands-On Microsoft SQL Server 2008 Integration Services part 31 pptx

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 t

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 f5 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 f5 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

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 f5 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

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 ctrl-shift-s to save all the files Close all the applications and log off

Figure 7-4 Error loading package with the EncryptAllWithUserKey protection level

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

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:

The db_ssisoperator role

roles You generally assign this role to users who need to execute the packages This 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

The db_ssisltduser role

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

The db_ssisadmin role

packages and package roles They have all the read and write permissions to

perform any operation on the SSIS packages The role can list, view, execute, and

export owned or other users’ packages This 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.

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.

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 The packages stored in the MSDB storage area in Integration Services

are saved in sysssispackages table of the MSDB database The 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 These roles are assigned while connected to

Integration Services in SQL Server Management Studio

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:

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

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

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 enter:

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.

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