SQL Server Error : 18452, Severity: 14. Login failed. The login is from an untru

SQL Server Error : 18452 Details

SQL Server Error: 18452
Severity: 14
Event Logged or not: Yes
Description:
Login failed. The login is from an untrusted domain and cannot be used with Windows Authentication.%.*ls
Severity 14 Description:
Indicates security-related errors, such as permission denied.

Error: 18452, Severity: 14, State: 1.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

This error can be seen in Error log of SQL Server as described below

Reading sql server error log location from SQL Query

Identifying SQL Server Error Log File used by SQL Server Database Engine can be done by reading SQL Server Error Logs. DBA can execute the XP_READERRORLOG extended stored procedure to read the SQL Server Error Log and search for its location used by the instance of SQL Server.

USE master
Go
xp_readerrorlog 0, 1, N'Logging SQL Server messages in file', NULL, NULL, N'asc'
Go

The parameters for XP_READERRRORLOG are:
1. Value of error log file we would like to read. values are 0 = current, 1 = last one before current, 2 = second last before current etc…
2. Log file type:- 1 or NULL = error log, 2 = SQL Agent log
3. Search string 1:- String one you want to search for
4. Search string 2:- String two you want to search for to further refine the results
5. start time for Search
6. end time for search
7. Sort order for search results:- N’asc’ = ascending, N’desc’ = descending

By default, we have 6 Server Error Logs kept but we can increase the number of SQL Server Error Logs from the default value of six.

For other ways to read and find error log location please our artcile https://sqlserver-dba.co.uk/error-log/sql-server-identify-location-of-the-sql-server-error-log-file.html

More details on this error message:

Reason behind error 18452 is because of wrong security authentication mode configuration. When SQL Server is set to accept only windows logins to connect to database instance this error may surface.
As we know SQL Server uses two authentication modes to accept database connections.

1.Windows Authentication mode

2. 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

Assume you have an Availability group configuration and are connecting to a database using the primary replica name rather than the listener name, and you are using a login for which the default database is set to be the availability database. If a failover occurs during your activity, or if you connect to a secondary replica with a login whose default database is configured to availability database, you will receive this error 18452, as well as the SSPI context errors listed 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 for Resolving the Error

To resolve this issue, we must first examine the authentication mode for your SQL Server instance. If your SQL Server instance is configured for Windows authentication, you must switch it to Mixed mode so that both Windows and SQL logins can be verified.

To check your SQL Server Instance’s specified authentication mechanism, open the SQL Server Instance property pane.

On Server properties the screenshot below, right-click on the instance node and select the properties option.

Go to Security and click on sql server and Windows authentication mode. and click OK to save.

Now for this changes to work, restart SQL Server services.
If your SQL Server instance is already configured for SQL Server and Windows Authentication, you’ll need to address this problem separately. As I previously stated, one of the most likely causes of error 18452 is when you use the availability group replica server name to connect to a database with a login whose default database is set to the AG availability database.
You won’t be able to access the database if failover occurs since it will become secondary. Because the same database is specified as the default database for your login, which has become inaccessible, Error 18452 will be created along with SSPI handshake failures.

The solution for this AG, to fix this issue is to failback the AG to your earlier primary replica.  Or we can/should use AG Listener name to make database connection. To avoid this error during failover like this we can set default database for your login to master rather than availability database so that it does try open the database when not available.

Alternate Solutions

1. Restarting SQL Server Service(non production instances only)

• To Restart, Start or Stop the SQL Server instance by right click on sql server instance in SSMS or in SQL. You may need to open SSMS as administrator to start, stop the instance.

• Other ways for restarting SQL server Service

1. Open SQL Configuration manager from Start menu and restart
2. From Services in Windows server
3. Open Cmd using net start and net stop

SQL Server Error Code and solution summary

SQL Server Error: 18452
Severity: 14
Event Logged or not: Yes
Description:
Login failed. The login is from an untrusted domain and cannot be used with Windows Authentication.%.*ls

Make sure ” sql server and Windows authentication mode” is enabled on SQL Server.

Default database for login is set to master.