Spring 2020 – Security Webinars

Also during (a somewhat different) spring, Microsoft is keeping its promise by delivering webinars to introduce new and improved technology.

Be sure to mark the dates!

April 15MCAS: Enabling Secure Remote Work
April 20MSSP Support
April 22Threat Hunting on AWS using Sentinel
November 21st Using Sigma to accelerate your SIEM transformation to Azure Sentinel

Details and registration information can be found on https://aka.ms/SecurityWebinars

Self-Service Password reset for Windows

Azure AD has the capability to enable end-users to perform a self-managed reset of the password, in case one does not remember it anymore.

Configuration is fairly easy, and can be done both through Intune and by adding a registry key. Detailed steps on how to do so can be found on https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-sspr-windows .

When configuring this on my home tenant, I received the following error:

All usual suspects were covered: the correct licenses were assigned, password writeback was configured and showed up in the portal as working, so no issues there. When opening the SSPR section in the Azure Portal, the following error was shown:

Digging into the Event Viewer on the Azure AD Connect Server revealed the error: The password could not be updated because the management agent credentials were denied access.

Following best practices from Microsoft, the account that was configured in the Azure AD Connect management agent did not have elevated permissions, and therefore did not have the possiblity to reset passwords.

Assigning delegated permissions to reset the password of the OU containing the synced users, solved the issue.

Selecting the right Subscription in PowerShell

When your organization has multiple Azure Subscriptions and you are entitled to work with them, selecting the correct subscription becomes an important thing to do.

Different approaches exist. I will have a look at the two most straight forward ones.

Using an argument to Connect-AzAccount

Connect-AzAccount holds specific attributes than can help you, namely SubscriptionName or SubscriptionId. If you know the Subscription name you want to connect to, issuing the following command directly connects to the correct subscription, after which you can start scripting:

Connect-AzAccount -SubscriptionName "Microsoft Partner Network"

To check to which subscription is linked, the command Get-AzContext can be issued.

Switching to another subscription in an active session

Switching to another Azure Subscription in an active session is also possible. This can be achieved by issuing the following command:

Set-AzContext -Subscription <subscription name> or <subscription id>

Useful PowerShell references

Connect-AzAccount https://docs.microsoft.com/en-us/powershell/module/Az.Accounts/Connect-AzAccount?view=azps-3.0.0
Get-AzContext https://docs.microsoft.com/en-us/powershell/module/Az.Accounts/Get-AzContext?view=azps-3.0.0

Understanding Azure Resource Management Hierachy

What is Azure Resource Management – or ARM?

ARM can be perceived as the unified management layer that is used to create, delete or otherwise manage components in Azure. Regardless of the tooling used to configure something (Azure Portal, Azure Powershell, Azure CLI, REST Clients,…) the actual change is handled by the Azure Resource Manager, handling all requests from different sources:

Resource Manager request model

Image source: https://docs.microsoft.com

What are the organizational scopes in Azure?

Nearly all components in Azure can be managed through the use of any one of the following organization constructs:

  • Resources
  • Resource Groups
  • Subscriptions
  • Management Groups

Resources are the workloads that you create and use in Azure. Virtual Machines, Virtual Networks, Network Security Groups, … are all examples of resources. Resources are the lowest scope that you can assign Role Assignments to. Resources inherit all Policies and Role Assignment that are created on a higher level.

Resource Groups are groups that entail one or more resources. All resources must belong to a resource group (and can only belong to a single resource group). You should only add resources to the same resource group if you manage (create, update, delete,…) them identically. permissions or policies that are assigned on this level automatically trickle down to all underlying resources.

A subscription, as per Microsoft, is “an agreement with Microsoft to use one or more Microsoft cloud platforms or services, for which charges accrue based on either a per-user license fee or on cloud-based resource consumption”.

A Management Group is the only entity described here that is able to work cross-subscriptions. As the Azure consumption in an organization grows, more and more subscriptions will be created. Management Groups can be used to centrally manage RBAC & Policies.

The following image describes the link between the aforementioned items with regards to RBAC and Policies:


Upcoming Azure webinars

Microsoft is strongly committed on sharing knowledge and information to partners and customers. One of the channels I highly appreciate is the frequent webinars they host to announce new features or to highlight specific features.

For the remainder of November 2019, the following webinars have been scheduled I certainly would recommend:

November 20thThree Things to Know About Starting Your Linux Workloads on Azureregister
November 20thApply Kubernetes Best Practices for Cluster Managementregister
November 21stMigrate to Azure and Windows Virtual Desktopregister
November 21st Manage Servers and Virtual Machines Anywhere with Windows Admin Centerregister
November 25thMicrosoft’s Marketplace Roadmap: November Updatesregister
November 26thSimplify the deployment, management and operations of Kubernetes with AKS on Azureregister

If you are not able to attend, you do not have to miss out. Most webinars are recorded and will be published for on-demand view afterwards. You can check out all recorded events here


Almost one year ago, the new Az Powershell module was released. The major change compared to the “older” AzureRM module is the fact that it is built on the .NET standard libraries, making it cross-platform compatible.
In addition, the nomenclature has been adjusted. AzureRM has been shorted to “Az”. No major updates or new features will be developed for the AzureRM module.

If you are late to the game, now is the time to start adjusting your scripts. December 2020 is announced as the date also bugs and security fixes won’t be published anymore, rendering the module not suitable for production anymore.

It is not recommended to run the AzureRM module and the Az module side-by-side. However, while you are re-authoring your scripts, luckily Microsoft offers you a “co-existence” method without requiring conflicting modules.. By issuing the commandlet Enable-AzureRMAlias , aliases will be created.

After using Enable-AzureRMAlias, the number of usable commands increases significantly:

If you want to enable the legacy commandlets for the localmachine, the “-Scope” parameter will help you out: https://docs.microsoft.com/en-us/powershell/module/az.accounts/enable-azurermalias?view=azps-3.0.0

Useful PowerShell references

Enable-AzureRMAlias https://docs.microsoft.com/en-us/powershell/module/az.accounts/enable-azurermalias?view=azps-3.0.0
Disable-AzureRMAlias https://docs.microsoft.com/en-us/powershell/module/az.accounts/disable-azurermalias?view=azps-3.0.0
Uninstall-AzureARM https://docs.microsoft.com/en-us/powershell/module/az.accounts/uninstall-azurerm?view=azps-3.0.0