There's a file stored in SharePoint that I want to use as data source in my SSIS package that will be run by SQL Server Agent.
The SQL Server Agent uses an account that doesn't have access to this file, so I want the Excel connection to use different login credentials (you can specify them in OLEDB connections). Is there any way to do this?
I know that the simplest way would be to just grant the permissions to the account that SQL Server Agent uses, but our responsible person is away. Changing the credentials in SQL Server Configuration Manager is not an option.
MS SQL Server 2008R2, Server Integration Services Version 10.50.1600.1, Sharepoint2010,
You can set up a proxy account that has the appropriate permissions to the location of the excel file and then set the job to run as that proxy account.
https://technet.microsoft.com/en-us/library/ms190698%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396
Related
I have a question with regards to configuring database connections in SSIS to SQL server and using AD credentials other than the regular user account. Is this possible to do, or do i need to use a SQL user account?
Our IT department just recently went through a change and split our user account to have a regular account and admin account. Since then, one of our guy's is struggling with some SSIS packages as well as some PowerBI dashboards that he had created, since now his regular user account no longer has access to the databases.
I'm thinking that it is probably best just to create a SQL user account, but he wanted to try and configure it using his admin credentials. Just wondering what others usually do with respect to this?
By the way we're using SSIS 2014
Thanks
The normal way to do this is to configure the SSIS host process to run as the target account. There's no way to embed AD credentials in a connection string, like with SQL Auth.
So in the normal case where SQL Agent runs the SSIS packages, you configure the AD credentials as a SQL Server Credential, and create a SQL Agent Proxy. Then whether the Agent job launches DTEXEC.EXE directly, or calls the SSISDB stored procedures, the package execution will use the AD account of the Proxy, and your connections to SQL Server can use Integrated Security.
I have a an SSIS solution that runs fine in BIDS. However, once I try to deploy it to the server and execute through SQL Server Agent, it fails with:
Cannot access datafile...
Details:
server: localhost that I built
sysadmin: my local domain account is the sysadmin using Windows Authentication
filepath: my local C:\Users\me\Downloads
I have tried mapping my login to a credential and using that credential as a proxy, but it still fails.
Can someone help with a step-by-step solution as to how to make sure the SQL Server Agent account has access to write and read files on my local file directory?
look that：
What is the service account for SQL Server Agent? Is has privilege to access operation sytem?
I am running SQL Server 2014
I am trying to set up a scheduled SQL Agent job that runs an SSIS package and I need it to use a SQL Authentication login in order to access all the applications/servers the SSIS package accesses.
I have created a Credential that is mapped to the SQL Authentication login and connected it to a Proxy which the SQL Agent runs as when accessing the SSIS package, however, the job fails with an error message:
Unable to start execution of step 1 (reason: Could not get proxy data for proxy_id = 1). The step failed.
I have confirmed that:
I can access all servers/applications using the SQL Authentication account
The SSIS package connections are configured for SQL Authentication
I can run the SSIS package manually using the SQL Authentication fine
All accessed SQL Server Databases are configured for both Windows AD and SQL authentication login
When I create the SQL Server Agent Job, the step that runs the SSIS package has an option for the SQL Server Authentication login but the option is greyed out and I cannot select it:
I feel like I am missing a very obvious step but it's eluding me, any assistance will be appreciated.
#oscar and #chuck are both correct SQL Agent jobs running SSIS packages cannot run in SQL Authentication mode they have to use Windows Authentication. The user that runs the agent job unless you specify otherwise is the SQL Agent service account. It is that service account and the SQL Service account on the server you are running it on that will need certain permissions. However, you can change which account it executes as per chuck's note. Of course depending on who many different servers you are passing credentials and what is being accessed you can also get into a kerberos double hop problem...... Trust me solving that last part not so fun but still doable.
However the thing is if you must use SQL Authentication you don't need a windows user at all. you can put the SQL Authentication credentials in your connection strings of the connection managers in SSIS package. The SQL Agent service account can handle any file access issues for you and your connection strings can pass the sql credentials. no double hop problem and easy. If you are worried about embedding credentials you should use a less privileged sql account but you can also encrypt them and store them with the package. There are also several ways of dynamically getting them from an encrypted state.
I have SSIS packages that have connections that use project params(only database and server), the actual login is set to windows authentication.
So when a SQL Server Agent runs that job step(package) how does it connect with windows authentication? Does it use it's own service account? If so as long as the service account has the same permissions as my windows account it shouldn't have issues right? All the objects in the SSIS packages are tables stored in that same server instance.
If I had external objects that use tables on different servers and such would it encounter issues then?
If the job owner is sysadmin and different server are in same domain it should be straight foward.
The secure way is to create a proxy on sql and give the Windows auth credentials. Then configured the package to run as "proxy defined".
I have built an SSIS job in visual studio 2005 that accesses a flat file and updates a table in SQL Server 2005. This works perfectly. I then store a copy on SQL Server by using the server storage option in the protection level property. When I try to run this it cannot locate the flat file. The flat file is located on a server and I use the IP address to access it. I have noticed that if I remove my maping to this server and run the job from visual studio, it cannot find it either. Hoe do I access the file from SQL Server 2005 ? I intend to schedule this job to run automatically on SQL Server.
Many Thanks for any help you can give.
Ronnie Carlin
Just to avoid anything more complex being the issue, check what account the job is being run under (e.g. has a procy and credential) or whether it is using the base SQL Agent account, and then check whether that account has access rights to the folder \ file you are trying to import.
Had that catch us out more than once.
Edited to include the additional information in the main answer.
When SQL Agent runs a job it does not use your account, even if you initiated the job execution - it uses the SQL Agent account. The account the SQl Agent is set up under (by default) or a named account you specidy with a proxy / credential. You might be able to access the folder, but you need to check what account SQL Agent is running under and whether it can access it.
To find out which account the job is running under by default you can access it via
Start -> Program files ->SQL Server -> Configuration Tools -> SQL Server Configuration Manager. In the 2005 Services SQL Server Agent will be listed, right click properties, first tab shows what account the Agent is being run under.
However, if you need a job running under a specific account I would advise you create a proxy / credential and not alter the agent account - since that is the account all the other jobs are using.
Credential and proxy are different objects within SQL, Credentials are stored under the security folder / credentials - that is where you create a credential and place your AD username / pwd.
The proxy then asks you to select a credential from the list of credentials already stored on the system - not your domain\user at that point.