ASR VMWare - Cache Storage Authentication

Question

We are implementing Azure Site Recovery (ASR) for protecting on-premises VMware virtual machines to Azure using the modernized architecture.

Our setup includes:

• On-premises ASR replication appliance / Process Server
• Mobility Service running inside on-prem VMware VMs
• Recovery Services Vault configured with Private Endpoints
• Cache Storage Account configured with Private Endpoint
• Connectivity between on-prem and Azure through Site-to-Site VPN (all replication traffic routed privately)

We understand that for Private Link-enabled ASR deployments, Microsoft recommends enabling a managed identity on the Recovery Services Vault and assigning RBAC permissions on the cache storage account.

However, we need clarification specifically about the authentication mechanism used by the on-premises ASR appliance/process server when uploading replication data to the cache storage account.

Our questions are:

1. Does the ASR appliance authenticate directly to the cache storage account using Microsoft Entra ID / Managed Identity with RBAC?
2. Or does ASR still use Storage Account Keys / SAS tokens internally for replication uploads?
3. If SAS/shared-key authentication is still used, is it mandatory to keep “Allow storage account key access” enabled on the cache storage account?
4. Is disabling shared-key authorization on the cache storage account currently unsupported for VMware-to-Azure ASR replication with Private Endpoints?
5. Is there any official Microsoft documentation that clearly explains the authentication flow between:

• Mobility Service
• ASR appliance / Process Server
  • Cache Storage Account in a Private Link-enabled hybrid ASR deployment?We are implementing Azure Site Recovery (ASR) for protecting on-premises VMware virtual machines to Azure using the modernized architecture. Our setup includes:
    • On-premises ASR replication appliance / Process Server
    • Mobility Service running inside on-prem VMware VMs
    • Recovery Services Vault configured with Private Endpoints
    • Cache Storage Account configured with Private Endpoint
    • Connectivity between on-prem and Azure through Site-to-Site VPN (all replication traffic routed privately)
    We understand that for Private Link-enabled ASR deployments, Microsoft recommends enabling a managed identity on the Recovery Services Vault and assigning RBAC permissions on the cache storage account. However, we need clarification specifically about the authentication mechanism used by the on-premises ASR appliance/process server when uploading replication data to the cache storage account. Our questions are:
    1. Does the ASR appliance authenticate directly to the cache storage account using Microsoft Entra ID / Managed Identity with RBAC?
    2. Or does ASR still use Storage Account Keys / SAS tokens internally for replication uploads?
    3. If SAS/shared-key authentication is still used, is it mandatory to keep “Allow storage account key access” enabled on the cache storage account?
    4. Is disabling shared-key authorization on the cache storage account currently unsupported for VMware-to-Azure ASR replication with Private Endpoints?
    5. Is there any official Microsoft documentation that clearly explains the authentication flow between:
       • Mobility Service
       • ASR appliance / Process Server
       • Cache Storage Account
         in a Private Link-enabled hybrid ASR deployment?

Answer 1

The available documentation in the provided context does not describe the detailed authentication flow (Entra ID vs. SAS/shared key) between the VMware Mobility Service, the on-premises replication appliance/process server, and the cache storage account, nor does it state whether disabling shared-key authorization on the cache storage account is supported for VMware-to-Azure ASR with Private Endpoints.

The context does state the following relevant points:

1. For Private Link–enabled ASR deployments, the Recovery Services vault must have a managed identity so that Site Recovery can access source, target, and cache/log storage accounts when using Private Link:
   • The vault’s managed identity is required “when you're using the Private Link service for the vault.”
   • The managed identity is used for the vault to access storage accounts (source, target, cache/log) via RBAC.
2. Cache storage account requirements and constraints:
   • Cache storage accounts must be in the same region as the VM being protected and in the same subscription as the source VMs.
   • General-purpose v2 (GPv2) and Premium storage are supported for cache.
   • Azure Storage firewalls with virtual networks are supported, but if a user-assigned managed identity (UAMI) is used on the vault, virtual network access to storage accounts used for Site Recovery must not be restricted; access from all networks must be allowed.
   • Managed identity is supported for cache storage accounts, with guidance to “Turn off key based access on cache account” referenced, but the detailed steps and exact impact on VMware scenarios are not included in the provided context.
3. Private endpoints for cache storage are optional but supported:
   • For both Azure-to-Azure and hybrid scenarios, a private endpoint can be created for the cache/log storage account.
   • Private endpoints for storage can only be created on GPv2 accounts.
   • If private endpoints are not enabled, replication still works but traffic goes over public endpoints.
4. For the modernized replication appliance, the support matrix and prerequisites emphasize:
   • Use of private links for *.blob.core.windows.net and *.siterecovery.windowsazure.com is supported and documented.
   • The appliance uses Azure Storage (*.blob.core.windows.net) to upload data that becomes target disks, and private endpoints can be configured for this.

Within this context, the following can be stated and nothing further:

1. The Recovery Services vault uses a managed identity to access storage accounts (including cache/log) when Private Link is used for the vault. This is done via RBAC on the storage accounts.
2. The context does not specify whether the on-premises replication appliance/process server itself authenticates directly to the cache storage account using Entra ID/managed identity, or whether it uses storage account keys/SAS internally.
3. The context references guidance to “Turn off key based access on cache account” under the “Managed identity” row for cache storage, but the detailed behavior and any VMware-specific limitations are not provided here. Therefore, the context does not explicitly state whether “Allow storage account key access” must remain enabled or whether disabling shared-key authorization is unsupported for VMware-to-Azure ASR with Private Endpoints.
4. The context does not contain a document that explicitly walks through the end-to-end authentication flow between Mobility Service → replication appliance/process server → cache storage account for a Private Link–enabled hybrid VMware deployment.

Based only on the provided material, the precise answers to:

• whether the appliance uses Entra ID vs. SAS/shared key,
• whether key-based access must remain enabled, and
• whether disabling shared-key authorization is unsupported for VMware-to-Azure ASR with Private Endpoints,

are not documented.

---

References:

• Replicate on-premises machines by using private endpoints
• Replicate machines with private endpoints
• Support matrix for Azure VM disaster recovery between Azure regions
• Deploy Azure Site Recovery replication appliance - Modernized
• Azure ExpressRoute with Azure Site Recovery
• Support matrix for deploying the replication appliance with Azure Site Recovery - modernized