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 ERROR [DBSS-MyServer-wmiThreadPool-1-[DBSS_Usability][YYYY-MM-DD HH:MM:SS.SSS]] com.quest.qsi.fason.sqlserver.collection.processor.DBSSUsabilityOSProcessor - Failed to get connection for Usability OS processor. For security reasons, the user account "EXAMPLE/sqlagent" is locked by the agent due to invalid login credentials. Please use the support module to unlock it. Detailed Date: YYYY-MM-DD HH:MM:SS.SSS Module: "MSSQLPool-DBSS-MyServer" Message : "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication."
or
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 (uppercase vs lowercase).
To begin troubleshooting, check the SQL Server Error Log on the monitored host for login failure information. The Login State mentioned there can give a clearer picture about the cause of the issue.
Here is an example of an error associated with the untrusted domain message.
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 remote 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.
SOLUTION #6 (sixth most common solution)
The issue appeared to stem from an overly complex password which may include special characters (such as %, $, :, ;). Customer simplified the password and shortened it as well on the domain account. Once that was completed this issue went away.
SOLUTION #7
Verified the domain name in the userid field. The slash separating the domain and user account was backwards.
SOLUTION #8
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.
SOLUTION #9
Troubleshoot the network hardware between the SQL Server and the Domain Controller by taking network traces and replacing network hardware as necessary
SOLUTION #10
Go to the server properties in the Management Studio and enable SQL Authentication.
To check:
SOLUTION #11
Add the NT AUTHORITY\NETWORK SERVICE access rights to SQL Server
SOLUTION #12
Add the domain account being used to access the SQL Server instance.
SOLUTION #13
To address cached network credentials in Windows
SOLUTION #14
To disable the loopback check via the Windows registry
SOLUTION #15
Change SQL Server Error Log settings to use JDBC instead of FALLBACK as per KB 156825
SOLUTION #16
Upgrade the SQL Server cartridge to 5.9.7.22 or higher for defect FOG-1582.
SOLUTION #17
Confirm that the Domain Controller can be reached by the remote host. This is usually accompanied by the message "SSPI handshake failed with error code 0x80090311, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. No authority could be contacted for authentication. [CLIENT: CLIENT_ID]" in the SQL Server Error Log
Please see the following MSDN articles for more information on this error message:
http://blogs.msdn.com/b/sql_protocols/archive/2005/09/28/474698.aspx
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center