Not too long ago, I came across a scenario where a user needed to launch an application (e.g. SQL Server Management Studio) to access SQL Server, not such an unusual scenario. The catch was that the user was running the application from his personal laptop, which was not part of the domain on which the SQL instance resided on. The other catch was that the SQL instance was not configured for SQL Server Authentication. Someone had previously suggested the "Run as a different user" option, a good start in the right direction. However, the "Run as a different user" option wouldn't allow you to validate the account credentials since the laptop wasn't a member of the domain.
After the first suggestion, the user was ready to dismiss the issue as unresolvable. Fortunately, I got wind of this dilemma and was able to get this issue squared away. While I doubt this issue is encountered very often, I thought it would be useful information to share.
The solution to this problem is quite simple. Launch the application from the command prompt while specifying the netonly parameter. According to Microsoft, netonly indicates that the user account that is specified in the command will be used for remote access only. I've provided a sample of the command syntax below:
runas /netonly /user:domain\user "path to executable"
In the sample command above, the text in red color should be updated to include the user account that you want to use and the path of the executable that you want to launch.
I have, however, found that some applications do not clearer indicate that you are running it under a different account. Let me provide an example to better illustrate. Let's say that I'm logged into Windows under my local account, TC-PC\TCHANTRA and the user account that I want to use is IDERA\idera_svc. The command that I use to launch SQL Server Management Studio is the following:
runas /netonly /user:IDERA\idera_svc "C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\Ssms.exe"
Despite the user account being specified in the command, SSMS still shows the username that I'm currently logged into Windows as.
This can be a little confusing at first. It certainly makes you think that the command didn't work as anticipated. However, you can quickly see that it works after you attempt to log into the target instance and you are able to successfully log in. To confirm the login, I've used sp_who2 to validate which login was used from SQL Server Management Studio as shown in the screenshot below.
