Connector endpoint filtering (preview)

[This article is prerelease documentation and is subject to change.]

Connector endpoint filtering lets admins control which specific endpoints makers can connect to when building apps, flows, or chatbots. It's configured within a data policy, and it's exclusively available for the following connectors:

• 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
• Browser Automation
• UI Automation

When a maker connects their app, flow, or chatbot to a blocked endpoint, they see a data policy error message.

Add endpoint filtering rules to your data policies

The Endpoint configurable column on the Prebuilt Connectors page in Data Policies indicates whether the endpoint filtering capability is supported for the connector.

If the value of the Endpoint configurable column is Yes, you can use this capability by right-clicking and then selecting Configure connector > Connector endpoints.

This opens a side panel where you specify an ordered list of Allow or Deny URL patterns. The last row in the list is a rule for the wildcard character (*) that applies to all endpoints in that connector. By default, the * pattern is set up as Allow for new data policies, but you can tag it as Allow or Deny.

Add new rules

You can add new rules by selecting Add endpoint. New rules are added to the end of the pattern list as the second-to-last rule. This is because * is the last entry in the list. However, you can update the order of the patterns by using the Order drop-down list or selecting Move up or Move down.

After adding a pattern, you can edit or delete it by selecting a specific row and then selecting Delete.

After you save your connector endpoint filtering rules and the data policy where they're defined, they are instantly enforced on the targeted environments. The following image shows an example where a maker tries to connect their cloud flow to an HTTP endpoint that isn't allowed.

Known limitations

• Endpoint filtering rules aren't enforced on environment variables, custom inputs, and dynamically bound endpoints during runtime. Only static endpoints that are known and selected when building an app, flow, or chatbot during design time are enforced. This means connector endpoint filtering rules for SQL Server and Azure Blob Storage aren't enforced if the connections are authenticated with Microsoft Entra ID. In the following two screenshots, a maker builds a cloud flow that defines the SQL Server and database inside variables, and then uses those variables as input to the connection definition. As a result, the endpoint filtering rules aren't evaluated, and the cloud flow executes successfully.

  

  

• Power Apps published before October 1, 2020, need to be republished for data policy connector action rules and endpoint rules to be enforced. The following script lets admins and makers identify apps that must be republished to comply with these new data policy granular control rules:

  Add-PowerAppsAccount
  
  $GranularDLPDate = Get-Date -Date "2020-10-01 00:00:00Z"
  
  ForEach ($app in Get-AdminPowerApp){
  
      $versionAsDate = [datetime]::Parse($app.LastModifiedTime)
  
      $olderApp = $versionAsDate -lt $GranularDLPDate
  
      $wasBackfilled = $app.Internal.properties.executionRestrictions -ne $null -and $app.Internal.properties.executionRestrictions.dataLossPreventionEvaluationResult -ne $null -and ![string]::IsNullOrEmpty($app.Internal.properties.executionRestrictions.dataLossPreventionEvaluationResult.lastAdvancedBackfillDate) 
  
      If($($olderApp -and !$wasBackfilled)){
          Write-Host "App must be republished to comply with granular data policy: " $app.AppName " "  $app.Internal.properties.displayName " " $app.Internal.properties.owner.email
      } 
      Else{ 
          Write-Host "App is already Granular data policy compliant: " $app.AppName 
      }
  }
  

Endpoint input formats and examples

Each connector defines an endpoint differently, and some endpoints can be in multiple formats. Therefore, you must enter endpoints in all possible formats to block makers from using them when creating apps and flows. Admins can enter the full endpoint name or use pattern matching with the wildcard character (*) to create an endpoint filtering rule. These rules are entered and presented in an ordered list of endpoint patterns, meaning that they're evaluated in ascending order by number. The last rule for any given connector is always * Allow or * Deny. Allow is the default, which can be changed to Deny.

The following guidance describes how to enter connector endpoints while creating rules to allow or deny them.

SQL Server

List SQL Server connection endpoints in <Server_name, database_name> format. A few things to keep in mind:

• Makers can enter the server name in various formats. To address an endpoint, enter it in all possible formats. For example, on-premises instances can be in <machine_name\named_instance, database_name> or <IP address, custom port, database_name> format. In this case, you have to apply allow or block rules in both formats for an endpoint. For example:

  • Block WS12875676\Servername1,MktingDB
  • Block 11.22.33.444,1401,MktingDB

• No special logic handles relative addresses like localhost. Therefore, if you block *localhost*, it blocks makers from using any endpoints by using localhost as part of the SQL Server endpoint. However, it doesn't stop them from accessing the endpoint by using the absolute address, unless the absolute address has also been blocked by the admin.

Here are some examples:

• Allow only Azure SQL Server instances:

  1. Allow *.database.windows.net*
  2. Deny *

• Allow only a specific IP range: (The IP addresses that aren't allowed can still be entered by the maker in <machine_name\named_instance> format.)

  1. Allow 11.22.33*
  2. Deny *

Dataverse

Dataverse endpoints are represented by the organization ID, such as 00aa00aa-bb11-cc22-dd33-44ee44ee44ee. Note that only the regular Dataverse connector is currently in scope for endpoint filtering. Dataverse dynamics and Dataverse current connectors aren't in scope. Also, the local instance of Dataverse (also known as the current environment) can never be blocked for use within an environment. This means makers can always access the Dataverse current environment within any given environment.

Therefore, a rule that says:

1. Allow 00aa00aa-bb11-cc22-dd33-44ee44ee44ee
2. Deny *

Actually means:

1. Allow Dataverse current environment
2. Allow 00aa00aa-bb11-cc22-dd33-44ee44ee44ee
3. Deny *

Allow Dataverse current environment is always implicitly the first rule in the Dataverse endpoint filtering list for any given environment.

Azure Blob Storage

Azure Blob Storage endpoints use the Azure storage account name.

SMTP

SMTP endpoints are represented in <SMTP server address, port number> format.

Here is an example scenario:

1. Deny smtp.gmail.com,587
2. Allow *

HTTP with Microsoft Entra ID, HTTP Webhook, and HTTP connectors

HTTP connector endpoints use a URL pattern. The Get web resource action of the HTTP with Microsoft Entra connector is out of scope.

Here's an example scenario:

Allow access to only the Azure subscriptions page within https://management.azure.com/.

1. Allow https://management.azure.com/subscriptions*
2. Deny https://management.azure.com/*
3. Deny *

Browser Automation

This feature lets you control the web pages a desktop flow accesses in Power Automate for desktop. The endpoints are represented in either URL format or web page name format, and you can use wildcards for dynamic URL or page name matching. Validation happens during "Launch Web Browser" or "Go to web page" actions before a desktop flow proceeds with browser interactions.

Here is an example scenario:

Allow access to all web pages except for the URL https://www.microsoft.com/ and any URL or web page containing the string powerplatform.

1. Deny https://www.microsoft.com/
2. Deny *powerplatform*
3. Allow *

UI Automation

This feature allows you to define which applications and screens a desktop flow can interact with in Power Automate for desktop. Endpoints are specified using the application's process name. When the process name is ApplicationFrameHost, Java, or Javaw—indicating a Universal Windows Platform (UWP) or Java application where multiple instances may share the same name—Power Automate for desktop uses both the process name and the window display name to accurately identify the target. Wildcards are supported for flexible matching.

Validation occurs on any action within the UI automation group. It checks the Process attribute (indicated by the number 1 in the image) or the Name attribute (indicated by the number 2 in the image) in the selector of the targeted screen (as shown by the arrow in the image). Usually the parent of the related UI elements is used to determine if the interaction is permitted.

Endpoint filtering rules don't apply to variables or dynamically-bound endpoints. If an expression includes anything other than a literal string, filtering is bypassed—potentially allowing access to restricted connector arguments. The default policy behavior is all endpoint filtering policies include a core rule (Allow * or Deny *), defaulting to Allow * (Allow All).

• When Allow * is used: Dynamic values aren't filtered. Any dynamic expression bypasses endpoint filtering, even if specific applications are restricted.
• When Deny * is used: All dynamic values are blocked by default, ensuring stricter enforcement.

Here is an example scenario. To allow access to all applications and screens, except those where the Process or Name attribute is either exactly Calculator or contains the string Java, you would configure the following rules:

1. Deny Calculator
2. Deny *Java*
3. Allow *

PowerShell support for endpoint filtering

Configure endpoint filtering rules for a policy

The object that contains endpoint filtering rules for a policy is called the connector configurations.

The connector configurations object has the following structure:

$ConnectorConfigurations = @{ 
  connectorActionConfigurations = @() # used for connector action rules
  endpointConfigurations = @( # array – one entry per 
    @{  
      connectorId # string
      endpointRules = @( # array – one entry per rule 
        @{ 
          order # number 
          endpoint # string
          behavior # supported values: Allow/Deny
        }
      ) 
    }
  ) 
}

Notes

• The last rule for each connector must always apply to URL * to ensure that all URLs are covered by the rules.
• The order property of the rules for each connector must use numbers 1 to N, where N is the number of rules for that connector.

Retrieve existing connector configurations for a data policy

Get-PowerAppDlpPolicyConnectorConfigurations 

Create connector configurations for a data policy

New-PowerAppDlpPolicyConnectorConfigurations

Update connector configurations for a data policy

Set-PowerAppDlpPolicyConnectorConfigurations

Example

Goal:

For the SQL Server connector:

• Deny database "testdatabase" of server "myservername.database.windows.net"
• Allow all other databases of server "myservername.database.windows.net"
• Deny all other servers

For the SMTP connector:

• Allow Gmail (server address: smtp.gmail.com, port: 587)
• Deny all other addresses

For the HTTP connector:

• Allow endpoints https://mywebsite.com/allowedPath1 and https://mywebsite.com/allowedPath2
• Deny all other URLs

$ConnectorConfigurations = @{ 
  endpointConfigurations = @(
    @{  
      connectorId = "/providers/Microsoft.PowerApps/apis/shared_sql" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "myservername.database.windows.net,testdatabase" 
          behavior = "Deny"
        }, 
        @{ 
          order = 2 
          endpoint = "myservername.database.windows.net,*" 
          behavior = "Allow"
        }, 
        @{ 
          order = 3
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    }, 
    @{  
      connectorId = "/providers/Microsoft.PowerApps/apis/shared_smtp" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "smtp.gmail.com,587" 
          behavior = "Allow"
        }, 
        @{ 
          order = 2 
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    },
    @{  
      connectorId = "http" 
      endpointRules = @(
        @{ 
          order = 1 
          endpoint = "https://mywebsite.com/allowedPath1" 
          behavior = "Allow"
        }, 
        @{ 
          order = 2
          endpoint = "https://mywebsite.com/allowedPath2" 
          behavior = "Allow"
        }, 
        @{ 
          order = 3
          endpoint = "*" 
          behavior = "Deny"
        } 
      ) 
    } 
  ) 
}
New-PowerAppDlpPolicyConnectorConfigurations -TenantId $TenantId -PolicyName $PolicyName -NewDlpPolicyConnectorConfigurations $ConnectorConfigurations