Correctly Enabling OLS for some tables in powerbi report for data from lakehouse w/Directlake model

[varunsomani]

We're at the final stages of establishing the Lakehouse for our data. We are struggling with setting up the security correctly and were hoping to assistance on this.

Our current setup is:

• Data on lakehouse in Fabric
• Directlake Semantic model in a different workspace
• PowerBi report built on top of the semantic model

We want to hide some senstive data inside the powerbi report from users that don't have access to it but still show the rest of the table. All the sensitive sits in specific schemas in our lakehouse. I've put the specific coreidentity group as the only one that should be able to access it based off Get started with OneLake security (preview) - Microsoft Fabric | Microsoft Learn, but they can still see the schema in the lakehouse and also the data in powerbi. Is there a "right" way to set up OLS for the tables/report/lakehouse such that only those with access can see the full report and everyone else sees a partial report?

Best,

Varun

[v-dineshya]

Hi @varunsomani ,

Thank you for reaching out to the Microsoft Community Forum.

Hi @Nasif_Azam , @tayloramy , Thank you for your prompt responses.

Hi @varunsomani , 

Please follow below steps to Enabling OLS.

1. Use OneLake Security (Preview) to restrict access at the schema/table level.

Go to your Lakehouse --> Manage OneLake Security (Preview). Create a role for your Core Identity Group. Under Add Data, expand schemas and select only the tables in the secure schema. Assign the role to the appropriate Azure AD group or user. This checks that only authorized users can access those tables in the Lakehouse UI and OneLake Catalog.

Note: OneLake Security currently does not hide schemas/tables from the SQL Analytics Endpoint. Users may still see schema names even if they can't access the data.

2. OLS must be configured within the semantic model using Tabular Editor or TMDL View in Power BI Desktop.

Use Tabular Editor, Open your semantic model in Power BI Desktop. Go to External Tools --> Tabular Editor. In Tabular Editor, Define roles like SecureAccess, GeneralUser. For each role, set Table Permissions like below.

None --> It hides the table completely.
Read --> It allows access
Apply None to tables in the secure schema for roles that shouldn't see them.

Use TMDL View, Enable TMDL View under Preview Features. Go to Modeling --> Manage Roles. Create roles and define OLS directly in the TMDL editor.

roles:
- name: GeneralUser
tablePermissions:
- name: SecureTable1
permission: None
- name: SecureTable2
permission: None

Note: This hides the tables from unauthorized users in the report visuals and metadata they won’t even know the tables exist.

3. Assign Users to Roles in Power BI Service, After publishing the semantic model, Go to the Power BI Service --> Navigate to the dataset --> More Options (…) --> Security, Assign users or groups to the roles you defined like SecureAccess, GeneralUser, etc.

I hope this information helps. Please do let us know if you have any further queries.

Regards,

Dinesh

[varunsomani]

Hi @v-dineshya @Nasif_Azam @tayloramy ,

Thank you all for the replies. We tried the steps here but we are still struggling. I will split this into two sections:

Lakehouse security:

- We downgraded a user to viewer access

- We setup one role named Secure which was granted read access to all tables.

- We created another role called general which we granted access to just the non-secure schemas and tables

- We then assigned the aforementioned user to the general role

Expectation: The viewer only sees the non-secure tables in the lakehouse

Result: The viewer is still able to see all the tables in the lakehouse

Semantic Model security:

- We opened the model in tabular editor, and created a role with OLS Secure Reader and General.

- We used the setting None for the secure tables in General

- We published the role

- We assigned the same viewer user above to this General  role in Fabric DirectLake Semantic model with the manage roles tab in fabric

Expectation: Visuals that rely on the secure role would not be visible to the user

Result: The viewer is still able to see all the visuals, including ones that rely on secure role

Any thoughts on what we could be doing wrong, or a more detailed step by step would be appreciated. We already verified that the user doesn't have acces to the lakehouse through some other groups.

[tayloramy]

Hi, 

The workspace viewer role will override the lakrhkuse permissions, if you want to restrict tables, you must remove the workspace level roles. 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

[v-dineshya · Accepted solution]

Hi @varunsomani ,

Thank you for the response. 

OneLake Security (Lakehouse Level)

Please try below things to fix the issue.

1. Remove workspace-level Viewer role for users who should have restricted access.

2. Assign access only via OneLake roles at the schema/table level.

3. Split sensitive data into separate Lakehouses if strict isolation is needed.

4. Use fixed identity in semantic models to prevent users from accessing Lakehouse directly.

Semantic Model Security (OLS via Tabular Editor)

Please try below things to fix the issue.

1. Avoid using field parameters with OLS. Instead Use Calculation Groups to dynamically show/hide columns.

2. Use SWITCH logic in measures to conditionally display data.

3. Create duplicate “view” tables without sensitive columns for restricted roles.

4. Test roles using “Test as Role” in Power BI Service to validate behavior.

5. Please check model Permission is set to “Read” for restricted roles in Tabular Editor.

6. Use Fixed Identity in Semantic Model, this is essential for DirectLake models.

Go to Semantic Model Settings --> Gateway and Cloud Connections. Change from Single Sign-On to a Fixed Identity using OAuth. This checks the model accesses Lakehouse data using the model owner’s credentials, while RLS/OLS still applies to the viewer.

Please refer below links.

Solved: Issues with OneLake Data Access in Lakehouse: Fold... - Microsoft Fabric Community

OneLake security access control model (preview) - Microsoft Fabric | Microsoft Learn

Solved: OLS with Tabular Editor - Breaking visuals - Microsoft Fabric Community

Solved: Re: RLS not wokring In OneLake security - Microsoft Fabric Community

Solved: Re: User unable to access semantic model - Microsoft Fabric Community

Solved: Re: Minimum permissions needed to share a lakehous... - Microsoft Fabric Community

Table and folder security in OneLake - Microsoft Fabric | Microsoft Learn

I hope this information helps. Please do let us know if you have any further queries.

Regards,

Dinesh

[v-dineshya]

Hi @varunsomani ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Regards,

Dinesh

[v-dineshya]

Hi @varunsomani ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Regards,

Dinesh

[v-dineshya]

Hi @varunsomani ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Regards,

Dinesh

[Nasif_Azam]

Hey @varunsomani ,

Requires Object-Level Security (OLS) at the semantic model level, not just OneLake security. Approach I recommended:

 1. Configure OLS in the Semantic Model

• OLS hides entire tables or columns for users who don’t have the right permissions. For those users, the objects simply don’t appear in the model.
• For DirectLake models, OLS isn’t set up in the standard Power BI Desktop UI. You’ll need Tabular Editor or the XMLA endpoint.
• Steps:
  1. Open your semantic model in Power BI Desktop.
  2. Launch Tabular Editor from the External Tools menu.
  3. Create roles and set Table Permissions:
     • None = completely hidden for that role.
     • Read = visible for that role.
  4. Publish the model and assign users/groups to roles in the Power BI Service under Manage Roles.

2. Combine with OneLake Security

• OneLake security controls access at the data storage level. Keep it in place to prevent unauthorized access outside Power BI. However, for report-level visibility, OLS in the semantic model is essential.

Things to remember: OLS only applies to Viewers in a workspace. Admins, Members, and Contributors bypass OLS because they have edit rights. OLS doesn’t currently propagate automatically from OneLake to Power BI; you need to configure both. Features like Quick Insights and Smart Narrative don’t work with OLS-enabled models.

For Detailed Information:

Object-Level Security (OLS) with Power BI - Microsoft Fabric

Best Regards,
Nasif Azam

[tayloramy]

Hi @varunsomani, 

Are the users you're trying to restrict a member of any workspace roles? 
Contributor, Member, and Admin's of a workspace will override OLS. 

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

[tayloramy]

Hi @varunsomani, 

---

@varunsomani wrote:

We want to hide some senstive data inside the powerbi report from users that don't have access to it but still show the rest of the table.

---

Are you trying to hide specific rows in a lakehouse table, or the entire table? 

If you're trying to hide speicific rows, then you'll want to look at RLS instead of OLS, as OLS will hide entire objects. 

https://learn.microsoft.com/en-us/fabric/data-warehouse/row-level-security

https://learn.microsoft.com/en-us/fabric/data-warehouse/tutorial-row-level-security

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.

[varunsomani]

• We're trying to hide entire tables in specific schemas. We have a schema named secure in the lake house, and we want to hide those from everyone that doesn't have access to the data based off a core identity group