hands-on evaluation of the AAD cross-tenant conditional access for guests marked as high-risk by Identity Protection

[tkol2022]

💡 Summary

We received a comment from an Azure AD subject matter expert suggesting to create a new baseline policy related to 2.2 "High Risk Users SHALL Be Blocked". The suggestion was to create a new access policy directly in Azure Identity Protection (in addition to the conditional access policy) that will also block high risk users. The reviewer suggested that conditional access policies do not apply to users when they are outbound guests to another organization's AAD.

The scope of this issue is to prototype this specific usage scenario and also experiment with the suggested new policy. The output from this exploration could lead to a new baseline policy. Reference comment in the matrix for details.

This maps to comment 4 in the adjudication matrix.

Implementation notes

• Design a scenario including designation of a test user account to examine how the conditional access policies are applied for a guest user when accessing an external Resource tenant. Make sure the trust settings are configured between the tenants to facilitate access.
• When a guest users is marked as High Risk in their home tenant, can the user still be granted access to an external Resource tenant?
• If the answer to the previous question is yes, then create a new Azure Identity Protection block policy as suggested by the reviewer and test again. After the new policy is created, can the High Risk user access the external Resource tenant?

[schrolla]

Discuss with Microsoft to determine direction of protections.

[tkol2022]

@gdasher @mitchelbaker-cisa
I researched into this item today. Microsoft states that customers should migrate to Conditional Access instead of using the Identity Protection service to define risk policies. They also state that the policies in Identity Protection will be retired. Therefore I don't think it makes sense to define new baseline policies based on a feature that is planned to be retired. If you agree I will close this one out.
https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies#migrate-risk-policies-to-conditional-access

[tkol2022]

Ping @gdasher @mitchelbaker-cisa

[mitchelbaker-cisa]

Concur we can close this specific issue out due to the underlying feature being retired. As a follow up @tkol2022 can we confirm the validity of the reviewer's statement, "conditional access policies do not apply to users when they are outbound guests to another organization's AAD." If false this may fall under #754 as an additional todo.

[tkol2022]

Concur we can close this specific issue out due to the underlying feature being retired. As a follow up @tkol2022 can we confirm the validity of the reviewer's statement, "conditional access policies do not apply to users when they are outbound guests to another organization's AAD." If false this may fall under #754 as an additional todo.

That statement is likely true because as far as I know conditional access policies protect the tenant in which they are defined when users try to access that tenant. I am not aware of conditional access policies affecting external tenants. There is a way to restrict users to only be able to access specific external tenants (in a whitelist) which many agencies likely use but that is in a completely different configuration portal than conditional access.

754 is about a different topic. Issue #754 is scoped to ensure that our policy checks examine all configuration fields of a conditional access policy and not just some of them (as our current Rego code does). This is to ensure the policies are precise enough so that they catch configurations that would affect the scope of the policy enforcement and therefore not achieve the goal of the baseline policy. For example, if an agency create a policy that requires phishing-resistant MFA, but only scoped it to laptops, that means that users could access the system without MFA from a mobile device.

[gdasher]

yes, lets go ahead and close this issue.