Just-in-time VM access policy blocks ERP patch automation during maintenance windows

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

We’re running into a blocking issue with our ERP patching process. Our Azure Security Center JIT VM access policy is interfering with our automated patch deployment schedule that runs during maintenance windows.

The automation script worked fine before we enabled JIT access. Now our patch automation fails because the VMs are locked down:

Connect-AzAccount -Identity
$vms = Get-AzVM -ResourceGroupName "ERP-Production"
Invoke-AzVMRunCommand -VMName $vm.Name -CommandId 'RunPowerShellScript'
# Error: JIT access not approved for source IP

The JIT policy requires manual approval for each VM access request, but our patching needs to run unattended at 2 AM on Sundays. We need the security benefits of JIT but also need our patch automation to work reliably. The patching window is tight and we can’t have manual intervention during off-hours.

Has anyone configured JIT policies to allow specific automation scenarios while maintaining security posture?

2

I’d recommend a time-based NSG rule approach rather than weakening JIT. Create an NSG rule with a lower priority than JIT that allows WinRM (5985/5986) from the AzureCloud service tag, but only activate it via automation during your maintenance window. Your runbook can enable the rule at 1:55 AM, run patches, then disable it at 4:00 AM. This maintains zero-standing-access principle while enabling automation.

Alternatively, use Azure Update Management which integrates natively with Security Center and doesn’t trigger JIT blocks because it uses the Azure management plane rather than direct VM access.

3

Here’s the complete solution that addresses all three aspects - JIT configuration, security group exceptions, and patch automation requirements:

Approach 1: Time-Based NSG Exception (Recommended)

Create an NSG rule that temporarily allows automation access:

# Enable automation window
$nsg = Get-AzNetworkSecurityGroup -Name "ERP-NSG"

Add-AzNetworkSecurityRuleConfig -Name "Patch-Window" 
  -Priority 200 -Access Allow -Protocol Tcp 
  -Direction Inbound -SourceAddressPrefix AzureCloud 
  -SourcePortRange * -DestinationPortRange 5985,5986

The key is priority: JIT rules are typically 100-199, so setting your rule to 200+ ensures JIT takes precedence for interactive access while your automation rule provides the exception. In your runbook, enable this rule at the start of your maintenance window and remove it afterward.

Approach 2: Azure Update Management Integration

Migrate to Azure Update Management which bypasses JIT entirely because it uses Azure Resource Manager APIs rather than direct VM connectivity. Configure it via Azure Automation:

  1. Enable Update Management solution in your workspace
  2. Link your VMs to the solution
  3. Create deployment schedules for Sunday 2 AM maintenance
  4. Update Management uses the Azure control plane, so JIT policies don’t apply

This is the cleanest solution because Update Management is designed for this scenario and includes compliance reporting, pre/post scripts, and maintenance window management built-in.

Approach 3: Dedicated Hybrid Worker

Deploy an Azure Automation Hybrid Worker on a locked-down management VM:

  1. Create a dedicated management VM in a secure subnet
  2. Add this VM to JIT permanent exceptions (single exception point)
  3. Install Hybrid Worker agent on this VM
  4. Configure your runbooks to execute on this worker group
  5. The worker VM has a static IP that can be whitelisted in JIT policies

Security Considerations for All Approaches:

  • Enable NSG flow logs to monitor all automation access attempts
  • Use Azure Policy to ensure consistent JIT configuration across all ERP VMs
  • Configure alerts for any JIT policy modifications
  • Document the exception in your security baseline
  • Review automation logs weekly to detect any anomalies
  • Ensure your managed identity has only the minimum required permissions

My Recommendation:

Go with Azure Update Management (Approach 2) because it’s purpose-built for this scenario, maintains your security posture without exceptions, and provides better patch compliance visibility. If you need custom pre/post patch scripts, Update Management supports those as well. The JIT policy remains fully intact with no exceptions needed, and you get enterprise patch management capabilities as a bonus.

If Update Management doesn’t meet your needs due to custom scripting requirements, use the time-based NSG approach but automate both the enabling and disabling in the same runbook to minimize the exposure window. Never leave the exception rule active permanently.

4

For Azure Automation scenarios, you’ll want to leverage service tags in your JIT policy configuration. The AzureCloud service tag covers Azure Automation IPs, but that’s quite broad. A better approach is to create a separate NSG rule that allows your managed identity to bypass JIT for specific ports during your maintenance window. You can use Azure Policy to enforce this pattern across all ERP VMs while keeping JIT active for interactive access.

5

I’ve dealt with this exact scenario. The issue is that JIT doesn’t recognize your automation service principal by default. You need to configure security group exceptions for your patch automation source.

First question: Are you using Azure Automation or running scripts from a specific management VM? The approach differs slightly based on your automation architecture.

6

The time-based NSG approach sounds promising. Can you clarify how to configure the rule priority to work alongside JIT? I want to make sure I’m not accidentally creating a security gap.

7

We’re using Azure Automation with a system-assigned managed identity. The runbook executes from Azure’s automation service, so there’s no fixed source IP that I can whitelist in the JIT policy. That’s part of what makes this tricky.

8

Quick addition to Tom’s suggestion - make sure you’re logging all automation access even with the exception rule. Enable NSG flow logs and send them to Log Analytics so you have audit trail of when the automation window was active. Also consider using Azure Automation’s hybrid worker on a dedicated management VM if you need more control over source IPs. That VM can be added to JIT exceptions permanently since it’s a known, secured management endpoint.