About: The purpose of this document is to detail the resolution of a situation that deals with a user's inability to login to a Server 2008R2/2012R2 system for no apparent reason; note that it is assumed that the system is not part of a domain (non-domain joined).

Symptoms and context: Logging in to the server (supplying the proper username and password) returns, instead of the expected Remote Desktop session, an error message which reads:

An authentication error has occurred. The Local Security Authority cannot be contacted.

The issue is encountered when the following two conditions are fulfilled:

1. the user account's password has expired or the account has simply become locked due to multiple incorrect login attempts

and

2. the underlying system is employing Microsoft's NLA technology (see the Wikipedia article for a succinct account of what NLA is, or see this Technet entry for a more detailed one); NLA comes enabled by default on Server 2012R2 systems, but it has to be manually enabled on 2008R2, which makes it less likely for the issue to be encountered on such systems

Root cause analysis: What happens, due to NLA, is that the user gets prompted for his credentials (at his end) by the RDP Client, which in turn packages and presents them to the server - if they are correct, the server opens the RDP connection proper and presents the user with a login screen (on which, usually, there is no need to input the credentials again) and the subsequent terminal session (the Desktop). But, if the credentials are not correct - because they have expired, for instance -, then the server simply refuses the connection and the user is never presented with the login screen which would allow him to change his expired password. As such, an user account that has an expired password can no longer login to a Server system that employs NLA - this is not a bug, but a consequence of the technology (it's a feature, as it were).

Resolution: Solving the issue mostly comes down to a password reset, with the additional effort of paying attention to a few details, due to the usual corporate context and good practices when it comes to a user's password. What follows is a step by step account of the process:

• login to the affected server and open an elevated Command Prompt shell

• run net user %userAccount%⁽¹⁾ and identify if the user's account is locked, or if the password has simply expired (the Password expires date is in the past)
  -> if the account is locked (Account active is set to Locked), and assuming that this is due to the user's own multiple incorrect login attempts, have the user try his login again after you have unlocked it:
  net user %userAccount% /active:yes⁽²⁾

• assuming that the the password is expired, or the user has forgotten it (the reason for the account being locked, for instance), reset it by running net user %userAccount% * (you will be prompted to input the new password twice; note that the input will not echo to the console)

• retrieve the timestamp of the password change that you've performed by running net user %userAccount% | findstr -ic:"password last set"

• check what the current minimum password age is set to through the Local Security Policy by running the following command: net accounts | findstr -ic:"minimum password age"; if the value is '0', there is no need to modify it and thus the next step can be skipped, otherwise make a note of what the value is

• set the Minimum password age policy to 0 days, because the policy is enforced even for administratively reset passwords (meaning that, without suspending the policy, the user will not be able to change his password on the same day that you have reset it); this can be accomplished by running the following command: net accounts /minpwage:0

• communicate the reset password to the user and ask that it be changed as soon as possible

• after the user reports that he's changed the provided password, verify the claim by running net user %userAccount% | findstr -ic:"password last set" again; the timestamp should differ from the one previously retrieved:
  -> if it does, the user has indeed changed his password and you can continue the process
  -> if it does not, the user has not yet changed his password, perhaps you can find out why and try to assist him

• assuming that the user has correctly changed his password, set the Minimum password age policy back to 1 days (or whatever value it had); the command for the 1 days example would look like this:
  net accounts /minpwage:1

• at this point you are all done

Notes: 1. %userAccount% denotes the username of the affected account (for example, itataru).

2. According to the 1st and 2nd references, especially the second, there exists an undocumented /logonpasswordchg: boolean switch (the values are 'yes' and 'no', with 'no' being the implicit value) for the net user tool. Unfortunately, this does not simplify the process because a password change cannot be executed through the establishment of an NLA-enabled RDP session, as explained in the 3rd reference link, meaning that the usefulness of this switch is negated in this scenario, forcing the use of the convoluted method described here.

References:

1. https://www.lifewire.com/net-user-command-2618097
2. http://blog.johnmuellerbooks.com/2011/04/12/working-with-net-user
3. https://serverfault.com/questions/604811/how-is-the-change-password-at-next-logon-requirement-supposed-to-work-with-rdp#605016