The login is from an untrusted domain and cannot be used with Windows authentication

Cause

There are several known root causes for this error message including the following:

• If this error message occurs every time in an application using Windows Authentication, and the client and the SQL Server instance are on separate machines, then ensure that the account which is being 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.
• This error message can appear if 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. This occurs 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 having been enabled when the server was setup.
• Insufficent access to the SQL Server database
• Cached network credentials in Windows
• Loopback check being enabled in the LSA
• A server is not resolving the SQL Server servername to a FQDN
• fms has incorrect dns gateway configuration"
  
  

  Resolution

  SOLUTION #1
  Verified the domain name in the userid field. The slash separating the domain and user account was backwards.
  SOLUTION #2
  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 #3
  Either to move the client machine into the same domain as the SQL Server and set it up to use a domain account, or to 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.
  SOLUTION #4
  Troubleshoot the network hardware between the SQL Server and the Domain Controller by taking network traces and replacing network hardware as necessary
  SOLUTION #5
  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 #6
  Go to the server properties in the Management Studio and enable SQL Authentication.
  SOLUTION #7
  Add the NT AUTHORITY\NETWORK SERVICE access rights to SQL Server
  SOLUTION #8
  Add the domain account being used to access the SQL Server instance.
  SOLUTION #9
  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 #10
  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 #11
  Fix the DNS or the hosts file on the server to correctly resolve the SQL Server servername.
  SOLUTION #12
  You can also make integrated scurity = false ;