Group membership not working for permissions assignment

[bryanhart73]

Running latest binary version. The user authenticates successfully in an interactive browser login, and authorization works if added directly to a site but gets redirected to the standard access denied page if part of a AAD group.

1. Tried both with and without a group claim set in AAD.
2. Augmentation is enabled and works correctly for "Check permissions" operations in _layouts/user.aspx

It's not entirely clear from the documentation how this is supposed to work. We are long time LDAPCP users but this is our first attempt with AzureCP. In LDAPCP if there are no group claims coming from the authentication provider, augmentation works for group authorization with both interactive login and "offline" (workflow, permissions checks, etc.) authorization requests. Is that how AzureCP is intended to work as well, or is it required to use group claims for interactive logins?

[Yvand]

@bryanhart73 it should work in the same way as LDAPCP. Here is what you need to validate:

• As your tests suggest, it is not mandatory that AAD includes the group membership, but it doesn't hurt if it does.
• One important thing is that (for good reasons) AzureCP uses the group ID as the value (not the group name)
• If check permissions work, it is very unexpected that interactive sign-in does not work, unless augmentation actually fails somehow.

Can you check the SharePoint logs when a user signs-in, and filter on producft/area "AzureCP" (and optionally on category "Augmentation") to see what happens ?

[bryanhart73]

Dug in more deeply and it appears the augmentation requests at sign in are being blocked by a Conditional Access policy in Azure but those done during Check Permissions are not. Are there any differences in the requests that might explain that? What appears in the logs makes the requests look identical.

[Yvand]

There is really no difference (except the process where it runs), both use exactly the same code path.
How do you know that the request is denied due to conditional access? It was my understanding that it applies only to user authentication, not apps

[bryanhart73]

The AzureCP log entries in the ULS make a specific mention of them. The environment in question has a conditional access policy in place that restricts by source IP (against a list of their outbound proxy servers). I think we have it traced down to the fact those 2 operations ended up using different outbound IPs and one of those is missing in the allow list. Waiting for the IT group that controls that configuration to config and fix as needed.

Closing this issue, will reopen later if we find anything pointing to there being a problem in AzureCP itself. Thanks for the responses.