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
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 two databases on the same SQL server. One for an ERP database that I am able to read tables and one I created in MS Access. A store procedure on the MSAccess database is updating some tables from the ERP DB. The MS Access DB from here on is independently running.
When I installed on other computers, the Access Database is giving me a connection error when I am logged in as another user than myself.
- Are permissions from the ERP database affecting me in my Access Database? Should I worry about them?
- Is Windows Authentication enough to make the connection happen?
- Do I need to Map the users over from the ERP database?? if so, how do I do it?
- Can I grant every user on the Server permission to access my tables using Windows Authentication? do I need to go down this road? How do I do it?
I am just not too sure what to do from here on. Here is some more information about the issue.
-In my database I have a ODBC stringconnection that looks like this:
Driver={SQL Server Native Client 11.0};Server=SERVER;Database=DATABASENAME;Trusted_Connection=yes;
-I am packaging an exe file using SSESETUP which is awesome.
-I am installing on the new computer and able to launch when I am logged on as myself however, I am getting a connection error when I am logged in as another user on the same computer. (Note: I am not able to debug from here on and see the vba because I am running under Access runtime 2013 only.)
I would appreciate if someone can assist me in narrowing my search for a solution.
Bottom line, it sounds like you need to set up database permissions on your SQL Server for each Windows account that will be using your Access db.
Here are specific answers to your questions:
Are permissions from the ERP database affecting me in my Access
Database
Yes, of course they are. Regardless of how you connect to the database the permissions will always be in effect.
Should I worry about them?
Yes, of course you should. Otherwise you won't be able to work with the data.
Is Windows Authentication enough to make the connection happen?
To make the connection, yes. SQL Server supports Windows authentication in both security modes (Windows only and mixed mode). But, this is just the connection. You also need to take the database permissions into consideration. Your Windows login needs to be granted the appropriate permissions within the specific database in order to do anything.
Do I need to Map the users over from the ERP database?
Map to what? Access? Based on the connection string in your question you're using Windows authentication to connect Access to SQL Server, so Access will connect to SQL Server under the security context of whoever is running Access. So the SQL Server permissions will need to be configured for each user who will be running your Access db.
Can I grant every user on the Server permission to access my tables
using Windows Authentication?
Access to the SQL Server tables? Sure, you could. But you should limit it to only the necessary permissions. Granting access for everyone is likely overkill and not best practice.
I have a server (2008R2) that has little Access (2010) databases relevant to departments and their needs. I have a new EHR server (2008R2) running SQL (2008R2) servers and am able to establish an ODBC connection between the two. I created the ODBC using the SA / SA password to the SQL Server.
As an administrator, I can log in to the Access database and run queries and reports based off of tables linked back to the SQL DB. No one else can. I did save the password when I created the External table link in Access. My Sys Admin - also Administrator, cannot run queries or reports logged into the Access database server for this DB.
On this particular SQL Server, I am not an admin under my login. I have to use the SA account to login to the backend or through the Management Console.
I need to have the EHR managers run their own reports. Does anyone have any experience with why the ODBC would not be allowing a connection for anyone but me when the connection is server based?
What Gord Thompson said is important. Access is not a database server and its engine runs on the client machine which will need copies of whatever DSNs are used.
But the problem of getting Access to 'remember' credentials is something I recall struggling with in Access 2000. My solution was to create a dummy pass-through query (anything that will run quickly) that stores the credentials. When a new client session starts, first call the dummy query and for the duration of their connection, they'll have access to the DSN in question.
I understand that the reason mixed mode allows login with Windows authentication is for security purposes. My boss asked me to create a setup.exe that installs:
our medical software
SQL Server 2008 R2
SQL Server Management Studio
The install is fully automated with limited user input. SQL Server and the SSMS are implemented with a config file. sa and serviceRXuser (strong passwords) are SQL Server authentication logins.
I don't want my clients to have access to our database, because editing drug data could be potentially life threatening. And yes, we have had clients alter things in our database... causing application errors that required re-installation.
Is there any way to, at least, limit access to keep end-users from editing the data? Preferably a T-SQL command so I can keep automation. If not, is there any way to hide the database?
first of all, don't share SA password (on any strong user password) with your clients :)
Your app is running on client machines and coonnect to SQL via ODBC?
hmmm.... it is hard, because the users can use Your ODBC connection from ACCESS and EXCEL too. Can you change Your app to don't use ODBC?
If You grant ONLY exec rights on stored procedures to serviceRXuser (don't need DB_DATAREADER or any other rights), then clients can't do anything, only what You can handle in SP-s. You can send an encoded parameter to every SP, and decode is wrong, raise any random error SQL ;) Users can't create this encoding from excel/access ;)
I have implemented an audit table in my sql server 2008 database using this technique which works exactly as I would want.
However, it relies on SYSTEM_USER to determine the username to write to the audit.
I am connecting to the database through an ASP.NET application, and am impersonating the windows user account in IIS to pass with the database using an integrated security = true connection. To enable the user to access the database I have had to grant them db_datareader and db_datawriter access.
This allows the audit to work as desired, however, I am concerned about security. How can I prevent a user connecting to the database using excel and reading all data?
Basically I want to accomplish 2 things:
Easily log audit records the windows user
Secure data access from anywhere other than my application
From my understanding I can have one or the other, not both.
If I allow access from the windows user I can easily audit, but data is insecure. If I connect with a specific service account the data is more secure, but the audit would not work as required.
Can anyone suggest a way of accomplishing both?