In my case I had this issue when I changed the TMG firewall Logging. I solveed it by going to
Start -> Microsoft SQl Server 2008 -> Configuration Tool -> SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for MSFW and then right click on TCP/IP Change it to Enable.
Suddenly our SCCM site systems experienced error 18456 on the remote SQL instance allthough it had been working for a long period - although it seem that every SPN correctly appeared on the SQL_ServiceAccount, I created a batch file which removed the spn''s registered on the SQL service account and readded them:
setspn -D mssqlsvc/SQL_INSTANCE:PortNumber SQL_ServiceAccount
setspn -D mssqlsvc/SQL_INSTANCE.nwtraders.msft:PortNumber SQL_ServiceAccount
setspn -D mssqlsvc/SQL_INSTANCE.nwtraders.msft SQL_ServiceAccount
setspn -D mssqlsvc/SQL_INSTANCE SQL_ServiceAccount
setspn -A mssqlsvc/SQL_INSTANCE:PortNumber SQL_ServiceAccount
setspn -A mssqlsvc/SQL_INSTANCE.nwtraders.msft:PortNumber SQL_ServiceAccount
setspn -A mssqlsvc/SQL_INSTANCE.nwtraders.msft SQL_ServiceAccount
setspn -A mssqlsvc/SQL_INSTANCE SQL_ServiceAccount
I had the same error when changing the memory size of my sharepoint virtual machine from 512MB to 256MB. Changed it back and everything was working perfectly. Nothing to do with authentication in my case.
In my case, this was caused by the Report Server. I reconfigured the Report Server, deleted the encryption key, tested it and everything come back to normal.
In my case this issue dissapeared when I gave the user local admin rights.
In another situation I had solved this event by customizing DBSPI monitoring, because SQL cluster group was on another node, and monitoring was not updated with this information
C:\WINDOWS>dbspicol OFF PP1DB
DB-SPI Collection turned OFF for instance PP1DB.
I've had this problem in conjunction with WSUS 3.0SP1 after installation of MS SQL 2000 SP4. WSUS could not start because it had no access to \WSUS\UpdateServicesDbFiles\SUSDB.mdf and SUSDB_log.ldf. I've solved the problem by resetting the file acess permission inheritance.
From a newsgroup post: "I started getting this error for user "NT AUTHORITY\NETWORK SERVICE" after I installed the .NET Framework version 3.0 on a new SBS 2003 R2 server. In the same time I was getting event id 1000 source from Windows SharePoint Services 2.0. After a few restarts both errors dissapeared".
The "Login failed for user <xx>" link provides an example of a situation when this error occurs if a user attempts to login to SQL using the osql.exe utility.
If you have installed databases from products akin to Team Foundation Server, or SharePoint (Services or Server) and you subsequently uninstall the databases from the server, then the jobs that go with the product are not removed. You can use the Job Activity Monitor to see which jobs are scheduled and you can disable them to ensure that the errors stop and subsequently delete the jobs from the server.
After migrating WSUS 3.0 SP1 database form Internal Database to SQL 2005 instance installed on the same server you can get the following error: Login failed for user "NT AUTHORITY\NETWORK SERVICE". [CLIENT: <local machine>]. This problem may appear because the NT AUTHORITY\NETWORK SERVICE account does not have login permissions to master database in the SQL 2005 instance. Add the NT AUTHORITY\NETWORK SERVICE account to the master database permissions list, restart the SQL server, restart the IIS service, and then restart the Update Services service. See T708558
for more details.
In my case, this SQL server was hosting several MOSS 2007 databases. I found that the SQL agent was trying to login to a database that did not exist. MOSS uses SQL Server Jobs to delete expired sessions on a set schedule, every minute, to free up resources that are not being used. You will need to go into SQL Server management studio and disable the job called SharedServices_DB_job_deleteExpiredSessions. Once this is done you should no longer see those error messages in the event log. If you disable the right job, and the error message no longer appears, you can then delete the job. Always disable first. You do not want to delete until you are sure you got the right job.
See the link to “SCOM2007 - Login failed for user” for information on this problem.
Make sure that the user specified in the description has a login created. If not, try creating one with the CREATE LOGIN command.
and the link to "Microsoft event 18456 from source MSSQLServer" for details on fixing this problem.
I installed SharePoint Services 3.0 with SQL 2005 Embedded Edition on a member server W2K3 R2. After updating the server to a Domain Controller, it was not possible to start the SQL services. According to Microsoft, this can happen, when you install SharePoint Services before upgrading the server to be a DC. See ME929665
for additional information. The workaround in this article did not work in my case. To fix the problem, I cleared all entries to MSSQL in the registry, rebooted the server, and reinstalled SharePoint Services.
For more information on your problem check the SQL Server log files on the affected server, as there is an Error State parameter that is relevant. I had this problem because the file system file owner was not a specified user in SQL Server. In my case, the message was "Error: 18456 Severity: 14 State: 16". I resolved this by doing the following on the SQL Server 2005:
1. Open SQL Server Management Studio
2. Expand Databases
3. Right Click on the Database with problems and choose "Properties"
4. Left Click the "Files" node
5. Ensure that an appropriate owner is listed. If none is, then set it.
Other Error States and causes include:
ERROR STATE - ERROR DESCRIPTION
2 and 5 - Invalid user id
6 - Attempt to use a Windows login name with SQL Authentication
7 - Login disabled and password mismatch
8 - Password mismatch
9 - Invalid password
11 and 12 - Valid login but server access failure
13 - SQL Server service paused
18 - Change password required
This error can also happen if you have jobs setup for a database that has been deleted.
This error can occur on machine startup when Microsoft CRM Deletion and Microsoft CRM Workflow Service services attempt to access the underlying databases before the SQL Server Agent service started. This is not critical. To fix this issue set both services to depend on the SQL Server Agent service:
Modify or create the DependOnService multi-word values for both services to include SQLSERVERAGENT.