ASR VMWare - Cache Storage Authentication

Question

ASR VMWare - Cache Storage Authentication

Anandha Chandrasekaran 20

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:

Does the ASR appliance authenticate directly to the cache storage account using Microsoft Entra ID / Managed Identity with RBAC?
Or does ASR still use Storage Account Keys / SAS tokens internally for replication uploads?
If SAS/shared-key authentication is still used, is it mandatory to keep “Allow storage account key access” enabled on the cache storage account?
Is disabling shared-key authorization on the cache storage account currently unsupported for VMware-to-Azure ASR replication with Private Endpoints?
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?

Suchitra Suregaunkar 13,990 Reputation points Microsoft External Staff Moderator

2026-05-14T11:32:17.7766667+00:00
Hello @Anandha Chandrasekaran

Thank you for posting your query on Microsoft Q&A platform.

Please have a look into below information shared to your queries asked:

Does the ASR appliance authenticate directly using Managed Identity?

Not directly. Since the ASR replication appliance runs on-premises, it doesn't have its own Azure managed identity. Instead, the Recovery Services Vault's managed identity acts as the intermediary. When you enable managed identity on the vault and assign the required RBAC roles on the cache storage account, the vault authenticates to the cache storage on behalf of the Process Server using Microsoft Entra ID.

Does ASR still use Storage Account Keys / SAS tokens?

Previously, yes- key-based access was required for cache storage accounts. However, Microsoft has updated this behavior.

So, ASR now supports managed identity-based (Entra ID) authentication for cache storage, and you are no longer forced to rely on storage keys or SAS tokens.

Is it mandatory to keep "Allow storage account key access" enabled?

No, it is no longer mandatory provided you complete the prerequisites before disabling key-based access:

Enable Managed Identity on the Recovery Services Vault.

Grant the vault's managed identity the required RBAC roles on the cache storage account:

For Standard storage: Contributor + Storage Blob Data Contributor

For Premium storage: Contributor + Storage Blob Data Owner

Under the storage account's Firewalls and virtual networks settings, enable "Allow trusted Microsoft services to access this storage account".

Once these are in place, you can safely set AllowSharedKeyAccess = false on the cache storage account.

Is disabling shared-key authorization unsupported?

No, it is supported now. Microsoft actually recommends disabling key-based authentication for improved security.

Important note: Do not disable and re-enable protection for existing VMs/servers after completing the prerequisites , just disable the key-based access on the storage account, and replication will continue seamlessly.

References:

Turn off key-based access on cache accounts

Replicate on-premises machines by using private endpoints

VMware to Azure disaster recovery architecture – Modernized

Hope this helps clarify the authentication flow for your Private Link-enabled ASR deployment. If you have further questions, feel free to ask.

Thanks,

Suchitra.

1 answer

Your answer

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:

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

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

Share via

ASR VMWare - Cache Storage Authentication

1 answer

Your answer