SQL Server 'Login failed for user' Error Fix

You're getting error 18456 and it's stopping your app dead. I've been there.

This error hits when SQL Server can't authenticate the user trying to connect. The fix is usually quick once you know where to look. Let's get you back online.

The Most Common Fix: Enable Mixed Mode Authentication

If you installed SQL Server with Windows Authentication only, SQL logins (like 'sa' or any SQL user) won't work. Here's how to check and fix it:

1. Open SQL Server Management Studio (SSMS) as administrator.
2. Right-click the server in Object Explorer, select Properties.
3. Go to the Security page.
4. Under Server authentication, select SQL Server and Windows Authentication mode.
5. Click OK.
6. Restart the SQL Server service. You can do this from SQL Server Configuration Manager or run this command in a command prompt as admin: net stop MSSQLSERVER && net start MSSQLSERVER (adjust service name if it's a named instance).

That's it. Now SQL logins should work. If you're still stuck, move to the next section.

Why This Works

SQL Server has two authentication modes: Windows-only (default for many installations) and mixed mode (Windows + SQL). When you pick Windows-only, the server rejects any login attempt that uses a SQL username and password — even if the credentials are correct. Switching to mixed mode tells SQL Server to accept both. This is the single most common cause of error 18456 in environments where developers or apps use SQL logins.

Less Common Variations

If mixed mode is already on, the problem is elsewhere. Here are the usual suspects:

1. The Login Doesn't Exist or Is Disabled

Check if the user you're connecting with actually exists in SQL Server. In SSMS, expand Security > Logins. If you don't see the login, create it:

CREATE LOGIN [your_user] WITH PASSWORD = 'your_password';

If the login exists but is disabled, right-click it, select Properties, and uncheck Login is disabled.

2. Wrong Password or Expired Password

SQL Server error 18456 doesn't always tell you it's a password issue. Try resetting the password for the login in SSMS. Right-click the login, choose Properties, and set a new password. If the login has a policy requiring password expiration, check User must change password at next login and uncheck it if you don't want that.

3. The User Doesn't Have Access to the Database

Even if the login works, the user must be mapped to a database. In SSMS, go to the login's Properties, then User Mapping. Check the database(s) you want, and assign a database role like db_owner or db_datareader. Without this, you get 18456 when trying to connect to a specific database.

4. Connection String Issues (Especially with Named Instances)

I've seen this trip up developers for hours. If you're using a named instance (like SERVER\SQLEXPRESS), make sure your connection string includes the instance name correctly. A common mistake is using a single backslash instead of double. In C#, it looks like this:

"Data Source=YOURSERVER\\SQLEXPRESS;Initial Catalog=YourDB;User ID=your_user;Password=your_password;"

In a config file, you escape it differently:

Data Source=YOURSERVER\SQLEXPRESS;Initial Catalog=YourDB;User ID=your_user;Password=your_password;

Also, if you're using a port number (like 1433), don't include the instance name — just use the port.

5. The SQL Server Browser Service Isn't Running

For named instances, the SQL Server Browser service must be running so clients can find the instance. Open SQL Server Configuration Manager, go to SQL Server Services, and check that SQL Server Browser is started and set to automatic. If it's not, start it.

How to Prevent This Going Forward

I'll be blunt: the easiest way to avoid error 18456 is to plan your authentication before you deploy. Here's what I do:

• Always use mixed mode if you'll have SQL logins, even if you think you only need Windows auth. It's easier to switch now than later.
• Document your logins and passwords in a secure vault. Nothing worse than resetting passwords because someone forgot.
• Test your connection strings locally before moving to production. Use a tool like sqlcmd to test: sqlcmd -S YOURSERVER\INSTANCE -U your_user -P your_password. If that works, your app should too.
• Check the SQL Server error logs for more detail. Open SSMS, go to Management > SQL Server Logs. Look for entries around the time the error happened. They often include a sub-state that tells you exactly what went wrong (like 'password didn't match' or 'login disabled').
• Set up alerts for 18456 errors in your monitoring tool. That way you catch issues before users do.

Error 18456 is annoying, but it's almost always a configuration problem — not a SQL Server crash. You've got this.