My current application uses very powerful credentials to access the SQL Server back-end database. I want to improve the security in my application by using an application role created.
For example, if I created one called app-role, with a password:
EXECUTE sp_addapprole #rolename = 'app-role', #password = `right pony duracell binderclip`
I want to enable the use of this application automatically during connection by specifying it in a connection string. I don't want to risk there being any places in the software that are accidentally not re-engineered to call:
EXECUTE sp_setapprole #rolename = 'app-role', #password = `right pony duracell binderclip`, #encrypt = 'odbc'
So obviously I want this to happen automatically during connection.
Bonus Chatter
The application roles feature was first added in SQL Server 2000.
Bonus Reading
How to to use SQL Server application role in my connection string
Related
I have a local SQL Server. My computer login is Domain\myName.
The local SQL Server instance allows me to sign in using Windows authentication. I am in logins as Domain\myName. I am using a third party app that creates a directory that only Domain\myName can access.
So I tried to create a credential for Domain\myName and then use a proxy to run a SQL Server Agent job that writes to that directory. However, when I right click on credentials, the only location that show up is <mycomputername>, so Domain\myName does not appear in the identity list.
How can I get Domain\myName to be able to run a job with the correct authorization to write to a directory?
Thanks
If you mean that SSMS dialog is not giving you a picker to select a Domain account, just use TSQL
USE msdb ;
GO
CREATE CREDENTIAL myNameCredential WITH IDENTITY = 'Domain\myName',
SECRET = 'G3$1o)lkJ8HNd!';
GO
-- creates proxy and assigns the credential
EXEC dbo.sp_add_proxy
#proxy_name = 'Proxy for myName',
#enabled = 1,
#description = 'Proxy for myName',
#credential_name = 'myNameCredential' ;
GO
-- grants the proxy "Proxy for myName" access to
-- the Powershell Scripting subsystem.
EXEC dbo.sp_grant_proxy_to_subsystem
#proxy_name = N'Proxy for myName',
#subsystem_id = 12 ;
GO
Create a SQL Server Agent Proxy - Using Transact-SQL
Note that the TSQL job step doesn't do a real local logon for the proxy account, so you'll have to use PowerShell or CMDEXEC.
We have a SSIS package which accesses database columns which are encrypted using Always Encrypted.
This does not work when triggering the SSIS package through a SQL job using a proxy user.
Failed to decrypt a column encryption key using key store provider 'mssql_certificate_store'
We have tried logging in to the server as the domain user and triggering the SSIS package manually and we don't receive this error. So it seems that there is some issue accessing the certs when a proxy user is activating the ssis package.
Code for the setup of the proxy user:
CREATE CREDENTIAL [SSIS Credential]
WITH IDENTITY = N'DOMAIN\service_ssis_user', SECRET = N'DomainPassword'
IF NOT EXISTS (SELECT name FROM sysproxies WHERE name = 'SSIS Package')
BEGIN
EXEC msdb.dbo.sp_add_proxy
#proxy_name = N'SSIS Package',
#credential_name = N'SSIS Credential', #enabled = 1
EXEC msdb.dbo.sp_grant_proxy_to_subsystem
#proxy_name = N'SSIS Package', #subsystem_id = 11
EXEC msdb.dbo.sp_grant_login_to_proxy
#proxy_name = N'SSIS Package',
#login_name = N'DOMAIN\service_ssis_user'
END
GO
The aim is to get the SSIS package running as the domain user and able to access the certificates associated with this user
Update:
The proxy user does not "login" as the user that I have created credentials for, it simply uses the security context of the user to run the command. So it does not load their windows user profile which would happen when logging in directly as the Domain User. And therefor the certs are not accessible when running via proxy. I dont know how to get around this issue however.
Windows user profile is not Loaded when a proxy account is used. As a result the certificates associated with the user are not accessible when running via proxy.
I'm trying to script a creation of SQL Server identity to be then used to execute SQL Server agent jobs via a proxy.
It looks as though I can only use a Windows account and thence I would have to provide its password in plain text. Seriously? There must be a better way to do this. I need this script to work on my team-mates' machines as well as mine:
USE [msdb]
CREATE LOGIN [proxy_login] WITH PASSWORD=N'passw0rd',
DEFAULT_DATABASE=[SSISConfig], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
CREATE CREDENTIAL [my_cred] WITH IDENTITY='proxy_login', SECRET='passw0rd'
EXEC msdb.dbo.sp_add_proxy
#proxy_name=N'My_Proxy',
#credential_name=N'my_cred',
#enabled=1
Error:
Msg 14720, Level 16, State 1, Procedure sp_verify_credential_identifiers, Line 69 [Batch Start Line 0]
The operation failed because credential '#credential_name' identity is not a valid Windows account
In ideal world I would like to use the SYSTEM_USER login for the credential without having to supply their password.
Yes your assumption is right, credentials cannot be created for SQL Server logins it can only be Domain users (visible from your SQL Server), and yes you have to pass the password when creating credentials.
Once credentials has been created one or more proxies can use them.
Typically proxies in SQL Server are used to facilitate cross domain processes. A process executing (probably SSIS job etc.) on DomainA\ServerA at run-time will access databases on DomainB\ServerB, The user account running the job on DomainA\ServerA must have access to DomainB\ServerB. Now in this case a proxy on DomainA\ServerA can be used with the credentials of a User, let say UserB from DomainB with access to ServerB etc. The proxy at run-time when reaches to DomainB will provide the credentials for UserB and the process can continue to run.
SQL Server Agent jobs which run via Proxy needs Credentials. These credentials will usually accept windows username-password.
Better way:
If you're concerned with the security aspect, I will suggest you create a Powershell utility which will prompt for windows username, password(star marked) and set it directly in credentials and create proxy out of that via sql query execution.
sample(.ps1 file):
# read from user input
$Winpwd = read-host "Enter windows Password for ""$(whoami)""" -AsSecureString ;
$BSTR=[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($Winpwd)
$Winpwd = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
#execute sql
Add-Content main.sql "CREATE CREDENTIAL SSISAdmin WITH IDENTITY = '$(whoami)', SECRET = '$Winpwd';"
Add-Content main.sql "GO"
I've got an application which is running under under the credentials of the local user. However, I would like to allow this application access to a MSSQL database using specific credentials.
This isn't a problem if I use an SQL login, however I would like to use a specific Windows account for which I have the username (along with the domain) and password. Note that I do NOT wish to run the entire application using these credentials.
Is this at all possible? This SO question seems to suggest that using Integrated Security=SSPI in the connection string WITH Windows credentials specified will allow me to login to the database as that user, however I was not able to do this on my test machine.
Given how the SQL Server Management Studio logs into databases (i.e. it uses the current credentials or specified SQL credentials, but doesn't seem to permit specified Windows credentials) I'm thinking this cannot be done, but I would like a confirmation of this...
You could deal with this as the SQL Server end
by encapsulating the tasks that need done under the other account in a stored procedure created using the "EXECUTE AS Clause"
Create Proc sp_Dosomething_As_specific_user
WITH EXECUTE AS '{SpecificUser}'
BEGIN
/*Do Something*/
END
and allow the user account execute permissions on that
GRANT EXEC ON sp_Dosomething_As_specific_user TO {Actual_User}
For fuller details on the "EXECUTE AS" clause look at this
http://msdn.microsoft.com/en-us/library/ms188354.aspx
This means that you've limited the user to running only a specifically predefined action or set of actions as the other user as opposed to a general permission to let them impersonate the other user
Which is going to help keep whoever is responsible for IT security happy
I can not access my sql server connection from c# code. I get this error:
Sql Exception: No Process Is on the Other End of the Pipe
thats the connection string in my app.config:
<add name="DefaultConnection" providerName="System.Data.SqlClient" connectionString="Data Source=BELLA\SQLEXPRESS;Initial Catalog=TLP;User Id=pascal;Password=test;Pooling=False"/>
When I use windows authentication: Integrated Security=True;
Then I can connect to the database.
BUT I can NOT use windows authentication because the opening of the sql connection is done from within a windows service which is run as LocalSystem. When I do this I get this error:
Login failed. Login failed for user 'NT AUTHORITY\SYSTEM'
Its the first time I create a login + user in sql management studio so I am nearly sure I did something wrong and its my fault.
This is what I did:
1) Create a new login in the server`s security folder with sql authentication user:pascal and password:test.
2) Went to my database and create a new user in the security folder with user: pascal and login: pascal and schema: dbo
3) Did I forget something?
Solutions from other people:
1) I have also tried this link but no luck my Sql Select on the suspect_pages table is empty.
Error: No process is on the other end of the pipe
2) My Sql Server network configuration has ENABLED on the tcp/ip, names pipes and shared memory settings.
3) SQL Server 2008 can't login with newly created user
Number 1 to 3 did not help at all.
All this is done on my local machine. No network is here.
Did you enable Shared Memory and TCP/IP providers in SQL configuration?
If not, try opening the SQL Server Configuration Manager utility and enabling Shared Memory and TCP/IP. The order that works for me is Shared Memory (1) and TCP/IP (2) for both server and client.
Also, make sure you are creating both a SQL LOGIN and DATABASE USER for PASCAL with correct rights.
Check out my blog article on creating logins. http://craftydba.com/?p=656
The snippet below will blow away and recreate your login/user with the correct default database, default schema and read/write privileges.
-- Which database to use.
USE [TLP]
GO
-- Delete existing user.
IF EXISTS (SELECT * FROM sys.database_principals WHERE name = N'pascal')
DROP USER [pascal]
GO
-- Which database to use.
USE [master]
GO
-- Delete existing login.
IF EXISTS (SELECT * FROM sys.server_principals WHERE name = N'pascal')
DROP LOGIN [pascal]
GO
-- Add new login.
CREATE LOGIN [pascal] WITH PASSWORD=N'test', DEFAULT_DATABASE=[TLP]
GO
-- Which database to use.
USE [TLP]
GO
-- Add new user.
CREATE USER [pascal] FOR LOGIN [pascal] WITH DEFAULT_SCHEMA=[dbo]
GO
-- Add to database read / write roles
EXEC sp_addrolemember 'db_datareader', 'pascal'
EXEC sp_addrolemember 'db_datawriter', 'pascal'
GO
-- Add to database owner role?
-- Only give out if application needs a high level of privileges.
-- EXEC sp_addrolemember 'db_owner', 'pascal'
-- GO
Server level protocols.
Client level protocols.
I never choose NETBIOS since it is a non-routable protocol.
If you are still having issues, please post a screen shot and more details.
Probably an unusual scenario but I just got this exception and tracked it down to an invalid database name in the Initial Catalogue value of the connection string.