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.
Related
Our SQL server agent already setup an AD account (e.g. MyCompany\Bob) for scheduled jobs. The logon setup is done via service.msc.
Recently, we have a new T-SQL job that connects to another SQL Server instance via linked server. Another AD account (MyCompany\Alice) is required for connection.
Is it possible to setup like that? Thanks
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".
The Oracle Wallet Manager allows admins to store and manage database login credentials securely by wrapping the them in a password-protected container. I have used this in the past to run VBScripts that update tables in an Oracle database, without prompting the user for a password or storing the password in cleartext in the script itself.
Now, I have written some Powershell scripts that update a SQL Server database, but I have had to store the passwords in cleartext in the scripts.
I was wondering if there was an equivalent to the Oracle Wallet feature in SQL Server? Or would I have to store passwords in a text file and encrypt it using Powershell's ConvertFrom-SecureString? I'm looking for a secure and flexible solution.
The easy way for one-off scripts, accessing specific databases, is to use scheduled tasks. You set them to run as a specific account which has the appropriate permissions, then you don't have to worry about SQL Logins or passwords.
If you want something similar to Oracle's Wallet manager, then you should look at Credentials, and Proxies in MS SQL server.
See: Security Questions: Logins Credentials and Proxies
The Credential allows you to store and manage Login information.
A proxy is used by SQL Server Agent to map credentials to SQL Server Agent subsystems (i.e. PowerShell or SSIS).
Here is a link to a detailed guide on creating Credentials and Proxies and: Run Operating System Commands in SQL Agent using PowerShell
Our custom SharePoint site uses a standard connection string (in web.config) to a remote sql server using a sql server authentication. I need to know if it is possible to change this connection to use a SharePoint service account instead of a sql server account. If so, how do specify the service account in the connection string and how do you create a login and user for an sp service account when that user does not exist on the sql server machine and nor is it available on Active Directory.
Update:
I think I need to use integrated security in the connection string and run db calls within SPSecurity.RunWithElevatedPrivileges block. If i use this as a delegate, what sp account will the code be executed under and how do i assign a sql server login to a sharepoint account on a remote machine. Any links to sample code or articles explaining this process would be helpful.
Thanks.
From the SQL Server side, you should create a domain account for Sharepoint in AD. Then you log in to SQL Server via Management Studio (SQL2005 or later), on the left hand side click on security tab, and add a new login - you'll enter the domain Sharepoint service account, and give it the relevant permissions to the databases it needs to access.
For the Sharepoint side, you probably can edit web.config but there must be a Sharepoint admin tool to take care of this properly.