I have a regular job that runs on a DataProc cluster, one of the steps involves connecting to a client's SQL Server DB to pull some data. We have been provided a SQL Login and password for this.
I'm told they are changing their security policies to only allow connection via integrated security, but I am unsure how to determine what user actually runs these jobs, or how to set it up so it uses integrated security.
Any help would be much appreciated, let me know if I need to provide more detail.
Related
Testing SQL queries with large datasets against Azure SQL server may be costly, so it is better for me to test my code against a local server. I would like to create a new local server with "SQL Server authentication" rather than "Windows authentication", and I would like to keep my default local server that uses Windows authentication.
In lack of better phrasing:... is it "common" to have multiple SQL servers with different authentication methods on the same Windows-10 pc ?
If it is "straight-forward" to do this, then please share "how-to", or share better jargon for web searches. I did not find much information on this when googling "create new local server with sql server authentication"
As you may easily catch from the text: I'm not an IT expert...
Yes, you can use at an instance and solely your will to provide the accesses.
where you can use Windows Authentication mode and mixed mode.
More information about Windows Authentication may be found at: Connecting Using Windows Authentication.
We may utilize SQL Server Authentication to solve your problem by passing the user name and password.
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 wanted to read AWS Postgresql from within SQL Server, so
I created a system ODBC connection to Postgresql on the SQL Server machine, tested it, fine.
I then created a Linked Server to connect to postgresql.
In the Security tab (For a login not defined in the list above, connections will), I selected "Be made using the login's current security context".
When using this linked server while connected to SQL Server through windows authentication, it works fine.
If I connect to SQL Server using a SQL Server authenticated account, trying to access postgresql data through that same Linked Server fails authentication.
I fixed that by switching my security setting to "Be made using this security context" and giving the POSTGRESQL login/password (same that I gave at the ODBC level).
Question:
Without repeating the postgresql details at the Linked Server stage, why is it working with Window sauthentication account and not for SQL Server authenticated accounts?
Neither are relevant to Postgresql?...
I made it work but still confused...
I will have to guess a bit to help you, but I hope to give you enough context to understand what is happening so you can debug further.
When you connect to SQL Server using integrated authentication, the domain controller gives out a token to talk to SQL and this is used to authenticate your connection from your client to SQL Server's process. Underneath the covers, Windows can use either NTLM or Kerberos to do this handshake. You can read more about this here in this blog post:
NTLM vs. Kerberos Blog. This protocol choice matters when trying to use linked servers since it has to then authenticate to something else over the network.
At this point, it matters what credentials are used to run SQL Server (usually as a service in the services window to see). If you are running SQL as Local System or Network Service or something else defined by windows (instead of as a specific user on the network), it may or may not have permissions to talk out to your target remote server (whether it be postgres or something else). When you use Kerberos and enable delegation (which the domain admin needs to do), you can have the original integrated auth credentials "flow" over the linked server link to the next connection. NTLM does not do this. Therefore, the usual scenario is to create a map in the local SQL Server of what credentials to use when talking out to a remote linked server.
If you are talking to an ODBC driver, then you are likely using the msdasql (OLEDB to ODBC bridge) provider and then also having to go through its authentication stack. It has been too long for my memory as to whether it even supports integrated auth at all, much less delegation in Kerberos. However, you may be able to debug this problem further if you:
consider which account is running SQL
consider which mechanism is used to do integrated auth to sql and whether that would work with delegation
determine which credentials are used to make the outbound connection to your ODBC target. You should be able to debug much of this through the profiler mechanism as there is a distributed query/linked server set of events IIRC.
I can't speak to your postgres provider specifically, but this should give you some more tools to debug. Hope that helps you get one step further.
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
I have one web server & one DB server (running SQL SERVER 2008). Both the servers are in different domains. The web server is allowed to communicate(the communication takes place internally without the intervention of firewall) directly with the DB server, it is given Admin privileges & the DB access through SQL is going on without any problems.But whenever the web server tries to access the Reporting Server & its services, its asking for a separate authentication(Local system account authentication has been configured for SQL Server). I want to know whether is there any way to get rid of this separate authentication for Reporting Services
If you are being prompted for credentials when running a report, then your data source is configured to prompt at run time. You'll need to change the DS to use a SQL login if you don't want this to happen. Your windows credentials cannot be passed from one server to another.
If you are being prompted to log on to the RS site - I've only experienced that on firefox but fixed with a firefox config setting to save the cred for the domain.