Unanswered: SQL Server 2005 - Service acct - login failed?
I've got a weird issue on my hands. I've got a 2 node/instance SQL 2005 SP2 Enterprise cluster on Server 2003 Enterprise, that's getting an odd event log error over and over. The service account that runs everything (SQL Services, Agent, Analysis Svcs, etc...) is a domain admin. The account is not locked out. SQL Server seems to be running fine. But, if you look in the SQL Server logs or the application logs, all you see are thousands of errors just like this:
Type: Failure Audit
Event ID: 18456
Login failed for user 'domain\ServiceAccount'. [CLIENT: xxx.xxx.xxx.xxx]
(BTW - the ip addr in the error is of that virtual instance of SQL Server.)
On the Server Evt log, it only shows up in the App log. In the security log, all of the audits related to this service acct are successes.
It happens on both instances of the 2005 cluster. But my SQL 2000 cluster (which uses the same service account) is having no problems at all. I've tried everything I could think of to diagnose/fix the issue and just can't seem to figure it out.
- verify that BUILTIN\Administrators is an SA in SQL
- verify that NT AUTHORITY\SYSTEM is an SA in SQL
- verify that the service account is an admin on both physical boxes.
- verify that there are no 'deny' permissions set on any of the system databases for the service account (or the two above built in groups).
Any ideas? I can't find anything on the web about it that's helped so far. Basically everything seems to be negated by the fact that the account is NOT locked out and the fact that the account is a domain admin. Luckily it's not causing any problems for me (at the moment), but I'm trying to diagnose a different issue and I can't seem to shake the possibility that both of the issues are related.
you sir are a genius. That's exactly what it was. We've been slowly going through a Sharepoint rollout over the last few months and in the beginning, one of the guys had decided to start from scratch by deleting all of the DBs off the server. I guess he didn't delete the Job. I see two different DeleteExpiredSessions jobs, one which has been trying to run against a non-existant DB for a long time.