Forum Discussion

stellahe102's avatar
stellahe102
Icon for Helper II rankHelper II
1 day ago

Red Flag in SQL Analytics EndPoint - User Identity Access Mode

We are seeing some red flags when switching the default access mode "Delegated" to ""User's Identity" in a SQL Analytics EndPoint of lakehouse, but seeing red flags with message not relevant to the user who were given access to downstream lakehouse, below is the details. 

Current Configuration:

LH1 is in the hub workspace/WS1 with Onelake security role where users were added. In the user workspace/WS2, a shortcut to LH2 the source data is created, user can access through LH2’s SQL Analytics Endpoint, data access mode is switched to User’s Identity, so that source lakehouse's security role control access fully.

In SQL End, there are some red flags as below, but user can access data without issue, which is confusing:

error details: User principal is not supported.

Issue: 

Error details is specifically for an AD group which is a workspace contributor role in the source workspace role (default reader of all tables in the source lakehouse), and it doesn't have access to the user's lakehouse. 

Question:

Does anyone see the same?  or it's a known issue?

 

 

 

 

one lake
security

2 Replies

  • v-achippa's avatar
    v-achippa
    Icon for Community Support rankCommunity Support
    22 hours ago

    Hi stellahe102​,

    Thank you for reaching out to Microsoft Fabric Community.

    The warning is caused by the source DefaultReader group not being mapped to the downstream lakehouse.

    Please grant the same DefaultReader group Read permission on LH2 and then run Metadata sync. Keep the User's identity access mode enabled.

    If the warning still appears after the sync, please verify that DefaultReader is a standard Microsoft Entra security group and not a mail enabled security group or distribution list.

    Thanks and regards,
    Anjan Kumar Chippa

    • stellahe102's avatar
      stellahe102
      Icon for Helper II rankHelper II
      19 hours ago

      Hi v-achippa​ thanks for your reply! if you don't mind, some follow-up questions:

      The DefaultReader group is inherited from the source Lakehouse (LH1) and should not need to be granted access again in the downstream Lakehouse (LH2), as we need to maintain curated access group in the downstream workspace.

      From a design perspective, why would central/power users who already have access to the source Lakehouse need to be explicitly added to the consumer's Lakehouse (LH2)?

      We also performed additional testing and found that the issue is not limited to AD groups. The error message references any user or group from other business group that has access to the same table in the source Lakehouse (LH1) prior to LH2, we cannot give access to those users who are not intended consumers of LH2

      Can you help explain why LH2 validates or checks access assignments that exist in the source Lakehouse (LH1)? What is the relationship between the downstream Lakehouse and the source Lakehouse's user/group permissions that causes those source-level user/group to appear in the error message?