This time we will have a closer look at Identity Protection and possible impact for guest users (B2B collaboration users).
So in order to test this out we will create a Identity protection user risk policy requiring all users to change password if there risk is calculated to medium or higher (tenant A):
In this test we will use a guest user in another tenant (tenant B). The guest has been invited to tenant A earlier and access has been tested and confirmed working.
For the test to work our test user (testrisk) now has a calculated risk level of medium in tenant B even though Identity Protection is not enabled in tenant B only in tenant A.
We need to know that the user risk for B2B collaboration users is evaluated at their home directory.
Now if we try to access for example a Microsoft team in tenant A from our risky user in tenant B we will see this information:
Your account is blocked.
We’ve detected suspicious activity on your account.
If we check the sign-ins on tenant A we can see that the user is blocked due to risk on home tenant.
There are well documented limitations in the implementation of Identity Protection for B2B collaboration users in a resource directory due to their identity existing in their home directory. The main limitations are as follows:
- If a guest user triggers the Identity Protection user risk policy to force password reset, they will be blocked. This block is due to the inability to reset passwords in the resource directory.
- Guest users do not appear in the risky users report. This limitation is due to the risk evaluation occurring in the B2B user’s home directory.
- We cannot dismiss or remediate a risky B2B collaboration user in their resource directory. This limitation is due to administrators in the resource directory not having access to the B2B user’s home directory.
So if a risky B2B user in our directory is blocked by your risk-based policy, the user will need to remediate that risk in their home directory.
Users can remediate their risk by performing a secure password reset in their home directory.
If they do not have self-service password reset enabled in their home directory, they will need to contact their own organization’s IT Staff to have an administrator manually dismiss their risk or reset their password.
This guest user also has access to a ASP.NET Core web app with B2B sign-in enabled, testing this application we get the same error: Your account is blocked.
The shown behavior is not always what we would like to see, and luckily we have several options to fix the issue.
In this example we will simply exclude all guests from Identity protection.
First we create a new dynamic group with all guests using this rule:
(user.objectId -ne null) and (user.userType -eq “Guest”)
Then we exclude our new group (ALL_Guests) from our User risk policy:
And after this change we can again access our ASP.NET Core web app with B2B sign-in enabled:
You can find the app used here: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-aspnet-core-webapp
Remember to change appsettings.json to only use Accounts in this organizational directory only.
Finally by excluding our guest from Identity protection, we can fine grain this even more using conditional access.
As an example we can do User risk policies targeting selected guests, selected applications and have different risk levels accepted.
We can also change the the behavior so that guests with a calculated risk set in there home directory are forced to do MFA instead of forcing them to do a password reset ending in a block condition.
Please remember that Identity protection is an Azure AD P2 feature.
That’s it for now. Happy testing!
As always if you have any questions regarding this topic, feel free to reach out to us.
