Forum Discussion

charlesdata's avatar
charlesdata
Regular Visitor
3 months ago
Solved

Is it expected group-based workspace Admins cannot see lakehouse items while individual users can

## Problem Description

 

We're experiencing an inconsistency with lakehouse item visibility depending on whether workspace Admin permissions are granted to individual users vs. Entra ID groups via Terraform (microsoft/fabric provider ~> 1.0).

 

## Environment

 

- **Deployment Method:** Terraform with microsoft/fabric provider v1.0
- **Authentication:** Service Principal
- **Workspace Capacity:** F2 (Fabric)
- **Region:** East US 2
- **Date Observed:** May 2026

 

## Observed Behavior

 

### ✅ Individual User Assignments (Works)
When we assign workspace Admin role to individual users:
```hcl
resource "fabric_workspace_role_assignment" "admins" {
  workspace_id = fabric_workspace.this.id
  role         = "Admin"
  principal {
    id   = "user-object-id"
    type = "User"
  }
}
```

 

**Result:** Users can see:
- ✅ Workspace
- ✅ Lakehouse item
- ✅ SQL endpoint

 

### ❌ Group-Based Assignments (Doesn't Work for Lakehouse)
When we assign workspace Admin role to an Entra ID security group:
```hcl
resource "fabric_workspace_role_assignment" "admins" {
  workspace_id = fabric_workspace.this.id
  role         = "Admin"
  principal {
    id   = "group-object-id"
    type = "Group"
  }
}
```

 

**Result:** Group members can see:
- ✅ Workspace
- ❌ Lakehouse item (not visible)
- ✅ SQL endpoint

 

## Steps to Reproduce

 

1. Create a Fabric workspace via Terraform
2. Create a lakehouse in that workspace
3. Assign an Entra ID security group as workspace Admin
4. Log in as a member of that group
5. Navigate to the workspace

 

**Expected:** User should see lakehouse, SQL endpoint, and workspace
**Actual:** User sees only workspace and SQL endpoint; lakehouse is hidden

 

## Workaround

 

We discovered two workarounds:

 

### Option 1: Manually add user as workspace Admin (UI)
- Navigate to workspace settings in Fabric Portal
- Add the specific user as Admin
- Lakehouse becomes visible

 

### Option 2: Assign individual users instead of groups (Terraform)
- Query Entra ID group membership
- Create individual `fabric_workspace_role_assignment` resources for each member
- This works correctly

 

## Verification

 

We verified via Fabric REST API that:
- Group assignment exists: `GET /v1/workspaces/{id}/roleAssignments` shows the group with Admin role
- User is in the group: Confirmed via `az ad group member list`
- Lakehouse item exists: `GET /v1/workspaces/{id}/items` shows both Lakehouse and SQLEndpoint items
- Individual assignments work: Same users see lakehouse when assigned directly

 

## Questions

 

1. **Is this expected behavior?** Should workspace Admin permissions granted to groups cascade to item-level visibility?

 

2. **Is there documentation** explaining when/why workspace permissions inherit to items differently for groups vs. individual users?

 

3. **Is there a REST API** to explicitly grant item-level permissions? We tried `/v1/workspaces/{workspaceId}/items/{itemId}/users` but it returns 404.

 

4. **Is this a known issue** with the Terraform provider or Fabric platform?

 

## Documentation Reviewed

 

We've reviewed the following official documentation but couldn't find explicit guidance on group vs. user permission inheritance:

 

 

## Impact

 

This affects our ability to manage workspace access via centralized Entra ID groups. We currently have to:
- Maintain individual user lists in Terraform
- Re-deploy when group membership changes
- Cannot use group-based access control (GBAC) best practices

 

## Request

 

Could the product team:
1. Confirm whether this is expected behavior
2. Update documentation to clarify group vs. user permission inheritance
3. If it's a bug, provide an ETA for a fix
4. If it's expected, provide guidance on managing item-level permissions for groups via API/Terraform

 

Thank you for any insights!

 

---

 

## Tags
 
data engineering
lakehouse
  • Tamanchu's avatar
    Tamanchu
    3 months ago

    Hi charlesdata,

     

    I ran into a very similar situation a while ago, so I wanted to share what we found.

    What you're seeing looks less like a Terraform issue and more like the way Fabric splits workspace permissions from OneLake/Lakehouse data access. Workspace roles can be assigned to users or security groups, but Lakehouse access is governed separately through OneLake security and Lakehouse sharing the Permission model doc lays out the layers if you want the official version.

    In practice, that means a group being workspace Admin doesn't always produce the same Lakehouse item visibility you get with a directly assigned user. From what we observed, the auto-mapping between a workspace role and the Lakehouse's built-in DefaultReader OneLake role seems to work reliably for individual users, but is hit-or-miss when the principal is a security group. That would also explain why the SQL endpoint shows up fine (it follows the workspace layer) while the Lakehouse item itself doesn't (it follows the OneLake layer).

    So I'd treat your workspace assignment as correct, but also open the Lakehouse, click Manage OneLake data access (preview) in the ribbon, pick the DefaultReader role, and add your Entra group as a member there explicitly. Give it a few minutes to propagate (the Lakehouse sharing doc mentions permission updates can take up to two hours in some cases). In our case that was enough to make the Lakehouse visible to all group members without falling back to per-user assignments.

    On the API side, I'm not aware of a public REST endpoint equivalent to /items/{itemId}/users for this specific Lakehouse permission layer, and the microsoft/fabric Terraform provider doesn't expose OneLake role membership yet either. So full automation is still limited today a null_resource with local-exec is probably the cleanest stopgap if you really need everything in Terraform.

    If this reproduces consistently for you even after touching DefaultReader, it's worth raising as a product issue. The current behavior is genuinely confusing even when you understand the security model, and the more people flag it the better the chances it gets smoothed out.

     

    Hope that helps!

     

    References 

     

     

     

     

  • rizalard0684's avatar
    rizalard0684
    3 months ago

    hey charlesdata this does not appear to be an expected behavior to me. And my guess is it’s most likely a Fabric platform limitation or bug around group‑based principals, rather than an issue with your Terraform configuration.

     

    Microsoft Fabric docs states that workspace roles (including Admin) can be assigned to users or security groups, and that Admins should be able to see and manage all workspace items, including Lakehouses. There is no documented distinction where group‑assigned Admins should have reduced visibility compared to individually assigned Admins. https://learn.microsoft.com/en-us/fabric/data-engineering/workspace-roles-lakehouse
    The fact that group‑based Admins can see the workspace, can see the SQL endpoint but cannot see the Lakehouse item suggests incomplete permission materialization for Lakehouse items when the principal is a group, not an intentional design decision.

     

    There is strong supporting evidence that this is a known and ongoing issue, especially when resources are provisioned via Terraform. 

    A Terraform provider issue documents Lakehouse items intermittently not being visible to group principals, including Admins, with recreation of role assignments temporarily fixing it. https://github.com/microsoft/terraform-provider-fabric/issues/735

    Multiple community threads report Lakehouse visibility inconsistencies specifically tied to group‑based role assignment timing relative to Lakehouse creation. https://community.fabric.microsoft.com/t5/Data-Engineering/Is-it-expected-group-based-workspace-Admins-cannot-see-lakehouse/m-p/5178290

     

    A key pattern in those reports:

    1. Workspace role assignments are created close in time to Lakehouse creation
    2. Group memberships are not immediately resolved for Lakehouse item ACLs
    3. SQL endpoints remain visible, but Lakehouse items do not

    So this matches your reproduction steps.

     

    As of now There is no supported Fabric REST API to directly grant Lakehouse item permissions to users or groups. Endpoints like /items/{id}/users returning 404 is consistent with current platform limitations

     

    Item‑level permissions are internally managed and can be inspected via Fabric Portal Fabric CLI (ACL inspection only, not provisioning). Terraform currently cannot explicitly correct item‑level ACLs post‑creation.

     

    Unless Microsoft addresses this "product bug", I would recommend assign workspace roles directly to users (what you already do) or delay role assignments until after Lakehouse creation (sometimes helps, but not guaranteed).

     

    Appreciate if you can 'Kudos' and/or 'Accept as Solution' if this answered your query.

4 Replies

  • Tamanchu's avatar
    Tamanchu
    Super User
    3 months ago

    Hi charlesdata,

     

    I ran into a very similar situation a while ago, so I wanted to share what we found.

    What you're seeing looks less like a Terraform issue and more like the way Fabric splits workspace permissions from OneLake/Lakehouse data access. Workspace roles can be assigned to users or security groups, but Lakehouse access is governed separately through OneLake security and Lakehouse sharing the Permission model doc lays out the layers if you want the official version.

    In practice, that means a group being workspace Admin doesn't always produce the same Lakehouse item visibility you get with a directly assigned user. From what we observed, the auto-mapping between a workspace role and the Lakehouse's built-in DefaultReader OneLake role seems to work reliably for individual users, but is hit-or-miss when the principal is a security group. That would also explain why the SQL endpoint shows up fine (it follows the workspace layer) while the Lakehouse item itself doesn't (it follows the OneLake layer).

    So I'd treat your workspace assignment as correct, but also open the Lakehouse, click Manage OneLake data access (preview) in the ribbon, pick the DefaultReader role, and add your Entra group as a member there explicitly. Give it a few minutes to propagate (the Lakehouse sharing doc mentions permission updates can take up to two hours in some cases). In our case that was enough to make the Lakehouse visible to all group members without falling back to per-user assignments.

    On the API side, I'm not aware of a public REST endpoint equivalent to /items/{itemId}/users for this specific Lakehouse permission layer, and the microsoft/fabric Terraform provider doesn't expose OneLake role membership yet either. So full automation is still limited today a null_resource with local-exec is probably the cleanest stopgap if you really need everything in Terraform.

    If this reproduces consistently for you even after touching DefaultReader, it's worth raising as a product issue. The current behavior is genuinely confusing even when you understand the security model, and the more people flag it the better the chances it gets smoothed out.

     

    Hope that helps!

     

    References 

     

     

     

     

    • v-menakakota's avatar
      v-menakakota
      Community Support
      3 months ago

      Hi charlesdata  ,
      Thanks for reaching out to the Microsoft fabric community forum. 


      I would also take a moment to thank  Tamanchu  , for actively participating in the community forum and for the solutions you’ve been sharing in the community forum. Your contributions make a real difference. 
      I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you.

      Best Regards, 
      Community Support Team

      • v-menakakota's avatar
        v-menakakota
        Community Support
        3 months ago

        Hi charlesdata ,

        I hope the above details help you fix the issue. If you still have any questions or need more help, feel free to reach out. We’re always here to support you.

        Best Regards, 
        Community Support Team

  • rizalard0684's avatar
    rizalard0684
    Resolver III
    3 months ago

    hey charlesdata this does not appear to be an expected behavior to me. And my guess is it’s most likely a Fabric platform limitation or bug around group‑based principals, rather than an issue with your Terraform configuration.

     

    Microsoft Fabric docs states that workspace roles (including Admin) can be assigned to users or security groups, and that Admins should be able to see and manage all workspace items, including Lakehouses. There is no documented distinction where group‑assigned Admins should have reduced visibility compared to individually assigned Admins. https://learn.microsoft.com/en-us/fabric/data-engineering/workspace-roles-lakehouse
    The fact that group‑based Admins can see the workspace, can see the SQL endpoint but cannot see the Lakehouse item suggests incomplete permission materialization for Lakehouse items when the principal is a group, not an intentional design decision.

     

    There is strong supporting evidence that this is a known and ongoing issue, especially when resources are provisioned via Terraform. 

    A Terraform provider issue documents Lakehouse items intermittently not being visible to group principals, including Admins, with recreation of role assignments temporarily fixing it. https://github.com/microsoft/terraform-provider-fabric/issues/735

    Multiple community threads report Lakehouse visibility inconsistencies specifically tied to group‑based role assignment timing relative to Lakehouse creation. https://community.fabric.microsoft.com/t5/Data-Engineering/Is-it-expected-group-based-workspace-Admins-cannot-see-lakehouse/m-p/5178290

     

    A key pattern in those reports:

    1. Workspace role assignments are created close in time to Lakehouse creation
    2. Group memberships are not immediately resolved for Lakehouse item ACLs
    3. SQL endpoints remain visible, but Lakehouse items do not

    So this matches your reproduction steps.

     

    As of now There is no supported Fabric REST API to directly grant Lakehouse item permissions to users or groups. Endpoints like /items/{id}/users returning 404 is consistent with current platform limitations

     

    Item‑level permissions are internally managed and can be inspected via Fabric Portal Fabric CLI (ACL inspection only, not provisioning). Terraform currently cannot explicitly correct item‑level ACLs post‑creation.

     

    Unless Microsoft addresses this "product bug", I would recommend assign workspace roles directly to users (what you already do) or delay role assignments until after Lakehouse creation (sometimes helps, but not guaranteed).

     

    Appreciate if you can 'Kudos' and/or 'Accept as Solution' if this answered your query.