I need to read/write to an MsSQL DB that uses AD to authenticate users. I have an account on that domain and I have been granted the appropriate priviledges on the MsSQL DB but because my PC does not authenticate to that AD Domain I am unable to access MSSQL.

Usually I just need to manually enter in my credentials when I connect to any server resources on that Domain like a file, web, or print server.

MsSQL is different. It does not give me the opportunity to manually log in.

In the ODBC driver it only has two choices. Use Windows NT Authentication (which does not allow me to enter a user name) or use SQL Server Authentication (which doesn't work because this DB uses Active Directory and not a local list)

So how can I log into a MsSQL server if my PC is not part of the authentication domain?Remember I do have valid domain credentials and have been granted the correct priveledges. It's just that my PC is not on the domain.

Thanks for any constructive advice. I will return the favor about any questions related to Enterprise Backup and Recovery, Disaster Recovery, Storage Area Networks, or Network Attached Storage. My areas of specialty.

  • can you "runas" your tool of choice with domain credentials? Jun 2 '09 at 5:09

Great question. I was going to say it wasn't possible until I tried it. You are trying to get a credential from a domain that your computer is not a part of. This blog shows how to invoke runas using /netonly to achieve this. /netonly is required because your domain account can't log in to your local machine.

From my home computer, VPN'ed to work, with no domain trust, I just authenticated using Windows Auth to a company Sql Server as follows

runas /user:mycompany\myname /netonly ssmsee.exe

This launches Sql Management Studio express. You could launch any program that uses the db connection in this way. The above trick appears to work for explorer and command shells as well. While this is a cool trick, it is simpler just to use Sql Authentication.

  • 1
    While using SQL auth may be simpler it is often not an option if you are in an environment that has strict audit requirements and an established provisioning process. Also, by relying on SQL auth for logon and not securing your data using AD users and groups, you are destroying the security that is available to you via Kerberos and the delegated security model. Jun 2 '09 at 8:22
  • 1
    Agree that Windows Auth is strongly preferred ( I just switched a dozen servers off SQL Auth ). Not everyone has unlimited time and technical savvy. Sql deployments range from Windows CE installs to clusters in a data center. There are cases where it is safe and much simpler to just use SQL Auth. Jun 2 '09 at 19:54
  • I tried this but I had to change the executable name to ssms.exe and unfortunately even then it just seemed to hung with the following type of message. Attempting to start smss.exe as user "mycompany\myname" ...
    – jpierson
    Jun 29 '16 at 13:39

This technote from IBM seems to suggest that this occurs when using named pipes. If you configure for TCP/IP connectivity, this may alleviate your issue



I've never seen the behaviour you describe, try conecting with TCP as Kevin Kuphal said.


If you hold down shift and right click you should be able to "run as a different user" - you can then specify the network credentials you wish to use to launch SSMS in the correct active directory context. If you're using Vista you can install the free tool which adds the context menu Microsoft removed (added back again in Windows 7 luckily) - search google for: sysinternals run as

Please let us know if that works?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy