TagBest Practices

Azure Resource Locks – The What & Why

Today I want to give you all an overview of Azure Resource Locks. Firstly about what they are and can do, then secondly how you can use them and some best practices around them. And finally a few things to watch out for so you don’t get caught out when using them; believe me it’s easily done!

What are Azure Resource Locks?

Resource Locking within Azure provides a method to lock subscriptions, resource groups or individual resources to protect them from accidental deletion and changes; even for administrators (depending on their RBAC role).

Resource Locks come in 2 levels; CanNotDelete (displayed as ‘Delete’ in the portal) or ReadOnly (displayed as ‘Read-only’ in the portal).

As the names suggest, CanNotDelete means the resources with the lock applied can be read and modified, but they cannot be deleted. The ReadOnly lock means that the resources with the lock applied can only be read but not modified or deleted.

Both types of lock can actually cause some resources to stop functioning as you’d expect so be aware. More on this later!

Resource locks can also only be created by users assigned the ‘Owner’ or ‘User Access Administrator’ RBAC roles. More specifically any users with roles that grant the following RBAC permissions: ‘Microsoft.Authorization/*’ or ‘Microsoft.Authorization/locks/*’. So you don’t need to worry about anyone with write permissions on Resource Groups or VMs etc… creating locks on everything and potentially breaking other services without knowing about it etc…

How should I use Azure Resource Locks?

Now you may think that once deployed putting ReadOnly locks on everything is probably the best thing to go and do. And in some select scenarios I may even agree with you, however this is not best practice; so only do this if you absolutely have too!

Resource Locks can be applied at the following Azure governance scoping levels:

  • Subscription
  • Resource Group
  • Resource

In my opinion, applying locks at the Subscription level is way to high in the governance hierarchy structure and makes using Azure clunky; as everything you deploy within that subscription will inherit the lock from the subscription level.

Taking it to the other end of the governance hierarchy at placing locks at the Resource level can again be very tedious and difficult to manage and keep on top of. However in some cases it can actually be very useful.

Think of a scenario where you have applied a CanNotDelete lock at the resource group level but on the VPN gateway you have deployed within the resource group you want to restrict anyone from changing anything about its configuration. Applying a ReadOnly lock on the VPN gateway resource as well will mean that the rest of the resource group’s resources can be modified as they need to be but the VPN gateway is completely locked and cannot be modified at all without the lock being removed first. Removing the lock itself requires specific permissions, as explained in the above section, so this become a very handy way of locking things down further.

It should also be stated that if 2 locks, 1 in CanNotDelete mode & 1 in ReadOnly mode, the most restrictive lock (ReadOnly) takes precedence.

So the only scope we haven’t mentioned yet is the Resource Group level. This is where I suggest the majority of your locks are applied. However this does rely on you having split resources in some fashion between multiple resource groups. Whether that’s by application, business unit or service; as long as they are split and not all in a single resource group this approach will work nicely!

Applying locks at the Resource Group level is also the advised best practice from Microsoft under the Enterprise Scaffold framework (no part of the Cloud Adoption Framework). And as explained in the above scenario its give you the best flexibility for control without the locks becoming a restricting factor in using Azure on a daily basis.

When governance controls become a blocker for using and consuming Azure you’ll find people will try as many ways as possible to avoid following the controls you have put in place. So my advice is to use them as guard rails and not super secure enforcement rules to stop this from happening.

How do I create and apply Azure Resource Locks?

This is actually quite easy and I find doing it via the Azure Portal is the best way as you can check what resources will be impacted very easily & quickly due to the visual nature of the portal. However locks can be applied via PowerShell, AZ CLI, ARM Templates & Terraform etc…

In the below example I will place a ReadOnly lock on my test resource group which contains a single storage account.

  1. Log into the portal and select the Resource Group you wish to apply a lock to
  2. Select the ‘Locks’ blade from the navigation bar on the right
  3. Click ‘Add’
  4. Fill out the details as required and select the ‘Lock Type’ then click ‘OK’
  5. The lock will now be applied – Note the ‘Scope’ is shown in the lock overview blade as well as ‘Notes’. Make sure you use notes as it helps the next person when they come across your locks.
  6. That is it. You can follow the same instructions and a Subscription or Resource level and the steps are the same.

If we now lock at the Storage Account in this resource group we will see it has inherited the lock.

If I now try to amend the storage account you will see that even though I’m an owner on the Subscription the lock still applies to me and I must manually remove it in order to amend the storage account or delete it.

Things to watch out for with Azure Resource Locks

As mentioned at the beginning of this blog post, using resource locks can actually break some functionality with resources.

The ones I know of to date are as follows:

  1.  Listing Storage Account Access Keys This happens whether using the Portal, PowerShell, AZ CLI etc… as they all utilise the Azure Resource Manager (ARM).
  2. Azure Backup of VM’s Managed Disks(Thanks to Adin Ernie for the screenshot of this as I didn’t have one to hand at time of writing.)
    This occurs because the ‘RestorePointCollection’ object is treated as a separate Resource object by ARM. So you cannot place any locks on Resource Groups that contain these objects. The resource group name will look like this: AzureBackupRG_ukwest_1 However the region name will change depending on where you are deploying resources and backing up etc….

Summary

Hopefully this article has given you an in depth overview of Azure Resource Locks and how they can be and should be used.

Further reading can be found on the Microsoft Docs pages as always.

Like, Share, Follow!
error

Azure Geos, Regions, Pairs, Availability Zones & Availability Sets Relationship

A common topic I find myself explaining to customers and colleagues who haven’t worked with Azure, or any public cloud platform for that matter, is the relationship between the following Azure components:

  • Geographies
  • Regions
  • Region Pairs
  • Availability Zones
  • Availability Sets

This is quite hard to visualize when trying to explain verbally and I have drawn the same diagram on whiteboards a thousand times and it seems to make that “light bulb moment” occur to who I’m presenting too .

So I finally decided to create them in Lucidchart and share them with you all!

(On a side not if you aren’t using Lucidchart already, seriously give it a go, it’s made my diagramming a lot fast and less stressful when trying to draw connection lines in Visio)

The Diagrams

The  above diagram depicts that Availability Sets live withing Availability Zone and they live within Regions and they finally reside within a Geography.

The  above diagram depicts the same as the previous diagram but shows the concept of Region Pairs.

Some Important Info…

Availability Zones

At the time of writing this, Availability Zones aren’t available in all Regions; however they have just been announced in UK South!

Check if the latest supported Regions here.

Also not all resources support Availability Zones, again check the latest supported list here.

Region Pairs

You cannot chose which region is paired with the region you chose to use, this is decided by Microsoft at the time when they build a new Region. As this is to support Geo Replicated Services (GRS) etc…

Brazil South doesn’t have another Region within the same Geography, so it is paired with South Central US. But South Central US isn’t paired back with Brazil South.

Again the latest information on Regions and where they are paired to can be found here.

Summary

Hopefully this will help you all and feel free to use the diagrams on the page (they have a transparent background, you’re welcome).

Until next time!

Like, Share, Follow!
error

AD DS DC’s In Azure

This week I received a couple of queries from clients around Active Directory in Azure and more specifically how they should handle/manage their Domain Controller IaaS VMs in Azure.

Now I have seen hundreds of IaaS VMs in Azure as Domain Controllers, it’s something that goes into the majority of my designs for clients today; it’s like a natural reaction/muscle memory for me.

However, these questions from my client made me take a step back and take a deep dive into Active Directory again, something I haven’t done in a few years, and review the recommendations and best practices for running DCs in Azure.

The Questions…

There were only 2 questions that got me thinking about this topic, they were:

  1. Should we place the Active Directory installation (database, logs & SYSVOL) on a separate data disk with caching disabled?
  2. Can we shut down the DC IaaS VM from the portal using the stop button as we do for other IaaS VMs?

The Answers…

So some of you may be thinking that these questions are pretty simple to answer and to some extent you are correct. However taking the time to check and investigate the answers to these questions and application specific best practices from time to time is never a bad idea.

Below I’ll answer each question and break it down as to what you should/shouldn’t do.

Question 1 – Separate Data disk For AD Data WITH No Caching

Now this topic isn’t actually specifically related to Azure only, it actually applies to any virtualisation platform (vSphere, Hyper-V, Xen Server, AWS EC2, etc…).

In short the answer is yes, store the AD data on a separate data disk and disable read and write caching.

The why is actually more to do with the caching element of the question. The theory being that if write caching is enabled at the hypervisor level for the data disk (or any disk where AD data is stored for that matter) there is a chance that if the VM is powered off abruptly for any reason, some changes are still waiting to be written/committed to the disk and therefore this can lead to issues like USN rollbacks.

So I would add an additional data disk to your Azure IaaS DC VMs when building them to place the AD install upon.

Create Managed Disk

Attach Disk To VM & Disable Caching

If you have already deployed your DCs and promoted them etc… I would suggest building new ones in Azure with the additional data disk and just following the process to promote/demote DCs. You can migrate the database etc… manually but, why I add the risk when it’s so easy to just build new and promote/demote.

Question 2 – SHutting down DC IaaS VM Via Portal stop button

So this one is a little more interesting and again isn’t exclusively related to Azure and applies to any virtualised DC depending on the hypervisor platform it runs upon.

However keeping this strictly Azure focused, Microsoft advise explicitly on the docs website that you should NOT shut down IaaS DCs via the portal. You can check that Microsoft page here.

Shutting down the VM via the portal causes a chain of events to occur when that VM is eventually powered back on.

The first thing that happens is the VM-Generation ID is reset/changed. The VM-Generation ID is stored as an attribute of the DCs computer object within the AD database called msDS-GenerationID upon promotion.

When a DC is started up and AD is starting up, it checks the VM-Generation ID against the msDS-GenerationID that it has stored in it’s database against the DCs computer object. If that value is not the same, the DC resets the Invocation ID and discards its RID pool; adding to the chain reaction!

Thankfully since Windows Server 2012 the VM-Generation ID is supported and stored as an attribute as explained above. So now AD knows exactly what to do when the VM-Generation ID changes to prevent a USN rollback and/or give out duplicate SIDs etc… Clearly none of us want these things to happen, so lets all take a moment and thank Microsoft for this feature since Windows Server 2012.

Anyway, now that AD has detected the VM-Generation ID and reset the Invocation ID it will clear the DCs RID pool and update the msDS-GenerationID on the DCs computer object with the new  VM-Generation ID. It will also perform a non-authoritative restore on the affected DC to replicate the SYSVOL and other information from another DC within the domain.

This all happens automatically to ensure that the integrity of the domain stays in tact and no duplicate SIDs are given out and also to keep the replication topology in tact.

Regardless that this all happens automatically, it’s still not a healthy thing to be happening to a DC and it is certainly something that can be avoided

So to avoid it all that you need to do is shut down the DC IaaS VM via the guest OS instead of clicking stop in the Azure portal. That’s honestly it. However you can sleep easily knowing that if your DC is at least Windows Server 2012 it will protect you if the VM gets shut down abruptly!

One thing to be aware of when shutting any VM down via the guest OS instead of stopping it via the Azure portal is that the VM will not enter the deallocated state once its shut down. It will just show a status of stopped. This will mean that you will still be charged for the VM compute costs etc… as if the VM was still powered on.

Although this does mean that the VM-Generation ID will not change when you start the VM back on!

Another point to consider is that your VM is unlikely to be turned off abruptly and even so you should be deploying at least 2 DCs in an Availability Set using managed disk to give your AD services the best SLA possible from Azure.

Summary

Again there is a lot of information to take in here. But I feel it’s a vital topic to cover as nearly every deployment will have a IaaS DC in it somewhere. Also to be prepared for the questions above from a client, your boss or an AD specialist is always best, rather than having to research the answer when asked.

Any questions on this topic please leave a comment or drop me a tweet and I’ll happily get back to you.

Like, Share, Follow!
error

© 2019 Jack Tracey

Theme by Anders NorénUp ↑