Recovering local administrator access in Azure VMs

Password

Hey guys!

Let’s assume that for any reason you have lost the local administrator password of a virtual machine in Azure or even don’t remember the initial user created during the deployment of your virtual machine, well, the idea of this post is to solve this your problem, which just seems silly  but not unusual.

Starting with the user, in case you don’t remember, it’s a pretty simple task to find out: Go to Azure and make sure your VM is powered on, then select your VM and go to blade “Operations” and select “Run Command” and finally click on “RunPowerShellScript”. This will cause a dialog box to open and in this box you will type the following command in: “Get-LocalUser” and click “Run”.

04

The output should be presented as the image above, and at this point you will know which are the local users of that VM.

Ok, now that you know which user to use, just type in the password, correct? But let’s say you also don’t remember which password to use (Bad days happen to everyone lol). Well then, I will present two simple ways to reset this local user password.

The easiest and simplest option would be again with your VM selected, go to the blade “Help” and click on “Reset Password”. You will only need to enter the user  you want to reset the password and your new password.

(Ps: You will need to be logged into Azure with an user who gives you this right,  “RBAC” is a certification exam topic).

05

If all goes well, you will have the new password and use your local account without any problems.

But let’s assume that this lost password is the domain controller administrator password in Azure. In this case, you will not be able to reset this password as I just showed you above.

Therefore, we will be using the Extensions function in Azure. Through this extension we will run a script to reset the admin password.

The script is very simple and has only one line and has been uploaded to Azure previously.

script

The script must have the command above: net user LOCALUSER PASSWORD

07

After creating the script, saving as ResetPassword.ps1 and uploading it to a storage account on azure, select your VM again and in the blade Settings click on Extensions > Add > CustomScriptExtension > Next > RESETPASSWORD.PS1 > Review + Create > Create.

09

The Azure extension function will run the script on the VM and your password will be reset as configured in the script.

Voila! You will now be able to access your domain controller as you wish. This script can also be used to reset any account’s password.

Obviously the reset options are not limited to what I presented here in this post, especially when it comes to PowerShell commands.

10

That’s it for today guys, see you next time!

Joao Costa

How to authenticate AzCopy on Azure

AzCopy should now be downloaded to your computer (If you don’t know how to do this, go back to the last post here). But before you can perform any tasks, it is necessary to authenticate to your Azure subscription to access Azure Storage first.

There are two ways to authenticate AzCopy to your Azure storage accounts – Azure Active Directory or by a Shared Access Signature (SAS) token. In this article, we’ll focus on using Azure AD.

The most common method to authenticate AzCopy is via Azure AD. When using Azure AD, you have several options. Some of these options are:

  • Interactive Login – User is prompted to log in using the browser.
  • Service Principal + password – For non-interactive login. Recommended for automation and scripting.
  • Service Principal + certificate – For non-interactive login. Recommended for automation and scripting.

In this article, you will learn how to authenticate via interactive login. To do so, first, open a command prompt or PowerShell and run the below command. The –tenant-id parameter is optional but recommended, especially if your login account is associated with more than one Azure tenant.

image

Once executed, you will be asked to open a browser and navigate to https://microsoft.com/devicelogin and enter the displayed code. You can see what that will look like below.

05Enter the code from AzCopy into the browser

Once you’ve entered the code into the browser, click Next and proceed to sign in to your account.

03

When sign-in is done, you should see the status shown in the browser and in the terminal similar to what’s shown in the screenshot below.

04

Now that you have all this knowledge, you should now be ready to put AzCopy in action! See you soon folks!

PowerShell Execution Policies

So you decide to use PowerShell for the first time, and when you run a PowerShell script, you get a security warning or maybe you see some error messages and then the PowerShell window disappears. Here are some simple tips for your first PowerShell experience to be a success.

Make sure you are using the latest version of PowerShell:

https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-windows?view=powershell-7.1

About Execution Policies

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.1

Open your PowerShell console

Always open it in elevated mode (If possible), with the title “Administrator: Windows PowerShell”. Then you try to execute a command, script or even import a module as in my example below.

image

This issue occurs because PowerShell starts with the execution of scripts disabled, obviously this happens for security reasons, after all, your environment can be seriously affected by a malicious script.

In the screen below, you can see that I ran the Get-ExecutionPolicy command and the response was Restricted

image

There are 5 scopes of Execution Policy, and it depends on your need, but it is important that you know how to manipulate each scope and why.

  1. MachinePolicy: Set by a Group Policy for all users of the computer.
  2. UserPolicy: Set by a Group Policy for the current user of the computer.
  3. Process: The Process scope only affects the current PowerShell session. The execution policy is saved in the environment variable $env:PSExecutionPolicyPreference, rather than the registry. When the PowerShell session is closed, the variable and value are deleted.
  4. CurrentUser: The execution policy affects only the current user. It’s stored in the HKEY_CURRENT_USER registry subkey.
  5. LocalMachine: The execution policy affects all users on the current computer. It’s stored in the HKEY_LOCAL_MACHINE registry subkey.

It is also important to know how to manipulate policies and which is the most suitable for your needs. I will list the policies that you can configure to use in your environment

  • AllSigned
  • Scripts can run.
  • Requires that all scripts and configuration files be signed by a trusted publisher, including scripts that you write on the local computer.
  • Prompts you before running scripts from publishers that you haven’t yet classified as trusted or untrusted.
  • Risks running signed, but malicious, scripts.
  • Bypass
  • Nothing is blocked and there are no warnings or prompts.
  • This execution policy is designed for configurations in which a PowerShell script is built in to a larger application or for configurations in which PowerShell is the foundation for a program that has its own security model.
  • Default
  • Sets the default execution policy.
  • Restricted for Windows clients.
  • RemoteSigned for Windows servers.
  • RemoteSigned
  • The default execution policy for Windows server computers.
  • Scripts can run.
  • Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the internet which includes email and instant messaging programs.
  • Doesn’t require digital signatures on scripts that are written on the local computer and not downloaded from the internet.
  • Runs scripts that are downloaded from the internet and not signed, if the scripts are unblocked, such as by using the Unblock-File cmdlet.
  • Risks running unsigned scripts from sources other than the internet and signed scripts that could be malicious.
  • Restricted
  • The default execution policy for Windows client computers.
  • Permits individual commands, but does not allow scripts.
  • Prevents running of all script files, including formatting and configuration files (.ps1xml), module script files (.psm1), and PowerShell profiles (.ps1).
  • Undefined
  • There is no execution policy set in the current scope.
  • If the execution policy in all scopes is Undefined, the effective execution policy is Restricted for Windows clients and RemoteSigned for Windows Server.
  • Unrestricted
  • The default execution policy for non-Windows computers and cannot be changed.
  • Unsigned scripts can run. There is a risk of running malicious scripts.
  • Warns the user before running scripts and configuration files that are not from the Local intranet zone.

And finally, right after changing the execution policy in my example below to Unrestricted, it was possible to import the Azure module into the PowerShell.

image

Example 1: Set-ExecutionPolicy Unrestricted -force

Example 2: Set-ExecutionPolicy RemoteSigned -force

Note: The Parameter –Force is used only to prevent warnings from appearing, and then it is not necessary to make confirmations.

I do not recommend leaving the policy set to Unrestricted, this was just for example. You must adapt to your need and if it is necessary to apply the Unrestricted policy do not forget to change when you finish your task. At the beginning of the article, I also left a link to Microsoft Docs where you can learn more about the subject, I will stop here and see you later!