Login to MsSQL without first Authenticating to the AD Domain
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.
Solution 1:
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.
Solution 2:
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
http://www-01.ibm.com/support/docview.wss?uid=swg21133904
Solution 3:
I've never seen the behaviour you describe, try conecting with TCP as Kevin Kuphal said.