We're using Microsoft Dynamics 365 Business Central to store documents in an Azure Blob Storage account. The connection works when the storage account is open, but fails when we restrict network access using the published Azure IP ranges and service tags.
Storage diagnostic logs show the request coming from a 10.0.0.0/16 address, which appears to be an internal Microsoft network address rather than one of the expected public Business Central IP ranges. Enabling the storage account option to allow trusted Microsoft services did not resolve the issue.
Because the Business Central instance is Microsoft-hosted, we're unsure whether private endpoints are supported for this integration. What is the recommended way to secure the storage account while still allowing Business Central to access a specific container? Would a SAS token be sufficient, or would the network layer still block the request?
3 Answers
This can happen when Business Central and the storage account are located in the same Azure region. Azure may route the traffic internally, so the source address recorded by Storage can be in a private-looking range rather than matching the public service tags. A commonly reported workaround is to place the storage account in a different region, or use a private endpoint where the integration architecture supports it.
A SAS token controls authentication and permissions, but it does not automatically bypass a storage account's network restrictions. Storage evaluates the network path first, so a request can still be rejected even with a valid SAS if public access is disabled or the source network is not allowed.
Check the diagnostic logs to distinguish a network-rule denial from an authentication or authorization failure. If the Business Central path cannot use a private endpoint and its source addresses cannot be reliably allowlisted, a secured proxy or middleware layer may be the most practical option. Another-region placement may also change the routing behavior, so it is worth testing before committing to a proxy.
I would avoid relying solely on Business Central outbound IP allowlisting. Microsoft-hosted SaaS traffic can use broad, changing, or internal service infrastructure addresses that do not map neatly to the published ranges. Also, allowing trusted Microsoft services does not necessarily mean every Microsoft SaaS product is included.
For sensitive documents, the stronger options are a private endpoint if the Business Central integration supports it, or an intermediary such as an Azure Function, App Service, or API. The intermediary can use managed identity and private networking to access Storage, while Business Central calls only the controlled API. If you use this design, the public function endpoint still needs to be protected with authentication, authorization, rate limiting, and careful input validation.
The integration comes from a Microsoft-hosted Business Central instance, and we do not control the add-on middleware. That makes a private endpoint seem difficult, especially since the request appears to originate from a public-facing service path.
Thanks, I'll test this with a storage account in another region. That should be straightforward to try.