Windows Authentication behaves oddly when VPN'd
- by Dan F
Hi all
We've got a few apps that rely on windows authentication - a couple of web apps with AD auth turned on and we usually connect to our SQL servers with windows auth. This normally runs without a hitch. It doesn't work so well if we're VPN'd to a client site though.
SSMS
Opening SSMS normally from the start menu, then picking a server that normally accepts windows auth, results in a message saying:
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (.Net SqlClient Data Provider)
If I drop to a command prompt and use runas /user:domain\user to launch SSMS I can successfully windows auth to our SQL server instances with that ssms process.
If I look in task manager, both copies of ssms.exe (start menu vs runas) have the same user, and I can see no discernible differences between the processes in procexp.
AD Auth websites
If I open IE and browse to any of our websites that require an authenticated windows user, I get the "who are you" prompt, and that dialog thinks I'm whoever the VPN user is. I can click "Use another account" and authenticate that way though.
Outlook
Even Outlook prompts for a username when we are VPN'd!
It's affecting our Win7 and Vista machines. It's been a while since we had an XP box, but I don't recall having this issue on XP for what it's worth.
The VPN connections are just using the built in windows VPN connections, they're not fancy cisco VPNs or anything of that nature.
Does anyone know how to tell windows that I'd like to be my normal old primary domain user rather than the VPN user when authenticating to resources in our domain? Heck, I'd be happy with a solution that prompted me with the "who are you" if I was trying to access windows auth requiring resources on the client's VPN.
Thanks!
Apologies if this is more a superuser question, I wasn't sure which site it best suited. It's about networking and infrastructure and plagues all of our developers here, so I hope it's a serverfault Q.
