Ошибка sql login failed for user

I’ve written a very simple JDBC login test program. And after all kinds of problems I’ve almost got it working. Almost, just can’t seem to get past this problem:

SQLServerException: Login failed for user xxxxx

I created a simple database PersonInfo then I created user user1 password1 (SQL authentication). And after trying everything was unable to connect to the database.

I am using SqlServer2008 on Win 7, I’ve got the latest JDBC driver from Microsoft.

My code is:

import java.sql.*;

public class hell {
public static void main(String[] args) {
    
    try {
        Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver").newInstance();
Connection conn=  DriverManager.getConnection("jdbc:sqlserver://localhost:1433;databaseName=PersonInfo;user=Sohaib;password=0000;");


System.out.println("connected");
       }

    } catch (Exception e) {
        e.printStackTrace();
    }
}
}

Here’s the Exception

Exception: Unable to get connect
com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user 'Sohaib'.
and all other supporting errors.

tshepang's user avatar

tshepang

12k21 gold badges91 silver badges135 bronze badges

asked Jun 28, 2013 at 19:51

The Code Geek's user avatar

2

Is your SQL Server in ‘mixed mode authentication’ ? This is necessary to login with a SQL server account instead of a Windows login.

You can verify this by checking the properties of the server and then SECURITY, it should be in ‘SQL Server and Windows Authentication Mode’

This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:

Scenario 1: The login may be a SQL Server login but the server only accepts Windows Authentication.

Scenario 2: You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server.

Scenario 3: 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.

It’s also possible the user put in incorrect information.

http://support.microsoft.com/kb/555332

answered Jun 29, 2013 at 8:28

Bryan's user avatar

BryanBryan

3,2312 gold badges15 silver badges30 bronze badges

2

In my case, I had to activate the option «SQL Server and Windows Authentication mode», follow all steps below:

1 — Right-click on your server
enter image description here

2 — Go to option Security

3 — Check the option «SQL Server and Windows Authentication mode»

4 — Click on the Ok button
enter image description here

5 — Restart your SQL Express Service («Windows Key» on the keyboard and write «Services», and then Enter key)
enter image description here

After that, I could log in with user and password

Federico Navarrete's user avatar

answered Oct 10, 2019 at 18:40

Junior Grão's user avatar

Junior GrãoJunior Grão

1,3018 silver badges6 bronze badges

4

I ran into the same issue, and I fixed it by adding my windows username to SQL and then to my server, here is how I did:

First, create a new login with your Windows username:
enter image description here

Click Search, then type your name in the box and click check names.
enter image description here

Then add your that user to the server:

Right click on the Server > Permissions > Search > Browse > Select your user
(You will notice that now the user you created is available in the list)

enter image description here

I hope it helps ;-)

Federico Navarrete's user avatar

answered Apr 30, 2018 at 19:12

Roberto Rodriguez's user avatar

We got this error when reusing the ConnectionString from EntityFramework connection. We have Username and Password in the connection string but didn’t specify

«Persist Security Info=True».

Thus, the credentials were removed from the connection string after establishing the connection (so we reused an incomplete connection string). Of course, we always have to think twice when using this setting, but in this particular case, it was ok.

rene's user avatar

rene

41.2k78 gold badges113 silver badges151 bronze badges

answered Aug 19, 2019 at 15:13

Alexander's user avatar

AlexanderAlexander

5943 silver badges13 bronze badges

3

I got the same error message when trying to connect to my SQL DB in Azure (using sql-cli). The simple solution was to escape the password with single quotes like this:

mssql -s server.database.windows.net -u user@server -p 'your_password' -d your_db -e

answered Apr 19, 2017 at 15:19

Tobias's user avatar

TobiasTobias

8107 silver badges11 bronze badges

Also make sure that account is not locked out in user properties «Status» tab

answered Aug 16, 2017 at 7:55

irfandar's user avatar

irfandarirfandar

1,69023 silver badges24 bronze badges

I have also caught the same issue,But don’t worry the solution is so simple

We need to understand the basic terms first that this error “Login Failed for User (Microsoft SQL Server, Error: 18456)” means you entered invalid credentials when logging into SQL Server with specific server authentication type.
enter image description here

Where I have Selected the option of Windows Authentication mode in Server Authentication

and In my ConnectionString in appsettings.json file has the following connection string:

Server=DESKTOP-PK4BJF5;Database=lms;Trusted_Connection=false;MultipleActiveResultSets=true;TrustServerCertificate=true

In which the «trusted-connection» is a parameter used in database connection strings to specify the type of authentication to be used when connecting to a database server.

When «trusted-connection» is set to «true» or «SSPI» (Security Support Provider Interface), it means that the connection will use Windows Authentication to authenticate the user. This means that the credentials of the currently logged-in Windows user will be used to connect to the database server. This type of authentication is also sometimes referred to as «integrated security».

When «trusted-connection» is set to «false», it means that the connection will use SQL Server Authentication to authenticate the user. This means that the connection string will contain a user ID and password that are used to connect to the database server.

I am Updating the Connection String line and just write SSPI instead of /false

"Server=DESKTOP-PK4BJF5;Database=lms;Trusted_Connection=SSPI;MultipleActiveResultSets=true;TrustServerCertificate=true",

answered Apr 12 at 4:46

AYESHA JAVED's user avatar

For Can not connect to the SQL Server. The original error is: Login failed for user 'username'. error, port requirements on MSSQL server side need to be fulfilled.

There are other ports beyond default port 1433 needed to be configured on Windows Firewall.

https://stackoverflow.com/a/25147251/1608670

answered Oct 24, 2017 at 19:32

Ivan Chau's user avatar

Ivan ChauIvan Chau

1,4041 gold badge17 silver badges28 bronze badges

We solved our Linux/php hook to SQL Server problem by creating a new login account with SQL Server authentication instead of Windows authentication.

answered Jun 5, 2018 at 18:46

Charles Kuehn's user avatar

Just in case any one else is using creating test users with their automation….

We had this same error and it was because we had recreated the user (as part of the test process). This caused the underlying SID to change which meant that SQL couldn’t properly authenticate the user.

We fixed it by adding a drop login command to our testing scripts to ensure that a previously created user (with the same user name) was no longer present on the instance.

answered Aug 4, 2020 at 6:23

xenon8's user avatar

I faced with same problem. I’ve used Entity Framework and thought that DB will be created automatically. Please make sure your DB exists and has a correct name.

answered Oct 31, 2020 at 16:38

Сергей's user avatar

СергейСергей

7503 gold badges13 silver badges31 bronze badges

In my case I have configured as below in my springboot application.properties file then I am able to connect to the sqlserver database using service account:

url=jdbc:sqlserver://SERVER_NAME:PORT_NUMBER;databaseName=DATABASE_NAME;sendStringParametersAsUnicode=false;multiSubnetFailover=true;integratedSecurity=true
    jdbcUrl=${url}
    username=YourDomain\$SERVICE-ACCOUNT-USER-NAME
    password=
    hikari.connection-timeout=60000
    hikari.maximum-pool-size=5
    driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver

answered Jan 11, 2021 at 22:44

Elias's user avatar

EliasElias

6542 gold badges11 silver badges23 bronze badges

try using this connection string

Server=ServerName;Database=DbName;Trusted_Connection=SSPI;MultipleActiveResultSets=true;TrustServerCertificate=true

answered Jan 3 at 16:04

Saeed RayatMoghadam's user avatar

You can try this method: add Trusted_Connection=True; to your connection string.

Brian Tompsett - 汤莱恩's user avatar

answered Apr 29 at 10:36

Huseyn Hemidov's user avatar

If you are using Windows Authentication, make sure to log-in to Windows at least once with that user.

answered Feb 18, 2019 at 7:33

Farkhod's user avatar

FarkhodFarkhod

1964 silver badges8 bronze badges

Previously I was using the Windows Authentication without problems, then occurred me the error below.

«Failed to generate SSPI context.»

Witch I resolve by changing my connection string from

Server=127.0.0.1;Database=[DB_NAME];Trusted_Connection=True;

to

Server=127.0.0.1;Database=[DB_NAME];Trusted_Connection=False;

Then the next error occurred me

«Login failed for user ».»

To solve this problem I used the sa user. Access the sa user to update de password if you need (on the SQL server Security > Logins > sa (right click) > Properties > General)) and then update the connection string to..

Server=127.0.0.1;Database=[DB_NAME];User Id=sa;Password=[YOUR_PASSWORD]

You can use another user of your choice.

answered Mar 30, 2021 at 9:26

Jéssica Machado's user avatar

1

In this article, I am going to explain fixing a problem related login failure error with SQL Server.

The Problem

One of the common error in the SQL Server error log is

«Login failed for user ‘DomainNameServerName$’. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>]«.

Even though it says that the login failure from user ‘DomainNameServerName$’, the actual user can be different. So the error message is a kind of misleading. This is the main problem with this error. So it is very hard to find our from where the error is coming.

If you look at the error log further, you can see that there is another line which gives some more details of the error as below

«Error: 18456, Severity: 14, State: 5

Root Cause Identification

Based on above two errors, we can narrow down to a specific service or process running in the local machine. Something is frequently trying to access the SQL Server. However a specific login name is not available.

In different blogs I’ve read, the resolution has been focused on very specific user accounts, but the correct account could be different in your scenario. Now the question is, how to find what is the specific user account which tries to access the database? The answer for this is very simple.

Resolution

First, verify whether there are any specific services or applications hosted on the local server. You should verify whether those services try to access the SQL Server with a specific user account and whether that account is created as a login in the SQL Server. If you find such an account or login is missing, just create it.

The next thing to do is open the Services applet, as shown in the below image, and verify whether the service accounts used in all the services that are related to SQL Server are available as logins in the SQL Server and have the access to the instance.

If any of these are not there, just create the account, and the error will go away.

Further Details

Further, even after creating the account, it might log a new error in the  Error log will sometimes show this:

«Login failed for user ‘AccountName’. Reason: Failed to open the explicitly specified database ‘DBName’. [CLIENT: <local machine>]»

This is due to the account not having enough privileges to access the database. In this case, the good thing is the error will specifically mention the name of the account that needs access to the specific database. Further the «state» of the error gives a good indication of the reason and different reasons for each state can be found in this blog.

Based on this information you can resolve this issue by doing either one of following

  1. create the specific user or login & give the necessary permission
  2. disable or remove a particular process or service if it not required

Hopefully this helps you debug login errors that appear in your log.

  • Remove From My Forums
  • Question

  • When I use the following setting to connect server, it succeeds
    Server type: Database Engine
    Server name: Home-PC
    Authentication: Windows Authentication

    User name: Home-PCJohn
    Password:<empty>
    However, when I try to use the following setting to connect the same server, it fails as always
    Server type: Database Engine
    Server name: Home-PC
    Authentication: SQL Server Authentication 
    Login:
    sa
    Password:
    1234567

    The Error Message as follows
    TITLE: Connect to Server
    ——————————
    Cannot connect to Home-PC.
    ——————————
    ADDITIONAL INFORMATION:
    Login failed for user ‘sa’. (Microsoft SQL Server, Error: 18456)
    For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=18456&LinkId=20476

    Then, I enter the server to change some security configurations by means of Windows Authentication
    1. go to Security > Login > sa
    change ‘sa’ status in Login to Enabled
    reset ‘sa’ password as ‘1234567’
    2. go to this database property > Security > SQL Server and Windows Authentication mode set as selected

    Unfortunately, the same problem still occurs.
    p.s. My computer o.s. is Vista Ultimate SP2 64bit and SQL Server 2008 has been installed successfully.

    Thank you so much for helping me.

Answers

  • Did you restart SQL services after changing the mixed mode authentication?
    Some of the server level properties takes only after a SQL restart , one such is authentication modes.


    Thanks, Leks

    • Proposed as answer by

      Tuesday, February 2, 2010 6:41 PM

    • Marked as answer by
      enix0907
      Tuesday, February 2, 2010 9:05 PM

Updated in July 2020 with a few new states.

I think we’ve all dealt with error 18456, whether it be an application unable to access SQL Server, credentials changing over time, or a user who can’t type a password correctly.

The trick to troubleshooting this error number is that the error message returned to the client or application trying to connect is intentionally vague – the error message is similar for most errors, and the state is always 1. In a few cases, some additional information is included, but for the most part several of these conditions appear the same to the end user. The reason for this is to be careful not to disclose too much information to a would-be attacker.

But this makes troubleshooting hard.

In order to figure out what is really going wrong, you need to have alternative access to the SQL Server and inspect the log for the true state in the error message. I helped our support team just today solve a client’s 18456 issues – once we tracked down the error log and saw that it was state 16, it was easy to determine that their login had been set up with a default database that had been detached long ago.

When I see folks struggling with this problem, I almost always see them pointed to this old MSDN blog post (or this other version from MSDN), which has a very brief partial list and a lot of unanswered questions. A newer list appears here, with some useful info, but it is still incomplete.

So here is what I consider a more complete listing of all the various states for login failures. I included an instance of 18470 under state 1 for completeness.

State Example / Description
(note: the verbose message usually has [CLIENT: <IP>] suffix)
1 Error: 18470, Severity: 14, State: 1.
Login failed for user ‘<x>’.
Reason: The account is disabled.
State 1 now occurs when a login is disabled – but actually, the error in the log is 18470, not 18456 – because the login is disabled, it doesn’t get that far. See state 7.Prior to SQL Server 2005, State 1 always appeared in the log for all login failures, making for fun troubleshooting. 🙂
2 Error: 18456, Severity: 14, State: 2.
Login failed for user ‘<x>’.
Reason: Could not find a login matching the name provided.
The login (whether using SQL or Windows Authentication) does not exist. For Windows Auth, it likely means that the login hasn’t explicitly been given access to SQL Server – which may mean it is not a member of an appropriate domain group. It could also mean that you’ve created a server-level login, mapped a database user with a different name to that login, and are trying to connect using the user name, not the login name. This is the same as State 5, but State 2 indicates that the login attempt came from a remote machine.
5 Error: 18456, Severity: 14, State: 5.
Login failed for user ‘<x>’.
Reason: Could not find a login matching the name provided.
Like state 2, the login does not exist in SQL Server, but the login attempt came from the local machine. For both state 2 and 5, prior to SQL Server 2008, the reason was not included in the error log – just the login failed message. And starting in Denali, for both state 2 and 5, this error can happen if you specify the correct username and password for a contained database user, but the wrong (or no) database. Note that if you are trying to connect to a contained database using the connection dialog in SSMS, and you try to <Browse server…> for the database instead of typing the name explicitly, you will first receive a prompt «Browsing the available databases on the server requires connecting to the server. This may take a few moments. Would you like to continue?» If the SQL auth credentials do not also match a login at the server level, you will then receive an error message, because your contained user does not have access to master.sys.databases. The error message in the UI is, «Failed to connect to server <server>. (Microsoft.SqlServer.ConnectionInfo)Login failed for user ‘<x>’. (Microsoft SQL Server, Error: 18456).» The takeaway here: always specify the database name explicitly in the options tab of the connection dialog; do not use the browse feature.
6 Error: 18456, Severity: 14, State: 6.
Login failed for user ‘<xy>’.
Reason: Attempting to use an NT account name with SQL Server Authentication.
This means you tried to specify SQL authentication but entered a Windows-style login in the form of DomainUsername. Make sure you choose Windows Authentication (and you shouldn’t have to enter your domain / username when using Win Auth unless you are using runas /netonly to launch Management Studio). In SQL Server 2012 at least, you will only get state 6 if the domainusername format matches an actual domain and username that SQL Server recognizes. If the domain is invalid or if the username isn’t an actual Windows account in that domain, it will revert to state 5 (for local attempts) or state 2 (for remote attempts), since the login doesn’t exist.
7 Error: 18456, Severity: 14, State: 7.
Login failed for user ‘<x>’.
Reason: An error occurred while evaluating the password.
The login is disabled *and* the password is incorrect. This shows that password validation occurs first, since if the password is correct and the login is disabled, you get error 18470 (see state 1 above). It’s possible that your application is sending cached credentials and the password has been changed or reset in the meantime – you may try logging out and logging back in to refresh these credentials.
8 Error: 18456, Severity: 14, State: 8.
Login failed for user ‘<x>’.
Reason: Password did not match that for the login provided.

Probably the simplest of all: the password is incorrect (cASe sEnsiTiVitY catches a lot of folks here). Note that it will say «the login provided» even if you attempted to connect as a contained database user but forgot to specify a database, specified the wrong database, or typed the password incorrectly – unless it finds a match, SQL Server doesn’t have any idea you were attempting to use a contained database user.

An interesting case here is Docker containers – docker run will allow you to spin up a container and specify an SA_PASSWORD with certain special characters, like $. However, you will never be able to connect to the container with that password. If you use non-alphanumerics, stick to slightly more benign characters like # and *.

9 Error: 18456, Severity: 14, State: 9.
Login failed for user ‘<xy>’.
Like state 2, I have not seen this in the wild. It allegedly means that the password violated a password policy check, but I tried creating a login conforming to a weak password policy, strengthened the policy, and I could still log in fine. And obviously you can’t create a login with, or later set, a password that doesn’t meet the policy. Let me know if you’ve seen it.
10 Error: 18456, Severity: 14, State: 10.
Login failed for user ‘<x>’.
This is a rather complicated variation on state 9; as KB #925744 states, this means that password checking could not be performed because the login is disabled or locked on the domain controller (note that if SQL Server does not start, it could be because the account that is locked or disabled is the SQL Server service account). No reason or additional information is provided in the «verbose» message in the error log.
11
12
Error: 18456, Severity: 14, State: 11.
Login failed for user ‘<x>’.
Reason: Login-based server access validation failed with an infrastructure error. Check for previous errors.

 Error: 18456, Severity: 14, State: 12.
Login failed for user ‘<x>’.
Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors.

States 11 and 12 mean that SQL Server was able to authenticate you, but weren’t able to validate with the underlying Windows permissions. It could be that the Windows login has no profile or that permissions could not be checked due to UAC. Try running SSMS as administrator and/or disabling UAC. Another reason could be that the domain controller could not be reached. You may need to resort to re-creating the login (see this post from Simon Sabin). Finally, PSS has recently released more information about states 11 and 12; see this post for potential scenarios and solutions, and also see states 146-149 below for changes in SQL Server 2016.
13 Error: 18456, Severity: 14, State: 13.
Login failed for user ‘<x>’.
Reason: SQL Server service is paused. No new connections can be accepted at this time.
This state occurs when the SQL Server service has been paused (which you can do easily and even accidentally from the context menu in Object Explorer).
16 Error: 18456, Severity: 14, State: 16.
Login failed for user ‘<x>’.

 You may also see:

 A connection was successfully established with the server, but then an error occurred during the pre-login handshake.

State 16, which only occurs prior to SQL Server 2008, means that the default database was inaccessible. This could be because the database has been removed, renamed, or is offline (it may be set to AutoClose). This state does not indicate a reason in the error log. In 2008 and beyond, this is reported as state 40 (see below), with a reason. In SQL Server 2005, this state may also be reported if the user’s default database is online but the database they explicitly requested is not available for the reasons stated above (also see state 27). If you get the pre-login handshake message, it may be because you’ve disabled SSL on the server.
18 Error: 18456, Severity: 14, State: 18.
Login failed for user ‘<x>’.
Supposedly this indicates that the user needs to change their password. In SQL Server 2005, 2008 R2 and SQL Server 2012, I found this was raised as error 18488, not 18456; this is because for SQL logins the change password dialog just delays logging in, and is not actually a login failure. I suspect that, like state 16, this state will no longer appear in future versions of SQL Server.
23 Error: 18456, Severity: 14, State: 23.
Login failed for user ‘<x>’.
Reason: Access to server validation failed while revalidating the login on the connection.
There could be a few reasons for state 23. The most common one is that connections are being attempted while the service is being shut down. However if this error occurs and it is not surrounded in the log by messages about SQL Server shutting down, and there is no companion reason along with the message, I would look at KB #937745, which implies that this could be the result of an overloaded server that can’t service any additional logins because of connection pooling issues. Finally, if there *is* a companion reason, it may be the message indicated to the right, indicating that SQL Server was running as a valid domain account and, upon restarting, it can’t validate the account because the domain controller is offline or the account is locked or no longer valid. Try changing the service account to LocalSystem until you can sort out the domain issues.
27 Error: 18456, Severity: 14, State: 27.
Login failed for user ‘<x>’.
State 27, like state 16, only occurs prior to SQL Server 2008. It means that the database specified in the connection string has been removed, renamed, or is offline (possibly due to AutoClose) – though in every case I tried, it was reported as state 16. This state does not indicate a reason in the error log. In 2008 and onward this is reported as state 38 (see below), with a reason.
28 Error: 18456, Severity: 14, State: 28.
Login failed for user ‘<x>’.
I have not experienced this issue but I suspect it involves overloaded connection pooling and connection resets. I think you will only see state 28 prior to SQL Server 2008.
38 Error: 18456, Severity: 14, State: 38.
Login failed for user ‘<x>’.
Reason: Failed to open the database specified in the login properties.

 or

 Reason: Cannot open database «<database>» requested by the login. The login failed.

The database specified in the connection string, or selected in the Options > Connection Properties tab of the SSMS connection dialog, is no longer valid or online (it might be set to AutoClose or the user may simply not have permission). I came across this once when I typed <default> here instead of picking that option from the list. This is reported as state 27 or state 16 prior to SQL Server 2008.

 Note that this could also be a symptom of an orphaned login. After establishing mirroring, Availability Groups, log shipping, etc. you may have created a new login or associated a user with a login on the primary database. The database-level user information gets replayed on the secondary servers, but the login information does not. Everything will work fine – until you have a failover. In this situation, you will need to synchronize the login and user information (for one example, see this script from the late Robert Davis).

40 Error: 18456, Severity: 14, State: 40.
Login failed for user ‘<x>’.
Reason: Failed to open the explicitly specified database.
Usually this means the login’s default database is offline (perhaps due to AutoClose) or no longer exists. Resolve by fixing the missing database, or changing the login’s default database using ALTER LOGIN (for older versions, use sp_defaultdb, which is now deprecated). This is reported as state 16 prior to SQL Server 2008.
46 Error: 18456, Severity: 14, State: 46.
Login failed for user ‘<x>’.
Reason: Failed to open the database configured in the login object while revalidating the login on the connection.
State 46 may occur when the login (or login mapping to the service account) does not have a valid database selected as their default database. (I am guessing here but I think this may occur when the login in question is attempting to perform log shipping. Again, just a guess based on the few conversations I discovered online.) It can also occur if the classifier function (Resource Governor) or a logon trigger refers to a database that is offline, no longer exists, or is set to AutoClose.
50 Error: 18456, Severity: 14, State: 50.
Login failed for user ‘<x>’.
Reason: Current collation did not match the database’s collation during connection reset.
As the message implies, this can occur if the default collation for the login is incompatible with the collation of their default database (or the database explicitly specified in the connection string). It can also happen if they are using a client tool like Management Studio which may, when they have been disconnected, try to connect to master upon reconnection instead of their default database.
51 Error: 18456, Severity: 14, State: 51.
Login failed for user ‘<x>’.
Reason: Failed to send an environment change notification to a log shipping partner node while revalidating the login.
Like states 11 & 12, this could have to do with UAC, or that the domain controller could not be reached, or that the domain account could not authenticate against the log shipping partner, or that the log shipping partner was down. Try changing the service account for SQL Server to a known domain or local account, rather than the built-in local service accounts, and validating that the partner instance is accessible, as well as the database that is being requested in the connection string and the default database of the login. Note that this could be trigged by the failover partner connection string attribute, and that the database may no longer exist or may be offline, single user, etc.
56 Error: 18456, Severity: 14, State: 56.
Login failed for user ‘<x>’.
Reason: Failed attempted retry of a process token validation.
State 56 is not very common – again, like states 11 & 12, this could have to do with UAC, or that the domain controller could not be reached. Try changing the service account for SQL Server to a known domain or local account, rather than the built-in local service accounts.
58 Error: 18456, Severity: 14, State: 58.
Login failed for user ‘<x>’.
Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only.
State 58 occurs when SQL Server is set to use Windows Authentication only, and a client attempts to log in using SQL Authentication. It can also occur when SIDs do not match (in which case the error text might be slightly different).
62 Error: 18456, Severity: 14, State: 62.
Login failed for user ‘<x>’.
State 62 occurs when a Windows Authentication account tries to access a contained database, and the contained database exists, but the SIDs do not match.
65 Error: 18456, Severity: 14, State: 65.
Login failed for user ‘<x>’.
Reason: Password did not match that for the user provided. [Database: ‘<x>’]
Contained user exists, the database is correct, but the password is invalid. This can also happen if you use a SQL login to connect to a contained database that has a contained user with the same name but a different password (one of several reasons this is not recommended).
102
103

110
111
Error: 18456, Severity: 14, State: 102.
Error: 18456, Severity: 14, State: 103.
Error: 18456, Severity: 14, State: 104.
Error: 18456, Severity: 14, State: 105.
Error: 18456, Severity: 14, State: 106.
Error: 18456, Severity: 14, State: 107.
Error: 18456, Severity: 14, State: 108.
Error: 18456, Severity: 14, State: 109.
Error: 18456, Severity: 14, State: 110.
Error: 18456, Severity: 14, State: 111.
Documented by Microsoft as Azure Active Directory login failures.
122
123
124
Error: 18456, Severity: 14, State: 122.
Error: 18456, Severity: 14, State: 123.
Error: 18456, Severity: 14, State: 124.
According to Microsoft, these indicate a blank or missing username and/or password.
126 Error: 18456, Severity: 14, State: 126.
The docs say «Database requested by user does not exist.» But it’s not clear why you would get 126 instead of, say, 38 or 40.
132
133
Error: 18456, Severity: 14, State: 132.
Error: 18456, Severity: 14, State: 133.
Documented by paschott and by Microsoft as Azure Active Directory login failures.
146
147
148
149
Error: 18456, Severity: 14, State: 146.
Login failed for user ‘<Windows auth login>’.
Reason: Token-based server access validation failed with an infrastructure error. Login lacks Connect SQL permission.

 Error: 18456, Severity: 14, State: 147.
Login failed for user ‘<SQL auth login>’.
Reason: Login-based server access validation failed with an infrastructure error. Login lacks Connect SQL permission.

 Error: 18456, Severity: 14, State: 148.
Login failed for user ‘<Windows auth login>’.
Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission.

 Error: 18456, Severity: 14, State: 149.
Login failed for user ‘<SQL auth login>’.
Reason: Login-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission.

These states replace states 11 and 12 above, but only in SQL Server 2016 or better. The goal was to make the actual underlying issue easier for the sysadmin to diagnose between SQL auth and Windows auth logins, and between connect and endpoint permissions (all without giving any further info to the user trying to log in). For more details, see the latter part of this post.

I am sure I missed some, but I hope that is a helpful summary of most of the 18456 errors you are likely to come across. Please let me know if you spot any inaccuracies or if you know of any states (or reasons) that I missed.

If you are using contained databases, there will be a little extra complication in solving login failures, especially if you try to create contained users with the same name as server-level logins. This is a ball of wax you just probably don’t want to get into…

Thanks to Jonathan Kehayias (blog | twitter), Bob Ward (CSS blog | twitter), and Rick Byham for input and sanity checking.

Sql server error 18456 is common issue appear during login process on Microsoft SQL Server. This error can happen when you try to login with local administrator, as well as under the domain administrator and under the sa. Microsoft SQL Server login failed error can be encountered due to varied reasons. Most of the time, an error code comes up with a description that gives a hint about what has gone wrong. But I some cases the error come without any description. In this article, we’ll take a look at the typical reasons of the error 18456 appear on SQL Server during login process and show different ways to solve this error.

The view of error:

“Login failed for user ‘<user_name>’. (Microsoft SQL Server, Error: 18456)”.

"<yoastmark

How To FIX SQL Server Error 18456

Troubleshoot with Short Solutions

Here, you have some possible reasons:

  1. The login does not exist or was not typed correctly
  2. Make sure that the username or password are correct
  3. The password is incorrect
  4. The user forgot the password or login
  5. The Windows Authentication is not in Mixed mode
  6. A virus resets all the passwords
  7. A malicious hacker reset the password
  8. The logins were damaged or the master database is damaged
  9. The database was migrated, but the logins were not migrated
  10. The administrator modified the passwords by mistake
  11. Restart the SLQ Server service

Troubleshoot with State of the Microsoft SQL error 18456

Most of the time the SQL error 18456 come with the severity and state number. A state number might not mean much, yet it can offer more details as to what is wrong and where to look next.

To get a more detailed info about Microsoft SQL Server Error 18456 reason, you need to open the SQL Server error log file – ERROR.LOG. This is plain text file located under folder MSSQLLog. Below are some states of the error 18456 sql server. The descriptions and potential solutions offer a quick explanation and potential troubleshooting guide.

 State Error Description
1 Error information is not available. This state usually means you do not have permission to receive the error details
2 Invalid user ID
5 User ID is not valid.
6 Attempt to use a Windows login name with SQL Authentication
7 Login disabled
8 Password is incorrect
9 Password is not valid
11-12 Valid login but server access failure
13 SQL Server service paused
16 Authorization is correct, but access to the selected database is not allowed
18 Change password required
27 Initial database not found
38 Could not find database requested by user
 

102 – 111

AAD failure.
122 – 124 Failure due to empty user name or password.
126 Database requested by user does not exist.
132 – 133 AAD failure.

Common Solution for Error 18456

If the issue cannot be resolved from with short solutions above, read below for additional information:

Read also other SQL Server Helping Posts:

  1. SQL Server Error 233
  2. Fix SQL server error 26 and error 40
  3. Restore Master Database

Checking the Server Authentication Mode

In this case you are trying to login on SQL Server using sql user. Once we login to SSMS using Windows Authentication, we need to check the security settings to confirm whether MSSQL is set up to allow both Windows and SQL Authentication.

Check and Change SQL Server Authentication Mode from GUI:

  1. In SSMS, right-click the Server Name at the top of the Object Explorer window and choose Properties.
  2. Next, click the Security page.
  3. If you find Windows Authentication is the only mode configured, this is the likely cause of sql server error 18456, Login failed for user ‘’.
  4. Setting the Server authentication mode to allow SQL Server and Windows Authentication, you will be able to login to MS-SQL with a SQL user and password or a Windows user and password. After making this change, you will need to restart the SQL Server service.

Server Authentication Mode

Server Authentication Mode

Change SQL Server Authentication Mode from regedit

You can use the registry to modify the authentication mode. Use the regedit to change the registry:

Image (regedit)

  1. machineHKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerMSSQLXX.MSSQLSERVERMSSQLServer
  2. Change the login mode value.
    1. 2 is mixed mode.
    2. 1 is Windows Authentication.

Change SQL Server Authentication Mode from regedit

Change SQL Server Authentication Mode from regedit

Checking pass expired or login disabled

Check out that the password is not expired.

  1. Open SSMS, Instance – Security – Logins and find the user that have issue
  2. On general tab check if the Enforce password expiration and enforce password policy are checked
  3. Un-check them

Check out that the login is enabled.

  1. Open SSMS, Instance – Security – Logins and find the user that have issue
  2. On status tab and check if is selected the “Enabled” option

Reset the Password of the user

If you forget your password, you can ask your DBA to reset your account. The easiest way to reset the password is by using SQL Server Management Studio (SSMS).

  1. Go to security and Logins:
  2. Select the login and you can change the password:

Checking pass expired or login disabled

Checking pass expired or login disabled

  1. If you do not like to use SSMS, you can use T-SQL to create users and change the password:

USE [master] GOALTER LOGIN [Test] WITH ‘newpasswordtest’GOChange Windows Authentication

So we hope that you fixed the issue with the sql server error 18456.

Понравилась статья? Поделить с друзьями:

Не пропустите эти материалы по теме:

  • Яндекс еда ошибка привязки карты
  • Ошибка sql 911
  • Ошибка sql 901
  • Ошибка sql 53603
  • Ошибка sql 42601

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии