Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
can you "runas" your tool of choice with domain credentials? –  Alexander Taran Jun 2 '09 at 5:09
add comment

4 Answers 4

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.

share|improve this answer
    
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. –  Ryan Fisher Jun 2 '09 at 8:22
    
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. –  Precipitous Jun 2 '09 at 19:54
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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?

share|improve this answer
1  
For the scenario where computer is not in the domain, you'll need to register it with ShellRunAs /regnetonly. Also useful on Windows XP. While XP has only RunAs in context menu, not Run As (Netonly) technet.microsoft.com/en-us/sysinternals/cc300361.aspx –  Precipitous Jun 2 '09 at 16:12
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.