Login Failed for User 'Sa'. the User Is Not Associated with a Trusted SQL Server Connection. (Microsoft SQL Server, Error: 18452) in SQL 2008

login failed for user 'sa'. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452) in sql 2008

Go to Start > Programs > Microsoft SQL Server > Enterprise Manager

Right-click the SQL Server instance name > Select Properties from the context menu > Select Security node in left navigation bar

Under Authentication section, select SQL Server and Windows Authentication

Note: The server must be stopped and re-started before this will take effect

Error 18452 (not associated with a trusted sql server connection)

Tell SQL Server 2008 R2 to use user name a password to avoid error 18452 using Access 2010 VBA and linked tables

A few things:

First, ensure that your created SQL logon works. Note that you need BOTH a sql logon, and the ALSO a SQL user created for the given database (so don’t confuse the difference between a SQL server logon and that of SQL server user – this is COMMON confusion)

Use the SQL studio tools and disconnect from the database via your authenticated user and now re-connect via your new SQL logon. In other words be 100% sure that such SQL logons work from SSMS. Then (and ONLY then), attempt connecting from Access. So in SSMS test + try your SQL logon + password to ensure it works and lets you open/use the tables. Consider making the SQL logon a “owner” of the database and THEN create the user of the same name for that table.

I of course assume you set SQL server to mixed mode? And if the user(s) are not logged into your domain, then you could well have issues resolving the server name. (try using \192.0.0.50\sqlExpress or whatever your sql ip address and instance name is).

Next up:

Your “test” logon syntax is incorrect and will ALWAYS return false. Try typing your select string into sql server via SSMA and note how it does not work (that select will never work).

Remove the space and the () that you have.

I would just use:

.SQL = "Select Current_User;"

So your space + the () does not work and needs to be removed.

Also, I do suggest you include the Network-DBMSSOCN, as this means connect via TCP/IP. You likely are, but this enforces the issue.

Eg:

  dbCon = "ODBC;DRIVER="SQL Server;" & _
       "SERVER=" & ServerName & ";" & _
       "DATABASE=" & DataBaseName & ";" & _
       "UID=" & USERid & ";" & _
       "PWD=" & USERpw & ";" & _
       "Network=DBMSSOCN"

Once you ensured connecting via SQL logon as opposed to windows authentication works in SSMS, then fix your logon “select” command.

Also note that for the pass-word cache to work as a “general” rule the test logon string you use MUST be the same as the linked string + your uid/password. So the tabledef linked string does not have the uid/password.

Thus if the saved table link has things like "APP" etc, or other not required parts in the connection string, then your TEST logon connection string should have those SAME extra values along with the extra uid/logon. So if your test logon and test connection string is rather “different” then existing saved links, then the cache might have issues matching things up for the right table and server.

The code I use for test logon is:

Function TestLogin(strcon As String) As Boolean

  On Error GoTo TestError

  Dim dbs          As DAO.Database
  Dim qdf          As DAO.QueryDef

  Set dbs = CurrentDb()
  Set qdf = dbs.CreateQueryDef("")

   qdf.Connect = strcon

   qdf.ReturnsRecords = False

   'Any VALID SQL statement that runs on server will work below.
    qdf.SQL = "Select Current_User;"
   qdf.Execute

   TestLogin = True

   Exit Function

 TestError:
   TestLogin = False
   Exit Function

End Function

And code to create the string is:

Public Function dbCon(ServerName As String, _
                     DataBaseName As String, _
                     USERid As String, _
                     USERpw As String, _
                     Optional APP As String = "Office 2010", _
                     Optional WSID As String = "SC", _
                     Optional IntegratedSecurity As Boolean = False) As String

      ' returns a SQL server conneciton string
  If IntegratedSecurity = False Then
     dbCon = "ODBC;DRIVER={" & SQLDRIVER & "};" & _
             "SERVER=" & ServerName & ";" & _
             "DATABASE=" & DataBaseName & ";" & _
             "UID=" & USERid & ";" & _
             "PWD=" & USERpw & ";" & _
             "Network=DBMSSOCN"

  Else
     dbCon = "ODBC;DRIVER=" & SQLDRIVER & ";" & _
             "SERVER=" & ServerName & ";" & _
             "DATABASE=" & DataBaseName & ";" & _
             "APP=" & APP & ";" & _
             "WSID=" & WSID & ";" & _
             "Network=DBMSSOCN" & ";" & _
             "Integrated Security= SSPI"
  End If

End Function

And my logon "test" is:

Public Sub Logon()

  ' this simply tests + logs in the user to the default database.
  ' once this occurs, then a odbc logon prompt for each linked table
  ' should not occur - this works WHEN the connection string used here
  ' matches the odbc connection string exaclty.

    Dim strcon     As String

   ' con string settings are:

   ' server , DataBaseName, User, Password, [Optional Application name], [Optional work station]
   ' last two optional are for sql performance tracing etc. - not required

   strcon = dbCon("albertkallal-pc\SQLEXPRESS", "MyTestDec222", "test", "test")

   Debug.Print TestLogin(strcon)

End Sub

I would run/test the above routines WITHOUT launch any Access forms etc. So just test/use the above code. You need to get your logon working and when the logon works, then the prompt will go away.

SQL Server 2008 Windows Auth Login Error: The login is from an untrusted domain

The issue was caused by a down Active Directory Server, which of course could not authenticate the Windows account. Thank you for your assistance.

SQL Server 2008 Error 18452 The login is from an untrusted domain and cannot be used with Windows authentication

I thought it was fixed, but it is obviously not as we had to add one
new user and they cannot authenticate.

The user has to relogin in order to pick up the new group. Otherwise, it's kerberos ticket is still using the old group membership information in its PAC

These are actually registered to the Service account that we use for
the SQL Servers. What is interesting is that I can't find the SPNs for
the servers that are working anywhere.

I think what happen is that you have one SQL Server with SPN setup properly while the other three SQL Servers with no SPN setup at all. So, you are going to use Kerberos on this particular server while NTLM on the other three.

As mentioned before, when you are using Kerberos, you have to either purge the ticket using some tools or you have to relogin in order to pick up the new group membership. You can also try to lock the screen and then unlock it. If I remember correctly, this should also refresh the ticket.

Unlike Kerberos, NTLM doesn't carry the group memberhsip data. After SQL Server authenticated the user using NTLM, it will find the authenticated user's group membership, including the new group you just added.

Cannot login after creating the user in SQL Server

Try setting your authentication mode to mixed mode. Your server does probably not accept logins using sql server accounts.

Open properties
Go to "Security"
Select "SQL Server and Windows Authentication mode"

Login Failed for User 'Sa'. the User Is Not Associated with a Trusted SQL Server Connection. (Microsoft SQL Server, Error: 18452) in SQL 2008