I used to have a dts that had a sql server authentication connection. Basically, the userid password is stored in the package itself. Now, when I go to SSIS, the password is not getting stored to the package. I saw SSIS Connection Manager passwords when I googled the problem, but no one seems to have given a good resolution.
You can store the password in the configuration string by going to properties and adding password=yourpassword, but it's very important to put a space after the ; on the line before password and after the ; on the password line, as shown below:
Data Source=50.21.65.225;User ID=vc_ssis;
password=D#mc317Feo;
Initial Catalog=Sales;
Provider=SQLNCLI10.1;
Persist Security Info=True;Auto Translate=False;
Application Name=SSIS-PKG_CustomerData-{2A666833-6095-4486-C04F-350CBCA5C49E}IDM11.Sales.dev;
That answer points to this article: http://support.microsoft.com/kb/918760
Here are the proposed solutions - have you evaluated them?
Method 1: Use a SQL Server Agent proxy account
Create a SQL Server Agent proxy account. This proxy account must use a credential that lets SQL Server Agent run the job as the account that created the package or as an account that has the required permissions.
This method works to decrypt secrets and satisfies the key requirements by user. However, this method may have limited success because the SSIS package user keys involve the current user and the current computer. Therefore, if you move the package to another computer, this method may still fail, even if the job step uses the correct proxy account.
Back to the top
Method 2: Set the SSIS Package ProtectionLevel property to ServerStorage
Change the SSIS Package ProtectionLevel property to ServerStorage. This setting stores the package in a SQL Server database and allows access control through SQL Server database roles.
Back to the top
Method 3: Set the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword
Change the SSIS Package ProtectionLevel property to EncryptSensitiveWithPassword. This setting uses a password for encryption. You can then modify the SQL Server Agent job step command line to include this password.
Method 4: Use SSIS Package configuration files
Use SSIS Package configuration files to store sensitive information, and then store these configuration files in a secured folder. You can then change the ProtectionLevel property to DontSaveSensitive so that the package is not encrypted and does not try to save secrets to the package. When you run the SSIS package, the required information is loaded from the configuration file. Make sure that the configuration files are adequately protected if they contain sensitive information.
Method 5: Create a package template
For a long-term resolution, create a package template that uses a protection level that differs from the default setting. This problem will not occur in future packages.
I use a variable to store the entire connection string and pass it into the ConnectionString expression. This overwrites all settings for the connection and allows you store the password.
The designed behavior in SSIS is to prevent storing passwords in a package, because it's bad practice/not safe to do so.
Instead, either use Windows auth, so you don't store secrets in packages or config files, or, if that's really impossible in your environment (maybe you have no Windows domain, for example) then you have to use a workaround as described in http://support.microsoft.com/kb/918760 (Sam's correct, just read further in that article). The simplest answer is a config file to go with the package, but then you have to worry that the config file is stored securely so someone can't just read it and take the credentials.
Please check the configuration file in the project, set ID and password there, so that you execute the package
It happened with me as well and fixed in following way:
Created expression based connection string and saved password in a variable and used it.
Try storing the connection string along with the password in a variable and assign the variable in the connection string using expression.I also faced the same issue and I solved like dis.
Check the text contents of the connection manager file itself, the password field might be configured in the Project.params file, in which case entering the password into the connection manager window will cause it to not save.
Here is a simpler option that works when I encounter this.
After you create the connection, select the connection and open the Properties. In the Expressions category find Password. Re-enter the password and hit Enter. It will now be saved to the connection.
There is easy way of doing this. I don't know why people are giving complicated answers.
Double click SSIS package. Then go to connection manager, select DestinationConnectionOLDB and then add password next to login field.
Example: Data Source=SysproDB1;User ID=test;password=test;Initial Catalog=ASBuiltDW;Provider=SQLNCLI11;Auto Translate=false;
Do same for SourceConnectionOLDB.
Related
I'm maintaining a project using Microsoft SQL Server 2016 (SP1) (according to this script) which heavily depends on recurring jobs (mirroring certain external db's and so on).
Especially the mirroring jobs are essentially based on SSIS packages which define a datasource, then execute a hardcoded SQL query and afterwards store the results in the specified destination.
Unfortunately the source databases where moved to a different domain and thus aren't accessible via the previous url.
My issue right now is that I simply have to change the source destination url but I'm not able to do that. There are plenty of ways to 'modify' SSIS packages but none of them seem to work with me.
What I managed (and seems the most promising) to do is to open the 'Integration Services...' part of my db, export the jobs to my desktop, modify them with Notepad and reimport them. And they seem to work if I execute them separately. But as soon as I try to execute the packages via SQL Server Agent it fails screaming:
Description: Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state."
Does somebody know whats going on here and how I'm able to solve this? No password or username changed, only the connection string.
Is it even possible to manage a package like that?
Thank you for your help!
After further investigation I detected that even a newly created job didn't run properly. It was kind of strange that a package would run without any issues while directly executed but not via the SQL Server Agent, so I assumed it may be a rights issue and it was!
Somehow the Server Agent wasn't allowed to decrypt (although I never changed the executing user of a step) the password anymore.
I was able to work around my issue by simply creating each SSIS package again (some click hell but ok) but this time I secured 'sensitive data' with a password instead of the users key.
Afterwards I had to change each job step with a reference to to the damaged ssis packages and obviously type in the new passwords.
Seems to work again.
Thanks anyway
I have an SSIS Package which is used to connect Oracle. I used the Oracle Provider for OLEDB connection manager in SSIS. I have specified my server name, user name and password, selected the check box "Allow Saving Password". It is running fine on my machine but when I give a copy to another developer, he fails to run as he gets null password error. Is there a way to save password in SSIS Package so that we don't need to worry about that?
Your goal is the Package Protection Level. By default, it is set to EncryptSensitiveWithUserKey. This means, that all passwords are encrypted using the authors Windows Account. As soon as another user tries to load the package, the passwords will be lost.
There are some other options for this package property. One option would be to use EncryptSensitiveWithPassword or EncryptAllWithPassword. Using these options, anyone can open an run the package as long as he/she has the password.
Yet another option would be to use the option DontSaveSensitive. You will then use the Expressions of the Oracle Connectionmanager to overwrite either the password or the full connection string. I can confirm that this is working pretty fine, we are using this method for our Oracle passwords for years. As this option results in having the password saved on your system(s) unencrypted, you need to be sure to secure it in some other way.
Further reading: https://msdn.microsoft.com/en-us/library/ms141747.aspx
You can utilize XML configuration files to store the passwords, but since they are stored in clear text, additional safety measures would be advised to protect the files from prying eyes.
This MSDN blog illustrates how to add and utilize configuration files very nicely.
I am an Oracle guy who suddenly got SQL Server and SSIS dropped in his lap, so I am probably not using the terminology in the correct manner, but here goes:
There is a SSIS package that pulls data from the Oracle database into our SQL Server 2008 R2 warehouse. If I open this package in SSIS Visual Studio 2008, I get prompted for a password:
The sensitive data in the package 'MyRefresh.dtsx' is encrypted with a password.
for the package itself. I enter the password. I run the package. Works great.
The previous guy had loaded this package into SQL Server with a job to run at 1am every day and it worked great there too.
Recently, there were some database changes. The package, of course, stopped working. I was able to fix it, and, again, it runs great if run through SSIS Visual Studio 2008. However, when I loaded it into SQL Server, and the job runs, it fails with:
0xC001405F Failed to decrypt an encrypted XML node because the password was not specified or not correct.
Where/how to I specify the password so the job can run?
Late answer, but might be helpful to other users/thread visitors
In short, to load the package to SQL Server it must be exported with new credentials specified, and then imported back into specified folder.
Here is the article I found on setting the SSIS package encryption manually in SSMS, that provides a quick tutorial on how to Import/Export an encrypted package.
Please note that the Protection level option regards sensitive data, in one case, or all the data included in particular package in other. Data that is considered sensitive is set by default in Integration Services: variables previously marked as delicate, non-changeable XML tags, which are controlled by the SSIS service, and password, which can be considered sensitive if the ‘Encrypt all data with password’ is chosen.
Package protection levels:
Do not save sensitive data: if sensitive data exists, it will not be included after the exporting of the new package, remaining unavailable;
Encrypt sensitive data with user key: sensitive data will be encrypted with current user credentials, and package still can be used on local server. Which data will be considered as sensitive, depends on the creator/owner of the package;
Encrypt sensitive data with password: with this level, a password must be provided – this kind of encryption is desirable, if user want to keep only sensitive data private.
Encrypt all data with user key: same as the encryption of sensitive data, it can be used on local server, but it regards all the data within the package;
Encrypt all data with password: this level encrypts all data within the package, password is required, and it provides a 100% privacy.
Hope this info is helpful.
If you have the opportunity I suggest you no longer use the EncryptAllWithPassword protection level. Read here for more info about package encryption levels:
http://sqlblog.com/blogs/eric_johnson/archive/2010/01/12/understanding-the-ssis-package-protection-level.aspx
In short the idea of package encryption is to stop people opening up the package XML to extract plain text passwords. But generally this is implemented in a insecure manner which defeats the purpose.
I suggest you use windows authentication throughout instead:
Ensure your Oracle server supports external authentication
Create an externally identified login to Oracle using the SQL Agent windows service account
In your Oracle connection manager, use external authentication (login with user / and no password)
If you have any SQL Server connection managers you need to do the same (in SQL Server this is called windows authentication)
Lastly ensure that all developers are set up with windows authentication in SQL Server and Externally identified authentication in Oracle so they can run the package in BIDS
Now you don't need to encrypt your package anymore (you can use DontSaveSensitive). The authority for all operations are against the SQL Agent service account.
You don't need to remember a package password or an Orace login password any more.
Also for example if you need to rotate the password on your Oracle login, originally you would have to go and change this password in Oracle and in your package. But by using windows authentication this is no longer necessary.
I can give you more info if you are interested.
You can use the /de switch along with the dtexec utility for your password like so:
dtexec /f <filename> /de <password>
I developed an SSIS package which runs fine i VS. To deploy the package, I need to send it to the DBA to deploy on the server but am getting login errors. I've narrowed it down to (what I believe is causing the issue) is the "ProtectionLevel: EncryptSensitiveWithUserKey" setting.
so when the dba opens the visual studio project, he doesnt get the passwords because of the settings and then running the dtsx files fails on the servers.
How do I properly send in the project so he can deploy it without re-typing in the passwords?
http://sqlblog.com/blogs/eric_johnson/archive/2010/01/12/understanding-the-ssis-package-protection-level.aspx
It sounds like Server Storage or Dont Save Sensitive with a configuration package is the way to go for your scenario.
Another option is to store the connection strings that require the passwords as string variables and hard-code the values. This is a pain when you need to change the password, however.
You need to set the SSIS ProtectionLevel (property of the package) to EncryptSensitiveWithPassword. This will force you to add a new password to the package. Your dba will be prompted for this package password when the package is opened. Without the password, access to the sensitive data (i.e. connection passwords within package) will not be possible.
I have an SSIS Package that sets some variable data from a SQL Server Package Configuration Table. (Selecting the "Specify configuration setings directly" option)
This works well when I'm using the Database connection that I specified when developing the package. However when I run it on a server (64 bit) in the testing environment (either as an Agent job or running the package directly) and I Specify the new connection string in the Connection managers, the package still reads the settings from the DB server that I specified in development.
All the other Connections take up the correct connection strings, it only seems to be the Package Configuration that reads from the wrong place.
Any ideas or am I doing something really wrong?
The only way I was able to do this was to use Windows Environment Variables. You can specify things like connection strings and user preferences in environment variables, and then pick up those environment variables from your SSIS Task.
I prefer to use Server Aliases in the SQL Client Configuration. That way, when you decide to point the package to another SQL Server it is as simple as editing the alias to point to the new server, no editing necessary in the SSIS package. When moving the package to a live server, you need to add the aliases, and it works.
This also helps when you have a real painful naming convention for servers, the alias can be a more descriptive name than the actual machine name.
I didn't actually understand your question completely but I store my connection settings in a configuration files usually one for each environment like dev, production etc. The packages read the connection settings from the config files when they are run.
When you're creating a job to call the SSIS package, and you're setting up the step, there is a tabbed area. The default tab is where you set the package name, and the next tab over is where you can set the configuration file. Have a config file for each package, and change for the server (dev, test, prod). The config file can be put directly on the dev, test, and prod servers, and then point to them when setting up that job.
If u are using SQL Server Package Configuration then all the properties of the packages will come from SQL Server table - Please check that
SSIS security the way it stands is terrible. No one will be able to support things when I am out of the office. The job never reads from the configuration file...I give up. It only works when I edit the string in the Data sources tab. However the password gets lost if you happen to go into the job a second time. Terrible design, absolutely horrible. You would think that when you specify a xml file in the job step it would read the connection string from there that is defined, but it does not. Does this really work for anyone else?
Goto the package properties and set deployment True. This should work for what you have done.
I had the identical question, and got the same answer, i.e. you cannot edit the connection string used for package configurations hosted in SQL Server, except if you specify that the SQL Server connection string should be in an environment variable.
This unfortunately does not work in my dev setup, where two environments are hosted on the same machine. I ended up following Scott Coleman's approach as detailed on SQL Server Central [Free sign-up and a good site]. The trick is that you create a view to store your configuration settings on one central server, and then use the machine that connects to it to determine which environment is active.
I used that approach, but also used the User connecting to the environment to make a determination, because my test and dev setups run on the same SSIS instance, but as different user names. Scott suggests in the comments that the application name should be set, but this cannot be changed in the package execution job step, so it was not an option.
One other caveat that I found was that I had to add "Instead of" triggers to my view to do the inserts, updates and deletes for configuration variables.
We want to keep our package configs in a database table, we know it gets backuped with our other data and we know where to find it. Just a preference.
I have found that to get this to work I can use an environment variable configuration to set the connection string of the connection manager that I am reading my package config from. (Although I had to restart the SQL Server agent before it could find the new environment variable. Not ideal when I deploy this to Production)
Looks Like when you run an SSIS package as a step in a scheduled task it works in this order:
Load each of the Package Configs in the order they appear in the Package Configuations Organiser
Set the Connection Strings from the Data sources tab in the Job Step properties of the Scheduled Job
Start running package.
I would have expected the first 2 to be the other way around so that I can set the data source for my package config from the scheduled job. That is where I would expect other people to look for it when maintaining the package.