The database SQL Server agent is locked with the following message appearing in the SQL Server agent log:
YYYY-MM-DD HH:MM:SS.SSS ECHO
Logon Error: 17806, Severity: 20, State: 2. YYYY-MM-DD HH:MM:SS.SSS Logon SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: 192.168.1.1]YYYY-MM-DD HH:MM:SS.SSS Logon Error: 18452, Severity: 14, State: 1. YYYY-MM-DD HH:MM:SS.SSS Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 192.168.1.1]
Root causes for this error message include:
Please note that for each of these solutions, the user id and password must be in the correct case.
SOLUTION #1 (the most common solution is networking related)
Move the Foglight Agent Manager into the same domain as the SQL Server and set it up to use a domain account or set up a remove Foglight Agent Manager in the same domain as the monitored database server.
Alternatively, set up mutual trust between the domains. Setting up mutual trust is a complicated procedure and should be done with a great deal of care and due security considerations.
The Foglight Agent Manager is in an overloaded state. Please review the Foglight for Databases deployment guide to ensure that the sizing and reservation requirements have been met.
SOLUTION #3 (third most common solution)
Use a SQL Server account instead of a DB account in the database properties for the agent
After addressing the untrusted domain issue in the database logs, the agents were then unlocked the database agent using the following steps:
SOLUTION #4 (fourth most common solution)
If your machine has multiple names, try to work around the need for multiple names and give it a unique name. If the machine just has one name, then check your DNS configuration.
SOLUTION #5 (fifth most common solution)
Fix the DNS or the hosts file on the server to correctly resolve the SQL Server servername.
The issue appeared to stem from an overly complex password. Customer simplified the password and shortened it as well on the domain account. Once that was completed this issue went away.
Verified the domain name in the userid field. The slash separating the domain and user account was backwards.
Create a domain account, give it the appropriate access rights to SQL Server, and then use that domain account to run the client application. Note that this case also includes the special accounts “NT AUTHORITY\LOCAL SERVICE” and “NT AUTHORITY\NETWORK SERVICE” trying to connect to a remote SQL Server, when authentication uses NTLM rather than Kerberos.
Troubleshoot the network hardware between the SQL Server and the Domain Controller by taking network traces and replacing network hardware as necessary
Go to the server properties in the Management Studio and enable SQL Authentication.
Add the NT AUTHORITY\NETWORK SERVICE access rights to SQL Server
Add the domain account being used to access the SQL Server instance.
To address cached network credentials in Windows
To disable the loopback check via the Windows registry
Change SQL Server Error Log settings to use JDBC instead of FALLBACK as per KB 156825
Please see the following MSDN articles for more information on this error message: