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"
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.
I try (for the first time) to create a user account on my SQL Azure database.
I have read in some blogs that I have to create these command lines
CREATE LOGIN login_name WITH PASSWORD = 'strong_password';
CREATE USER 'user_name' FOR LOGIN 'login_name';
And then
USE [Database];
GO
GRANT CONNECT TO login_name;
But, when I try to connect with this new account on my database, I have the message error 916
The server principal "login_name is not able to access the database "master" under the current security context.
I don't understand because the don't create my new user for the master but for a specific database in my SQL Azure environment (I have 5 databases in my SQL Azure by the way)
If you have any idea to help me, thanks in advance
When first logging in, unless a database is specified in the connection string, a login connects to its default database. If the database is not specified in the CREATE LOGIN statement, the system default of master is used.
To fix this, use this for your CREATE LOGIN:
CREATE LOGIN login_name WITH PASSWORD = 'strong_password',
DEFAULT_DATABASE = MyDatabase;
I just installed Firebird for Win64, and I was trying to connect to the employee database which comes pre-packaged with ISQL.
Following the steps from the Firebird official QuickStart Documentation I opened the ISQL utility and entered:
connect localhost:employee user sysdba password masterkey;
As a result I got:
Statement failed, SQLSTATE = 28000
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
Strangest thing is that if I navigate to the employee database sample itself and issue the isql command from there I can successfully connect.
The difference is that connecting directly to a database file doesn't require a password, it will even ignore the password, and just use the provided user to know which privileges to apply.
Without a hostname, ISQL will by default use Firebird embedded mode, and not the server. To compare, try using isql employee.fdb (or isql employee), it will just login with your current OS username, while isql localhost:employee will fail with a 'Your user name and password are not defined'.
It looks like you specified a different password than the default of masterkey, or somehow the sysdba account wasn't initialized. I recall there was a problem with the installer of an earlier Firebird 3 version, but I don't think 3.0.2 should be affected by this (or at least: it worked for me).
If the SYSDBA account wasn't initialized, then follow the steps of the Firebird 3 release notes, section Initializing the Security Database:
Initialization Steps
Initialization is performed in embedded mode using the isql utility.
For an embedded connection, an authentication password is not required
and will be ignored if you provide one. An embedded connection will
work fine with no login credentials and “log you in” using your host
credentials if you omit a user name. However, even though the user
name is not subject to authentication, creating or modifying anything
in the existing security database requires that the user be SYSDBA;
otherwise, isql will throw a privilege error for the CREATE USER
request.
The SQL user management commands will work with any open database.
Because the sample database employee.fdb is present in your
installation and already aliased in databases.conf, it is convenient
to use it for the user management task.
Stop the Firebird server. Firebird 3 caches connections to the security database aggressively. The presence of server connections may
prevent isql from establishing an embedded connection.
In a suitable shell, start an isql interactive session, opening the employee database via its alias:
> isql -user sysdba employee
Create the SYSDBA user:
SQL> create user SYSDBA password 'SomethingCryptic';
SQL> commit;
SQL> quit;
To complete the initialization, start the Firebird server again. Now you will be able to perform a network login to databases,
including the security database, using the password you assigned to
SYSDBA.
Where 'SomethingCryptic', should be your password.
If a SYSDBA user was created, you will need to change its password if you no longer remember what you set. Follow the same steps, but in step 3 do:
SQL> alter user SYSDBA set password '<new password>';
SQL> commit;
SQL> quit;
If this gives an error "record not found for user: SYSDBA", make sure you are really connected as SYSDBA, otherwise retry the original step 3. Not having admin access will behave as if the user doesn't exist, so the error is the same if the user really doesn't exist, or if you are connected with an unprivileged user.
CONNECT 'employee' user 'SYSDBA' password 'masterkey';
You need make sure that your alias.conf have something like this: employee=C:/examplepath/employee.fdb
make sure that the services of firebird is on
After running these commands against an Azure SQL Server (in SSMS or using a command line utility):
-- run in the master table to create the login
CREATE LOGIN SusanDBA with password= 'U$3r---Pa55W0rd!!'
-- run against AnotherDB (not the master db)
CREATE USER SusanDBA from LOGIN SusanDBA
SusanDBA can login to open a connection to the AnotherDB but cannot execute the Alter Login command to change the password. This reportedly has to be done against the master database. But we don't want the user to connect to the master db for security reasons.
The command
Alter Login SusanDBA
with PASSWORD = 'U$3r---Pa55W0rd!!---'
OLD_PASSWORD='U$3r---Pa55W0rd!!'
Gets the response
Msg 5001, Level 16, State 3, Line 1 User must be in the master
database.
An administrator with appropriate master privileges can change the password but that kind of defeats the purpose: the administrator now knows the user's password.
Constraints:
- We are not in a position to use AD in this case so its SQL Authentication.
- We would like to use a command prompt utility like SQLCMD.
Correct syntax on March 2021
ALTER LOGIN [login] WITH PASSWORD='XXX' OLD_PASSWORD='NNN';
ALTER USER userName WITH PASSWORD='newPassword' OLD_PASSWORD='oldPassword';
also reference:
https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-user-transact-sql?view=sql-server-ver15
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