Campaign Azure Blob SAS Attachment Authentication Failures

Adobe Campaign delivery preparation can fail when a delivery uses an Azure Blob Storage file referenced by a SAS-signed HTTPS URL. The URL may work successfully in a browser or with curl, but fail when Campaign retrieves the attachment during delivery preparation.

Description description

During delivery preparation, Campaign attempts to download an attachment from Azure Blob Storage and returns an HTTP 403 authentication error:

The HTTP query returned a ‘Server failed to authenticate the request.
Make sure the value of Authorization header is formed correctlyincluding the signature.’ type error.

*The issue can occur even when: The Azure Blob URL works in a web browser.

• The same URL works with curl when quoted correctly.
• The Azure Blob endpoint has been allowlisted at the MID level.
• The issue reproduces in both staging and production.
• The SAS URL appears correctly formatted in the Campaign logs.In some variations, manually entering an XML-escaped URL can result in an HTTP 409 error such as PublicAccessNotPermitted.The business impact is that delivery preparation fails before sending, blocking email deliveries that depend on Azure-hosted attachments.## Resolution resolution**

Root Cause

The problem is caused by Campaign re-encoding the remote attachment URL before sending the HTTP request.Azure SAS URLs commonly contain percent-encoded characters in the signature, such as:%2B
%3DCampaign encodes the URL again during the attachment-fetch operation. As a result, the already encoded characters can become double-encoded:Original value:  %2B
Sent value:      %252BAzure then receives a different signature value from the one used to generate the SAS token. Because the signature no longer matches, Azure rejects the request with an authentication failure.The & versus & representation is not the underlying cause when Campaign processes the URL normally. XML serialization can represent an ampersand as &, and Campaign can unescape it. However, manually entering & into the URL can cause the query separators to be interpreted incorrectly and can lead to a 409 response instead of the expected SAS-authentication error.URL allowlisting does not resolve the problem because the request reaches Azure but contains a modified or invalid SAS signature.The investigation also determined that using a remote Azure Blob SAS URL as a dynamically retrieved attachment is an undocumented usage gap for this delivery scenario.

Resolution

*The recommended and supported approach is to download the Azure Blob file to the Campaign server before the delivery is prepared. Retrieve the file inside the workflow using an appropriate file-transfer mechanism or a JavaScript activity that calls the Azure Blob API.

• Store the file on the Campaign server.
• Configure the delivery attachment to reference the local server-side file path.
• Run a test delivery to verify that the file is available during delivery preparation.This avoids Campaign’s remote URL re-encoding behavior and follows the server-local attachment pattern.**