What’s with the Endpoint Manager? I recently shared the Endpoint Collector, an extension of the CoE Kit which allows CoEs and Admins to report on the Endpoints configured with the HTTP connector in Cloud Flows. Having visibility is great, but how about actual control? I have heard the below question many times when speaking with different organizations:

Can we whitelist some internally approved endpoints at tenant level and block any other?

Although Microsoft released the endpoint filtering feature a few years ago, it is still in preview today. In my opinion, even if it wasn’t, it would still fail to really meet the above need in an efficient way as per its current design. That’s when the Endpoint Manager comes in!

• The problem with Microsoft OOB features
• The Endpoint Manager to manage Endpoint rules at scale
• The API used by the Solution
• Limitations

The problem with Microsoft OOB features

Let’s start with a review of the relevant features available.

Everything mentioned in this article is closely related to the Power Platform Data Loss Prevention Policies (DLP Policies). It is the platform feature to enable or block connectors in each environment. I will not describe what DLP Policies are in more details here, but more information is available in the official documentation if needed.

Endpoint Filtering

What is Endpoint Filtering?

Endpoint filtering is a sub-feature of DLP Policies. I cannot remember when Microsoft introduced it but I believe it was a good few years ago. When configuring a DLP Policy, it is possible to define endpoints to Allow or to Deny for each supported connector. These connectors are:

• HTTP
• HTTP with Microsoft Entra ID (AD)
• HTTP Webhook
• SQL Server (includes using SQL Server Connector to access Azure Synapse data warehouse)
• Azure Blob Storage
• SMTP
• The SharePoint and Public Sites Knowledge Sources for Copilot Studio

What is the problem with Endpoint Filtering?

Let’s list the problems with this feature in its current state:

1. It is still in Preview, after many years. Unfortunately this is not something we can control as customers, apart from pushing Microsoft to do the work required to move it to Generally Available.
2. There is a well-documented limitation: “Endpoint filtering rules are not enforced on environment variables, custom inputs, and dynamically bound endpoints during runtime“. This is a pretty big issue from a governance perspective. It means Makers can easily bypass the endpoint filtering rules by using a variable or other dynamic values for the endpoint. I assume that this limitation is the reason why the feature has remained in preview for years.
   
3. Configuring the endpoint filtering rules for each DLP Policy and each connector manually is… cumbersome. For large organizations, managing hundreds (if not more) environments, dozen of DLP Policies, maintaining these rules is not an easy task.
4. There is not any easy way to quickly list all the endpoint rules defined across connectors and policies. So if an Admin needs to remember where they enabled a specific endpoint… 🤯
5. The endpoint rules are not stored directly in the definition of the DLP Policy, meaning that they cannot be easily duplicated by using the Power Platform for Admin connector.

To be fair with my comment 3, there is actually some PowerShell support for endpoint filtering, meaning that Admins can use a script to update the rules across multiple policies. That said, it is still not so convenient for Admins to proceed in that way…

Custom Connector Pattern Rules

A very similar feature exists for Custom Connectors. It is possible to enable or block the custom connectors’ host URL endpoints, more info in the official documentation. There are a few differences with the endpoint filtering feature mentioned above:

• The endpoints can be classified as business, non-business or blocked in the DLP Policy, as opposed to the endpoint filtering rules which can only allow or deny endpoints.
• Since the host is in the custom connector definition and is not dynamic, Makers cannot bypass the rules as easily as with the endpoint filtering feature.
• This feature is no longer in Preview.

Here again though, there is some PowerShell support to update these rules programmatically.

Other than the above points, the other challenges remain, especially the inconvenience to manage these rules at scale across multiple policies and environments.

The Endpoint Manager to manage Endpoint rules at scale

In a nutshell, the Endpoint Manager is an App which allows Admins to apply endpoint filtering and custom connector pattern rules to multiple DLP Policies at once, instead of having to open each DLP Policy and each connector individually. The idea is that Admins no longer need to configure the Endpoints via the Admin Center at all and would instead use the Endpoint Manager for more efficiency.

⚠️ Please note that It does not change the fact that Endpoint Filtering is still a preview feature, which can be bypassed by Makers. It also leverages some non-supported API endpoints that I describe further in the next section “The API used by the Solution“. ⚠️

Overview – Endpoint Rules and Endpoint Rule Sets

The two core concepts of the solution are:

• Endpoint Rules: define the endpoints to allow or deny for each connector.
• Endpoint Rule Sets: the endpoint rules are combined into sets, which are then deployed to the relevant DLP Policies.

Supported Connectors & Data Policies

Supported connectors are the connectors that support Endpoint Filtering (HTTP, SQL Server, etc.). To keep things simple, the solution considers Custom Connectors just as any other Supported Connector in this solution. A Cloud Flow populates them into the Supported Connectors table. They will likely not change very often, but the flow still runs on a weekly basis in case new connectors become supported.

The Data Policies are the Power Platform DLP Policies; another Cloud Flow maintains them on a daily basis.

Creating Endpoint Rule Sets

Admins can create Endpoint Rule Sets using the Model Driven App Form.

Not much information is required at first, only a Display Name, the Scope and a Status:

The Status Reason is either Draft or Confirmed. Only confirmed rule sets can be deployed.

There can be one of three values for the Scope:

• All Policies: the solution will deploy the set to all the policies from the Data Policies table.
• Selected Policies: if selected, another subgrid will show on the form after saving the record once to select the Policies in scope. Only these policies will be updated when the set is deployed.
• All Policies Except: if selected, another subgrid will show on the form after saving the record once to select the Policies to exclude. Any other policies will be updated when the set is deployed.

After saving the record, a new section shows to create the relevant endpoint rules for the set. Based on the selected scope, another section might also show to select the policies to include or exclude.

Creating Endpoint Rules

Once a set is initiated, the related rules need to be created. Admins can create the rules one by one by using the model driven app form.

At this point you might be thinking “what is the point of this App if I have to create each rule individually for each connector?”. Fair point! A custom page “Bulk Create Rules” makes it possible to create them in bulk for a rule set. From a rule set main form, the button “Bulk Create Rules” will open the custom page in a dialog. It allows to select the connectors to associate to the rules and add the rules one by one in a similar fashion as you would do in the Admin Center. To keep things simple the Custom Connectors are considered as standard connectors here.

Deploying a Rule Set

When clicking the custom “Deploy” command from a rule set main form, a confirmation dialog shows on the screen, and the user lands then on the Rule Set Deployments page. In this table, one row is created for each DLP Policy that the set is deployed to.

Adding a row in the Rule Set Deployments table triggers the Flow that deploys the Endpoint Set to the policy. The table stores the link of the flow run for troubleshooting purposes, and the Status column can indicate Pending, Deployed or Failed.

The API used by the Solution

The HTTP connector is used in the cloud flows, to use the Business Application Platform API (api.bap.microsoft.com). The API itself is supported but the actual endpoints used in the Flows are not officially supported, though I suppose they are closely related to the supported PowerShell functions. The below endpoints are used:

• https://api.bap.microsoft.com/providers/PowerPlatform.Governance/v1/connectors/metadata/endpointfiltering: used to get the connectors that support Endpoint Filtering. This is used in the Flow “Epm – Populate Supported Connectors”, which also adds an additional row for Custom Connectors
• https://api.bap.microsoft.com/providers/PowerPlatform.Governance/v1/tenants/<tenantId>/policies/<policyId>/policyconnectorconfigurations: used to get and update the Endpoint Filtering rules. The structure for the request body and response is the same as in PowerShell. (By the way, the same endpoint can also be used to manage action controls, out of scope for this post).
• https://api.bap.microsoft.com/providers/PowerPlatform.Governance/v1/tenants/<tenantId>/policies/<policyId>/urlPatterns: same principle as the previous one, but this endpoint is used to configure the pattern rules for Custom Connectors. The structure is also the same as documented for PowerShell.

The Data Policies table stores the current endpoint configuration for each policy, and the Rule Set Deployments table also stores the request sent to update each policy.

To be able to use the API, an App needs to be registered in Azure as an Admin Management Application. More information about the prerequisites to use the Endpoint Manager is available in my GitHub Repo.

Limitations

The Endpoint Manager is a first version and intended to explore what admins can do to fill the gaps of the platform. Ideally Microsoft would improve the functionality to manage endpoint rules more efficiently, without an easy way for Makers to bypass them.

Let’s list the most obvious limits:

• It unfortunately relies on a preview feature which can be bypassed, and on non-supported API endpoints.
• The deployment rows for each Policy are created via the “Deploy” command in the App. It can take a minute to create all the rows. A better way could be to use an intermediate table with one row per deployment, which would trigger a flow to create each deployment row. This is the approach I use in the Solution Deployer for example.
• The configuration columns to show the actual endpoint rules for each DLP Policy and the the request body attached to the Deployment rows could be formatted in a more user-friendly way.
• Nothing is built to prevent conflicts between Endpoint Rule Sets. Some caution required for Admins to not overwrite the rules from one set with the ones from another.

As always, I welcome any feedback and ideas! Would love to hear what you think.