With Microsoft Identity Protection you have the ability to know which of your users are at risk and (automatically) remediate. Except for guest users (this statement isn’t entirely true, but I’ll explain that later in this blog), as they don’t show up in your reports. So, how do you know which of your guest users have a user risk and how do you protect them, if they are at risk, from accessing your resources? Let’s discuss user risk for guests.
When you navigate to Identity Protection and Risky Users in Microsoft Entra, you’ll get an overview of all users with detected risks. The number of users displayed depends on the filter you apply. By default, only users with medium and high risk are shown.
This list doesn’t show all of your guest users of which a risk is detected. As you can see in below image, the risky user report (an export of all risky users), shows some guest users. You can recognize them based on the #EXT# in their username and in this case I’ve exported all users with a risk level of Low, Medium and High.
This report shows 9 unique guest users with a risk level of Low and Medium. It doesn’t show any guest users with a High risk level. But I know there are some, because I’ve setup and configured a Conditional Access policy in report-mode that blocks access for guest users with a high risk level.
The policy is configured as follow:
Name: CA0404-Guests-IdentityProtection-AllApps-AnyPlatform-BlockforHighUserRisk
Users: Guest or external users
Target Resources: All
Conditions: Users Risk - High
Grant: Require MFA, Require secure Password Change - Require all of the selected controls
Session: Sign-in frequency: Every time
Enable Policy: Report-OnlyPutting the policy in Report-Only mode gives me the ability to look at the effects of this policy without it blocking access for any guest users in case a High Risk Level is detected.
When I take a look at Insights and Rerporting to the effect of this policy over the past 14 days, I see that this policy would’ve been applied (failed) 11 times.
So we can conclude that, within the same tenant, there are at least 11 unique guest users detected with a High Risk level that doesn’t show up in the Risky Users report. What is going on here?
The explanation is that it depends entirely on where the Risk Level is calculated for the guest user. If a guest user is homed in a Microsoft tenant, the calculation of the Risk is held within the home tenant and passed through to the resource tenant at the moment of a sign-in. Therefore, you won’t see them in your Risky Users report. Microsoft tells you that here: Microsoft Entra ID Protection for B2B Users – Microsoft Entra ID Protection | Microsoft Learn
The claim “guest users do not appear in the risky users report” is a bit misleading as it is only subjected to guest users that are homed in a Microsoft tenant.
If the guest user isn’t present in a Microsoft tenant, the calculation occurs in the resource tenant, your tenant. Those guest users will show up in the Risky Users report. That makes perfect sense because for Identity Protection to work, the calculation must be performed somewhere. And if it can’t be calculated at the home location of the guest user, it will be calculated in the resource tenant.
Below table shows the different origins (Identities property value) of a guest user and where the Risk is being calculated:
| Identities property value | Sign-in state | Risk Calculation | Alert and report |
|---|---|---|---|
| ExternalAzureAD | This user is homed in an external organization and authenticates by using a Microsoft Entra account that belongs to the other organization. | Home tenant | No |
| Microsoft account | This user is homed in a Microsoft account and authenticates by using a Microsoft account. | Microsoft | No |
| {host’s domain} | This user authenticates by using a Microsoft Entra account that belongs to this organization. | Home tenant | No |
| This user has signed up by using Microsoft Entra External ID email one-time passcode (OTP). | Resource tenant | Yes | |
| {issuer URI} | This user is homed in an external organization that doesn’t use Microsoft Entra ID as their identity provider, but instead uses a Security Assertion Markup Language (SAML)/WS-Fed-based identity provider. The issuer URI is shown when the Identities field is clicked. | Couldn’t test1 | Yes |
When will you get an alert in case of an risky guest user?
Microsoft Entra Identity Protection offers the option to alert someone when a user at risk is detected. I attempted to simulate user risk using an ExternalAzureAD guest user, but as far as I could test, no notifications were sent. The setting I used is:
At first glance there were risk detected but no notifications:
To simulate risk I followed the steps mentioned here: Simulate Risk Detections in Microsoft Entra ID Protection for Enhanced Security.
Organizations should be aware of this behavior, as the setting creates the impression that you will be notified if any user risk is detected, including risks involving guest users.
So, why is that? Why don’t you get to see those risky guest users? Let’s perform some tests to see what happends. I’ve got three test users. One guest with the Identity Property Value “ExternalAzureAD”, one with “Microsoft Account” and one with “Mail”. The first is bor.munter@365nerd.nl, the second is an Outlook account and third is a burner mailaddress called tmhazeybsakafgyypd@xfavaj.com.
For bor.munter@365nerd.nl I can see the following happen:
- The risk is calculated at the home tenant and there the user is marked as risky:
- In the resource tenant nothing shows that the user is at risk:
- If you have a user risk policy defined, it will detect it and, if enabled, enforce a block:
- When you go to ‘view details’ in the resource tenant, you’ll find nothing:
And thus, nobody will be informed.
As a result, the guest user will probably call his contact person who on his turn, will call your IT department to solve the issue. But the challange here is that your administrators can’t remediate the risk. That should happen in the home tenant of the guest user, he/she should call his/hers own IT department. Once the risk level is lowered / remediated, the guest user can access the resources again.
For the Outlook account, some strange behaviour occurs when I try to simulate user risk (anonymously using a Tor browser). The page for multifactor authentication simply doesn’t load:
I’ve tried multiple times from multiple devices and locations but couldn’t succeed. Obviously Microsoft does something here which detects and prevents further action from the user.
If you can’t perform MFA, you don’t even hit any conditional access policies and no sign-in event is logged. Therefore, you wont be notified in case of a risky Microsoft Account user.
The mail guest user got interesting! As this is a temporary account without a tenant, the risk is calculated in the resource tenant. After simulating anonymously sign-in, the sign-in attempt got blocked:
As a result, the user was marked as risky:
I even got an alert! 🥳
This confirms my assumption that the risk calculation of these kind of guest users are performed at the resource tenant.
How do I protect my tenant against risky guest users?
By implementing User and Sign-in risk Conditional Access Policies.
To protect all your guest users against sign-in risk, configure the following policy:
Name: CA0403-Guests-IdentityProtection-AllApps-AnyPlatform-MFAforHighSignInRisk
Users: Include: Guest and external users - Exclude: Emergency Access Accounts
Target Resources: All
Conditions: Sign-in Risk - High
Grant: Require MFA - Require all of the selected controls
Session: Sign-in frequency: Every time
Enable Policy: OnAs a result, everytime a sign-in risk is detected, the guest user will need to perform multi-factor authentication. Ideally, you want to force a phishing-resistant mfa method.
To protect all your guest users against user risk, configure the following policy:
Name: CA0404-Guests-IdentityProtection-AllApps-AnyPlatform-BlockforHighUserRisk
Users: Include: Guest and external users - Exclude: Emergency Access Accounts
Target Resources: All
Conditions: Users Risk - High
Grant: Require MFA, Require secure Password Change - Require all of the selected controls
Session: Sign-in frequency: Every time
Enable Policy: OnAs a result, everytime a user risk is detected, access will be blocked for the guest user as a password change is, obviously, not an option.
As mentioned, risky guest users will need to remediate the risk at their home tenant. Except for guest users with the Identities Property Value ‘mail’ and {issuer URI}. For these users the administrator will need to define what to do:
If you have Workspace analytics and Insights and reporting enabled , you’ll be able to inventory how often these policy hit and whom is at risk.
- I assume that as long as there is no Microsoft tenant, the risk calculation occurs in the resource tenant, so it will appear in the risky user report, and you will be notified if a risk is detected. ↩︎