Error 18456 indicates that SQL Server rejected a login attempt because the supplied credentials or connection settings were invalid or unauthorized.
SQL Server Error 18456 occurs when the server rejects a login attempt with “Login failed for user.” Check the message state code, verify username/password, unlock or enable the account, and confirm the login has CONNECT permission on the target database to resolve the issue.
Login failed for user '<user>'. (Microsoft SQL Server, Error: 18456)
SQL Server raises Error 18456 when an incoming connection attempt fails authentication. The message always reads “Login failed for user” and includes a hidden state code that pinpoints the exact reason. The error blocks access, so mission-critical apps can stall until credentials are fixed.
The error appears in SQL Server 2005 through 2022 and surfaces in SQLCMD, SSMS, .NET connection strings, and third-party tools like Galaxy.
Because the text is generic, reading the state code from the SQL Server error log is essential for accurate troubleshooting.
Error 18456 is triggered by incorrect passwords, disabled logins, missing server-level permissions, or mismatched default databases. Other causes include expired SQL logins, Windows account lockouts, and authentication mode mismatches (Windows vs. SQL authentication).
Each root cause maps to a numeric state (2–38).
For example, State 8 means a bad password, State 11 means the login lacks server access, and State 38 means the login cannot open the requested database.
Start by capturing the state code from the SQL Server error log with EXEC xp_readerrorlog. Cross-reference the code with Microsoft’s list to identify the root cause.
Then apply the corresponding corrective action—reset the password, enable the login, grant CONNECT SQL, or change the default database.
After making changes, retry the connection.
If the error persists, validate that the client uses the correct server name and that the instance allows the chosen authentication mode.
Bad password (State 8): Reset the SQL login password and update stored connection strings.
Disabled login (State 7): Re-enable the login with ALTER LOGIN … ENABLE.
Missing server access (State 11/12): Grant server-level CONNECT SQL permission or add the login to sysadmin.
Cannot open user default database (State 38): Change the login’s default database to a valid one or restore the database.
Use Windows Authentication whenever possible to avoid password drift.
Implement SQL Agent jobs to alert on login failures. Rotate and store SQL credentials in a secrets manager. Regularly audit disabled or orphaned logins.
Galaxy’s AI Copilot surfaces failed login attempts in real time and suggests the exact T-SQL fix, reducing time-to-resolution for engineering teams.
Error 4064 – Cannot open user default database. Fix by changing the default database or restoring it.
Error 233 – No process is on the other end of the pipe.
Usually follows 18456 if shared memory/pipe protocols are disabled.
Error 18452 – Login failed. Not associated with a trusted connection. Indicates Windows authentication failure when Mixed Mode is off.
.
The submitted password does not match the stored hash for the SQL login.
The login is disabled by an administrator or locked after too many failures.
The account exists but lacks CONNECT SQL permission or is denied explicitly.
The default database is offline, dropped, or the user has no access.
The server is set to Windows Authentication, but the client uses SQL Authentication, or vice versa.
.
“Login failed.
Not associated with a trusted connection.” Occurs when Windows authentication is required but the client sends SQL credentials.
“No process is on the other end of the pipe.” Often follows 18456 when the connection is terminated during login negotiation.
“Cannot open user default database.” Happens when the default database is offline or the user lacks permission.
“Cannot open database requested by the login.” Indicates the database does not exist or the user is not mapped.
.
Query the SQL Server error log with EXEC xp_readerrorlog and locate the row containing “Error: 18456.” The last number in the line is the state code.
SQL Server itself does not lock accounts, but Windows policies or contained database settings can lock or disable logins after repeated failures.
No. Repeated login failures fill logs, mask security issues, and may indicate credential drift that will eventually break the application.
Galaxy’s context-aware AI surfaces the exact error state, auto-generates the corrective T-SQL, and lets teams share endorsed fixes, reducing MTTR.