SQL Server Error 18456: Login Failed for User — Read the State First

Why the client message is not enough

SQL Server deliberately limits authentication detail returned to the client. The corresponding server log can contain the more useful Reason and State. Error 18456 is therefore a family of login/authentication failures, not one password error. Use the state table as a router only after correlating the exact log entry; Microsoft can document additional states or deployment-specific meanings over time.

Fix #1 — find the server-side Reason and State, even if you cannot log in

Reproduce one failed login at a known time. If you already have a different administrative connection, SSMS can show the current log under Management → SQL Server Logs. But do not assume SSMS access exists: Microsoft also documents the SQL Server error log as a text file that can be read directly by an authorized operating-system administrator. On Windows the default pattern is <drive>:\\Program Files\\Microsoft SQL Server\\MSSQL.<n>\\MSSQL\\LOG\\ERRORLOG; on Linux it is /var/opt/mssql/log. The actual Windows instance path can differ, so locate the active instance rather than guessing MSSQL.<n>. If you have neither SQL nor host access, give the DBA the timestamp, username, client/application, and exact target instance and ask for the matching 18456 Reason/State.

Verify: the log entry matches the same identity, timestamp/client/application and the server instance/node that actually received the attempt. Read the textual Reason together with State, then confirm the mapping against current Microsoft documentation for that deployment before changing security configuration.

Fix #2 — states 2, 5, 7, 8, 9, or 18: credentials/login branch

Microsoft maps States 2 and 5 to invalid user ID, 7 to a disabled login with incorrect password, 8 to incorrect password, 9 to invalid password, and 18 to a password that must be changed.

First prove the application reaches the intended instance and uses the identity you expect. Deployment configuration, environment settings, secret stores, or generated connection strings can override a value that looks correct elsewhere.

Verify: Retest the intended account against the intended instance; the original credential-related Reason/State should be gone.

Fix #3 — states 38, 46, 126: requested/default database branch

States 38, 46 and 126 route you toward the requested/default-database branch in current Microsoft guidance, but do not reduce the diagnosis to spelling alone. Read the accompanying Reason: the effective database can be missing, unavailable, not openable in the current deployment/state, or inaccessible through the intended login context. Availability-group/listener and failover scenarios also make it important to confirm which replica/node received the login.

Important boundary with Error 4064: the client may show Cannot open user default database. Login failed and Microsoft SQL Server, Error: 4064, while the SQL Server error log records the underlying login/database-open failure. If 4064 is the visible client error, treat 4064 as the primary troubleshooting intent; use the 18456 Reason/State here only as supporting server-side evidence.

Check the effective database name, the login’s default database, database availability, and whether the login has intended access. If another permitted database is available, specifying it temporarily can help prove that the login itself works while the default/requested database is the failing gate. Do not confuse that diagnostic test with repairing the intended database.

Verify: Connect to an available database the login is allowed to use, or correct the intended database/access. Confirm both that the database-related 18456 state is gone and that a client-facing 4064 no longer occurs when the intended database is used.

Fix #4 — states 6 or 58: align authentication mode

State 6 can indicate a Windows login name was used with SQL Server Authentication. State 58 commonly appears when SQL authentication is attempted against a Windows Authentication-only instance; Microsoft also documents SID mismatch as another possible cause.

If Windows Authentication is intended, use integrated/trusted authentication; Microsoft recommends Windows Authentication when possible. If SQL logins are genuinely required, confirm that Mixed Mode is an intentional server policy and create/use a scoped SQL login appropriate to the application.

Verify: The client authentication method matches the approved server configuration, the application uses the intended least-privileged identity, and the original State 6/58 is gone.

Fix #5 — domain user or states 11/12: verify Windows server access

Microsoft maps States 11 and 12 to a valid login whose server access fails. Check the Windows identity SQL Server actually receives, intended SQL Server login/group, effective group membership, explicit DENY permissions and target server. Do not infer the server-side token solely from the interactive username or service configuration you expected.

Do not make “Run as Administrator” the permanent answer. Elevation is one documented State 11 scenario, but durable access should be granted intentionally to the identity the application or user actually runs as.

Verify: test through the real application/service path and confirm the SQL Server log sees the intended Windows identity and that identity has intended server access without depending on accidental local-admin elevation.

Fix #6 — ANONYMOUS LOGON or (null): Kerberos/SPN/delegation branch

NT AUTHORITY\ANONYMOUS LOGON commonly points to a Windows authentication handoff problem. In multi-machine double-hop scenarios, Microsoft directs troubleshooting toward Kerberos, SPNs, and delegation. A (null) identity can also point to token/SPN problems.

Confirm the client → middle tier → SQL Server path, service identity, DNS/server name, and SPN ownership before changing delegation.

Verify: The SQL Server log shows the intended Windows identity rather than ANONYMOUS LOGON/(null), and the real application path succeeds.

Other states — keep the exact state

Microsoft also documents State 62 for a contained-database Windows-authentication SID mismatch, States 102–111 and 132–133 for Microsoft Entra ID failures, and 122–124 for an empty username or password. Other states can indicate unexpected internal processing errors.

Verify: Match the exact state and Reason against current Microsoft documentation for the deployment before applying a fix from a different branch.

Still seeing Error 18456?

If the state changes after a fix, treat the new state as new evidence. Reaching a database-related state after clearing an authentication-mode state can mean you passed the first gate.

Official references