Error 0xC000006D: logon failure when connecting to a server or share

Fix it now

0xC000006D is the general logon failure. Microsoft publishes it as “Generic logon failure” with two causes: an invalid username and/or password, or a LAN Manager authentication level mismatch between the source and target computers. The detail you need is in the sub-status recorded alongside it in the security event log.

net use \\server\share /user:DOMAIN\username *
nltest /dsgetdc:contoso.local
cmdkey /list

1. On the machine that refused the connection, open Event Viewer, Windows Logs, Security, and find event 4625 for the attempt. Read the Sub Status field, not the message the user saw.
2. Match the sub-status against the table below. 0xC000006A is a wrong password; 0xC0000064 means no account by that name exists as submitted.
3. Test the identity format explicitly. Try the down-level form, DOMAIN\username, then the user principal name form, user@contoso.local, and see whether the sub-status changes.
4. Confirm the client can find a domain controller with nltest /dsgetdc:contoso.local before concluding anything about the credential.
5. Clear any stored credential for that server so Windows stops replaying an old password behind your back, then retry and re-read the newest event.
6. If nothing about the credential is wrong, compare the LAN Manager authentication level setting on both machines. Microsoft names a mismatch there as a documented cause of this code.

Read the event on the machine that did the refusing. For a share that is the file server, not the client, and looking in the wrong place is the commonest reason this takes an hour instead of five minutes.

If the connection succeeds and the newest event records a success, you are done. If not, the next section maps each sub-status to its own fix.

Why it happens

When an authentication attempt fails, the package returns a general status to the caller and records a more precise sub-status in the event log. The user-facing message is deliberately unhelpful: Microsoft’s own note on repeated 0xC0000064 events is that several in a row can indicate a user enumeration attack, which is exactly what a message distinguishing an unknown account from a wrong password would make easier. The detail lives in the security log, which only administrators can read.

The fields worth reading are the account name and domain exactly as submitted, the logon type, both status values, and the source network address. Logon type 3 is a network logon such as a share; type 10 is Remote Desktop. Between the submitted name and the logon type you can usually tell within seconds whether this is a typing mistake, an identity format problem or something structural.

Identity format causes more of these than bad passwords do. The down-level form is domain and user separated by a backslash. The user principal name form is the user name, an at sign and a suffix, and the suffix has to be one the forest actually knows about, which is not always the DNS domain name. A local account on a remote machine needs the machine name in front of it, and a local account name typed without a prefix is often sent as a domain account instead.

One documented cause is regularly missed: Microsoft lists a LAN Manager authentication level mismatch between the source and target computers as a cause of 0xC000006D, alongside a bad username or password. If the credential is definitely right and the account is definitely fine, that is where to look next, and no amount of retyping the password will move it.

Full reference

Mapping the sub-status to the fault

These are Microsoft’s published descriptions, taken from the tables for Security events 4776 and 4625.

Note that 0xC000006A is the wrong-password sub-status and is not itself in this article’s code list, because it is not what the caller receives – it is what the log records underneath 0xC000006D. That is the whole shape of this problem: the code you are shown and the code that explains it are different, and only one of them is useful.

Identity formats, and when each one works

The LAN Manager authentication level

This is the cause most often left out of advice on this code, and Microsoft lists it explicitly. The setting decides which authentication protocols a machine will send and accept. Two machines configured at incompatible levels cannot complete a logon, and the result is a generic failure with a correct password and a healthy account.

• Compare the setting on both the source and the target, not just on the one that is complaining.
• Expect this where an older device, appliance or application is talking to a hardened Windows machine, or where a hardening baseline has been applied to one side only.
• Raise the weaker side rather than lowering the stronger one. Lowering it to make a connection work weakens every other connection that machine makes.
• If the weaker side is a device that cannot be raised, that is a replacement conversation, not a configuration one.

Reading the event without guessing

1. Go to the machine that refused the connection. For a share, that is the file server.
2. Windows Logs, Security, and find the newest 4625 for the account and time in question.
3. Read Account Name and Account Domain exactly as submitted. Half the answers are visible right there.
4. Read Logon Type. 3 is a network logon; 10 is Remote Desktop.
5. Read Sub Status, and only then decide what to change.
6. Retry, and read the newest event again. A changed sub-status is progress even when the connection still fails.

Every code this article covers

Confirm the fix worked

1. Repeat the connection and confirm the newest security event records a success rather than a failure.
2. Confirm the bad password count on the account has stopped rising.
3. Test the same credentials from a second machine, to prove the fix is on the account rather than on one client.
4. Where a stored credential was the cause, sign out and back in and confirm nothing re-creates it.
5. If you changed an authentication level setting, confirm the machine’s other connections still work before you leave it.

Questions people ask about this