Possible to log into another Windows account using "SQL Server Authentication"? - sql-server

If I want to log into a SQL Server instance using another Windows account can I do this by simply selecting "SQL Server Authentication" as my authentication mode and entering the DOMAIN/username and password for the account I want to use?
Are there any special settings that I need to set in order to get this to work?

No. 'SQL Server Authentication' works only with SQL Server logins, it won't work with a NT login. To log in as another credential have the process run as the credential you desire to run as. Use runas, most likely you want to run SSMS like this:
runas /netonly /user:domain\user "c:\program files\...\ssms.exe"
By specifying the /netonly argument your SSMS will run with the desired NT credential only for remote hosts, locally will have your local credentials. This not only preserves your SSMS environment (last used files, options etc) and doesn't require domain\user to have local priviledges, but, more importantly, it works even for a completely unrelated domain. That is if you machine is in domain foo (or not even joined to the domain) and the desired runas is in domain bar, the runas /netonly /user:bar\user ... will run just fine.
The /netonly trick works only if the SQL server host you are connecting to is remote (not on the same machine). If is local, then your runas must be locally using the desired credential, so remove the /netonly argument.

If you have Windows 7, you can add credentials for other domains via Control Panel > Administrative Tools > Credential Manager. Map your credentials to each server you want to log into.
Then, log into additional machines using Windows Authentication. I think there is a caveat - it will try to log you in to the server using your current domain/username. IF that is rejected, it will lookup any entries you have for that server in Credential Manager, and if those are valid, you will be logged in.

If I understand the question correctly, the solution it just ship + Right click on your SSMS, that will give you "connect as different user" option and that where you want to put your windows authentication. Domain\User and password.

Related

How can we pass encrypted password in SQL connection string on PowerShell?

How can we pass encrypted password in SQL connection string on PowerShell?
Unable to connect SQL server with NT AUTHORITY\ SYSTEM account. What teps need to be taken to connect to SQL Server with NT Authority\System account?
As checked, I installed PSTools and extract all files in specific location and ran cmd.
With below cmd
psexec -i -s ssms.exe
After running the above cmd, I got :
couldn't install
Access denied
You dont say much about the client and what you are supposed to achieve. The part about psexec is quite hard for me to understand.
You can use credentials in two ways from local network, sql login and windows login. I assume you are attemting to use windows login.
If you, from a windows computer, run a console app or desktop app, you will connect as the user who started the app. In normal terms, you.
Since you get "NT AUTHORITY\SYSTEM", I guess you want to try as similar as possible like a Windows Service. My recommendation is to start the service as a named user "AD\MyServiceAccount". You give access to this user in SQL server.
I recommend you to read about the differences of:
NT AUTHORITY\System
NT AUTHORITY\NetworkService
AD Account
If you are not trying to debug/build a service, but just want to get some sql server data in an desktop application. Use regular tools and your personal account. If not, sql login.
If you want to use the Computer Account, you should use add AD\$ComputerAccount to ACL list on SQLserver.
Note: AD being the name of your Active Directory.

Login SQL Server without having password with mapping an environment variable to password

I want to define password in environment variable inside windows and instead of password give users the environment variable to login.
Do we have such thing in SQL Server? And how they can login with environment variable through SQL Server Management Studio?
No. The SQL Client drivers won't pick up credentials from environment variables. If you are writing an application you can do that and pass them to the driver. But there's no way, say, to cause SSMS to pick up credentials from the environment.
On Windows your users should connect using Windows Auth, using their own identity. Alternatively you can override the users' Windows identity with credentials stored in the Windows Credential Store, or provided while launching the process with runas to impersonant another user locally and on the network, or runas /netonly to only use the provided credentials with network authentication (NTLM).

Attempting to use an NT account name with SQL Server authentication

The authentication mode is "Mixed" for my SQL Server 2016.
I'm using SSMS to run cross-server queries.
I've checked the user account & have ensured that the account has proper authority. I can use a different account and run cross-server queries as expected. The account has proper authority to the databases in question and it has authority to them. I've tried everything I've seen on the internet searches I've done and no luck. The account can login using SSMS.
My linked server properties are:
The account's login properties are:
Has anyone else seen this & have a resolution?
** EDIT: rebooting the target server fixed the issue
When creating a linked server you choose the authentication mechanism by which the remote connection will be made. If you select the fourth option (pictured), the remote login must be a Sql Server authenticated login. It cannot be a windows login.
The only way to connect through a linked server using windows authentication is to forward the credentials of the login on the local server. There is no option to specify a windows username and password.
Indeed, there is no way, ever, to specify a password when connecting to a Sql Server with windows credentials, since the whole point of windows credentials is that you're already authenticated. That happened when you logged in to windows in the morning*
You can only (and must always) specify a password if you are using Sql Server authentication.
What seems to be going on in your case is that the linked server may have been created with the wrong security options. This is just easier to explain with an image:
* More precisely, a connection will be made using the account that the client is running under. If you start SSMS using a "runas /user ..." command, then the windows credentials used to connect to servers will be the credentials specified in runas

How to enable sa login when doing an unattended install of SQL Server 2014 Express?

I have an installer that's running the SQL Server 2014 Express installer in unattended mode.
Basically, it's creating a command-line and running the setup.
My problem is that I need to be able to connect to the installed instance as admin using SQL Server authentication.
The command-line already contains /SECURITY MODE=SQL. I can create a SQL login and login successfully, so that part of the problem works fine.
My problem is that while I can see sa in sys.server_principals, it's flagged as is_disabled, and I can't login using it.
Is there a way, when running the SQL Server 2014 install unattended, to pass command line arguments that will have it enable sa so I can successfully login using it?
Or some other login, if that's easier.
What I need is a sql_login that I can use to connect to the database as an db administrator without regard for the permissions of the logged-in windows user, after having run the installer in unattended mode.
The full commandline args:
/QS /IACCEPTSQLSERVERLICENSETERMS /ACTION=Install /FEATURES=SQL
/INSTANCENAME=SQLEXPRESS /SAPWD="SQLSVCPASSWORD"
If I login to Windows using an admin account, I can connect to the database using Windows authentication. I can then create a normal SQL Server login. With that, I can then login using SQL Server authentication and that account.
So I'm certain the DB is in mixed mode. And this:
Exec xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'LoginMode'
returns '2'.
My problem is that I need the users to be able to run the software without being a windows admin. And part of what the software needs to be able to do is to drop and create databases, within the instance.
So I need SQL admin permissions, without depending upon the windows user having elevated permissions.
===
The setup tool I'm using is configured using XML files that contain, in them, LUA scripts that build and run the Windows Installer package command lines. Between the nested languages and various levels of escaping, I'd not noticed that the "/SECURITYMODE=SQL" argument was commented out, and not included in the command line.
With it included in the command line, the "sa" user is enabled.
TL;RD If you want the "sa" user enabled, after an install, include "/SECURITYMODE=SQL" on the command line.
You need to specify /SAPWD as well when using /SECURITYMODE=SQL. I am not sure, but if you do not specify the password, it will be disabled by default.
Have a look at this article https://learn.microsoft.com/en-us/sql/database-engine/install-windows/install-sql-server-from-the-command-prompt?view=sql-server-2017 for more information.

How to use Windows Authentication with SSMS without using RunAs?

I have SQL Server 2012 installed as a standalone instance in Windows 8 Enterprise edition. It is running in Mixed-mode. The currently logged in account is a member of local MACHINE\Administrators and the local BUILTIN\Administrators group is in the sysadmin role. For good measure, the current user is also in a MACHINE\SQLAdmins group which is also in the sysadmin role.
When I launch SQL Server Management Studio (SSMS) from the shortcut, I can't use Windows Authentication. I get the following error:
TITLE: Connect to Server
Cannot connect to INSTANCENAME.
ADDITIONAL INFORMATION:
Login failed for user 'MACHINE\user'. (Microsoft SQL Server, Error: 18456)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=18456&LinkId=20476
In fact, if I launch LinqPad from a shortcut, I can't connect to the server using a connection string which relies on Windows Authentication.
However, if I run SSMS or LinqPad with elevated privileges using RunAs Administrator, I can use Windows Authentication and the experience is as expected.
Alternatively, I can include the RunAs command into the SSMS shortcut like so.
C:\Windows\System32\runas.exe /USER:MACHINE\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
Surprisingly, double-clicking the shortcut will prompt for me to enter the password of the current user. However, once that re-authentication occurs, SSMS will allow Windows Authentication of the current user.
The question is, what user is SSMS running under when I double click the shortcut and ultimately, how can I just run LinqPad or SSMS or any other app that connects to the database with Windows Authentication without first elevating my privileges?
Are you by any chance supplying the credentials of the user who installed SQL Server when you use Run as?
See the second answer on this SO question:
In previous versions of SQL the BUILTIN\Administrators group was given
the sysadmin role. Local administrators are not given login privileges
by default in SQL 2008. Only the user performing the install is
defaulted sa privileges. During install you have the option to add
additional users, but you apparently did not.
You will need to login as sa and configure whatever windows logins are
required (such as the local administrator account).
I had the same thing happen, where my user account was a local admin, and yet unable to login until the guy who installed SQL Server added my windows account to the SQL Server logins manually.
In previous versions of SQL the BUILTIN\Administrators group was given the sysadmin role. Local administrators are not given login privileges by default in SQL 2008. Only the user performing the install is defaulted sa privileges. During install you have the option to add additional users, but you apparently did not.

Resources