Share via

Azure Blob Storage integration with Adobe Experience Manager throws 403

Arindam Chakravorty 20 Reputation points
2025-11-19T16:54:37.9133333+00:00

I am integrating azure blob storage with Adobe Experience Manager and for that I have created my blob storage and a container put in relevant permissions. Also I'm restricting the access to only IP = 49.25.37.71. In Firewalls and virtual networks I've set the Allow access from to Selected networks and put in the IP in the list. Also in the container, I've put in the IP to be allowed which subsequently created a URL like : https://linktestblobstorage.blob.core.windows.net/testlinkcontainer?sp=racwdl&st=2025-11-19T05:23:57Z&se=2025-11-30T13:38:57Z&sip=49.25.37.71&spr=[redacted]

Now this keeps on throwing 403 with Service Message: If you are using a StorageSharedKeyCredential, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate method call._If you are using a SAS token, and the server returned an error message that says 'Signature did not match', you can compare the string to sign with the one generated by the SDK. To log the string to sign, pass in the context key value pair 'Azure-Storage-Log-String-To-Sign': true to the appropriate generateSas method call._Please remember to disable 'Azure-Storage-Log-String-To-Sign' before going to production as this string can potentially contain PII._Status code 403, "<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthorizationFailure</Code><Message>This request is not authorized to perform this operation._RequestId:06c1c2df-e01e-0045-42ad-587603000000_Time:2025-11-18T17:04:26.2169791Z</Message></Error>"

But on the contrary if I allow Public access and have the URL formed without the sip=49.25.37.71, it works perfectly. So what exactly am I doing wrong in the Azure config?

Azure Storage
Azure Storage
Globally unique resources that provide access to data management services and serve as the parent namespace for the services.
Answer accepted by question author
  1. Jeevan Shanigarapu 3,280 Reputation points Microsoft External Staff Moderator
    2025-11-19T19:58:35.0066667+00:00

    Hello @Arindam Chakravorty,

    Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

    When you use an IP address restriction (the sip parameter) in an Azure Blob Storage SAS token, Azure expects requests to come from exactly that IP. However, some operations like those performed internally by Azure or Adobe Experience Manager are done by Azure service IPs, not your client IP. Since these Azure internal IPs are outside your restricted IP range, the SAS token validation fails, causing the 403 AuthorizationFailure error.

    In contrast, when you remove the IP restriction or allow public access, these operations succeed because there's no IP check blocking the Azure internal service calls.

    To fix this:

    1. Ensure your SAS token has the right permissions and that the start time is set with some buffer to avoid clock skew.
    2. Remove the IP restriction from the SAS token for operations that involve server-side calls from Azure services or allow a wider IP range that includes Azure service IPs (though this can be complex).
    3. Consider instead using Azure RBAC with Managed Identity or Private Endpoints for secure access without relying on IP-based SAS restrictions.
    4. Verify your storage account firewall allows your client IP and optionally enable "Allow Azure services on the trusted services list" for trusted Azure access.
    5. For troubleshooting, you can temporarily enable logging to compare the SAS "string to sign" for signature issues. Disable logging in production.

    Reference:

    https://learn.microsoft.com/en-us/troubleshoot/azure/azure-storage/blobs/authentication/storage-troubleshoot-403-errors
    https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security

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

    Please "Accept the Answer" if the information helped you. This will help us and others in the community as well.

    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2025-11-19T16:55:11.66+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    It seems that the 403 error you are encountering when integrating Azure Blob Storage with Adobe Experience Manager is likely due to the permissions and network restrictions you have set up. Here are a few points to consider:

    1. SAS Token Permissions: Ensure that the SAS token you are using includes all the necessary permissions for the operations you are trying to perform. The error message indicates that there might be a mismatch in the permissions granted by the SAS token. Check the sp (permissions) field in your SAS token to confirm it includes read, write, delete, and list permissions as needed.
    2. IP Address Restrictions: Since you are restricting access to a specific IP address (49.25.37.71), make sure that this IP is correctly configured in both the storage account's firewall settings and the SAS token. If the request is coming from a different IP, it will result in a 403 error.
    3. Public Network Access: When you allow public access, it works because the storage account does not enforce IP restrictions. However, when you restrict access to a specific IP, ensure that all configurations (including firewall and SAS token) are aligned to allow that IP.
    4. Service Message: The error message suggests that if you are using a StorageSharedKeyCredential or SAS token, you should compare the string to sign with the one generated by the SDK. This can help you identify if there is an issue with how the SAS token is being generated or used. Consider enabling the logging for the string to sign to troubleshoot further.
    5. Firewall Rules: Double-check the firewall rules to ensure that they are not inadvertently blocking the requests. Ensure that the client making the requests is indeed coming from the allowed IP address.

    By reviewing these aspects, you should be able to identify the root cause of the 403 error and resolve the issue accordingly.

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.