Red Flag in SQL Analytics EndPoint - User Identity Access Mode

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.