security
427 TopicsFabric Apps + semantic models: Build permission required just to view a report?
Hi team, We've started building POCs of our existing workspace Power BI apps as the new Fabric Apps, to support requirements our current apps can't — mainly data annotation and "soft" writeback. Our semantic models are solid, so we've built the Fabric App on top of our existing semantic models (RLS and all), with a sidecar SQL database as the annotation/writeback vehicle. Currently, our semantic models sit on F64-backed workspaces, meaning our users don't need a per-user license (Pro/PPU). But it seems Fabric Apps work differently: the app appears to execute queries on behalf of the signed-in user via the XMLA endpoint, which requires Build permission on the semantic model — and Build in turn requires an end-user license (Pro/PPU). Am I missing something obvious, or is this simply how Fabric Apps are meant to work? There seem to be two existing paths for this exact problem: Fabric data agents let consumers query a semantic model with Read-only access, no Build required: https://community.fabric.microsoft.com/blog/fbc_fabricupdatesblogs/update-to-required-permissions-for-semantic-models-in-fabric-data-agents/5172274 For multi-user applications on Premium/Fabric capacity, you already document that an app can use a service account or app identity to query on behalf of end users, without each one signing in individually (see "Multi-user application"): https://learn.microsoft.com/en-us/fabric/enterprise/powerbi/service-premium-connect-tools If either of those is viable, why does a Fabric App need each signed-in user to hold Build (and therefore a paid license) just to view a report? As it stands, requiring an end-user license for 1,000+ internal users who might open a report once a quarter is a hard sell. Thanks!11Views0likes1CommentOutbound Access Protection Tenant Level
Hi, what is the GA timeline for outbound access protection on tenant level in Fabric? Here are the relevant articles on the same. Any input is appreciated. Manage outbound access from OneLake with outbound access protection - Microsoft Fabric | Microsoft Learn Workspace outbound access protection overview - Microsoft Fabric | Microsoft Learn116Views1like4CommentsDatagateway stuck at "Failed to sign in. Please Verify your credentials and try again."
Im droping this here as i didnt see anywhere where this had been addressed. When trying to signin to the data gateway the app freezes and says "Failed to sign in. Please Verify your credentials and try again." The credentials are good and everything was fine prior to update. I got this after updateing the datagateway. The app freezes up and you have to force close. The work around is that you click signin options prior to entering email select these options and it will redirect you to your browser to login and wont lock up hope this someone38Views0likes1CommentUnable to connect Fabric Web API to Partner Center Referrals API – 401 Incorrect Audience
I am trying to connect Microsoft Fabric to the Microsoft Partner Center Referrals API using the Web API connector. API Endpoint GET https://api.partner.microsoft.com/v1.0/engagements/referrals?$orderby=createdDateTime desc This is related to: Partner Center → Referrals → Insights → Referral Summary Current Setup Azure App Registration An Azure App Registration has been created. The following API permissions are configured: Microsoft Partner - user_impersonation Microsoft Partner Center - user_impersonation Admin consent has been granted. For Microsoft Partner Center only Delegated permissions are available. No Application permissions are exposed. Partner Center The Azure application is registered in Partner Center under: User Management → Microsoft Entra Applications The test user has: Referrals Admin assigned for the entire organization. MFA is enabled and successfully completed. Authentication Test I tested Authorization Code Flow (App + User) and successfully obtained a delegated access token. JWT claims: { "aud": "https://api.partnercenter.microsoft.com", "scp": "user_impersonation", "idtyp": "user", "amr": ["pwd", "mfa"] } This confirms: User authentication works MFA works Authorization Code Flow works Delegated permission is applied Referrals Admin role is assigned Problem When calling: GET https://api.partner.microsoft.com/v1.0/engagements/referrals?$orderby=createdDateTime desc with the delegated token, the response is: { "statusCode": 401, "message": "Unauthorized: Invalid Authorization header, incorrect audience" } Token audience: https://api.partnercenter.microsoft.com Referrals API endpoint: https://api.partner.microsoft.com The API appears to reject the token because of an audience mismatch. Fabric Behavior When attempting to create a connection in Fabric Dataflow Gen2 using: Authentication = Organizational Account Fabric returns: Unable to create connection using an organizational account. Please check to see if the data source path is correct and that the data source supports using an organizational account. Since the same API call fails outside Fabric with the exact audience error, I suspect this is not a Fabric issue but an OAuth configuration issue for the Referrals API. Additional Findings The following scope successfully generates a delegated token: https://api.partnercenter.microsoft.com/user_impersonation However, the resulting token audience remains: https://api.partnercenter.microsoft.com I also verified that the only permission exposed by Microsoft Partner Center in Azure App Registration is: user_impersonation I do not see any Referrals-specific permissions such as: Referrals.Read.All Referrals.ReadWrite.All Question What is the correct OAuth resource URI / scope required to obtain a token that is accepted by: https://api.partner.microsoft.com/v1.0/engagements/referrals Has anyone successfully connected Fabric, Postman, Bruno, Power BI, or a custom application to the Referrals API and can share the required authentication configuration? Thanks!97Views1like1CommentAPI to see OrgApps you have access to via audiences
Hi, I want to mimic the Power BI portal's App page for an internal website. So I would like to see all apps I have access to. It's easy for Workspace Apps, it's also easy (through the OneLake Catalog API) to find out the OrgApps you have access to through the workspace they are in. What I can't find out are the Org Apps I can see because I have access to them via Audiences, without having access to the underlying workspace. Any idea how to solve that? Thanks, Thomas165Views0likes4CommentsWorkspace IP Firewall: Expected Behavior for Cross-Workspace API Calls?
We are evaluating Workspace IP firewall rules and noticed that cross-workspace API calls may be blocked when the source IP is not included in the workspace allowlist. Example: Workspace A uses its Workspace Identity to call Fabric APIs. Workspace B is protected by Workspace IP firewall rules. Workspace A has the required permissions on Workspace B. The API call fails because the source IP is not allowed. Is this expected behavior? If so, what is the recommended approach for secure Fabric-to-Fabric API communication between workspaces protected by Workspace IP firewall rules? More specifically, are Workspace Identities and Service Principals expected to work in this scenario, or are they also subject to the same IP-based restrictions? Workspace IP firewall rules restrict incoming access based on approved IP addresses. Additionally, is Microsoft currently evaluating any enhancements in this area, such as support for trusted Workspace Identities or Service Principals for cross-workspace API scenarios?Solved139Views1like3CommentsDeep-Dive: Microsoft Fabric Warehouse Internal Architecture (Polaris, V-Order & Lakehouse Tradeoffs)
Hi Fabric Community, I’ve spent the last few weeks researching and writing a complete architectural guide on the internals of the Microsoft Fabric Warehouse, and wanted to share some key design patterns and takeaways with you. When moving from Azure Synapse Dedicated Pools or SQL Server to Fabric, the mental model shift can be challenging—especially regarding serverless execution and open-standard storage. Here is a summary of the 3 most critical findings from my architecture breakdown: 1. The Polaris Engine Mechanics Unlike traditional Dedicated SQL Pools which bind compute to VM instances, Fabric Warehouse runs on the Polaris distributed SQL engine. Query compilation is split into stateless metadata services. Compute nodes are allocated dynamically per query. There is no local page storage; instead, the engine reads and writes open-source Delta Parquet format files directly in OneLake. 2. The Reality of Constraints A common point of confusion is table constraints. Fabric Warehouse allows you to define Primary Keys, Foreign Keys, and Unique Constraints, but they are not enforced during data ingestion. They serve purely as metadata for the query optimizer (to improve join paths). You must handle data validation/enforcement upstream in your Spark/Dataflow pipelines! 3. Direct Lake & Cold Queries Power BI's Direct Lake mode is a game-changer because it bypasses the SQL endpoint and queries the Delta Parquet files directly. However, if the dataset size exceeds the F-SKU memory limits, the query falls back to DirectQuery mode. This fallback forces the engine to run SQL queries on the SQL endpoint, introducing cold-query compilation times. I have published the full 11,000-word engineering handbook covering capacity planning, monitoring DMVs, security setups (RLS/OLS), and a retail case study. If you are planning an enterprise migration or studying for the DP-600 / DP-700 exams, check out the deep dive here: 👉 Read the Microsoft Fabric Warehouse Architecture & Performance Guide Would love to hear how your teams are managing cold query compilation and metadata cache warming on Fabric SQL endpoints. Let’s discuss below!141Views4likes3Commentsd365 finance and operations - azure synapse link
Hi Team, I have linked D365 F&O to Microsoft Fabric using Synapse Link, and the data is successfully syncing to my Lakehouse. My requirement is to create semantic models and share them with users so they can build their own Power BI reports, without giving them access to the underlying Lakehouse tables. This is what I've done: Created a semantic model. Shared it with users using Manage permission. Configured the required Cloud Connection. The users can access the semantic model, create reports, and add visuals without any issues. However, when they try to save the report, they receive a 401 Unauthorized error (screenshot attached). Am I missing any permissions or configuration? Is this the correct approach for sharing semantic models while restricting access to the Lakehouse tables? Any guidance would be greatly appreciated. Thanks!Solved192Views0likes6Comments