Forum Discussion
Helper IIRed Flag in SQL Analytics EndPoint - User Identity Access Mode
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.
Community ChampionHi 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.
Helper IIHi 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.