Login Failed: The Account Is Disabled (Error 18470)

This is the friendliest member of the login-failure family, because it tells you exactly what is wrong. Unlike a wrong password, where the client gets a deliberately vague message and the real reason hides in the server error log, a disabled account announces itself. On a current driver the client sees the reason directly. This is the exact client output from the lab repro:

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for
user 'ErrDemoDisabled'. Reason: The account is disabled..

And the server error log entry, same attempt:

Logon    Login failed for user 'ErrDemoDisabled'. Reason: The account is
disabled. [CLIENT: 192.168.1.109]

So when someone reports “login failed” and the word disabled appears anywhere, you can skip the whole password-reset dance. The account exists, the password may even be right, and none of that matters until the login is switched back on.

Why This Happens

Logins do not disable themselves. Someone or something did it:

• A leaver or security process. Disabling instead of dropping is the correct practice for accounts that might own objects or might need to come back, so tidy environments produce this error by design.
• The sa lockdown. Disabling sa is standard hardening, and anything still configured to connect as sa starts failing with exactly this the moment it happens.
• Policy lockout confusion. An account locked out by Windows password policy reports a different reason (and a different state), but the two get mixed up in tickets constantly. The message text settles it: disabled means disabled.
• A restore or migration. Logins scripted from another server with Generate-LoginScript style tooling carry their disabled state with them, which is correct behaviour that surprises people.

Confirm It in One Query

SELECT name,
       is_disabled,
       type_desc,
       modify_date
FROM sys.server_principals
WHERE name = N'ErrDemoDisabled';

is_disabled = 1 is the whole diagnosis, and modify_date tells you when it changed, which is usually the fastest route to who changed it. The default trace and the server audit, if one is configured, hold the rest of that story.

The Fix

ALTER LOGIN [ErrDemoDisabled] ENABLE;

That is genuinely all, but before running it, ask the question the error is really raising: was this account disabled on purpose? If it belonged to a leaver, the fix is not enabling it, the fix is finding out what is still trying to use it. The server error log’s [CLIENT: ip] suffix in the entry above names the machine making the attempts.

When It Is Not This

If the message says nothing about the account being disabled you are in ordinary 18456 territory, where the client is told State 1 and the truth lives server-side. And if logins fail in a burst across many accounts, look at the domain and the server rather than any single login.

Common Questions

Related Scripts

• Login Failed (18456), the vague parent of this whole family
• Untrusted Domain (18452), the Windows-identity sibling
• Get Login Security Audit, every login’s state and policy flags in one pass
• Kerberos vs NTLM, the authentication plumbing behind the series