I have an SSIS package that I'm trying to run from a SQL job. However, it fails, and the log claims that the password for the user specified in the connection string is wrong. For testing I've got the protection level set to EncryptSensitiveWithKey, and it runs fine from BIDS. When I import it into SSIS I change it to ServerStorage. (My understanding of the documentation says that this should work. I could be wrong though.) During the import it asks for the decryption key, which I supply, and everything seems fine.
It also seems fine when I set up the job in SQL Server Agent. However, when I run the job, it fails and the log says that the password for that user is incorrect. It doesn't say that there is a permission problem, but that the password is wrong.
I've been through the connections and double checked the username and password that is used to access the database. I can connect just fine with that username and password combination. This is the user that is used to connect to the database. There don't appear to be any problems executing the job.
Any help with this would be appreciated.
From what it looks like, it seems like you still need to modify the password after you have installed it to the SQL Agent. The decryption key decrypts the sensitive information but it is still tied to the person that created it. Have you tried re-entering the password when you install it to the server?
http://decipherinfosys.wordpress.com/2008/09/17/scheduling-ssis-packages-with-sql-server-agent/
Related
I migrated from SQL Server 2008 to 2019. On the old server there is set up a job, which calls a dtsx file. It needs database access, file system access because it saves tmp files to disk, and internet conneciton to send this file.
The connection string is defined followings:
<DTS:ConnectionManager
DTS:ConnectionString="Provider=SQLOLEDB.1;Password=p#ssword;Persist Security Info=True;User ID=MyUser;Initial Catalog=MyDB;Data Source=SQLServer\Instance;" />
If I run it using the Execute Package Utility it works. If I run it through the SQLServer Job, I get the error that the user is not granted to access the file system. The owner of the job is the same I am logged in and run the package using the Utility.
In the history i see:
The job failed. The Job was invoked by User Domain\RightUser.....
where RightUser is the Owner (and same as before, the same user run the package using the utility)
but the second row of the error:
Executed as user: NT Service\SQLAgent$AnotherUser.
And I have no idea where this AnotherUser comes from.
Whats wrong?
Furthermore, I don't really like the hardcoded password in the connection string, If the job run in its owner context, should it work changing the connection string to Integrated Security=True;, right?
This is a very common problem with running SSIS packages. That other user is SQL Agent, which in reality runs the package (this is the default user running the steps in jobs). Job owner has got nothing to do with running the SSIS packages. SQL Agent user name is set during the SQL Server installation. If it's omitted, the installer creates automatically a username like you described.
To the second question, yes you are right. If the user, who executes the package, has the correct permissions to the SQL Server described in the connection string, the userid and password are unnecessary. But in your case, the package is run by the SQL Agent with NT Service -level username, so it might be impossible to add that username to the SQL Server. You should set up a proper username for running the SSIS package and set it as a proxy account to the SQL Server, like described here: https://community.spiceworks.com/how_to/129293-configure-an-ssis-package-to-execute-as-a-proxy-account
following Problem:
I want to Check all Open MySQL Ports in a network and give myself a list of them.
After this i want to check if i can get access to the MySQL database from the open ports.
It Would be just a security check script to avoid other people getting access to the databases.
Bash/perl/Powershell... maybe someone can give me a hint?
You can use NMAP for all port scanning tasks.
EDIT:
Lets asssume an example: mysql-vuln-cve2012-2122(This vulnerability tries to access the MySql server through open ports by bypassing authentication, if possible, also dumps the MySQL usernames and password hashes.)
Pre-requisite: You need the 'Vulns' library to be installed separately. Please read the documentation, to know more about how to install and other details, since it would be too tedious to explain it here.
mysql-vuln-cve2012-2122.pass
MySQL password. Default: nmapFTW.
mysql-vuln-cve2012-2122.user
MySQL username. Default: root.
mysql-vuln-cve2012-2122.iterations
Connection retries. Default: 1500.
mysql-vuln-cve2012-2122.socket_timeout
Socket timeout. Default: 5s.
Please leave the password blank to check for non-password vulnerabilities.
Command to run:
nmap -p3306 --script mysql-vuln-cve2012-2122 <target>
Here is your MySql instance
This will give an output, something like this:
PORT STATE SERVICE REASON
3306/tcp open mysql syn-ack
mysql-vuln-cve2012-2122:
VULNERABLE:
Authentication bypass in MySQL servers.
State: VULNERABLE
IDs: CVE:CVE-2012-2122
Description:
When a user connects to MariaDB/MySQL, a token (SHA
over a password and a random scramble string) is calculated and
compared
with the expected value. Because of incorrect casting, it might've
happened that the token and the expected value were considered
equal,
even if the memcmp() returned a non-zero value. In this case
MySQL/MariaDB would think that the password is correct, even while
it is
not. Because the protocol uses random strings, the probability of
hitting this bug is about 1/256.
Which means, if one knows a user name to connect (and "root"
almost
always exists), she can connect using *any* password by repeating
connection attempts. ~300 attempts takes only a fraction of
second, so
basically account password protection is as good as nonexistent.
Disclosure date: 2012-06-9
Extra information:
Server granted access at iteration #204
root:*9CFBBC772F3F6C106020035386DA5BBBF1249A11
debian-sys-maint:*BDA9386EE35F7F326239844C185B01E3912749BF
phpmyadmin:*9CFBBC772F3F6C106020035386DA5BBBF1249A11
For more and detailed info, please refer the above link.
The NMAP tools will not only help you in getting the list of port related vulnerabilities. It can also be used to search for other vulnerabilities like MySql injection,DDOS, brute force vulnerabilities and lot more. Though you need to download separate libraries for those.
Deployed a new version of our app on heroku and migrated over database from previous free jawsdb instance. However now every time user signs up gives
(Mysql2::Error: INSERT command denied to user <username for instance
what have i missed
migrated using a dump and re-import using mysql command line. eye balled exported data and it seems to be there (user emails etc)
all config vars look ok (DATABASE_URL is mysql2...)
i can login to the database via the url
I have not had to grant access or anything like that before, anyone come across this?
thanks
Ben
My guess is they disabled your INSERT grant because you have reached your max Storage Capacity for your plan.
To validate this is a permissions problem, log into a MySQL prompt with the user the app is running as, and enter this query:
SHOW GRANTS;
It probably list many, but no INSERT.
See this link. As explained in given link, jawsdb preliminary plan does not give you permission to add a new database. You are provided with one schema with some random name and you have to work with that only.
Check your migration
e.g. Make sure the database name matches.
For me, I got the same error as OP when trying to migrate my data. This was a fresh account with only a 50kb'ish database; nowhere close to the free-plan 5mb limit.
In my SQL export statement, my local database name is being used, however the remote MySQL (ie JawsDB) service auto-generates a db name, which will obviously not be the same. Simply used find-replace to change the database name to match remote; everything works.
I have a SSIS package used the protection level as "DontSaveSensitive"
So initially I have saved the oledb connection manager password as in a XML config file. And this worked fine for me.
Now for business requirement I have stored the configuration in SQL Server.
Including password.
Initially it worked fine.But suddenly connection manager is not taking password from sqlDB.
If I set an environment variable for the "password" it's working.
My question is:
what is the solution for this. (I can only save the configurations in SQL)
initially how it worked. I mean initially from SQL Server the password was taking.
Please give some clue. I am doing a lot of trial and error.
How are you going to retrieve the password from the database if you need the password to connect the database?
There is a small article here about storing passwords which may help you.
I'm trying to use Sam Saffron's program SoSlow (as suggested here) for importing SO's data sump into MS SQL Server 2008.
Unfortunately, I have little idea of what I'm doing, and so do not know the Connection String that the program asks for.
I have tried the following syntax:
Data Source=SHIMI\SQLEXPRESS; Initial Catalog=SO; User Id=sa; Password=;
where SHIMI is the name of my machine, and SO is the name of the DB I've created.
SoSlow announces that the login fails "Login failed for user 'sa'".
Tried all other logins that are listed through the object browser in SQL Server Management Studio > Security > logins.
I have not altered the server in any way since install, defaults apply.
What am I doing wrong? (besides asking noob questions)
Thanks!
You would have set an SA password during the installation of SQL Server Express - if you don't recall it you will need to reset it. Follow the steps here to reset.