Unable to Change Password Logging into an Azure-hosted Virtual Server

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…

Symptom

On a Windows Server 2008 R2, a user may be prompted to change his/her password when logging on for the first time:

The user’s password must be changed before logging on the first time

This error message is expected and is a good feature from the security standpoint – however, it indirectly causes the next issue:

Configuration information could not be read from the domain controller

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:

The user’s password must be changed before signing in

Once you type in the new password, you get the same error:

Configuration information could not be read from the domain controller

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.

Cause

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.

Resolution

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.

Additional Information

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:

The local security authority cannot be contacted

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.

No Responses to "Unable to Change Password Logging into an Azure-hosted Virtual Server"

This article definitely applies to Windows 2008 R2 Workgroup Servers as well. It is good to know the fix is in how we log onto the server via the RDP client.

If you use .Username as your RDP entry it will fill in the hostname of the PC/Server from which you a launching the RDP client. YOU MUST USE either the hostname or IP Address of the remote computer to which you are connecting to avoid the issue (RemoteHostnameUsername, RemoteIPAddressUsername).

For example if the remote server was named Lulu at IP Address 10.20.30.40 and the username was Bubba you would use either of the following logon credentials to launch your RDP session.

LuluBubba – The name Lulu must be in DNS file or your Local Host file (C:Windowssystem32driversetchosts)

10.20.30.40Bubba – This is perhaps the easiest method to utilize to avoid the issue as it requires no additional changes to any host files.