Forum Discussion
Helper IIUsers gained unauthorized access to reports!!! How to stop them?
HI all,
As per the subject, we just discovered some users gained unauthorized access to reports: someone with access reshared (without permissions, needless to say) a report link. So we checked and it turned out that with a link, every user, *even users that don't have access to workspace* can access unauthorized reports, and this despite the permissions settings we put in place.
RLS is working, but this is not enough: every report must be accessed by authorized users only.
Our configuration is like this.
1) no end user has workspace access
2) no end user has direct access to reports
3) appropriate AD groups are given read ONLY access to dataset underlying the reports.
4) users are given report access via APP and audiences.
Despite that, users can access undue reports by using links provided by someone else, thus accessing sensistive information they shouldn't have to.
Now I have to remediate; the first thing I have to do is to revoke any access via link. I found some posts here showing how to do so, but none of them are working. If I click on a report and check permissions, there is no "via link" section, direct access shows only authorized users (I. E. admins and nobody else) and "Access via related item" section is empty.
BTW: grants via link should appear here, right? Why there aren't any?
EDIT: I double checked the advanced settings in every app audience: everything is correctly unchecked:
How do I revoke existing access via shared links?
And secondly, how do I stop users from sharing links? or, better yet: how do I stop users accessing unauthorized reports even if they have a link?
Thank you in advance,
Gianfranco.
Here it is the support team response.
It is not possible to restrict users from opening some of the repots sharing same semantic model. Actually, giving read access to the semantic model (which is required for the reports to work) automatically gives access to *ALL* the reports sharing the same semantic model. This is by design, they say.
I will have to develop a way to deny users access to undue reports using RLS features, somehow. Maybe using OLS. We'll see..
13 Replies
iW1DOVHi, luisoliveira89 thank you for your feedback.
Actually no user except for admins have permission higher than READ. No user has Build permission. We even set up an explicit test user, with READ ONLY permission on the dataset (see snippet) and the user *DOES* access unauthorized reportsit definitely looks like something is not working as it should...
I surely will ask the Tenant Admin to double-check the “anyone with the link” setting.- GilbertQ
Super User
Hi iW1DOV
What I have seen happen in the past is where you share a report with the user and unknowinly . There is also another tick box that allows that user to share the report with others and that could be potentially how they are getting access to the reports. Even though you haven't done it, a single user has reshared with another user and that user will then also have the option to on share again.
v-pnaroju-msftCommunity Support
Hi iW1DOV,
Based on our understanding, organization wide or specific people share links might still grant report access even when users do not have workspace access or explicit report permissions.
Kindly follow the below steps which may help to resolve the issue:
1.Check each affected report and paginated report, and remove any existing People in your organization or unintended links. Also review the semantic model permissions, since report sharing links tied to the semantic model can also grant access.
2.Ask your tenant admin to review tenant settings such as "Allow shareable links to grant access to everyone in your organization" and external sharing settings. Also ensure that "Allow access to hidden content" is disabled in App audiences, because hidden content can still be opened through direct URLs if this option is enabled.
If users can still open unauthorized reports, the issue might be related to the shared semantic model architecture itself, particularly with paginated reports and shared datasets. In such a case, we kindly request you to open a Microsoft Support ticket so that the support team can inspect effective backend permissions and inherited access paths in detail using the link:Microsoft Fabric Support and Status | Microsoft Fabric
Additionally, kindly find the below links for reference:
Share and Collaborate on Power BI Reports and Dashboards - Power BI | Microsoft Learn
Manage Semantic Model Access Permissions in Power BI - Power BI | Microsoft Learn
Export and sharing tenant settings - Microsoft Fabric | Microsoft LearnWe hope the information provided helps to resolve the issue. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you.
- iW1DOV
Hi v-pnaroju-msft , thank you.
I was assessing the situation with the customer. We triple-checked permissions on workspace and reports, and no one has access to other reports than they have to. Users have only access to due reports via the app.
We audited access to some of most sensible report and it turned out that some users gained access to those wia the Onelake catalog. where all reports are listed!So, definitely we will raise a ticket to solve the main problem: users accessing undue reports via links, but we think also onelake access has to be restricted ASAP - but I don't know how rto do so: can you provide some guidance on this matter, please?
Thank You!
Gianfranco
- v-pnaroju-msft
Hi iW1DOV,
Based on our understanding, the behaviour may be related to effective permissions and discoverability through the OneLake catalog rather than workspace access alone. The OneLake catalog itself may not independently grant access, however, it surfaces items based on the user's existing effective permissions. Therefore, if a user can open a report from the OneLake catalog, there may still be some underlying permission path allowing access, such as direct or inherited report permissions, semantic model permissions, related item inheritance, App propagation, or existing share links.
At this stage, as suggested, we request you to open a Microsoft Support ticket so that the support team can investigate backend effective permissions, inherited access chains, catalog discoverability behaviour, and hidden sharing paths.
Additionally, kindly refer to the link below:
OneLake catalog overview - Microsoft Fabric | Microsoft Learn
We hope the information provided above helps to resolve the issue. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you.
- iW1DOV
We are currently in touch with Microsoft Support, let's see if they will be able to solve our issue
- luisoliveira89
Helper I
Hello iW1DOV
I believe this is actually expected behavior, not a bug.
What’s happening is tied to Build permission on the semantic model. If users have Build, they can access any report connected to that dataset, even if they don’t have explicit access to the report or workspace.
It also explains why you don’t see anything under “via link”. The access isn’t coming from sharing, it’s inherited through the dataset.
To fix this, you need to remove Build permission from those user groups. You can do that by going to the semantic model → Manage permissions → Direct access / Advanced, and removing those users/groups or unchecking Build.
Also worth checking tenant settings to limit link sharing (“anyone with the link”) if that’s enabled.
Once Build is removed, the links alone won’t work anymore.
Best Regards,
Luis Oliveira
- v-pnaroju-msft
Thankyou, luisoliveira89 and GilbertQ for your responses.
Hi iW1DOV,
We appreciate your inquiry through the Microsoft Fabric Community Forum.
We would like to inquire whether have you got the chance to check the solutions provided by luisoliveira89 and GilbertQ to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.
Thank you.- iW1DOV
Hi v-pnaroju-msft
Unfortunately no, they didn't. Users must access only reports granted to them, thus retaining read access to the underlying dataset. I realize right now that I should have mentioned that a single dataset feeds more than 50 reports; users, based on their profile, should access only a subset of them. Most are paginated reports.
So the question is better rephrased as: how do I stop users to access unauthorized reports, while retaining read access to the dataset?
- v-pnaroju-msft
Hi iW1DOV,
Thank you for the update.
We kindly request you to share the feedback provided by the support team with the community. This will help others who are facing similar challenges and benefit the broader community members.
- iW1DOV
Here it is the support team response.
It is not possible to restrict users from opening some of the repots sharing same semantic model. Actually, giving read access to the semantic model (which is required for the reports to work) automatically gives access to *ALL* the reports sharing the same semantic model. This is by design, they say.
I will have to develop a way to deny users access to undue reports using RLS features, somehow. Maybe using OLS. We'll see..
- v-pnaroju-msft
Hi iW1DOV,
Thank you for the detailed investigation and the findings that you have shared with the community. This will certainly assist other customers who are designing secure shared semantic model architectures in Microsoft Fabric and Power BI.Based on our understanding, in scenarios where different user groups require access to different reports while using the same underlying data source, the following approaches may be considered.
1.Implementing stringent Row Level Security (RLS) to ensure that users can only view the rows of data they are authorized to access.
2.Evaluating Object Level Security (OLS) if sensitive tables or columns also need to be restricted from unauthorized users.
3.Separating highly sensitive reports into dedicated semantic models when true report isolation is necessary.
4.Minimizing broad semantic model permissions wherever feasible.Additionally, kindly refer to the following documentation links:
Semantic model permissions - Power BI | Microsoft Learn
Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
Analysis Services tabular model object-level security | Microsoft LearnWe hope that the above information is helpful in resolving your concern. Should you have any further queries, please feel free to contact the Microsoft Fabric community.
Thank you.
- v-pnaroju-msft
Hi iW1DOV,
We would like to follow up and see whether the details we shared have resolved your problem. If you need any more assistance, please feel free to connect with the Microsoft Fabric community.
Thank you.
