Azure Image VM Build Failure: not authorized by network security perimeter

Question

Azure Image VM Build Failure: not authorized by network security perimeter

Sophia S 20 Microsoft Employee

Error Message:
Not authorized to access the resource: https://gi0lhakmj1mszi4rerthr8xf.blob.core.windows.net/vhds/7e609920-5d4c-4ab5-b732-02fd6987db27.vh… This request is not authorized by network security perimeter to perform this operation.
I have gone into that storage account's nsp and added outbound access to the storage profile to include this FQDN. Also, I have added service tags inbound access for AzureVMImageBuilder and AzureVMImageBuilderNonProd. I seem to still be hitting this issue though and eventually the build timeouts. Can you please help me with what steps I need to take to fix this? Thank you.

Venkatesan S 6,440 Reputation points Microsoft External Staff Moderator

2026-03-23T17:16:59.9+00:00
Hi Sophia Susanto,

Thanks for reaching out in Microsoft Q&A forum,

Not authorized to access the resource: https://gi0lhakmj1mszi4rerthr8xf.blob.core.windows.net/vhds/7e609920-5d4c-4ab5-b732-02fd6987db27.vh… This request is not authorized by network security perimeter to perform this operation.

The "Not authorized to access the resource" errors on the VHD blob (gi0lhakmj1mszi4rerthr8xf.blob.core.windows.net/vhds/...) are classic when your storage account has publicNetworkAccess: SecuredByPerimeter enabled. Your outbound FQDN rule and inbound service tags (AzureVMImageBuilder, AzureVMImageBuilderNonProd) were on point, but NSP's secure-by-default lockdown (Inbound: Denied, Outbound: Denied until associated) was silently blocking everything despite those rules. Here's the complete resolution path that addresses both network and identity layers.

Your storage needed perimeter association first, then rules activate. Plus Image Builder's managed identity (MSI) requires explicit RBAC on the storage accountNSP doesn't override that.

Verify Storage Lockdown Status
az storage account show --name <storage-account> --resource-group <storage-rg> --query "publicNetworkAccess"
If it shows "SecuredByPerimeter" and it confirms the deny-all state.

Associate Storage Account to NSP Perimeter
# Grab ARM IDs STORAGE_ID=$(az storage account show --name <storage-account> --rg <storage-rg> --query id -o tsv) PERIMETER_RG=<your-perimeter-rg> PERIMETER_NAME=<your-perimeter-name> PROFILE_NAME=default # Usually "default" PROFILE_ID=$(az network perimeter profile show \ --name $PROFILE_NAME \ --perimeter-name $PERIMETER_NAME \ --resource-group $PERIMETER_RG \ --query id -o tsv) # Associate in Learning mode (logs gaps, falls back to firewalls) az network perimeter association create \ --name storage-association \ --perimeter-name $PERIMETER_NAME \ --resource-group $PERIMETER_RG \ --access-mode Learning \ --private-link-resource "{\"id\":\"$STORAGE_ID\"}" \ --profile "{\"id\":\"$PROFILE_ID\"}"
Verify: az network perimeter association show --name storage-association --perimeter-name $PERIMETER_NAME --rg $PERIMETER_RG

Confirm/Update NSP Rules (Now Active Post-Association) Inbound Rules (Storage > Image Builder):

AzureVMImageBuilder

AzureVMImageBuilderNonProd

Storage (covers storage endpoints)

Outbound Rules (Image Builder > Storage):

gi0lhakmj1mszi4rerthr8xf.blob.core.windows.net (your exact FQDN)

*.blob.core.windows.net

AzureCloud

Portal: NSP > Access rules > Validate.

Grant Image Builder MSI Storage Permissions

# Get template MSI TEMPLATE_MSI=$(az image builder show \ --name <template-name> \ --resource-group <template-rg> \ --query "identity.userAssignedIdentities" | jq -r 'keys[0]') # Assign Storage Blob Data Reader (minimum for VHD reads) az role assignment create \ --assignee $TEMPLATE_MSI \ --role "Storage Blob Data Reader" \ --scope $STORAGE_ID

Test below:

az image builder cancel --name <template-name> --rg <template-rg> az image builder run --name <template-name> --rg <template-rg> # Monitor logs: Staging RG > storage > packerlogs > customization.log

Success: No network auth errors. Then lock down:

az network perimeter association update \ --name storage-association \ --perimeter-name $PERIMETER_NAME \ --resource-group $PERIMETER_RG \ --access-mode Enforced

Your storage needed perimeter association first, then rules activate. Plus, Image Builder's managed identity (MSI) requires explicit RBAC on the storage account NSP doesn't override that.

This sequence (association>rules > RBAC > test > enforced) resolves the exact NSP+Image Builder pattern hitting production environments. Your NSP table was the perfect diagnostic.

Official Documentation

Troubleshoot Azure VM Image Builder

VM Image Builder Permissions (CLI)

Storage Network Security Perimeter

NSP Transition Guide

az network perimeter association CLI

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Sophia S 20 Reputation points Microsoft Employee

2026-03-23T20:37:39.2933333+00:00

When I go to the storage account itself, I already see Public network access Enabled with the same Network security perimeter associated that I enabled the inbound and outbound rules on.
When I try to run your first command, I get resource group not found. Also, isn't this an Ephemeral RG too? Thank you.
Venkatesan S 6,440 Reputation points Microsoft External Staff Moderator

2026-03-23T22:26:07.71+00:00

Hi Sophia S,

Here I checked in my environment it executed successfully.

Could you please double check in your environment and let me know?
Venkatesan S 6,440 Reputation points Microsoft External Staff Moderator

2026-03-24T21:21:48.19+00:00

Hi Sophia S,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 11,915 Reputation points Microsoft External Staff Moderator

2026-03-30T08:42:53.71+00:00

Hello Sophia S

Thanks for the reply!

I’ve started a private message with you. Please share the required details in Private chat so I can assist with troubleshooting.

1 answer

Your answer

Sophia S 20 Reputation points Microsoft Employee

2026-03-23T20:37:39.2933333+00:00

When I go to the storage account itself, I already see Public network access Enabled with the same Network security perimeter associated that I enabled the inbound and outbound rules on.
When I try to run your first command, I get resource group not found. Also, isn't this an Ephemeral RG too? Thank you.
Venkatesan S 6,440 Reputation points Microsoft External Staff Moderator

2026-03-23T22:26:07.71+00:00

Hi Sophia S,

Here I checked in my environment it executed successfully.

Could you please double check in your environment and let me know?
Venkatesan S 6,440 Reputation points Microsoft External Staff Moderator

2026-03-24T21:21:48.19+00:00

Hi Sophia S,

We haven’t heard back from you regarding our last response and wanted to check if you had the opportunity to review our previous post.

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 11,915 Reputation points Microsoft External Staff Moderator

2026-03-30T08:42:53.71+00:00

Hello Sophia S

Thanks for the reply!

I’ve started a private message with you. Please share the required details in Private chat so I can assist with troubleshooting.

Answer 1

The error indicates that Azure VM Image Builder is blocked by network/security configuration when trying to access the source VHD in the storage account. In the available guidance, similar failures are caused by missing or incorrect permissions or access on the storage account or other required resources.

To fix this, validate and adjust the following areas that are called out for VM Image Builder:

Confirm VM Image Builder identity and role assignments
VM Image Builder uses a managed identity to access source images and storage.
- Get the identity on the image template:
```
     az image builder identity show -g <template resource group> -n <template name>
```
- List its role assignments:
```
     az role assignment list --assignee <identity_client_id_or_principal_id>
```
- Ensure this identity has appropriate roles (for example, read access) on:
  - The storage account/resource group that contains the VHD (vhds/...vhd).
  - Any Azure Compute Gallery or managed image resource groups used as source or distribution.
Ensure VM Image Builder has required permissions on all resources
VM Image Builder might need permissions to:
- The source image or Azure Compute Gallery resource group.
- The distribution image or Azure Compute Gallery resource.
- The storage account, container, or blob that the File customizer or source VHD is accessing.
Recheck that VM Image Builder has all required permissions as described in the permissions documentation for Azure CLI or PowerShell.
Check for network/security policies blocking access
The prerequisites highlight that:
- VM Image Builder must be able to connect to the storage account and create resources in the staging resource group.
- Azure Policy or other controls must not prevent creation/use of required resources (for example, storage accounts, container instances, virtual networks, private endpoints, Azure Files).
Review:
- Storage account firewall and network rules to ensure the VM Image Builder service and its staging resources can reach the storage account.
- Any Azure Policy assignments that might be blocking or modifying required resources.
Verify staging resource group configuration
VM Image Builder creates resources in a staging resource group. Conflicts or restrictions on this group can cause build failures.
- Ensure the staging resource group name is unique per template.
- Ensure no policies or NSG rules on the staging resources block outbound access to the storage account.
Inspect build failure details
For more precise diagnostics:
- Get the build failure status:
```
     az image builder show --name $imageTemplateName --resource-group $imageResourceGroup
```
- Use lastRunStatus and then review customization.log from the packerlogs container in the staging resource group storage account to see exactly where the access is denied.

If, after confirming network rules, the issue persists, focus on ensuring the VM Image Builder managed identity has the correct role assignments on the storage account and that no Azure Policy or NSG on the staging resources is blocking the outbound call to the VHD blob.

References:

Share via

Azure Image VM Build Failure: not authorized by network security perimeter

1 answer

Your answer