Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have a timeclock database setup on a Windows 2008 server, SQL Server. It has been working for MONTHS. Today, all of a sudden, it seems like some peoples’ logins are working and some peoples’ logins are not working.
SQL authentication works fine, however the Windows authentication is not working. I checked the log files and it seems like SQL Server 2008 is just not liking the passwords!
Does anyone know what could be going on here?
Windows auth relies on the SIDs contained in the login token generated when folk log in to Windows: not the actual windows password or even username
If it’s failing, then you have issues witg Active Directory or some underpinnings such as Kerberos.
Saying that, there are some common issue I’ve seen over time:_
password changes: invalidate the login token in some circumstances. If you have a policy for password changes then simply sking folk to lock/unlcok their PCs will cause a “re-login” against AD
use FQDN + port: If you use named instance, the client must query port 1434 to get the actual port of the instance. If you have a lot of firewalls or remote clients then sometimes this handshake fails. IIRC something to do with Kerberos. We found using
server.domain.tld\instance, portfixed all our issues (I’m talking USA or Hong Kong to Europe based server)