NT Authentication with XP and VPN
-
Hi,
I recently upgraded my PC at home to Windows XP. Before the upgrade, I was able to connect to the SQL Server databases at work with NT Authentication through a VPN connection by logging in to my Windows 98 home system with the same username and password as I use at work. I would log into the pc, run the Shiva VPN software to connect to work and then fire up Query Analyzer with an NT authentication login with no problem. Since I switched to XP, SQL Server doesn't recognize my user id. I've been told that the only solution is to register my PC in the work domain but the server group won't allow that for security reasons.
Does anyone know of a workaround to this? We have just spent months moving everyone to NT authentication and we have several power users who log in from home.
Thanks in advance for any suggestions.
Don Keyes
-
What is the error message? Do you have similar problem if you work at office (PC is in Local Area Network)?
-
Hi,
I posted this from work so I'll have to capture the error message from home tonight. Basically it's saying that it doesn't recognize me as a known NT user id. Everything works fine at work because my pc is a member of the domain and I am able to log in and get validated by a domain controller.
-
One correction. We use Cisco VPN not Shiva VPN if that makes any difference.
-
What version of WIndows XP?
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley -
I am running Windows XP Professional from home. The error message is Server: Msg 18452, Level 16, State 1 [Microsoft][ODBC SQL Server Driver][Sql Server] Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.
My Query Analyzer client version is 8.00.194. I have the latest SQL Server service pack installed and a recent MDAC version. The XP is service pack 1 with the latest updates from windows update.
I hope that helps.
Don
Thanks
-
The problem you're running into is Windows 9x systems weren't actually part of the domain. Therefore, they could pass credentials without issue across domains. Now that you're on a WinNT-based kernel you're running into issues. In order to get Windows Auth to work, either your system at home is going to have to authenticate against the domain or you're going to need a local user account on the SQL Server itself, so far as I am aware. I'll look in the knowledgebase again, but I don't believe there's a way to use domain authentication otherwise.
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley -
Hi I have had a similar issue and the only way around it was to log in thru cisco vpn to the network then VNC(winvnc) onto one of my pcs at work and then coonect to my sql boxes and work as normal.This will allow you to use keberos/NT authentication.
-
It sounds like there is no workaround. I'm surprised that with all of the Microsoft publicity about being able to do anything from anywhere with .Net that they can't handle something as simple as validating my NT domain account through VPN.
I have WinVNC but it's very slow and it's not something that we want to give people outside of IS. I guess we will be staying with SQL ids for people who work from home.
One suggestion from our DBA was to set up a dedicated server in the domain with MS Office and SQL tools on it and let people connect to it with the Windows XP remote desktop connection software. It works much better than WinVNC.
Thanks everyone for the research and suggestions. If anyone comes across another workaround please post it here.
Don
-
Try starting up the application using the RUNAS command.
One thing you may need to do is an actual domain log on through dial-up first using the check box 'log on using dial-up connection'.
-
The problem is specific to SQL Server. If you were to Windows auth to a file share, you'd be okay. In that case the computer defaults to the domain. For whatever reason SQL Server seems to default to the local computer and I've never seen any literature on how to change that.
K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley -
I have a solution that works, without adding your home machine to your work domain. The below instructions are from memory, so the wording may be a bit off.
Go into Control Panel on your WinXP machine.
Go to User Accounts
Click on your user account
On the left hand side, there should be a list of options; click on Manage my network passwords.
Click on Add
On the line labeled "Server" put your FQDN for you SQL Server at work
(NOTE: you can apply this to ALL servers in your domain by using *.yourwin2kDNSdomain.com)
put in the user and password that you use at work
click on OK
Now try to log into your SQL server using windows authentication.
If this doesn't work, let me know since i really do have this working for me.
-
Thanks for the new suggestion. I'll try it from home tonight and post the results.
-
SUCCESS!!!!
I followed the instructions from mmortensen and it worked! It was even a little simpler than the instructions. All I had to put in was the server name, not the fully qualified server and domain name. For the id I had to put domain\id and then my domain password.
Thank you so much for your reply! You have saved us a ton of work!
Happy New Year!
Don
-
Thanks, mmortensen, this is a feature WinXP has Win2K doesn't. Guess it's time to see about upgrading the home systems.
I'm also going to have to pass it along to a few folks I work with who are in a similar boat but who have WinXP Pro at home.K. Brian Kelley, GSEC
http://www.truthsolutions.com/
Author: Start to Finish Guide to SQL Server Performance Monitoring
K. Brian Kelley
@kbriankelley
I'm also going to have to pass it along to a few folks I work with who are in a similar boat but who have WinXP Pro at home.Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply