Microsoft Fabric Lakehouse Access Control remediate
Diagnose and resolve access control issues across all security layers of Microsoft Fabric Lakehouse, including workspace roles, item permissions, OneLake security data access roles, SQL analytics endpoint granular permissions, and Direct Lake semantic model security integration.
When to Use This Skill
- •User cannot access lakehouse data or sees "permission denied" errors
- •Queries return empty results or missing rows/columns unexpectedly
- •OneLake security roles not applying or taking too long to propagate
- •SQL analytics endpoint permissions not restricting access as expected
- •Direct Lake semantic model returns errors after enabling OneLake security
- •Shortcut data is inaccessible or returns 404 errors
- •DefaultReader role conflicts with custom data access roles
- •Deployment pipeline or git integration issues with data access roles
- •Users see data they should not have access to (over-provisioned)
- •Row-level or column-level security not filtering correctly
Prerequisites
- •Microsoft Fabric workspace with capacity or trial license
- •Admin, Member, or Contributor workspace role for managing security
- •Familiarity with T-SQL for SQL analytics endpoint security
- •PowerShell 7+ for running diagnostic scripts
Fabric Lakehouse Security Layers
Fabric Lakehouse enforces security through multiple overlapping layers. Understanding the evaluation order is critical for remediate.
Layer 1 - Workspace Roles control coarse access to all items in a workspace.
| Role | Workspace Access | OneLake Read/Write | Manage Security |
|---|---|---|---|
| Admin | Full | Yes | Yes |
| Member | Full | Yes | Yes |
| Contributor | Full | Yes | No |
| Viewer | See items only | No (unless granted) | No |
Layer 2 - Item Permissions grant access to a single lakehouse without a workspace role. Key permissions: Read (see item), ReadAll (read all OneLake data), Reshare, Write.
Layer 3 - OneLake Security (Preview) provides granular role-based access at the table, folder, row, and column level. Enforced across all compute engines. Disabled by default; once enabled, cannot be turned off.
Layer 4 - SQL Analytics Endpoint Security uses T-SQL GRANT/DENY/REVOKE for object-level, row-level, and column-level security. Only applies to queries via the SQL analytics endpoint.
Layer 5 - Semantic Model Security applies RLS/OLS within Direct Lake or DirectQuery models only.
Quick Diagnostic Workflow
Follow this sequence to isolate the root cause. See workflow-diagnostics.md for full details.
TODO
- • Step 1: Identify the access path — see workflow-diagnostics.md
- • Step 2: Verify workspace role and item permissions — see workflow-diagnostics.md
- • Step 3: Check OneLake security role membership — see workflow-diagnostics.md
- • Step 4: Audit SQL analytics endpoint permissions — see workflow-diagnostics.md
- • Step 5: Validate Direct Lake security integration — see workflow-diagnostics.md
- • Step 6: Check shortcut and cross-region access — see workflow-diagnostics.md
Common Issues and Resolutions
| Symptom | Likely Cause | Resolution |
|---|---|---|
| User sees all data despite OneLake security roles | DefaultReader role still active | Delete or edit DefaultReader role to remove ReadAll grant |
| Empty results from queries | RLS filtering all rows for user | Check RLS predicates; verify user is member of correct role |
| "Can't find table" or "Column can't be found" in Direct Lake | OLS/CLS hiding objects after OneLake security applied | Add user to role with table/column access |
| Shortcut returns 404 | Cross-region shortcut with OneLake security enabled | OneLake security does not support cross-region shortcuts |
| Permission changes not taking effect | Propagation latency | Role definition changes: ~5 min. Group membership changes: ~1 hour. Some engines add another hour of caching |
| SQL endpoint shows data OneLake security should restrict | SQL security and OneLake security are separate layers | Apply security at both layers or restrict access to only the secured endpoint |
| B2B guest user cannot access data via OneLake security role | Entra External ID settings | Set Guest user access to "same access as members" in Entra External Collaboration settings |
| Distribution list members can't access SQL endpoint | SQL endpoint can't resolve DL membership | Use security groups instead of distribution lists for OneLake security roles |
| Deployment pipeline fails for data access roles | Target workspace DAR tracking not enabled | Manually enable DAR tracking on target workspace before deploying |
OneLake Security Limitations
See onelake-security-reference.md for complete details.
Key limits to remember: maximum 250 roles per lakehouse, 500 members per role, 500 permissions per role. Mixed-mode queries accessing both OneLake-security-enabled and non-enabled data will fail. OneLake security does not work with private link protection or Azure/Purview Data Share.
Available Scripts
Run the SQL permissions audit to enumerate explicit grants on a SQL analytics endpoint.
Run the access control checklist to validate a user's effective permissions across all security layers.
Use the RLS validation template as a starting point for testing row-level security predicates.
References
- •Diagnostic Workflow — Step-by-step remediate procedure
- •OneLake Security Reference — Data access roles, limitations, propagation latency, and best practices
- •SQL Endpoint Security Reference — T-SQL granular permissions, RLS, CLS, OLS, dynamic data masking
- •Direct Lake Security Integration — Permission models, OLS/RLS interaction, remediate matrix
- •Microsoft Learn: OneLake Security Overview
- •Microsoft Learn: SQL Granular Permissions
- •Microsoft Learn: Best Practices for OneLake Security