Office 365: Users or guest accounts cannot access resources due to risk assigned

Leave a reply

Organizations may configure conditional access policies that evaluate if users are at risk when accessing resources hosted in Office 365. There are a variety of risks that can be assigned to users that may impact their ability to access resources.

 

For information regarding risk assignment and detection see What is risk? Azure AD Identity Protection – Microsoft Entra | Microsoft Learn.

 

For information regarding conditional access application to risk see Sign-in risk-based multifactor authentication – Azure Active Directory – Microsoft Entra | Microsoft Learn.

 

When risk has been identified on a user and conditional access applied this may result in the user being blocked. Users may receive a message during the authentication process stating

“We’ve detected suspicious activity on your account. Sorry, the organization you are trying to access restricts at-risk users. Please contact your …”

 

When users receive this message there is also an associated entry in the Azure Sign In Logs that shows the sign on failure and that risk was the reason the sign on was blocked. It’s important to note that risk application can either be in the tenant where the user resides or when the user is accessing resources in another tenant based on a guest invitation.

 

I’ve recently worked some investigations where users were being blocked from signing into guest tenants. When reviewing the Azure sign in logs of the home tenant we were able to validate that the block occurred in the home tenant due to risk being assigned. What we were not able to do was locate this user as a risky user. The tenant that hosted the account did not have conditional access policies that evaluated risk only the tenant hosting the guest resource was evaluating risk. There are several options to remediate risk assigned to a user one of them being administrator dismissal of risk. Unfortunately, that was not possible because the user was not showing as having any risk assigned in the Azure portal. (For information on remediating risk see Remediate risks and unblock users in Azure AD Identity Protection – Microsoft Entra | Microsoft Learn)

 

Why was a user blocked for risk yet not showing as a risky user? As we continued our investigation, we discovered that the risk that was assigned to the user was assigned in December of 2020. As there were no conditional access policies previously evaluating risk there was never an identification of risk. As risk continued to develop in Azure there were essentially two risk platforms. For simplicity I’ll refer to it as V1 risk and V2 risk. The current risk platform is the V2 risk platform. Users that are assigned risk detections today are assigned under the V2 platform and our management tools display this information. In this case the risk assigned to the user was assigned under the V1 platform and is not immediately discoverable in our tools. I will note that having V1 risk assigned to users is not something that is common but could happen and result in access denied to resources being assigned risk administrators cannot see.

 

How do you fix this? Fortunately, administrators have access to a set of tools for dismissing user risk via the Microsoft Graph API. The tools may be located here GitHub – AzureAD/IdentityProtectionTools: Sample PowerShell module and scripts for managing Azure AD Identity Protection service. The following instructions outline how to utilize the tools.

 

  • Prepare MS Graph
    • Open powershell as administrator.
    • Execute install-module Microsoft.Graph.Authentication (this assumes that the full Microsoft.Graph module is not already installed)
    • Execute install-module Microsoft.Graph.Identity.SignIns (this assumes that the full Microsoft.Graph module is not already installed)
    • Execute install-module Microsoft.Graph.Users (this assumes that the full Microsoft.Graph module is not already installed)
    • Execute $scopes = @(“Identity.RiskyUser.ReadWrite.All”,”IdentityRiskyUser.Read.All”,”User.Read.All”)
    • Execute Connect-MGGraph -scopes $scopes
      • At this point you may be prompted to consent to this applications use and permissions.
      • It may be possible you do not have rights to do this and may have to have someone perform consent on your behalf.
      • This is required to establish the MSGraph permissions necessary to complete this work.
  • Prepare the Identity Protection Module
    • Download the code zip file from the GitHub repository.
    • Expand the zip file to a folder.
    • Navigate to the extracted folder \ src \ modules \ IdentityProtectionTools with Powershell.
    • Run unblock-files * to remove any restrictions on downloaded Powershell files.
    • Run import-module IdentityProectionTools.psd1
  • Revoke User Risk
    • In order to revoke user risk you must have the object IDs of the users to revoke. An example search via user principal name:
      • Get-MGUser -search ‘”UserPrincipalName:user@domain.com”‘ -consistencyLevel eventual
      • The ID column lists the object ID of the user.
    • Create an array of users to revoke risk.
      • $users = @()
      • $users += “ID1”
      • $users += “ID2”
      • If only a single user there is only a single add to the array creating an array of 1 users.
    • Revoke the risk assigned to the users.
      • Invoke-AzureADIPDismissRiskyUser -userIDs $users

This will perform a risk dismissal on one or more users. After dimissing risk the user should wait 30 minutes before attempting the sign on again. If the sign on is still unsuccessful due to risk assignment and the risk cannot be otherwise located or remediated in the Azure portal please open a case with support for assistance.

Leave a comment