November 15, 2011 at 7:32 am
I have a user that is trying to connect to one of our SQL Servers and he gets the following error:
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
After looking in the SQL Error Logs, the following error is raised:
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed
This user changed is password recently and this error is now happening. I can't find any good articles on this. Can anyone help?
Thanks,
Bill
November 15, 2011 at 7:35 am
has the user logged off and back on again after changing his password? if not this is a good place to start as the servers will be trying to authenticate using the old password not the new password.
I used to get this with the developers at my old job, they always locked their machines never logged off which caused this problem every 45 days
November 15, 2011 at 8:06 am
Ufortunately, they did log off and the issue is still happening.
November 15, 2011 at 8:14 am
bpportman 52825 (11/15/2011)
Ufortunately, they did log off and the issue is still happening.
Not to worry, always try the most obivous thing first.
Few questions
Has the users machine dropped out of the domain? Might have some IT systems process which cleans up AD for users who havn't logged on or machines that haven't been connected in X amount of days.
Are you using multiple domains? Is there two way trusts between the domains
Is the users machine in the same domain as the server?
Has the users account been granted access to SQL?
Might be a bit obivous the last one but just gotta check.
What other troubleshooting have you done?
November 15, 2011 at 8:17 am
I have had this issue in our company when we have multiple domains. I connect to my laptop using my office domain and Remote Desktop into Servers using datacenter domain.
November 15, 2011 at 10:42 am
Drop & Recreate Login.
To create a SQL Server login that uses Windows Authentication (SQL Server Management Studio)
1. In SQL Server Management Studio, open Object Explorer and expand the folder of the server instance in which to create the new login.
2. Right-click the Security folder, point to New, and then click Login.
3. On the General page, enter the name of a Windows user in the Login name box.
4. Select Windows Authentication.
5. Click OK.
November 15, 2011 at 2:38 pm
Thanks everyone. We only have one domain. The user can log into this computer with no problem. Still searching....
November 15, 2011 at 2:42 pm
Silly question, is the Login added to the server with permissions to connect to a database(s)?
November 15, 2011 at 3:22 pm
hi!
i have create a vizual c# program linq to sql ..when i whont to open the databse from vizual i have this error ...
Cannot open database requested by the login. The login failed. Login failed for user
please can someone help me ??
November 16, 2011 at 4:51 am
hi!
i have create a vizual c# program linq to sql ..when i whont to open the databse from vizual i have this error ...
Cannot open database requested by the login. The login failed. Login failed for user
please can someone help me ??
Please don’t hijack someone else thread. You already started a new Thread, right?
November 16, 2011 at 4:58 am
bpportman 52825 (11/15/2011)
Thanks everyone. We only have one domain. The user can log into this computer with no problem. Still searching....
I understand, user would be able to Login to Computer but not with SQL Server. It happens after a password change (some sort of caching, I am not sure). Drop & re-Create SQL Server Login (Windows) as I mentioned below. Also, crosscheck user's privileges for connection.
November 16, 2011 at 11:04 am
Thanks for you help all - the problem has been solved. This is the message I got from our network admin.
I was able to fix this yesterday after some serious troubleshooting. We ran a piece of software that allowed us to see where this user was trying to log in what was causing the lockout from his machine and from the SQL server. I had asked the user a few times if he had anything running anywhere or logged in anywhere, and he said no.
So we ran this tool that allows us to see where his ID might be used and it came up there were a couple of SQL servers where using his ID. They were being used for SQL reporting and DBs running scripts with his ID. So what happened was when he changed his password over vpn on the weekend, something happened where it broke and it didn’t propagate everywhere and it didn’t update everywhere. So his old password on these SQL servers were still using and turning to connect to the network with his old credentials.
So I went in and removed his credentials from those SQL boxes and problem was solved.
November 17, 2011 at 1:19 am
bpportman 52825 (11/16/2011)
Thanks for you help all - the problem has been solved. This is the message I got from our network admin.I was able to fix this yesterday after some serious troubleshooting. We ran a piece of software that allowed us to see where this user was trying to log in what was causing the lockout from his machine and from the SQL server. I had asked the user a few times if he had anything running anywhere or logged in anywhere, and he said no.
So we ran this tool that allows us to see where his ID might be used and it came up there were a couple of SQL servers where using his ID. They were being used for SQL reporting and DBs running scripts with his ID. So what happened was when he changed his password over vpn on the weekend, something happened where it broke and it didn’t propagate everywhere and it didn’t update everywhere. So his old password on these SQL servers were still using and turning to connect to the network with his old credentials.
So I went in and removed his credentials from those SQL boxes and problem was solved.
It justifies my suggestion. If you would have drop the Logins (forcefully) all of these connection would have been invalidated. Everything would be smooth thereafter (Creating a New login).
November 17, 2011 at 1:21 am
this is a good reason why service accounts should be used with none expiring passwords to run SQL server services
November 17, 2011 at 1:23 am
Dev (11/17/2011)
bpportman 52825 (11/16/2011)
Thanks for you help all - the problem has been solved. This is the message I got from our network admin.I was able to fix this yesterday after some serious troubleshooting. We ran a piece of software that allowed us to see where this user was trying to log in what was causing the lockout from his machine and from the SQL server. I had asked the user a few times if he had anything running anywhere or logged in anywhere, and he said no.
So we ran this tool that allows us to see where his ID might be used and it came up there were a couple of SQL servers where using his ID. They were being used for SQL reporting and DBs running scripts with his ID. So what happened was when he changed his password over vpn on the weekend, something happened where it broke and it didn’t propagate everywhere and it didn’t update everywhere. So his old password on these SQL servers were still using and turning to connect to the network with his old credentials.
So I went in and removed his credentials from those SQL boxes and problem was solved.
It justifies my suggestion. If you would have drop the Logins (forcefully) all of these connection would have been invalidated. Everything would be smooth thereafter (Creating a New login).
In this instance this wouldn't of helped as they detail there are multiple SQL servers at play here, not just the one having the issue with the login. It seems that there where a number of SQL servers running under the users account, as this was locking the account out at AD level when the account tried to authenticate with SQL, AD said no as the account is locked.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply