Login failed for user (Microsoft SQL Server, Error: 18456)

What it means

The server received your sign-in and turned it down. Error 18456 covers every reason a login can fail (wrong password, no such login, a database you can’t open, SQL Server authentication turned off), and SQL Server deliberately doesn’t say which one to the client. Whatever went wrong, your client gets the same thing:

Msg 18456, Level 14, State 1
Login failed for user 'inlet'.

State 1 means “no details for you”. The real reason goes to the server’s error log, as a state number and a Reason: line:

Error: 18456, Severity: 14, State: 8.
Login failed for user 'inlet'. Reason: Password did not match that for the login provided. [CLIENT: 192.168.148.1]

So the fastest fix is to ask whoever runs the server to look up the state, or to look it up yourself if you have another login that can read the log (see below).

What the states mean

The states from Microsoft’s documentation, with the Reason: text SQL Server 2022 wrote for the ones we triggered on a test server:

Microsoft notes that other states exist and mean an unexpected internal error.

Common causes

1. Wrong password (state 8): a typo, a password changed on the server but not in the app, or special characters mangled in a connection string.
2. The login doesn’t exist on this server (state 5): you’re on a different server, instance or port than you think, or the account is a database user with no server login.
3. The database you asked for can’t be opened (state 38, with error 4060 first): a misspelt name, an offline database, or a login with no user in that database.
4. The login’s default database is gone (state 40, with error 4064): it was dropped, renamed or taken offline, and you didn’t name another one.
5. SQL Server authentication is off (state 58): the server is in Windows Authentication mode, so no SQL login works, sa included.
6. The login is disabled, locked out, or must change its password (state 7, or the separate errors 18470, 18486, 18487 and 18488).
7. On Azure SQL Database: a contained database user without the database in the connection string, or a client address the firewall doesn’t allow (that one is error 40615, not 18456).

How to fix it

Read the state in the error log

On the server, with a login allowed to read the error log:

EXEC sp_readerrorlog 0, 1, N'Login failed';   -- the "Reason:" lines
EXEC sp_readerrorlog 0, 1, N'18456';          -- the "State:" lines, same timestamps

The first argument is the log file (0 is the current one), the second 1 means the SQL Server log (2 is SQL Server Agent’s), and the third filters the lines. SQL Server 2022 and later need the VIEW ANY ERROR LOG or VIEW SERVER PERFORMANCE STATE permission for this; 2019 and earlier need VIEW SERVER STATE. Without it you get:

Msg 27219, Level 16, State 1, Procedure sp_readerrorlog, Line 11
Caller does not have permissions to execute the stored procedure.

In Docker, docker logs <container> prints the same lines. On Windows the log is also in SQL Server Management Studio under Management › SQL Server Logs.

Wrong password (state 8)

Check the password the app actually sends: environment variables and .env files with a stray space or newline, and connection strings where ;, = or } inside the password broke the string. Then reset it, as an administrator:

ALTER LOGIN [app] WITH PASSWORD = '<new password>';

In Docker, MSSQL_SA_PASSWORD sets sa’s password when the container first creates its data files. If the data lives on a volume, changing the variable later doesn’t change the password: sign in with the old one and use ALTER LOGIN, or start with a fresh volume if the data is disposable.

Login not found (state 5)

Make sure you’re on the server you think, then list its logins:

SELECT @@SERVERNAME AS server_name, @@SERVICENAME AS instance;
SELECT name, type_desc, is_disabled, default_database_name
FROM sys.server_principals
WHERE type IN ('S', 'U', 'G')
ORDER BY name;

A login lives on the server; a user lives in a database and is linked to a login. A database restored from another server brings its users but not the logins, so create the login (and map the user to it), or create both:

CREATE LOGIN [app] WITH PASSWORD = '<password>';
-- then, in the database:
CREATE USER [app] FOR LOGIN [app];

Contained database users have no login at all: the database checks the password itself. For those, the connection string must name the database, or the server looks for a login in master, finds none, and refuses you with 18456.

The database can’t be opened (states 38 and 40)

State 38 is the database named in your connection string; see Cannot open database requested by the login. State 40 is the login’s default database, used when you don’t name one. Either name a database that exists in the connection string, or point the login at one:

ALTER LOGIN [app] WITH DEFAULT_DATABASE = [master];

SQL Server authentication is off (state 58)

Check the mode:

SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS windows_only;   -- 1 = Windows only

To allow SQL logins, open the server’s Properties › Security in SQL Server Management Studio, choose SQL Server and Windows Authentication mode, and restart the SQL Server service. Microsoft notes that when a server installed in Windows mode is switched to mixed mode, sa stays disabled, which then fails with state 7: enable it with ALTER LOGIN sa ENABLE; and give it a strong password, or better, create a named login instead.

Disabled, locked or expired logins

SELECT name, is_disabled,
       LOGINPROPERTY(name, 'IsLocked') AS is_locked,
       LOGINPROPERTY(name, 'IsExpired') AS is_expired,
       LOGINPROPERTY(name, 'IsMustChange') AS must_change
FROM sys.sql_logins
ORDER BY name;

ALTER LOGIN [app] ENABLE;
ALTER LOGIN [app] WITH PASSWORD = '<new password>' UNLOCK;   -- also clears a lockout

These cases often come with their own number and a reason the client does see: a disabled login with the right password gets Msg 18470 … Reason: The account is disabled., and one that must change its password gets Msg 18488 … Reason: The password of the account must be changed.

Azure SQL Database

• There’s no error log to read. The client message adds a session tracing ID that Azure support can look up.
• Logins live in the logical server’s master database and users in each database; the server admin you chose when creating the server has full access. A user created in a database WITH PASSWORD is a contained user and must connect with that database named.
• Sign in with the plain login name and the full server name, <server>.database.windows.net, as Microsoft’s own SSMS steps do. The <user>@<server> form in older guides isn’t needed for that.
• A client address the server’s firewall doesn’t allow gets error 40615 before any password is checked, starting Cannot open server '<server>' requested by the login. Client with IP address '<address>' is not allowed to access the server. Add your address under the server’s Networking settings in the Azure portal (or with sp_set_firewall_rule in master); changes can take up to five minutes. See connecting to Azure SQL Database.

Reproduce it

On SQL Server 2022 (RTM-CU27, 16.0.4295.3) in Docker, with sqlcmd 18.6 from the container:

sqlcmd -C -S localhost -U inlet -P wrong -d inlet -Q "select 1"
sqlcmd -C -S localhost -U nobody -P whatever -d inlet -Q "select 1"
sqlcmd -C -S localhost -U reader -P <password> -d sales -Q "select 1"

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'inlet'..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'nobody'..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Cannot open database "sales" requested by the login. The login failed..
Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'reader'..

sqlcmd doesn’t print the state of a login error, so we also read the error the server sent back with a short TDS client script. All three, and a login with a database that doesn’t exist, got state 1:

Msg 18456, Level 14, State 1, Server 7732422b7f56, Line 1
Login failed for user 'inlet'.
Msg 4060, Level 11, State 1, Server 7732422b7f56, Line 1
Cannot open database "sales" requested by the login. The login failed.
Msg 18456, Level 14, State 1, Server 7732422b7f56, Line 1
Login failed for user 'reader'.

The error log, read with EXEC xp_readerrorlog 0, 1 for those seconds:

Error: 18456, Severity: 14, State: 8.
Login failed for user 'inlet'. Reason: Password did not match that for the login provided. [CLIENT: 192.168.148.1]
Error: 18456, Severity: 14, State: 5.
Login failed for user 'nobody'. Reason: Could not find a login matching the name provided. [CLIENT: 192.168.148.1]
Error: 18456, Severity: 14, State: 38.
Login failed for user 'reader'. Reason: Failed to open the explicitly specified database 'sales'. [CLIENT: 192.168.148.1]
Error: 18456, Severity: 14, State: 38.
Login failed for user 'inlet'. Reason: Failed to open the explicitly specified database 'nosuchdb'. [CLIENT: 192.168.148.1]

SQL Server 2019 (15.0.4490.9) and 2025 (17.0.5005.3) gave the same client messages, states and reasons.

The other states came from a temporary SQL Server 2022 container (the same build), where we could create logins: a disabled login with a wrong password (state 7), a login whose default database had been dropped (state 40, with Msg 4064 … Cannot open user default database. Login failed. first), and a login with DENY CONNECT SQL (state 147). A disabled login with the right password got Msg 18470 and a MUST_CHANGE login Msg 18488, each with its reason in the client’s message. Sending an empty user name got state 58 and the “Integrated authentication only” reason, even though that server allows SQL logins. Every one of them reached the client as state 1 or with its own number; none showed the 18456 state.

Last, a SQL Server 2022 container with its data on a Docker volume, started with MSSQL_SA_PASSWORD set to one password, then stopped and started again on the same volume with a different one: the new password failed with state 8, and the first one still worked.

In Inlet

When SQL Server rejects the password, Inlet’s connection window shows the server’s message and asks for the password right there; once the server accepts it, Inlet can save it in the Keychain. The error’s detail reads SQL Server error 18456, state 1, severity 14 (state 1 is all any client is told) and links to this page. Inlet signs in with SQL Server authentication, a login and password; Microsoft Entra ID and Windows sign-in aren’t supported yet.