Skip to main content

Just in Time access to Azure Virtual Machines

· 4 min read

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. Azure Portal - Configuration
  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.

Azure Portal

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. Azure Portal - Defender for Cloud
  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. Azure Portal - Defender for Cloud
  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. Azure Portal - Just In Time
  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. Azure Portal - Just In Time
  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

Application Security Groups in Microsoft Azure

· 5 min read

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.

High Level  - Diagram ASG

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. Create an Application Security Group
  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. Assign Application Security Group
  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. Assign Block Network Security Group Rule
  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.

Port 80 blocked

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. Create Network Security Rule Allow

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).

AVD - Test Port 80 Allow

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

AVD - Test Port 80 Deny

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.

AWESOME-Azure-Architecture List

· One min read

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

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.

Create Azure Point to Site VPN using Microsoft Entra ID authentication

· 9 min read

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.

Azure Point to Site

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. Azure Virtual Network
  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. Azure Virtual Network
  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. Azure Virtual Network Gateway
  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. Azure VPN Permissions

  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. Azure VPN

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. Azure Virtual Network Gateway
  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. Azure VPN Client
  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. Azure VPN Connection
  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. Azure VPN Connection
  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. Azure Point to Site Connections
  18. If I navigate back to the Point-to-site connection in the Azure Portal, I can see, my connection has been allocated:
  19. Azure Point to Site Connections
  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. Azure Point to Site VPN

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

My Website Setup

· 2 min read

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.

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!