Red 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.