Microsoft Defender for Cloud offers advanced security features, combining functions such as adaptive application controls (application whitelisting), networking hardening (machine learning that learns the traffic passing through your network security group, which helps you create more restricted rules) and advanced antivirus and threat protection; however, a hidden gem of this suite is: Just in Time VM Access.

For a fee for Microsoft Defender for Cloud, you can use Just In Time or JIT to lock down inbound traffic to your Azure Virtual Machines when you only need it.

This reduces exposure to attacks while providing easy access when you need to connect to a VM.

Today, we will use the Azure Portal and configure Just-in-Time access for RDP for a Windows virtual machine running in Microsoft Azure that has a public IP.

This article assumes you have the authority and permissions (at least the Security Administrator role) to configure and pay for Defender for Cloud.

Configure Defender for Cloud​

1. Open the Azure Portal
2. Navigate to the Virtual Machine you would like to enable Defender for Cloud on and enable Just in Time Access for
3. Click on Configuration
4. Click on: Upgrade your Security Center subscription to enable just-in-time access.
5. 
6. Select the Subscription that holds your VM and select Upgrade
7. If you want to make use of the rest of the Cloud Defender offerings (and you should), then make sure you install the Log Analytics agent; however, you don't need it for Just In Time Access.
8. Navigate back to your Virtual Machine
9. Click on Configuration
10. Now you should see: Enable for Just-in-Time VM access; select this to enable Just in Time.

Now, if you go to the Network Security Group attached to the network interface of the VM, you should see a Deny Rule for 3389 that's been created with a priority lower than the allowed rules, forcing the block.

Configure Just In Time​

Now that we have enabled Defender for Cloud, it's time to configure what ports (can be used for more than just RDP and SSH access) and the length of time that access is allowed.

1. Click on Microsoft Defender for Cloud
2. Select Workload Protections
3. Select Just-In-Time VM access
4. 
5. Select the VM you have configured.
6. Click the ellipsis on the right-hand side
7. Select Edit
8. Azure has automatically added the port for RDP (3389) and sets a maximum 3 hour request time (that I am allowed to connect to the VM); I can also restrict Just In TIme access from specific IP addresses, and IP ranges to avoid anyone being able to RDP from their home IP.
9. 
10. Make any adjustments you feel suits your environment. I am going to leave the configuration as is.

Request Access for Just In Time Access to RDP​

You can programmatically_request JiT access to Azure VM through PowerShell and the REST API (see Additional Resources below for a PowerShell script to get you started), but we are going to use the Azure Portal.

1. Open the Azure Portal
2. Navigate to the Virtual Machine you would like to enable Defender for Cloud on and enable Just in Time Access for
3. Click Connect
4. You should see an information alert at the top of the blade "This VM has a just-in-time access policy. Select "Request access" before connecting."
5. 
6. Select Source IP (My IP)
7. Click Request access
8. You should now have access to RDP to the machine!
9. If you look at the Network Security Group, you should be able to see a new 'Allow' rule has been created with a priority lower than the block rule.
10. 
11. After 3 hours, the allowed rules will be removed automatically.

Hopefully, this helps keep your environment secure; if you implement this, make sure you read about the custom roles. To prevent the people from just adding in a rule for their public IP in the address manually, it may be better to create a custom role (see the script in Additional Resources below to create this role).

Additional Resources​

• Secure your management ports with just-in-time access
• Understanding just-in-time (JIT) VM access
• Just in Time Access Policy Script & Custom Role Script

Azure Application Security Groups (ASG) allow you to define what workloads (Virtual Machines) you are running in Azure has access to what resource - without being tied by managing complex IP address rules inside a Network Security Group.

Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses.

These Azure Application Security groups allow you to define your workloads, for example, Azure Virtual Desktop Session Hosts as a 'group' and what they may have access to in your Azure Virtual Network without opening up the service to everything inside of that VNET or creating overly complex rules that could make it hard to troubleshoot.

There are a few things to be mindful of:

• Azure Application Security Groups are Virtual Network-specific, so they can work to allow resources across subnets, but not in separate Virtual Networks, even if they have peered.
• As with most Azure resources, there are Subscription levellimits; you cannot have more than 3,000 Azure Application Security groups in a single subscription and region.
• The rules that specify an application security group as the source or destination are only applied to the network interfaces that are members of the application security group; this does not affect anything not in this group, even though your Network Security Group is based on the subnet.
• You can assign more than one Application Security group to a resource

In my example, I have a single virtual network, with 2 subnets (one subnet, has an Azure Virtual Desktop session host and the other one has a webserver running IIS), using Azure Application Security Groups, we will restrict IIS access to the webserver from the Azure Virtual Session hosts only - so IIS won't be accessible from any other machine in the Virtual Network.

Create Application Security Group​

Let's get started by creating an Application Security Group.

1. Open the Azure Portal
2. Click on + Create a resource
3. Search for: Application security group and select it
4. Click Create
5. Select the subscription that the Application Security group will be created in
6. Select the Resource Group (in my example, I am selecting AVD)
7. 
8. Click Review + create
9. Click Create

Assign Application Security Group​

Now that the Application Security group has been created it's time to assign it this our Azure Virtual Desktop session hosts.

1. Open the Azure Portal
2. Navigate to your Azure Virtual Desktop session host (or other workloads you are going to use)
3. Select Networking
4. Select Application security groups
5. Click Configure the application security groups
6. Select the Application Security group created earlier
7. 
8. Click Save

Assign Block Rule Security Group​

Now it's time to assign a block rule to our web server, for port 80 as by default it is allowed through the 'AllowVnetInBound' default rule.

1. Navigate to the Network Security Group that holds your web server (I am going to make the change on a Network Security group that is tied to the Network Interface of the web server, but the same principle applies if it was applied to a Network Security Group on the subnet - you just need to add the destination IP of the webserver)
2. Click on Inbound security rules
3. Click + Add
4. Add a Deny port rule for port 80 for all source
5. 
6. Click Save

After a few minutes, traffic from any workloads on the virtual network will now be blocked from accessing the web server on port 80.

Create Allow rule using Application Security Group​

Just a note around the priorities of Network Security Group rules:

Rules are processed in priority order (using a number between 100 and 4096), with lower numbers processed before higher numbers, because lower numbers have higher priority. Once traffic matches a rule, processing stops.

As a result, any rules that exist with lower priorities (higher numbers) that have the same attributes as rules with higher priorities are not processed.

1. Navigate to the Network Security Group that holds your web server (I am going to make the change on a Network Security group that is tied to the Network Interface of the web server, but the same principle applies if it was applied to a Network Security Group on the subnet - you just need to add the destination IP of the webserver)
2. Click on Inbound security rules
3. Click + Add
4. For Source, select the Application Security Group
5. Select HTTP as the service
6. Select Allow as the action
7. Set the Priority to be lower than the block rule, ie 4095
8. Click Save
9. 

After a few minutes, traffic from any workloads on the virtual network will now be allowed for any workloads from your Azure Virtual Desktop farm only (assigned to the Application Security group).

If I attempted to access the webserver from my application server, it fails:

Hopefully, this helps you avoid overly complex security rules that are reliant on knowing and managing the IP of your workloads and help secure your networks.

A very brief Blog article today, I have created an AWESOME-Azure-Architecture list, this list is hosted in Github and located here:

• AWESOME-Azure-Architecture

This list is a curated list of AWESOME blogs, videos, tutorials, code, tools & scripts, related to the design and implementation of solutions in Microsoft Azure.

This list contains anything that can help with your Microsoft Azure architecture and quickly get you up and running when designing, planning, and implementing services that empower organisations around the planet to achieve more.

You may be working remotely or only have a few devices needing access to your resources in Azure; a solution that can be deployed is a point to site connection straight into your Microsoft Azure network.

This functionality allows your computer to connect privately to resources over a secure tunnel using your internet connection, using an Azure Virtual Network gateway, you can seamlessly connect to resources without the need of opening up your resources to the internet or having to whitelist your (or third party vendor) IP address, which may change daily.

You know only your specified users access your Azure resources using Microsoft Entra ID.

You can have a site to site and point to site VPN running on the same Gateway today. We will set up a Point to Site VPN using Windows 11.

Depending on the SKU of your Virtual Network Gateway, depends on the number of concurrent connections and throughput you are allowed; because we are using Microsoft Entra ID and the OpenVPN protocol, I will be selecting Generation 1, VpnGw1, supporting a max of 250 connections (you can double the number of throughput and connections if you are running in Active/Active and have a second gateway, or select a higher SKU).

Azure AD authentication is supported for OpenVPN® protocol connections only and requires the Azure VPN client.

A note about Gateway SKUs (apart from Basic) you can resize in the same generation (i.e. Generation 1 VpnGw1 to VpnGw3, but you can't go from Generation 1 VpnGw1 to Generation 2 VpnGw5, in order to upgrade, you have to delete and recreate the Gateway, just keep this in mind when deciding on the SKU of your resources).

You can read more about the Virtual Network Gateways and VPN SKUs at the official Microsoft documentation here; your Gateway SKU may differ depending on your requirements.

Create Azure Point to Site VPN using Microsoft Entra ID authentication​

Prerequisites​

• An Azure subscription (that you have at least contributor rights to and the ability to create Users and Groups)
• An endpoint device running Windows 10 or 11 that you can install the Azure VPN client onto

Create Virtual Network​

First things first, let's create a Virtual Network.

1. Log in to the Azure Portal
2. Click on + Create a resource
3. Search for: Virtual Network and click on it
4. Click Create
5. Select or create your Resource Group that you want your network resource to sit in (I recommend Virtual Network and the gateway resources sit in its own Resource Group away from other resources so that they can be protected by resource locks, RBAC and they are usually classified as a shared resource).
6. 
7. Click Next: IP Addresses
8. Now we need to define the Address space and subnets; I will leave the Address space as 10.0.0.0/16 but remove the Default subnet (select the checkbox next to the Subnet and select Delete)
9. Click +Add Subnet, and add a new subnet with the name of GatewaySubnet with an IP range of: 10.0.1.0/27 (this Subnet will be used by our Virtual Network Gateway, and the name needs to be exactly GatewaySubnet).
10. Now I will add a subnet named: app servers, for the Virtual Machines I will need to connect to will be placed.
11. 
12. Click Next: Security
13. Leave everything (BastionHost, DDoS Protection Standard, Firewall) as Disabled.
14. Click Next: Tags
15. Enter in any tags and click Review + Create
16. Review your configuration and click Create

Create Virtual Network Gateway​

Now that we have the foundation of our setup - an Azure Virtual Network, it is time to provision the Gateway itself; just a note before we continue, the Gateway can take 30-60 minutes to provision.

1. Log in to the Azure Portal
2. Click on + Create a resource
3. Type in and search for: Virtual Network Gateway
4. Click Create
5. Type in the name of your Azure Virtual Network Gateway
6. Select the region (it must be the same region as your virtual network)
7. Select the Gateway Type: VPN
8. The VPN type is: Route-based
9. Select the SKU, in this example - I will be going with VpnGw1
10. Select the Generation of the Virtual Network Gateway; I am going with: Generation 1
11. Select the Virtual Network that you created earlier, and it will automatically find and assign the Gateway to the Subnet named: GatewaySubnet
12. Select Standard public IP address SKU
13. Select Public IP address and select: Create new
14. Type in your public IP name
15. Leave 'Enable active-active mode' and 'Configure BGP' as Disabled.
16. Click Review + Create
17. 
18. Verify configuration is correct and clicks Create
19. It can take up to 30-60 minutes for the Virtual Network Gateway to be created.

Setup Microsoft Entra ID authentication on the Virtual Network Gateway​

Now that the Virtual Network has been created, we can now set up Microsoft Entra ID authentication.

Collect Microsoft Entra ID Tenant ID​

First, we need to collect the Azure AD Tenancy ID

1. Log in to the Azure Portal
2. Click on Microsoft Entra ID
3. In the Overview pane, copy the Tenant ID and save this for the next step.

Grant Azure VPN Client permisisons​

Now we need to grant the Azure VPN application permissions.

1. Log in to the Azure Portal

2. Open a new window and type in and press Enter:

   https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent
   

3. If you get an error about external identity, then replace /common/ with your tenant ID.

4. 

5. Click Accept

6. Navigate back to Microsoft Entra ID

7. Select Enterprise Applications

8. Select Azure VPN

9. Copy the Application ID of the Azure VPN enterprise application (you will need both Application ID and tenant ID for the next steps)

10. 

Configure Point to Site Connection​

Now its time to configure the Virtual Network Gateway

1. Log in to the Azure Portal
2. Navigate to the Virtual Network Gateway you created earlier
3. Click on Point-to-site configuration
4. Click Configure now
5. Enter in your address pool (this is the address pool of the VPN clients, make sure this doesn't overlap with any other IP range you use, I will go with: 172.0.0.0/16)
6. Make sure the Tunnel type is: OpenVPN (SSL)
7. Select Microsoft Entra ID for the Authentication type
8. For Tenant, ID enter in: https://login.microsoftonline.com/**TENANTID**/ and enter in your own Tenant ID.
9. For the Audience (this is the users and groups that are assigned to the Enterprise Azure VPN application), put in the Application ID of the Azure VPN.
10. For the Issuer, enter in: https://sts.windows.net/**TENANTID**/
11. 
12. Click Save
13. It may take 1-5 minutes to save the configuration

Install and connect using the Azure VPN client​

Now that the Point to Site VPN has been configured it's time to connect!

1. Click on Download VPN client (if it is greyed out, then navigate to the Overview pane, then back to the Point-to-site configuration).
2. Extract the zip file, you will need these files
3. Download the Azure VPN Client to your computer.
4. 
5. Once, downloaded click Open.
6. Click the + sign (lower left)
7. Click Import
8. Navigate to the: azurevpnconfig.xml file that you downloaded earlier and click Open
9. You can change the Connection Name to something more user friendly (you can also edit the file directly for when you look at pushing out this to multiple users, but make sure you have a backup of the file)
10. Click Save
11. 
12. Click Connect
13. Enter in your Microsoft Entra ID credentials (you may be prompted for MFA, depending on the rules - you can use Azure VPN application under conditional access)
14. 
15. You should now be connected to the Azure network through a point to site VPN!
16. If I run 'ipconfig /all' on my device, I can see a PPP adapter that is connected and on the VPN address range created earlier: 172.0.0.2
17. 
18. If I navigate back to the Point-to-site connection in the Azure Portal, I can see, my connection has been allocated:
19. 
20. I can now use Remote Desktop to connect to a Virtual Machine, running in my AppServers Subnet, which I am running without the need of a Public IP or bastion/jump host:
21. 

Note: I don't have a DNS service running in Azure, but the Azure VPN agent will take DNS from the Virtual Network if you have this configured to point towards a DNS server (Active Directory, or other DNS forwarder (pointing towards Azure DNS IP: 168.63.129.16) such as Azure Firewall DNS proxy; you can set Custom DNS servers by modifying your DNS configuration, or add entries into the host file of the computers.

You can set your Custom DNS settings (remember to add the DNS suffix if needed) and configure the VPN to automatically connect by following the details on the OpenVPN Azure AD Client page.

Using Intune, you can also push this configuration to your Windows 10 and 11 clients

• Create custom Intune profiles to deploy VPN client profiles

Pretty simple article today regarding 'My website setup'.

I've had a few people ask what CMS (Content Management System) my website runs on - and no it's not running on an Azure App Service!

I am using:

• Github Pages (running Jekyll and Ruby on Rails)
• Cloudflare as my DNS CDN (which also allows me to set HTTPS) and cache the website across the planet

Because the pages are in a git repository, I have version control across my pages, can roll back or make any changes easily and allow others to submit pull requests for changes, or issues natively.

The pages are created using Markdown, I usually have a OneNote page with an idea or blurb, then Forestry to do the initial post, and then manually edit the files and verify the syntax is correct, add tables into the page and fix any issues that may have been caused (Forestry doesn't support markdown tables and can make some content look a bit weird and unstructured, but its usually an easy fix editing the markdown manually).

Having it on Github pages, helped me learn a lot more about using git and source control, versioning methodologies.

Then for comments, I use Disqus and for analytics, Google Analytics and Bing Webmaster Tools.

• Markdown
• https://pages.github.com/
• What CMS is this site using?
• https://forestry.io/
• https://disqus.com/

All in all - I just have to pay for the domain, everything else is free and because it's stateless, caching content is a lot easier and I don't have to worry about keeping a CMS up to date/patched or a database tuned!

If you're wondering why it's not running on an Azure App Service? I wanted something cheap, could further challenge and learn from, at the end of the day I wanted a stateless website (static websites in Storage account, wasn't available when I set this up) and I wanted to reserve my limited Azure credits to be able to actually learn and play more. I have no regrets in putting it in Github Pages and depending on your requirements - recommend you try it out!