"Login failed. The login is from an untrusted domain..." errors (4295150)

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:

• Passwords including special characters
• Incorrect case in userid or password
• Insufficient FglAM resources
• If this error message occurs every time in an application using Windows Authentication, and the FglAM and DB instance are on separate machines, ensure the account used to access SQL Server is a domain account. If the account being used is a local account on the client machine, then this error message will occur because the SQL Server machine and the Domain Controller cannot recognize a local account on a different machine.
• The user logging in is a domain account from a different, untrusted domain from the SQL Server’s domain.
• This error message can appear immediately after a password change for the user account attempting to login because of caching of the client user’s credentials.
• If this error message only appears sporadically in an application using Windows Authentication, it may result because the SQL Server cannot contact the Domain Controller to validate the user. This may be caused by high network load stressing the hardware, or to a faulty piece of networking equipment.
• This error message can appear consistently for local connections using trusted authentication, when SQL Server’s SPN is not interpreted by SSPI as belonging to the local machine. This can be caused either by a misconfiguration of DNS, or by a machine having multiple names.
• "SQL Authentication" not enabled when the server was setup.
• Insufficient access to the SQL Server database
• Cached network credentials in Windows
• Loopback check enabled in the LSA
• A server is not resolving the SQL Server servername to a FQDN
• fms has incorrect dns gateway configuration
• FALLBACK setting for SQL Server Error Log collection causes additional connections to the host
• Driver incompatibility
• The Domain Controller cannot be reached due to DNS issues

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

1. Administration > Agents | Agent Status
2. Edit Properties
3. Change the authentication from "Windows_Custom_Account" to "SQL Server Authentication"
4. Update the Username and Password to the new account details
5. Save the Changes
6. Deactivate and activate the agent

-------------------------------------------------------------------------------------

After addressing the untrusted domain issue in the database logs, the agents were then unlocked the database agent using the following steps:

1. Open the dashboard "Databases | Support Dashboard | Database Technical Support"
2. Click on the tree node "Unlock Agents" in the dashboard
3. On the right hand side select the agent from the drop down list and click on "Unlock DB" and/or "Unlock OS"
4. Reactivate the agent if necessary.

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

1. Open Command Prompt
2. Type the following command ----> rundll32.exe keymgr.dll, KRShowKeyMgr
3. Remove all the cached passwords

SOLUTION #14

To disable the loopback check via the Windows registry

1. open regedit
2. go to path: HKLM\System\CurrentControlSet\Control\LSA
3. add DWORD „DisableLoopbackCheck”
4. set value to 1

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/2008/05/03/understanding-the-error-message-login-failed-for-user-the-user-is-not-associated-with-a-trusted-sql-server-connection.aspx

http://blogs.msdn.com/b/sql_protocols/archive/2005/09/28/474698.aspx