Activity
Mon
Wed
Fri
Sun
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
What is this?
Less
More

Memberships

Learn Microsoft Fabric

14.4k members • Free

Modern Data Community

1.4k members • Free

3 contributions to Learn Microsoft Fabric
A change to the Lakehouse security.
Hi all, came across a challenge in Fabric in my organization and curious if others are seeing the same thing. Lakehouses created in autumn 2024 or later seem to behave differently when it comes to access control. Previously, we were able to grant users either Read or ReadAll permissions on the Lakehouse and its SQL endpoint, which allowed them to access the SQL endpoint, the default semantic model, and query the data via Power BI Desktop. This setup worked well and allowed us to give access at the Lakehouse level without exposing the whole workspace. However, for newer Lakehouses, this no longer seems to work. Users with the same permissions can no longer access the SQL endpoint or the default semantic model from Power BI Desktop. The only workaround we’ve found is giving them Viewer access to the entire workspace, which also gives access to all other lakehouses/items in the workspace, not ideal from a security and governance standpoint. We also experimented with enabling RBAC on the Lakehouse and assigning access that way, but it didn’t help in this case since it doesn't apply to the SQL endpoint today. Our assumption was that this might be related to the gradual rollout of Microsoft’s broader OneLake security model, and possibly tied to the private preview functionality around more granular access control. With Monday's announcements on User identity mode / Delegated identity mode (link: Fabric March 2025 Feature Summary | Microsoft Fabric Blog | Microsoft Fabric) I'm convinced our first lakehouse is in "Delegated Identity" and our newer is in "User's identity" mode and there's no option to change it today and the functionality that User's identity mode is supposed to bring just isn't there today so it's not any good. I guess I'm just curious if anyone has the same issue or not, I don't see any discussions about this not working online and I'm wondering if we're the only ones using a lakehouse this way? Feels like Microsoft rolled this change out randomly multiple months before it was done...
F64 to F16 SKU - Features lost ?
F64 to F16 - Downgrade - Features lost ? Hi everyone , we aren’t really using the capacity of F64 and it it breaking our bank. Are there any specific features or capabilities that would be lost due to this downgrade ?
2 likes • Sep '24
AI Skills (preview) also requires F64 capacity
Granting access to Lakehouse SQL Endpoint issues
My company is actively moving Microsoft Fabric with an architecture of two lakehouses, one for raw and one for transformed data, with ingestion and transformation tasks inbetween. We want the lakehouse with the transformed data to be serving layer today and in the future we might continue to a further "layer" in the future but we're not super mature yet and are in an exploratory phase. My frustration is that what I want my users to be able to do, is to connect to the SQL Endpoint of the Lakehouse from Power Bi and pick out their desired tables, then choose either direct query or import mode and start modeling or building reports. However, when I started creating RBAC roles in the Lakehouse and granting people access, they could either not see any tables in the SQL Endpoint or they can see everything (tested with different workspace settings also). I can't get OneLake data access to control on a table level through the SQL Endpoint, as it seems to only apply to the Lakehouse default semantic model.. I don't want to control access control on a Semantic model level today cause that enforces direct query to my knowledge. No problem, I'll go to the endpoint and create SQL queries that defines roles and what tables can be seen from which roles, using GRANT/REVOKE/ALTER ROLE commands. But then I wake up to half of the roles are missing (users no longer have right to the tables which I gave)the next day, and upon further investigation every pipeline I have running during the night that uses some type of drop table logic, also removes the role at the same time? Same thing for any overwrite or replace I have in use I believe.. How do I today let people access certain tables in my lakehouse, as either query or import mode. Is it to just accept Direct query, to not have any type of drop tables in tables or have multiple lakehouses... My understanding in the roadmap is that this will be "fixed" in Q1 2025 by taking SQL Endpoint into the RBAC Onelake system. Any views or help is appreciated, thanks fellow Fabric friends.
0 likes • Jun '24
@Will Needham In the pipelines currently in our system there is a mixture of , appends, overwrites, replaces, but even some pipelines that are dropping tables and recreating them. This is where the access is also dropped. Is it industry standard to avoid dropping and recreating at all costs? Even if the data amount is low?
1 like • Jun '24
@Will Needham Thank you, this is what I needed! Appreciate your time. Also yes to your edit, I use copy data activity with mode overwrite (and yes that drops permissions)
1-3 of 3
William Liljedahl
2
14points to level up
@william-liljedahl-6784
Based in Finland and trying to learn Fabric best practices.

Active 75d ago
Joined Apr 18, 2024
Powered by