Forum Discussion
Helper IIRed 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?
Hi stellahe102,
Yes, I think your Legal/Marketing example is exactly where the current 1:1 requirement becomes important, and I would refine my earlier wording slightly.
I would not grant the Marketing group access to the Legal downstream lakehouse simply to remove the warning if that group is not supposed to consume that spoke. That would work against the least-privilege model you are trying to implement.
The current SQL analytics endpoint OneLake security documentation describes the 1:1 rule as an identity-mapping requirement when security policies are carried from a producer to a consumer through a shortcut. The exact same principal/Object ID referenced by the producer OneLake role must also have Fabric Read on the consumer; nested or effective group membership is not resolved across that boundary.
So I would separate two concepts:
- Who should consume LH2 - your Legal group only.
- What the User's identity security-sync process expects to map from LH1 - the literal principals represented in the producer OneLake security configuration
Microsoft's OneLake security best-practice guidance still recommends least privilege and downstream/domain-specific workspaces, so I don't think the right architectural response is to mirror every hub business group into every spoke.What you are seeing is consistent with the SQL endpoint security-sync process attempting to translate and validate the producer OneLake security definitions against the consumer. The documentation explains the 1:1 requirement, but I haven't found Microsoft documentation stating that an unrelated producer principal should be granted access to every downstream consumer purely to make those sync warnings disappear.
That also explains why I would be cautious about treating the red flag itself as proof that the user should have LH2 access, particularly since you have confirmed that the intended users can still query successfully.
One thing I would still verify is the Entra group type. Microsoft currently supports normal security groups here, but mail-enabled security groups and distribution lists are listed as unsupported. Since you have reproduced the warning with individual users as well, though, that clearly wouldn't explain the complete behaviour you are observing.
For a strict hub-and-spoke design where Legal and Marketing must have independent downstream audiences, I would keep those consumer permissions separate rather than granting cross-business access just to satisfy the warning. If the 1:1 sync requirement prevents that cleanly, I would treat that as a current limitation of this User's identity + shortcut pattern and raise the specific reproduction with Microsoft.
There is also a delegated shortcut authentication model specifically intended for scenarios where downstream permission management needs to be separated from the source, although whether that fits here depends on the OneLake RLS/CLS policies you need at LH1.
So yes - I agree with your concern. In your Legal/Marketing example, I would not give Marketing access to the Legal spoke merely to clear a security-sync warning.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
7 Replies
v-achippaCommunity Support
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
stellahe102Hi 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?
- v-achippa
Hi stellahe102,
Thank you for reaching out to Microsoft Fabric Community.
Thank you ShivekMaharaj for the prompt response.
As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa - v-achippa
Hi stellahe102,
We wanted to kindly follow up to check if the solution provided by the user for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa - ShivekMaharaj
Community Champion
Hi stellahe102,
Your follow-up raises an important distinction.
Microsoft's current SQL analytics endpoint OneLake security documentation now explicitly documents a 1:1 identity-mapping requirement for hub-and-spoke shortcut scenarios using User's identity mode.
If a OneLake security role on the producer references Group A, that exact Entra group/Object ID must also have Fabric Read permission on the consumer Lakehouse. Granting access only to individual members of Group A does not satisfy the mapping.
So that explains why LH2's security sync is validating principals originating from LH1.
However, I would check one thing before granting the source Contributor group access to LH2.
If that group is only a workspace Contributor on LH1 and is not actually referenced by a OneLake security role, I would first identify why it is being propagated. Microsoft's OneLake security model notes that Admins, Members and Contributors already receive elevated data access through their workspace permissions and aren't normally dependent on reader roles in the same way as Viewers.
I would therefore inspect Manage OneLake security → Members in role on LH1 and check whether the group appears in DefaultReader, another custom role, or through virtual/default membership.
I would also verify the Entra group type. Microsoft's current SQL endpoint documentation lists mail-enabled security groups and distribution lists as unsupported, and User principal is not supported is also a documented security-sync error for principals Fabric cannot resolve correctly.
From a design perspective, if those LH1 power users should never consume LH2, I would prefer:
- keep them as Contributors on LH1 for their source access;
- avoid including them in the producer OneLake role used for downstream shortcut consumption;
- create explicit source OneLake roles for the actual LH2 consumer groups;
- grant those same consumer principals Read on LH2 to satisfy the documented 1:1 mapping.
That keeps the source administration population separate from the downstream consumption population rather than granting every LH1 user access to the curated Lakehouse.AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- stellahe102
Hi ShivekMaharaj Thanks for the details. In a hub-spoke security model, why would the users/group in the hub be 1:1 to the spoke (downstream customerized)? say, i have legal team and marketing team's access centralized in the hub lakehouse, and in legal team's lakehouse, why should market team be granted access?
we are observing the error in original thread in our use case, not sure if you have implemented the similar things with actual scenarios.
- ShivekMaharaj
Hi stellahe102,
Yes, I think your Legal/Marketing example is exactly where the current 1:1 requirement becomes important, and I would refine my earlier wording slightly.
I would not grant the Marketing group access to the Legal downstream lakehouse simply to remove the warning if that group is not supposed to consume that spoke. That would work against the least-privilege model you are trying to implement.
The current SQL analytics endpoint OneLake security documentation describes the 1:1 rule as an identity-mapping requirement when security policies are carried from a producer to a consumer through a shortcut. The exact same principal/Object ID referenced by the producer OneLake role must also have Fabric Read on the consumer; nested or effective group membership is not resolved across that boundary.
So I would separate two concepts:
- Who should consume LH2 - your Legal group only.
- What the User's identity security-sync process expects to map from LH1 - the literal principals represented in the producer OneLake security configuration
Microsoft's OneLake security best-practice guidance still recommends least privilege and downstream/domain-specific workspaces, so I don't think the right architectural response is to mirror every hub business group into every spoke.What you are seeing is consistent with the SQL endpoint security-sync process attempting to translate and validate the producer OneLake security definitions against the consumer. The documentation explains the 1:1 requirement, but I haven't found Microsoft documentation stating that an unrelated producer principal should be granted access to every downstream consumer purely to make those sync warnings disappear.
That also explains why I would be cautious about treating the red flag itself as proof that the user should have LH2 access, particularly since you have confirmed that the intended users can still query successfully.
One thing I would still verify is the Entra group type. Microsoft currently supports normal security groups here, but mail-enabled security groups and distribution lists are listed as unsupported. Since you have reproduced the warning with individual users as well, though, that clearly wouldn't explain the complete behaviour you are observing.
For a strict hub-and-spoke design where Legal and Marketing must have independent downstream audiences, I would keep those consumer permissions separate rather than granting cross-business access just to satisfy the warning. If the 1:1 sync requirement prevents that cleanly, I would treat that as a current limitation of this User's identity + shortcut pattern and raise the specific reproduction with Microsoft.
There is also a delegated shortcut authentication model specifically intended for scenarios where downstream permission management needs to be separated from the source, although whether that fits here depends on the OneLake RLS/CLS policies you need at LH1.
So yes - I agree with your concern. In your Legal/Marketing example, I would not give Marketing access to the Legal spoke merely to clear a security-sync warning.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.