Hidden features of “resetting” passwords of VMs in the Azure Portal

The “Reset” Password functionality for VMs in Azure.

In the Azure Portal, Azure conveniently allows you to reset the password of the local Administrator on a Virtual Machine. To use this functionality it requires you to enter the username and the new password for this account. All good and well, you’d say. That’s what it is supposed to do after all.

Color me surprised when I noticed that a colleague of mine had gotten access to my VM without resetting the password of the local Administrator account that I had created. I didn’t give this colleague the username (which you need) nor should it have been trivial to put the password back to what it was (and that I had safely stored in my password manager).

Hidden feature: creating new Users

And not just any User but a new local Admin. When you enter a non-existent username in the Portal, it will happily create a new local Administrator account for the User entered.

Hidden feature: enabling a disabled account

What if you know the username of the local Administrator but the account has been disabled? No problem! The VMAccess extension will reset the password and enable the account for you as a side-effect.


Only Administrator accounts

If you try to reset the password of an account which does not belong to the Administrators group, you’ll get an error in the activity logs and the provisioning status of the VMAccess extension will change to “Failed”.

Errors in the Activity Log

Monitoring this activity

As I am part of Team Blue, one of the immediate reflexes I have is to check the logs this activity generates. The Activity Log mentions all activities above as “Create or Update Virtual Machine Extension”.

Logs generated by “resetting” passwords.

The reason for this is that the “Reset Password” functionality uses the VMAccess extension to make the changes and thus the logs only mention “writes” to this extension.

The Activity Log in Log Analytics

Microsoft Defender for Endpoint will also log User creations in the logs which can be monitored for the creation of new local Admin accounts.

Is this expected behaviour?

Turns out it is although the only mention you’ll find on Azure Portal of the “hidden features” are hidden under a small icon. I wrongly stated this on Mastodon where I missed this since nobody would hover this “info” icon anyway.

Hidden under the small Info icon is the expected behaviour of also adding new users.

No mention, however, of also enabling the account if it is disabled.

In the Error you get when resetting the password of a non-Administrative account, we find the function name of the code that’s being run and that clearly mentions it can also add user accounts:

Microsoft.WindowsAzure.GuestAgent.Plugins.RemoteAccessAccountManager.AddOrUpdateRemoteUserAccount(String userName, SecureString password)


Leave a comment

Your email address will not be published. Required fields are marked *