Are your IaaS DC's Secured in Azure ?

by Contributed | Nov 26, 2020 | Azure, Microsoft, Technology

This article is contributed. See the original author and article here.

Hi Everyone,

Zoheb here again with my colleague Tim Beasley. Today, we will be sharing some best practices to help ensure that your VMs (virtual machines) (including Domain Controllers) are secure in your Azure/Cloud environment.

I would like to start this blog with an African Proverb “If you want to go fast, go alone. If you want to go far go together.”

This proverb is one of the principals we refer to internally at Microsoft (#OneMicrosoft). It helps us utilize the synergy to build / leverage great ideas from other Microsoft employees across the globe.

This proverb sums it up perfectly of what occurred during the creation of this blog post. There were multiple contributors (Tristan Kington, Akhlesh Sharma, Pierre Audonnet and Shobhit Garg) who also helped provide details and additional information in hopes of benefiting our customers.

The Initial Problem I found myself facing – I forgot my Administrator Password!

While working in my lab environment in Azure, I sometimes forget what the Administrator password is (This rarely happens. Am I right? :p). Considering this is an important environment I needed to regain access to, I started thinking about different ways of retrieving my password.

Initially, I tried guessing what password was using a few random ones. However, this did not work (I have Azure AD Password Protection configured in my lab to help protect against known passwords :smiling_face_with_smiling_eyes:). I then tried the VM Password Reset option, but that only works for members of the local Administrators group.

Suddenly, I had an epiphany! I remembered the Extensions setting that is available for VMs running in Azure where you can execute scripts running under the System Context.

To achieve this, I located and selected the Azure Virtual Machine I was targeting and clicked on Extensions which is located under Settings. Here is where I will upload and execute a Custom Script Extension as shown below:

 Figure 1. Click on Extensions.

 Figure 2. Select Custom Script Extension.

 Figure 3. Browse for the custom PowerShell script you wish to upload.

 Figure 4. Select Upload to upload your custom PowerShell script.

As you can see below, I uploaded the testreset.ps1 PowerShell script (to be added as a custom script extension) and ran it on the virtual machine in my lab environment. The PowerShell script uses the native Command Prompt utility Net.exe. In this example, we used Net User to reset the password for an Administrator account named zdcadm using DontKeepe@syPassw0rd$ as the password.

Net User zdcadm DontKeepe@syPassw0rd$

 Figure 5. Custom PowerShell script was uploaded.

After the extension was applied and executed against the VM, it successfully reset the password for my Administrator account (zdcadm), which allowed me to regain access to that VM.

We managed to achieve this because Azure VM Agent is installed by default on any Windows VM deployed from an Azure Marketplace image. When you deploy an Azure Marketplace image from the portal, PowerShell, Command Line Interface, or an Azure Resource Manager template, the Azure VM Agent is also installed.

Though I was happy that this allowed me to log back into the VM, it also started to concern me. So, I started thinking about how this could potentially affect our customers and whether they are protecting their environment from such risks where Privilege escalation can be gained by Azure operators to domain admin (and by extension, domain admin on-prem).

We found similar concerns that were raised / discussed for our traditional infrastructure (Hypervisors) where we provide broad guidance on how to secure them. You can learn more about this by reading the Virtualizing Domain Controllers using Hyper-V Microsoft article.

Why should you be concerned?

You as an organization who have DC’s in Azure or cloud you should check who has access to them in Azure & is the access to Subscription controlled well.

Do you have any Azure Operators who could do Privilege Escalation to become a Domain Admin?

Remember when you let someone else administer a lower layer than your own, you are implicitly trusting that person equivalently to yourself.

The 10 Immutable Laws of Security are applicable everywhere.

Increasingly we see permissions being mis managed in many organization and Identity team is not always managing subscriptions, this can lead to some loose permissions on your resources if left unmonitored/checked.

How can you check who has access to your Domain Controllers or Azure Resources ?

There are many ways you could see who has access to resources, I am listing one of the easier ways where you can get full information from a single dashboard.

Use the Azure Continuous Cloud Optimization dashboard, this can show the Azure RBAC (role-based access control) permissions from all the subscriptions a given Azure account has access to. You will be able to identify the roles applied to all Azure resources and if the subscriptions have custom roles. You can filter the information by:

• Tenant


• Subscription


• Object type


• User

The Solution to this little dilemma:

This made us think about the “Level of Protection” we should recommend to our customers that have important VMs (e.g. Domain Controllers) running in Azure. After several internal discussions along with reviewing publicly available Microsoft documentation, we decided that the following recommendations below will add an extra layer of protection to help secure your Azure IaaS VMs / environment (Not all, but heavy hitters)

1. Force MFA (Azure Multi-Factor Authentication) for Admins with access to Domain Controllers (no matter where they are at – on-premises and cloud) whenever they are accessing Azure Portal.
   
   
   
   1. This will ensure that access to Azure Portal has at least two factor Authentication.
   
   
   2. Use this policy for all the users who have access to Azure Subscription where DC’s are hosted.
      
      
   
   
   
   


2. Use Conditional access policies to define Admins location, Trusted machines to access Azure Portal for Domain Controller Subscriptions.
   
   
   
   1. You can further control the access to the Azure Portal/Subscription by using Conditional Access.
   
   
   2. You could define Trusted location, Trusted devices and many such parameters.
   
   
   3. This will help reduce the access to Domain Controllers.
      
      
   
   
   
   


3. Limit Highly privileged users and use RBAC permissions to allow access to only specific people to DC’s.
   
   
   
   1. This is probably the most crucial point of all, you need to review who has permission to do such an activity and if they really need this.
   
   
   2. You could review this using CCO dashboard.
   
   
   3. Alternatively you could navigate to Azure Portal and look for “Access Control”
   
   
   4. Check for important Role Assignments like “Contributors, Owners etc.
   
   
   5. Review these users on a regular basis
      
      
   
   
   
   


4. Where possible, use a Different Subscription for Domain Controllers or Tier 0 systems.
   
   
   
   1. Effective subscription design helps organizations establish a structure to organize and manage assets in Azure during cloud adoption.
   
   
   2. When possible use a dedicated subscription for all your Tier 0 assets
      
      
   
   
   
   


5. PIM (Azure Active Directory Privileged Identity Management) for elevation to Domain Controller VM Access and follow just enough Administration (Least Privilege principal)
   
   
   
   1. Setup appropriate permissions to the “Azure Resource” through PIM.
   
   
   2. Define Eligible Assignments
   
   
   3. This will ensure that only users who are eligible get access to Domain Controllers in Azure
   
   
   4. Follow Just Enough Administration and least privilege model
      
      
   
   
   
   


6. Use Azure ADDS (Active Directory Domain Services) when possible.
   
   
   
   1. When you create an Azure AD DS managed domain, you define a unique namespace.
   
   
   2. Two Windows Server domain controllers (DCs) are then deployed into your selected Azure region. This deployment of DCs is known as a replica set.
   
   
   3. You do not need to manage, configure, or update these DCs. The Azure platform handles the DCs as part of the managed domain, including backups.
   
   
   4. Since this is managed there is reduced risk also for this
      
      
   
   
   
   


7. Using PAW(Privileged Access Workstations) to access Azure portal
   
   
   
   1. Secured, isolated workstations are critically important for the security of sensitive roles like administrators, developers, and critical service operators.
   
   
   2. Use highly secured user workstations and/or Azure Bastion for administrative tasks for Azure.
   
   
   3. The secured workstations can be centrally managed to enforce secured configuration, including strong authentication, software and hardware baselines, and restricted logical and network access.
   
   
   4. Using conditional access allow only approved machines to have access to Azure portal.
   
   
   5. Alternatively manage these machines through hardened GPO’s & Intune
   
   
   
   

Hope this helps,

Tim & Zoheb