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!