Recently, I started getting reports from clients/users having issues logging into virtual servers running Windows Server 2008 R2 and Windows Server 2012 operating systems via RDP. This logon issue seems to be affecting virtual machines in private datacenters as well as in Azure Cloud.
Before signing off on a project, you test everything out using dev/admin/test accounts and pass all checks. The moment users try to access the server for the first time, they immediately report problems…
On a Windows Server 2008 R2, a user may be prompted to change his/her password when logging on for the first time:
This error message is expected and is a good feature from the security standpoint – however, it indirectly causes the next issue:
This error, “Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied“, is not making a lot of sense especially in Azure Cloud deployment scenario, when you just created your first server and do not have any integration with any of the existing on-prem Active Directories.
This error happens on a stand-alone, workgroup-joined server, brand new installation right out of the box.
On the Windows Server 2012 virtual server running in Azure Cloud, the error is the same but of course looks a bit different in line with the UI changes:
Once you type in the new password, you get the same error:
Again, the same scenario – brand new server installation, never joined to any AD environments, brand new user account that is set to change password on the first logon.
The issue is caused by the RDP client, more specifically by the user providing incorrect DOMAIN information in the RDP logon dialog box.
- The latest RDP Client (8.0 as of this writing) is affected by this issue
- It does not matter what authority the user has on the remote system, this issue affects administrators and members of the Remote Desktop Users group alike
When you log on to a stand-alone Windows server using RDP, normally you can type in anything into the domain box, and as long as your user account name matches to a local account on the server you are connecting to, RDP connection will succeed. So in this use case, domain information does not need to be accurate.
Example: if you are logging in as “WORKBENCH\Administrator” to a stand-alone server named TOR-SAPBW-01 that has a local Administrator account, this logon request will be matched to the local Administrator account and the RDP logon will succeed.
However, if the local account on the remote server has an expired password, or has the “change password on next logon” flag set, domain information has to be provided accurately in the RDP logon dialog. If you are logging into a stand-alone server (running in Azure Cloud, for instance), you must provide logon credentials in the localhost\<username> format; for example, localhost\Administrator.
The issue is easy to run into on any RDP client machine that logs on to more than one RDP-enabled server. By default, RDP client will remember credentials from the previous logon, and will pre-populate domain information incorrectly when you launch mstsc.exe (RDP client) to establish a new connection to a different server.
Save your RDP connections as .rdp files with the correct logon information, or ensure that you provide account information using the correct “LOCALHOST” domain during the logon that forces you to change password.
Keep in mind, that this information applies to RDP servers that are set to NOT force network-level authentication (NLA). If NLA is forced, and the password expiration or change is in effect on the account, RDP client not located on the same local network as the remote server will not be able to authenticate at all. You would get this error message instead:
To avoid this issue, you are advised to disable NLA (in the server properties, Remote Access tab), but in this case it is also a very good idea to use Terminal Server Gateway to encrypt all RDP traffic using SSL.