Tag: Azure

Automate and Deploy Microsoft Defender Advanced Threat Protection (MDATP) via PowerShell

A few days ago, I needed to on-board Azure Windows Server VMs with Microsoft Windows Defender Advanced Threat Protection, or in short, MDATP. Sometimes Azure Security Center (ASC) has issues with on-boarding VMs and deploying the MDATP agent. As a result, I wrote the following PowerShell script that will download the MDATP.cmd file from my Azure Blob container and install it locally to the VM. This script allows you to automate it for many VMs to the scope of a Resource Group.

Now there are a few assumptions here…

  1. Download the MDATP.cmd file from the Defender Security Center portal
  2. Remove the requirement for user consent for the MDATP execution
  3. Upload the modified MDATP file to an Azure Blob container
  4. Generated a SAS URI for the MDATP file

There are many examples on the Internet on how to go step #4. Maybe in time I will do another post.

To remove the requirement of the MDATP agent to execute based on user interaction/consent can be done by removing, or commenting out the following lines of code. Launch the MDATP.cmd file within Notepad, and add a “:” before each line of code from lines 9 through 19, except line 14. Should look something like this.

Now, update and run the following PowerShell code. You can validate the VM is calling back to the Defender Security Center portal or by running the MDATPClientAnalyzer on the VM.

#update resource as needed
$resourcegroup = "YOUR_RESOURCE_GROUP"
#get only Windows Server VMs
$vms = Get-AzVM -ResourceGroupName $resourcegroup | Where-Object {$_.StorageProfile.OSDisk.OSType -eq "Windows"} | Select-Object Name
foreach ($vm in $vms)
{
    #friendly start message to indicate which server has started
    Write-Host "Server $vm has started..."
    #create folder, do not display error if folder already exists
    New-Item -Path "C:\" -Name "MDATP" -ItemType "directory" -ErrorAction SilentlyContinue
    #download MDATP.cmd file from Storage Account with SAS URI. Execute the cmd file. Passing "Y" to continue with installation.
    Invoke-WebRequest -Uri "YOUR_URI_SAS" -OutFile WindowsDefenderATPLocalOnboardingScript.cmd; Start-Process -FilePath "C:\MDATP\WindowsDefenderATPLocalOnboardingScript.cmd" -Verb RunAs
    #sleep for 5 seconds
    Start-Sleep -Seconds 5
    #restart-server
    Restart-Computer -ComputerName $vm
    #friendly finished message to indicate which server has completed and will now reboot
    Write-Host "Server $vm has completed, reboot initiated..."
}

Get Azure Global Administrators

Recently a customer asked me to retrieve all users that have Global Administrator access to their Azure environment. The PowerShell code below will allow you to query the Azure environment against Azure Active Directory (AAD). Nothing new here or unique here, but this quick two-liner should do the trick. 😉

$role = Get-AzureADDirectoryRole | Where-Object {$_.displayName -eq 'Company Administrator'}
Get-AzureADDirectoryRoleMember -ObjectId $role.ObjectId | Sort-Object DisplayName | Select-Object DisplayName, UserPrincipalName, ObjectId 

Hope this was helpful!

Azure Bastion – What is it?

A little late to the party but nevertheless, I wanted to quickly show what is and how to use Azure Bastion. Azure Bastion is still in “public preview” but the solution is mature enough to start implementing now. Azure Bastion reduces the risk significantly in comparison to your traditional jumpbox approach, as it forces users to authenticate over SSL/443.

So what is Azure Bastion? Azure Bastion is a fully managed service by Azure/Microsoft that allows you to RDP and/or SSH into any Azure VM. Azure Bastion allows you to connect to your Azure VMs over HTML5-based browsers and using SSL.

Key Benefits:

  • Protection against 0-Day exploits:
    • Because Bastion sits at the perimeter of your VNet, you do not need to worry about hardening each of your VMs (although you should harden everything!!) The Azure platform will protect you keeping Azure Bastion hardened and is always up-to-date.
  • No Public IP(s) required for your Azure VMs:
    • By using Bastion, you can remove PIPs from your Azure VMs and can force your users to go through the Bastion host to connect to your VMs in your Azure environment.
  • Remote Sessions over SSL:
    • Since Azure Bastion uses HTML5 modern browsers, users can RDP/SSH over SSL (443) enabling you traverse corporate firewalls securely.
  • Simplified Management of NSGs:
    • Since Bastion is fully managed PaaS service by Azure, you no longer need to apply Network Security Groups (NSGs) on your Bastion subnet.  Since Bastion connects to your VMs over a Private IP, you can configure your NSGs to allow RDP/SSH from Azure Bastion only.

Architecture:

Source: Microsoft, https://docs.microsoft.com/en-us/azure/bastion/bastion-overview

The architecture diagram above shows use the workflow how Azure Bastion works.

  • The Bastion host is deployed within a VNet and with its own dedicated subnet
  • Users can connect with any modern HTML5 browser
  • No Public IPs on Azure VMs

Base Requirements:

Before getting setup with Azure Bastion there are some key things to know for example.

  • You must have a Virtual Network
  • The VNet must have a subnet dedicated for Bastion and its name must be “AzureBastionSubnet”
  • It is always recommended to have the subnet with a /27 CIDR. It is easy to grow your subnet as needed, much more difficult to shrink. Always start small and grow as needed.
  • No User Defined Routing (UDR) or Network Security Groups (NSG) can be applied to the subnet.

 

Next step, how to deploy and configure Azure Bastion. If you want to get started with Azure Bastion, you can enroll with the Public Preview here, https://aka.ms/BastionHost.

Azure Policy – Audit for Network UDR Changes

Azure Policy has been available for some time now, but for folks getting start with Cloud Governance, Azure Policy is a service in Azure that allows you to manage, assign, and create custom policies. These policies can be used to enforce a global set of rules or specific set of controls for a specific environments, ie. less control and governance in a “development” environment. This allows resources to stay compliant with you enterprise standards. Azure policies can enforce different rules, from Denying specific services, for example, ensuring only resources are built within a specific region, ie. resources can only be built within the Canadian regions. Conversely, rather than enforcing, policies can also be configured to Audit, where resources will be marked if they are not compliant, for example, a Storage Account is not configured with secure transfer.

Before diving into the policy itself, I want to quick go over the types of conditions that are available, and that can be used to enforce different compliance rules. The following table shows how different policy effects work with the condition evaluation for the resulting compliance state. Although you don’t see the evaluation logic in the Azure portal, the compliance state results are shown. The compliance state result is either compliant or non-compliant.

Resource StateEffectPolicy EvaluationCompliance State
ExistsDeny, Audit, Append, DeployIfNotExist, AuditIfNotExist*TrueNon-Compliant
ExistsDeny, Audit, Append, DeployIfNotExist, AuditIfNotExist*FalseCompliant
NewAudit, AuditIfNotExist*TrueNon-Compliant
NewAudit, AuditIfNotExist*FalseCompliant
  • *The Append, DeployIfNotExist, and AuditIfNotExist effects require the IF statement to be TRUE. The effects also require the existence condition to be FALSE to be non-compliant. When TRUE, the IF condition triggers evaluation of the existence condition for the related resources.

Source: https://docs.microsoft.com/en-us/azure/governance/policy/assign-policy-portal

In this example today, I want to show a real world example, where a customer recently asked to monitor any changes being made to their UDRs (User Defined Routes/Routing).

The following will continuously monitor all UDRs in the environment. If any changes are made to a single UDR table, it will be audited and its changes will be tracked. Once the policy is enabled, you can see it in action by creating/modifying a UDR.

“policyRule”: {
   “if”: {
      “anyOf”: [
       {
            “source”: “action”,
            “like”: “Microsoft.Network/routeTables/*”
       }
    ]
    },
   “then”: {
   “effect”: “audit”
    }
}

See below for the compliance once a change has been made to a UDR. Once you drill down to the event, the user, the activity log, you can then see the exact changes that were made to the UDR.

I hope this was helpful! 

Deploy an Azure Cloud Witness for your Failover Cluster Quorum for Windows Server 2016 & 2019 with PowerShell

For the longest time, when deploying a cluster with Windows Server, you only had the two options,

  1. Using a dedicated disk for the quorum, or
  2. Configuring an SMB file-share as the quorum witness

With Server 2016 and 2019, there is now a third option, Cloud Witness. The Cloud Witness leverages Azure Blob storage to provide that additional cluster/quorum vote.

Before showing you how this is done, one should understand the purpose of a witness/quorum is with respect to a failover cluster.

When one or more members of a cluster stops reporting to the other cluster members, there is a vote. The vote ensures that there is no split-vote, and ensures the cluster has a true owner. For example, in a two node cluster, if each node believe it is the owner, then this will cause a “split-brain”. In short, neither node will ever agree it is the owner (or not). This is where a quorum is required to determine who is the owner by providing the third vote, ie. majority. This ensures the cluster has a true owner by having the majority of votes. Each member gets a vote, plus the quorum.

Why this matters, in the even there is no quorum, a node from the cluster can be evicted and as a result will suspend all application services to prevent data corruption by more than one system writing data without the cluster services coordinating data writes and access. Depending on policies, VMs running on the ejected cluster member will either suspend operations or be migrated to other nodes before being ejected.

Below is a step-by-step guide on how to configure the Azure Blob storage as the Cloud Witness.

Assumptions:

  • The Azure Blob storage account has already been created,
  • The cluster with at least 2 nodes already exists.

Launch the PowerShell console as Administrator, and execute the following cmdlet:

Set-ClusterQuorum -CloudWitness -AccountName "storage_account_name" -AccessKey "primary_access_key"

Now if we go back to the Failover Manager console we can see we have successfully configured cluster with a Cloud Witness.

In conclusion, deploying a Cloud Witness for a Failover Cluster is very simple, and in case of power outage in one datacenter, maintenance on a node, etc. then the entire cluster and its members (nodes) are all given an equal opportunity. Not only is it recommended and a requirement for 2-node clusters, but for any number of nodes, having a quorum is key ensuring high-availability.  As mentioned, there are the traditional options such as using a dedicated disk or a file-share (SMB) as the cluster witness. However with Azure Blob storage with its 16×9 uptime, we can always ensure the quorum witness is online and available.

Deploy an Azure Cloud Witness for your Failover Cluster Quorum for Windows Server 2016 & 2019

For the longest time, when deploying a cluster with Windows Server, you only had the two options,

  1. Using a dedicated disk for the quorum, or
  2. Configuring an SMB file-share as the quorum witness

With Server 2016 and 2019, there is now a third option, Cloud Witness. The Cloud Witness leverages Azure Blob storage to provide that additional cluster/quorum vote.

Before showing you how this is done, one should understand the purpose of a witness/quorum is with respect to a failover cluster.

When one or more members of a cluster stops reporting to the other cluster members, there is a vote. The vote ensures that there is no split-vote, and ensures the cluster has a true owner. For example, in a two node cluster, if each node believe it is the owner, then this will cause a “split-brain”. In short, neither node will ever agree it is the owner (or not). This is where a quorum is required to determine who is the owner by providing the third vote, ie. majority. This ensures the cluster has a true owner by having the majority of votes. Each member gets a vote, plus the quorum.

Why this matters, in the even there is no quorum, a node from the cluster can be evicted and as a result will suspend all application services to prevent data corruption by more than one system writing data without the cluster services coordinating data writes and access. Depending on policies, VMs running on the ejected cluster member will either suspend operations or be migrated to other nodes before being ejected.

Below is a step-by-step guide on how to configure the Azure Blob storage as the Cloud Witness.

Assumptions:

  • The Azure Blob storage account has already been created,
  • The cluster with at least 2 nodes already exists.

Launching the Failover Manager within Windows Server manager, connect to the cluster, and do the following. Right click the cluster object and select More Actions > Configure Cluster Quorum Settings…

Next select the Advanced Quorum configuration..

Ensure we have all the nodes selected, as seen below.

Next, select the Configure a Cloud Witness:

Now we need to get our Azure Blob storage account name, and its primary account key. This can be retrieved from the Azure portal.

Now validate the settings and complete the configuration.

Now if we go back to the Failover Manager console we can see we have successfully configured cluster with a Cloud Witness.

In conclusion, deploying a Cloud Witness for a Failover Cluster is very simple, and in case of power outage in one datacenter, maintenance on a node, etc. then the entire cluster and its members (nodes) are all given an equal opportunity. Not only is it recommended and a requirement for 2-node clusters, but for any number of nodes, having a quorum is key ensuring high-availability.  As mentioned, there are the traditional options such as using a dedicated disk or a file-share (SMB) as the cluster witness. However with Azure Blob storage with its 16×9 uptime, we can always ensure the quorum witness is online and available.