Integrated security/Windows authentication does not work in Windows 7 (or Vista?)
Question
Thursday, September 24, 2009 11:37 PM
I think this problem applies to Vista also, but i haven't tested it.
The problem is simply that unlike in XP, the Windows 7 client (not member of any domains) won't log onto the SQL server (or network shares, Exchange/Outlook) with the logged in username/password.
This was really convenient in XP, i could just create a user/pass like one on the server, and I would automatically be logged in to everything without even get prompted for user/password.
My SQL .net app crashes with the following error: "***Login failed for user ''. The user is not associated with a trusted SQL Server connection."
***Does anyone know if there's any way to fix this? Any hidden configurations to make Windows 7 work like XP in terms of authentication?
Or does anyone know a workaround on getting my app work under Vista/7? (without saving the password in the app). I want the app to use the current user's username/pass when connecting to the SQL server.
All replies (14)
Thursday, October 1, 2009 4:06 AM âś…Answered | 2 votes
Hi,
Well, if you are using VPN to connect to your server via Windows Authentication on a VISTA/7 client, you have to try the following steps.
- Locate the .pbk file that contains the entry that you dial. To do so, click Start, type *.pbk in the Research Bar, and then press Enter.
2. Open the file in Notepad.
3. Locate the following entry: UseRasCredentials=1
4. Modify the entry to the following: UseRasCredentials=0
5. On the File menu, click Save, and the click Exit.
And generally, the .pbk file can be found at *C:\Users\USERNAME>\AppData\Roaming\Microsoft\Network\Connections\Pbk
*Thanks.
Microsoft Online Community Support Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Friday, September 25, 2009 12:46 AM
Is you SQL Server configured for both Windows and SQL Authentication? If you are using Integrated Security, any reason why you are providing username/password. You could just say Integrated Security=SSPI (or) Trusted_Connection=True in your connection string.
Have you checked to make sure the user has the right permissions to connect to SQL Server?This posting is provided "AS IS" with no warranties, and confers no rights
Friday, September 25, 2009 3:21 AM
Hi,
I think you misunderstand the problem. The whole problem is that I do use "Integrated Security=True" - but that does not work for clients on Vista/7. It works fine on XP, but appearantly there's some fundamental changes in how "windows authentication" works in Vista/7.
There's definately nothing wrong on server side, or user accounts, cause as mentioned, the exact same user account works on XP.
I don't what's the difference between True and SSPI is, but SSPI did not work either.
According to MSDN Library: ***When true, the current Windows account credentials are used for authentication.
***This is NOT correct for Vista/7! I think the problem MAY be that Vista/7 sends User: "COMPUTERNAME\User", while XP sends just "User".
I've read a bunch of other people with the same problem, but i haven't found any solutions...
Friday, September 25, 2009 9:37 AM
I think the key here is that the XP machine seems to be running in the same domain as the server, while the Win7 doesn't.
Then if you use Integrated Security=TRUE (or SSPI) then the XP machine will use the windows account to log into the server however when
running on the Win7 machine then that machines windows account is not valid in SQL Server.
I simply think that when you say that you add a user/password on the server, those values are not beeing used, as mentioend,
if the app connects via SSPI then it uses that users windows account, not the SQL Authentication details.
In short, if you'd join the Win7 machine to domain, it will probably work.
Otherwise you will have to change the connectionstring to use User=<user>; Password=<password> and not Integrated Security.
Integrated Security will take precedence over User/Password in the connectionstring.
BTW, I've been running several Win7 machines with SSPI without any issues.
Also, when you say that Win7 doesn't use the windows account credentials, that doesn't seem to be correct, COMPUTERNAME\User is the windows account.
"Choosing an Authentication Mode"
http://msdn.microsoft.com/en-us/library/ms144284.aspx
HTH
//MichaelThis posting is provided "AS IS" with no warranties.
Friday, September 25, 2009 12:44 PM
As already mentioned, the XP computers are NOT part of any domain! They are set up THE EXACT same way as the Win7 computer, but in contrast to Win7, integrated security works right. In other words, i can run the app fine on any XP computer, as long as i'm logged on with a user that has the same username and password as the one on the server. I don't need to do anything serverside, or any configuration on client. The only thing that matters is that the username/password matches the server's! But this does not work on Vista/7.
And again, i'm not the only one who experiences this problem. Here's a few others:
http://social.msdn.microsoft.com/Forums/en-US/sqlsecurity/thread/c10865e1-e7a3-4977-8579-fbf80425bd92 (check the three last replies)
Friday, September 25, 2009 8:25 PM
Hi James,
This scenario should still work, but my understanding is that there have been some significant changes in Vista credential management that seem to be causing people problems. For a workaround, can you try doing the following?
- Open Control Panel
- Open Credential Manager
- Click "Add a Windows credential"
- Type the Server name that you are trying to authenticate to, the username (as Server\user), and password.
Try that and see if you are able to connect.This post is provided 'as is' and confers no express or implied warranties or rights.
Saturday, September 26, 2009 2:08 AM
Thanks for your reply.
I tried to add credentials using SERVERDOMAIN\Username, for the sql server (both IP and same URL as in connection string) both under "Windows credentials", and "Generic credentials", but it still it won't log on: "Login failed for user ''." error. Notice that the username is blank in the error... I could understand it if it was "Logon failed for user 'CLIENTCOMPUTER\User', but it almost looks like it doesn't send any user credentials...
Tuesday, September 29, 2009 7:04 AM
Hi,
Just as you mentioned, it seems that the issue relates to the client side.
First, I suggest that you can try to check if your browser has disabled the Windows Authentication feature. (Menu->Tools->Internet Options ->Advanced->Enable Integrated Windows Authenctication checkbox).
Second, I suggest that you can use HttpWatch to get the authentication tickets from explorers on XP box and Vista/7 box. Especially for those data on Vista/7 box, try to check the Headers for the request, and you can see if the value in Authorization attribute exists.
Besides, since Vista is using NTLM v2 authentication level by default, just try to enable NTLM.
Type "secpol.msc" in Run;
Expand local policies;
Click on "Security Options", and find "Network Security: LAN Manager authenctication level";
In the comming dropdownlist, choose "Send LM&NTLM - use NTLMv2 session security if negotiated";
Thanks.
Microsoft Online Community Support Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Wednesday, September 30, 2009 10:39 PM
I forgot to mention that i'm working with windows forms apps - not web apps. I tried what you suggested anyway, but it doesn't help. Still crashing with "***Login failed for user ''. The user is not associated with a trusted SQL Server connection."
***Just to be clear, I did not strip out my username before posting the error, it actually says [ for user '' ] indicating that it doesn't even send a username when integrated security is on.
I also forgot to mentioned that i'm connected to the server through a VPN connection (but again, this works fine in XP).
Thursday, October 1, 2009 7:42 PM
WOW!!! That solved the problem! THANKS!!
Friday, October 23, 2009 9:06 PM
I have been experiencing the same exact problems that Steven has been. I am in the exact same scenario where I am not joined to a domain. I am trying to connect to a remote SQL Server via Windows Authentication (that is enabled on the SQL Server). I am connected to the network via VPN (using NCP Secure Entry Client -- it's the only 64-bit VPN client I have found that works with Windows 7 thus far) and using Windows 7. I have set up both a Windows credential and a Generic credential just as I had my network password set up in XP. In XP, I had no problems connecting to the same SQL Server via Windows Authentication with either SSMS 2005 or 2008. Now that I've installed Windows 7, it keeps saying Login failed for user ''. The user is not associated with a trusted connection. I tried to follow Jin's solution above -- the .pbk file was not in the directory to which he pointed, but I did find it in the directory of the VPN client I'm using. There was not an entry for UseRasCredentials, but I added UseRasCredentials=0 anyway. I can still connect to the VPN, but my results trying to log on to the SQL server are the same. Are there any other suggestions or fixes to this issue out there?
Thanks in advance,
Ben
Thursday, December 3, 2009 5:36 PM
Has a final solution been found for this problem? I have virtually the same issue, except I am not connected via VPN, I am on site, but my laptop is not part of the domain. I always connected to the development servers in question using Windows Auth by adding machine/login/password to Network Logins in XP, and this still works in my XP Virtual Machine installation I still run. (this is via SQL Management Studio) But since I installed Windows 7 on my host machine, I cannot connect to ANY SQL Servers (2005 or 2000), even though I have setup the same access via "Windows Credentials" that comes with Windows 7. The error message I receive is also the same as above, that is the user name is blank (Login failed for user '' blah, blah), even though my local login is visible in the login window itself, and, as I stated, I setup my Windows Credentials for the servers in question. It seems SQL Management Studio no longer is aware of the network credentials...
Any help would be greatly appreciated!
Friday, December 4, 2009 3:28 PM | 1 vote
I found a work around at the following link:
http://codebetter.com/blogs/james.kovacs/archive/2009/10/11/tip-how-to-run-programs-as-a-domain-user-from-a-non-domain-computer.aspx
This appears to me to be a rather obvious bug with Management Studio...as the existing Windows Credentials on 7 work fine for file shares...just not with this application, or, from what I gather from other postings here (and elsewhere), any SQL Database connection.
Hopefully a fix comes out at some point. Good luck everyone.
Thursday, April 29, 2010 11:22 AM
Great hint, hurrah! You saved my week!!! Thx a lot!