I use windows 7 ultimate. I can login with windows authentication mode but SQL authentication with user sa doesn’t work. sa user is enabled. So what do I do?
RBT
23.8k21 gold badges158 silver badges240 bronze badges
asked Aug 27, 2010 at 11:16
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)
RBT
23.8k21 gold badges158 silver badges240 bronze badges
answered Aug 27, 2010 at 11:18
KashifKashif
14k17 gold badges65 silver badges98 bronze badges
Login with windows authentication mode and fist of all make sure that the sa authentication is enabled in the server, I am using SQL Server Management Studio, so I will show you how to do this there.
Right click on the server and click on Properties.
Now go to the Security section and select the option SQL Server and Windows Authentication mode
Once that is done, click OK. And then enable the sa login.
Go to your server, click on Security and then Logins, right click on sa and then click on Properties.
Now go tot Status and then select Enabled under Login. Then, click OK.
Now we can restart the SQLExpress, or the SQL you are using. Go to Services and Select the SQL Server and then click on Restart. Now open the SQL Server Management Studio and you should be able to login as sa user.
answered Aug 29, 2019 at 9:58
Sibeesh VenuSibeesh Venu
18k12 gold badges99 silver badges138 bronze badges
-
Click on Start menu > Programs > Microsoft Sql Server > Configuration Tools
-
Select Sql Server Surface Area Configuration.
-
Now click on Surface Area configuration for services and connections
-
On the left pane of pop up window click on Remote Connections and Select Local and Remote connections radio button.
-
Select Using both TCP/IP and named pipes radio button.
-
click on apply and ok.
Now when try to connect to sql server using sql username and password u’ll get the error mentioned below
Cannot connect to SQLEXPRESS.
ADDITIONAL INFORMATION:
Login failed for user ‘username’. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
ation
To fix this error follow steps mentioned below
-
connect to sql server using window authentication.
-
Now right click on your server name at the top in left pane and select properties.
-
Click on security and select sql server and windows authentication mode radio button.
-
Click on OK.
-
restart sql server servive by right clicking on server name and select restart.
Now your problem should be fixed and u’ll be able to connect using sql server username and password.
Have fun.
Ateev Gupta
answered Feb 2, 2011 at 12:03
- First make sure
sais enabled - Change the authontication mode to mixed mode (Window and SQL authentication)
- Stop your SQL Server
- Restart your SQL Server
RBT
23.8k21 gold badges158 silver badges240 bronze badges
answered Aug 24, 2013 at 10:23
- Go to services.msc from run prompt.
- Restart the services of SQL server(MSSQLSERVER)
- Restart the services of SQL server(SQLEXPRESS)
RBT
23.8k21 gold badges158 silver badges240 bronze badges
answered Jul 18, 2016 at 10:55
sivasiva
1151 silver badge4 bronze badges
I faced the very same error when I was trying to connect to my SQL Server 2014 instance using sa user using SQL Server Management Studio (SSMS). I was facing this error even when security settings for sa user was all good and SQL authentication mode was enabled on the SQL Server instance.
Finally, the issue turned out to be that Named Pipes protocol was disabled. Here is how you can enable it:
Open SQL Server Configuration Manager application from start menu. Now, enable Named Pipes protocol for both Client Protocols and Protocols for <SQL Server Instance Name> nodes as shown in the snapshot below:
Note: Make sure you restart the SQL Server instance after making changes.
P.S. I’m not very sure but there is a possibility that the Named Pipes enabling was required under only one of the two nodes that I’ve advised. So you can try it one after the other to reach to a more precise solution.
answered Mar 15, 2018 at 12:43
RBTRBT
23.8k21 gold badges158 silver badges240 bronze badges
I was stuck in same problem for many hours. I tried everything found on internet.
At last, I figured out a surprising solution : I had missed SQLEXPRESS part of the Server name: MY-COMPUTER-NAMESQLEXPRESS
I hope this helps someone who is stuck in similar kind of problem.
answered Jun 29, 2020 at 7:39
Hi
Last week I was receiving an error when trying to connect to two of our seven sql servers from my laptop via my domain admin account. The only fix was to have my laptop rebuilt and everything re-installed.
Today however another administrator is starting to have the same problem but to only one of the seven servers!
When that administrator uses my laptop with her domain admin account it works!?
What could possibly be going wrong with our laptops? We have not installed or changed anything.
The full error message we see:
Login failed for user ». The user is not associated with a trusted SQL Server connection. (Microsoft Sql Server, Error: 18452)
The error being logged on the server: (two errors are logged each time)
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: 53.35.165.148]
Login failed for user ». The user is not associated with a trusted SQL Server connection. [CLIENT: 53.35.165.148]
SQL Server Troubleshooting: Login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)
Table of Contents
- SQL SERVER ERROR:
- SOLUTION:
SQL SERVER ERROR:
Cannot connect to MSSQL Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)
SOLUTION:
- Open host file and add entry like 127.0.0.1 localhost.
- Once It is added we can reconnect to SQL Server as usual.
- The location of the host file is C:WindowsSystem32driversetc.
- You will find the file with the name hosts in it. Open it with Notepad.
Are you receiving a Microsoft SQL error 18452 while connecting to the database?
Incorrect authentication mode commonly causes this error.
Here at Bobcares, we routinely resolve SQL errors such as this as part of our Server Management Services.
Today we’ll cover the most effective fix and alternate solutions for Microsoft SQL error 18452.
What leads to Microsoft SQL error 18452?
SQL Server supports two authentication modes:
Windows authentication is the default mode. Specific Windows user and group accounts are trusted to log in to SQL Server.
Mixed-mode supports authentication by both Windows and SQL Server. SQL server maintains the User name and password pairs.
As Windows authentication mode is the default authentication mode enabled after installing the Microsoft SQL Server, users may face issues while connecting to the server.
[Need help to fix Microsoft SQL error 18452? We are available 24×7]
How to fix Microsoft SQL error 18452?
Switching to the Mixed-mode authentication can fix the Microsoft SQL error 18452. This can be done easily with the steps below:
- From Start >> click All Programs >> click Microsoft SQL Server 20xx (where xx is the version of SQL)>>and then click SQL Server Management Studio.
- In the SQL Server Management Studio, right-click the server, and then click Properties.
- On the Security page, under Server authentication, click the SQL Server and Windows Authentication
mode option button, and then click OK.
- In the SQL Server Management Studio dialog box, click OK to restart SQL Server.
Alternative Fixes
At times, this error occurs when users try to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists.
Also, this error can occur if the login may use Windows Authentication but the login is an unrecognized Windows principal. An unrecognized Windows principal means that Windows can’t verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.
[Need help to fix Microsoft SQL error 18452? We are available 24×7]
Conclusion
In short, the common cause for SQL error 18452 is the Windows authentication mode. Today, we discussed how our support engineers fix this error easily.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Recently a user has reported error 18452 while connecting to database server. Full description of this error is given below:
Error: 18452, Severity: 14, State: 1.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
You can see the screenshot of the error 18452 in below image.
Error 18452 – Root Cause
Reason behind error 18452 is because of wrong security authentication mode configuration. SQL Server is set to accept only windows logins to connect to database instance.
As we know SQL Server uses two authentication modes to accept database connections. One is Windows Authentication mode and another one is SQL Server and Windows Authentication mode. We also call it Mixed Authentication mode.
Sometimes, SQL Server authentication mode is set to SQL Server and Windows Authentication mode to accept SQL as well as windows connections but still you will face this issue. That might be because you try to connect to a server that has Always on Availability Group configuration or database mirroring configuration.
Suppose you have AOAG configuration and you are connecting to database using primary replica name not listener name using a login for which default database is set as availability database. If failover got happen during your activity or you are connecting to secondary replica using a login for which default database is set as availability database then also you will get this error 18452 along with some SSPI context error that I have given below.
Error: 17806, Severity: 20, State: 14.
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed
SSPI handshake errors comes because of Kerberos failure, which would most likely be related to non-existent SPN or bad SPN for SQL Server.
Solution
To fix this issue first we need to check the authentication mode set for your SQL Server Instance. If your SQL Server instance is running with windows authentication mode then you must change it to Mixed mode so that windows and SQL both type of logins can be authenticated.
To check the configured authentication mode for your SQL Server Instance, we need to launch SQL Server Instance property window. Right click at the instance node and click at the properties option as shown in below screenshot.
Once you will click at Properties option, you will be getting below SQL Server instance property window. Click at Security option from left side pane. You can see current Server Authentication configuration is set to Windows Authentication mode in below screenshot.
Now we will change it to SQL Server and Windows Authentication mode. Select the radio button for SQL Server and Windows Authentication mode option and click ok button to proceed. You can see that I have selected above mode to apply the changes.
Restart SQL Server services to apply the changes.
If your SQL Server Instance is already set with SQL Server and Windows Authentication mode then you should fix this issue in separate way. As I described above that one of the probable reason to get this error 18452 is because you might use AOAG replica server name to connect to the database with the login for which default database is set as the AOAG availability database.
If failover will happen then you would not be able to access the database because it will become secondary. Error 18452 will be generated along with SSPI handshake errors because same database is set as default database for your login that has become inaccessible now because of acting secondary database in AOAG. Failover will not happen for you because you are using replica server name to make database connection.
Possible solution to fix this issue is failback the AOAG to your earlier primary replica or you should use AOAG Listener name to make database connection. Also, to avoid this error during failover you should set default database for your login to master rather than availability database.
I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.
Read More:
- Fix Error 18456: Login failed for user “User_Name”
- Fix Error 4064: Cannot open user default database. Login failed
- Error 53: Could not open a connection on SQL Server
- AOAG Listener Error 19471: The handle is Invalid
- Author
- Recent Posts
I am working as a Technical Architect in one of the top IT consulting firm. I have expertise on all versions of SQL Server since SQL Server 2000. I have lead multiple SQL Server projects like consolidation, upgrades, migrations, HA & DR. I love to share my knowledge. You can contact me on my social accounts for any consulting work.
Summary
Article Name
Fix Error 18452: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
Description
Recently we got a login issue where one of the SQL user was not able to connect to database instance and was getting error 18452. Full error description of this error is given below: Error: 18452, Severity: 14, State: 1.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.