DirectLake Without OneLake Access: A Fixed-Identity Pattern That Keeps the Lakehouse Off-Limits

There’s a moment that catches a lot of Fabric teams off guard.

You publish a beautiful report on a DirectLake semantic model. Users can slice, filter, and explore exactly the way you intended. Then someone asks, “Why can I open the lakehouse and browse the tables?” Or worse: “Why can I query the SQL analytics endpoint directly?”

If your objective is semantic model consumption without lake access, the default DirectLake behavior can feel like it’s working against you. By default, DirectLake uses Microsoft Entra ID single sign-on (SSO)—meaning the viewer’s identity must be authorized on the underlying Fabric data source.

This post walks through a clean, operationally heavier—but very effective—pattern:

Bind the DirectLake semantic model to a shareable cloud connection with a fixed identity, and keep SSO disabled. Then do not grant end users any permissions on the lakehouse/warehouse item. Users can query the semantic model, but they can’t browse OneLake or query the data item directly.

Along the way, we’ll also cover the “gotchas” that trip teams up (especially around permissions and “SSO is still on somewhere”), plus a few guardrails that matter for real-world data governance in Microsoft Fabric.

The idea in one sentence

DirectLake enforces permissions based on the effective identity. With SSO, that’s the current user; with a fixed identity, it’s the identity you bind via an explicit cloud connection—so end users don’t need (and shouldn’t have) access to the underlying lakehouse/warehouse.

Why the default DirectLake setup breaks the separation

DirectLake’s default is straightforward:

• A report viewer queries the semantic model.
• DirectLake evaluates permissions using that viewer’s Entra identity.
• If the viewer can’t read the underlying data item, queries fail.

That’s perfect when you want source-level authorization to be enforced per user.

But if your goal is “people can use the model, not the lake,” then default SSO forces you into granting the very permissions you’re trying to avoid.

Microsoft’s own guidance is explicit here: you can bind a DirectLake model to a shareable cloud connection (SCC) to provide a fixed identity and disable SSO, so only that fixed identity needs read access to the source.

When this pattern is the right choice

This fixed-identity approach is a strong fit when you want one or more of the following:

• Users can view reports (and maybe build reports) on the semantic model, but cannot query the lakehouse/warehouse or browse OneLake.
• You’re using DirectLake with RLS at the semantic model layer and don’t want users to bypass it via the SQL analytics endpoint.
• You’re delivering content through an app or embedded scenario and want to keep source access tightly scoped (classic Power BI “semantic layer as product” thinking).

It’s not lightweight operationally—there’s identity configuration, connection management, and permission testing—but it’s clean and auditable.

How-to: Implement a fixed-identity DirectLake semantic model

Prerequisites you should confirm up front

Before you touch anything, be clear about these boundaries:

• Which Fabric item is the source: lakehouse or warehouse?
• Are you using Direct Lake on SQL endpoints or Direct Lake on OneLake? The permission requirements differ.
• Do users need to only consume reports, or also create reports on the semantic model?
• Where will RLS live—semantic model, OneLake Security, or both? (For this pattern, semantic model RLS is usually the simplest.)

Now the build.

Step 1: Choose your fixed identity

DirectLake fixed identity is implemented through the data connection configuration. For DirectLake models, Microsoft notes supported authentication methods include OAuth 2.0, Service Principal, or Workspace Identity.

In practice, most teams choose one of these:

• Workspace identity (my default when possible): it’s an automatically managed service principal associated with the workspace, with Fabric-managed credentials (less secret-rotation overhead).
• Service principal: useful when you want a dedicated app identity that’s not tied to workspace lifecycle.

If you go the workspace identity route, read Microsoft’s warnings carefully: workspace identity is powerful, and access to assume it should be tightly controlled.

Step 2: Grant the fixed identity access to the data item (not the users)

This is the core security shift: the fixed identity gets the data access, not the report consumers.

Microsoft breaks the requirements down by mode:

If your DirectLake model is using Direct Lake on SQL endpoints:

• Grant the fixed identity Read on the target Fabric artifact (lakehouse/warehouse).
• Grant SELECT on the tables via the SQL analytics endpoint permissions model.

If your DirectLake model is using Direct Lake on OneLake:

• Direct Lake on OneLake uses OneLake APIs and OneLake Security for permission checks.
• If OneLake Security isn’t enabled, the effective identity may require Read and ReadAll on the target artifact to access Delta tables.

Either way, the intent is the same:

The fixed identity can read the data item. End users do not get permissions on the data item.

Step 3: Create a shareable cloud connection (SCC) for the data source

This is where the “fixed identity” becomes real.

In the Power BI service:

1. Go to Settings → Manage connections and gateways.
2. On the Connections tab, select New.
3. In the New connection dialog:
   • Choose Cloud
   • Select the Connection type (the Fabric source type you’re connecting to)
   • Configure authentication using your chosen fixed identity

This creates the shareable cloud connection object you’ll map your semantic model to.

Two practical notes here:

• Fabric sources default to Entra SSO, but you can override that by mapping the semantic model’s data source to your shareable cloud connection.
• Shareable cloud connections can be shared—and if you share one, you are effectively sharing the credentials/identity behind it. Treat this like a privileged asset, not a convenience feature.

Step 4: Bind the DirectLake semantic model to that connection (and keep SSO disabled)

Now you map the model’s source to the connection you created.

1. In the workspace, find the semantic model.
2. Choose More options → Settings.
3. Expand Gateway and cloud connections.
4. In the Maps to dropdown, select your shareable cloud connection and Apply.

This is also where the “disable SSO” requirement matters. Microsoft notes you can configure both SSO and fixed identity, but if you want the fixed identity used for queries and refreshes, SSO must be disabled in the data connection configuration.

If you skip that, you’ll end up in an uncomfortable middle ground where you think you’ve implemented fixed identity, but end users still get blocked because SSO checks their source permissions at query time.

Step 5: Remove user access to the data item (lakehouse/warehouse)

This is the step that makes the pattern do what you actually want.

• Do not grant end users permissions on the lakehouse/warehouse item.
• Do not add them to workspace roles that grant OneLake read capability.
• Do not give them SQL endpoint access if your intent is to prevent bypass paths.

Microsoft explicitly calls out the scenario you’re implementing: “Users can query the semantic model but are denied querying the lakehouse or SQL analytics endpoint” by binding to a fixed-identity connection with SSO disabled and not granting users permission for the target Fabric artifact.

This is the separation-of-concerns move that keeps DirectLake powerful without turning every report viewer into a lakehouse browser.

Step 6: Grant the right permissions to the semantic model and reports

Now you give users access where you want it: the semantic layer.

At minimum:

• To view reports: users need Read permission on the report and Read on the semantic model.
• To create reports (thin reports) on the semantic model: users need Build permission on the semantic model.

Microsoft also notes semantic model permissions can be assigned directly, via apps, or implicitly through workspace roles—so be intentional about which path you’re using.

A subtle but important security footnote: users with higher privileges can sometimes discover schema metadata even when they don’t have data access. That may be acceptable—or it may mean you should avoid over-granting Build.

Step 7: Test like you mean it

Microsoft’s guidance here is simple and worth repeating: always test permissions before production.

A practical testing routine:

• Create a test user who has only report/semantic model permissions.
• Validate:
  • The user can view the report and interact normally.
  • The user cannot open or browse the lakehouse/warehouse item in Fabric.
  • The user cannot query the SQL analytics endpoint (if applicable).
• If you have RLS, test expected filtering in the semantic model security experience.

Operational realities and common “gotchas”

This pattern works well, but it has edges.

The semantic model owner still matters. DirectLake requires the semantic model owner to have read access so it can “frame” the model during refresh operations; lack of owner permissions can break refresh/framing.

SSO can sneak back in. If users still need lakehouse permissions to query the model, that’s almost always a signal that:

• The semantic model is still mapped to the default SSO connection, or
• The connection is configured in a way that still performs per-user SSO checks at query time.

Don’t share the connection broadly. Shareable cloud connections are powerful precisely because they let other artifacts reuse the same credential context. That’s great for centralized management—but risky if the wrong people can attach new models to your fixed identity.

If you need per-user enforcement at the source, this is not your pattern. Fixed identity intentionally collapses source authorization to a single identity. If you need OneLake Security to enforce per-user RLS/OLS at the data item, you likely need SSO—or you need to rethink where your rules live.

Closing: Your semantic layer is the product—treat it that way

If you want the semantic model to be the contract, not a side door into the lakehouse, fixed identity is one of the cleanest ways to enforce that boundary in Fabric.

You’re trading a little operational simplicity for a big governance win:

• users can query and consume the model,
• the lakehouse stays protected,
• and your Power BI semantic layer becomes the intentional interface to data.

If you’re building out a Fabric workspace strategy and trying to keep your security story coherent as usage scales, this is a pattern worth having in your toolkit.