Co-author: Abhishek Narain
Protect continuity, understand connection risk, and set tenant-wide guardrails
Imagine that the person who built a business-critical pipeline has left your organization. The connection still exists, but nobody is sure who can manage it or whether its credentials will keep working. What begins as a handover problem quickly becomes a governance question: who owns your connections, where do they lead, and which identities should be allowed to use them?
Microsoft Fabric brings these questions together through two complementary capabilities:
- Admin connection APIs give tenant administrators visibility and ownership-management tools across connection types.
- Data connection policies set preventive controls for cloud connections.
Together, they support a practical sequence: restore responsibility, understand your connections, then enforce the authentication boundaries your organization needs.
From recovery to prevention
Keep work moving when a connection owner leaves
A departure should not leave a connection without someone who can maintain it. When an existing connection has a single owner, a Fabric tenant administrator can use the admin connection APIs to grant the Owner role to a responsible successor, another administrator, or an appropriate service principal. This restores the ability to manage the connection and establishes clear accountability during the handover.
Use the admin connection APIs to review current access, assign a responsible successor as an Owner, update an existing assignment, and remove access that is no longer appropriate. The role-assignment endpoints support GET, POST, PATCH, and DELETE operations; refer to Admin Connections REST API reference for endpoint syntax and examples.
Ownership is only part of continuity. Granting Owner does not transfer or renew OAuth credentials, confer permissions on the source system, or guarantee that dependent workloads will run. The incoming owner must check the connection requirements, update or reauthenticate credentials where needed, and validate the workloads that depend on it. Treat that validation as part of offboarding, not a task to postpone until something fails.
See your connections, endpoints, and access clearly
A tenant-wide inventory helps administrators find ownership gaps, unexpected access, and connections that may require review before they become operational issues. The admin APIs provide visibility across all connection types, including connections you do not own or have permission to manage. By comparison, the standard Manage connections and gateways experience does not provide a tenant-wide inventory, even for administrators.
Use the tenant-wide connections endpoint to collect the complete inventory, including all paginated results. The response includes connection names and IDs, connectivity and connector types, endpoint paths, privacy levels, and credential or authentication-type metadata—but not secret values. Combine this information with current role assignments to identify unexpected access and endpoints or domains that require closer review.
Recency data can help prioritize the review. Created, last-linked, and last-credentials-used timestamps answer different questions: last linked indicates when the connection configuration was most recently associated with a workload, while last credentials used provides a runtime signal. These timestamps do not provide a complete historical audit log, an automatic dependency map, or proof that an apparently idle connection is safe to delete. Confirm critical dependencies with workload owners before making changes.
Figure: Animated GIF — Read-only Fabric Connection Inventory sample app showing illustrative data; no live tenant details or ownership changes are shown.This read-only demonstration uses a Python client to list tenant connections and inspect a connection role assignment. It does not change ownership. For the admin API endpoints and an example response, refer to List Connections (Admin) and List Connection Role Assignments (Admin).
Try a read-only connection inventory app
For a hands-on inventory, refer to the Fabric Connection Inventory sample app. It uses the admin connection APIs to list tenant connections and their Owner and PendingOwner assignments, with search and filters for reviewing connector types, endpoints, and ownership results. It does not change connections, assign owners, or enforce policies.
This is a single-tenant deployment template, not a hosted app that readers can sign into. To use it, an organization must deploy its own instance in a workspace that supports Fabric Apps (Preview), configure a single-tenant Microsoft Entra app, grant delegated Tenant.Read.All consent, and sign in with a Fabric administrator account. See the repository’s setup instructions.
Illustrative API examples
To inventory connections across the tenant, an administrator can make a read-only request:
GET https://api.fabric.microsoft.com/v1/admin/connections
Authorization: Bearer <access-token>
{
"value": [
{
"id": "11111111-1111-4111-8111-111111111111",
"displayName": "ContosoConnection",
"connectivityType": "ShareableCloud",
"connectionDetails": {
"type": "Web",
"path": "https://www.contoso.com/"
}
}
]
}
If the response includes a continuationToken, use it to request the next page.
For an ownership handoff, the following illustrative write request shows the payload for adding a user as an Owner. It was not part of the read-only GIF or the production test:
POST https://api.fabric.microsoft.com/v1/admin/connections/11111111-1111-4111-8111-111111111111/roleAssignments
Authorization: Bearer <access-token>
Content-Type: application/json
{
"principal": {
"id": "22222222-2222-4222-8222-222222222222",
"type": "User"
},
"role": "Owner"
}
An ownership assignment may require the incoming owner to reauthenticate. It does not transfer credentials or guarantee that dependent workloads will run.
Make approved authentication methods the rule
An inventory shows how connections authenticate today. An authentication allowlist turns your organization’s requirements into a tenant-wide boundary for cloud connections. Instead of relying on every creator to make the same choice, you define the methods that policy permits.
An authentication allowlist helps administrators reduce inconsistent or noncompliant authentication choices across cloud connections. In the Fabric admin portal, select Data Policies in the left navigation, then open the Authentication allowlist tab. Add the approved authentication methods, turn on Restrict to allowlist, and select Save. Review the tenant-wide confirmation before committing. Select methods that meet your organization’s requirements and are supported by the relevant connectors; no single method is universally available or appropriate.
When enforcement is enabled, methods outside the allowlist fail policy evaluation for existing as well as new cloud connections. Enable this carefully, because it can disrupt existing workflows. That makes the inventory essential preparation: identify affected connections, agree on supported alternatives with their owners, and plan credential changes before enabling the restriction. These controls govern cloud connections; they are not a promise of coverage for every gateway, desktop client, or data path.
Figure: Authentication allowlist example before enforcement. Restrict to allowlist is turned off, and Workspace identity is included as a sample entry.Define which Microsoft Entra tenants can authenticate connections
An approved authentication method does not make every Microsoft Entra tenant acceptable. Organizations may also need to block connection authentication associated with unapproved tenants. The Tenant allowlist addresses this requirement by defining which Microsoft Entra tenants can be used for Entra-authenticated cloud connections, helping reduce the risk of authentication through unapproved tenant identities.
On Tenant allowlist, select Add tenant ID and enter the approved tenant GUIDs. Validate each ID carefully: the experience does not look up friendly names, and the list supports up to 100 IDs. Turn on Restrict to allowlist, select Save, and review the tenant-wide confirmation. Once enforced, the restriction affects both existing and new Entra-authenticated cloud connections.
Keep identity and destination controls distinct. The Authentication allowlist limits which methods cloud connections can use, while the Tenant allowlist limits which Microsoft Entra tenants they can authenticate with. Neither control approves destination endpoints nor acts as a firewall rule.
Figure: Tenant allowlist example before enforcement: Restrict to allowlist is off. The GUID shown is fictitious.Start with visibility, then enforce
Before enabling enforcement, inventory your cloud connections, identify critical workloads and their owners, and confirm the authentication methods and Microsoft Entra tenant IDs they need. Review the Authentication allowlist and Tenant allowlist tabs together, then enable only the controls you intend to enforce. Each allowlist has its own Restrict to allowlist switch. Communicate the change and assess its effect on existing as well as new cloud connections; enforcement applies tenant-wide.
Policy changes can take up to one hour to take effect. After enforcement begins, test affected cloud connections and dependent workloads. A noncompliant new connection is rejected; an existing connection may show Policy Evaluation Failure and go Offline. Open the connection details to identify the cause, then work with the connection owner and tenant admin to resolve the authentication-method or tenant-policy mismatch. Ownership transfer alone does not resolve a policy failure.
Figure: Connection details explain a policy failure. In this example, OAuth 2.0 non-Entra ID is not an allowed authentication kind.Closing
Start with a complete inventory and an ownership review of critical connections. Use that evidence to define and validate authentication-method and Microsoft Entra tenant allowlists. These capabilities cannot prevent every outage or misuse, but they can reduce unmanaged handovers, clarify decisions about access and endpoints, and apply preventive controls that reflect your organization’s requirements.
To plan your implementation, review the guidance for data source management and data connection policies.
