What is the IP address used by your online Dynamics 365 or Microsoft Dataverse environment? If you are connecting from a plugin, a Custom API, a custom workflow activity or a Power Automate Flow to an external API, what is the public IP seen by that external system?
Before answering those questions, why are we actually doing this? IP addresses are still the primary network identifier. In a security context, especially in enterprise projects, very often it is required to restrict what IP addresses are allowed to connect to certain services. This provides an additional security layer to the authentication and authorisation.
One day our national ID and passport numbers will be replaced by IP addresses… just kidding🙃, not yet. I think I’ve been watching Black Mirror and Humans too much lately (great TV series, by the way).
Going back to our initial questions again. Basically, long story short, there is not a mechanism to indicate what exact IP your plugin or Custom API will use to connect to the external system 😨. This is actually part of the compromise we make when using SaaS. However, Microsoft has tried to alleviate this constraint by sharing the IP ranges used by Azure, and therefore the Power Platform and Dynamics, by regions and services.
Let’s say we have a Microsoft Dataverse environment in UK (I’ll take UK as an example, but you could do the same with other country/regions). Then we have a Custom API that is triggering a plugin and calling an external API. The IP address used in this plugin will be one within the Azure IP Ranges and Service Tags – Public Cloud JSON file. But this file contains all the IP ranges for all the Azure services in all regions (apart from some special ones as US Government, China and Germany). So how can we be more specific and extract those IPs efficiently?
You can use the following code shared by Microsoft in this example. Although this scenario is about Microsoft-hosted agents in Azure DevOps, the same idea is applied. In that example, the US regions are filtered (e.g. AzureCloud.centralus). We just need to replace those for the UK regions:
A quick way to find the required values for those Azure service tags is to download the JSON file (e.g. ServiceTags_Public_20210301.json) and search for “AzureCloud.uk“, which would give you the following IDs to be used in that example script:
- uknorth
- uksouth
- uksouth2
- ukwest
“Wait, wait, wait… but there are still many ranges after applying this filter?” Those may be the words from your InfoSec colleague 😣
There is another trick we can try to be more specific, but this may not be easy to support or maintain. In our example, as we were running that Custom API plugin, let’s make a call from this plugin to a mock service and examine the HTTP request. We are going to use Pipedream to mock this external service:
In the HTTP request, the header x-forwarded-for will give us the “exact IP used by the plugin”. This is NOT a guaranteed IP address and you must NOT take it as your unique reference. But it can help you to reference the actual Azure service in the IP addresses file:
As the IP address 51.137.165.192, indicated by x-forwarded-for, fulls under the range 51.137.165.0/25, we could conclude that whitelisting the Azure IoT Hub service for the UK West region would be enough 🤠
Can you rely on this conclusion 100%? Probably not. Microsoft hasn’t documented publicly yet the relationship between the Power Platform components and the exact Azure Services underneath. They may never do it to keep it simple and have the flexibility to change their architecture as they need it. But, it would be definitely useful if they gave us some additional details, as they have actually done with Power Automate 👏
Requests from Power Automate use IP addresses that are associated with the region of the environment in which your flow exists as described in the following documentation:
@ramontebar 👨💻 
Reblogged this on Nishant Rana's Weblog.