Handling user risk can be a difficult task, especially today when users are based all across the globe and identity-based attacks are on the increase. Organisations need to have an understanding of the risks present to them and visibility in real-time of how it is impacting them.
All of this of course comes as a burden to your IT or security teams who have to field off and remediate these risks, so by putting some responsibility back to the end user, we can help alleviate this burden.
By enabling users to remediate risk associated with their account by resetting their on-premises password we can reduce the administrative burden and simply the process as a whole. Generally, it is easier for a user to reset their password locally (when possible) than to follow the password reset process in the cloud.
Understanding resetting user risk in Microsoft Entra
Risks are detected in Microsoft Entra when suspicious actions are performed by users either at the sign-in (known as a sign-in risk) or after the user is signed in (known as a user risk). Different actions by the users during or after sign-in contribute to different levels of risk, usually based on the likelihood that the user account is compromised.
Depending on an action, or a combination of different actions performed by the user, the risk level is automatically updated in Microsoft Entra. You can view the risk from within the Microsoft Entra Admin Center:
- Log in to Microsoft Entra
- Expand Protection
- Select Risky activities
From here you can see a list of risky users and the associated risk level.
When Microsoft Entra calculates the risk based on the action a user has performed, some of these risks are calculated in real-time (as they are happening) and some are calculated offline (after the event has happened), this is dependent on the type of the event, which have been listed in the below tables.
Sign-in risk detections
| Risk detection | Detection type | Type |
|---|---|---|
| Atypical travel | Offline | Premium |
| Anomalous Token | Offline | Premium |
| Token Issuer Anomaly | Offline | Premium |
| Malware linked IP address | Offline | Premium |
| Suspicious browser | Offline | Premium |
| Unfamiliar sign-in properties | Real-time | Premium |
| Malicious IP address | Offline | Premium |
| Suspicious inbox manipulation rules | offline | premium |
| Password spray | offline | premium |
| Impossible travel | offline | premium |
| New country | offline | premium |
| Activity from anonymous IP address | offline | premium |
| Suspicious inbox forwarding | offline | premium |
| Mass Access to Sensitive Files | offline | premium |
| Verified threat actor IP | Real-time | Premium |
| Additional risk detected | Real-time or offline | nonpremium |
| Anonymous IP addres | Real-time | Nonpremium |
| Admin confirmed user compromised | Offline | Nonpremium |
| Microsoft Entra threat intelligence | Real-time or offline | Nonpremium |
User risk detections
| Risk detection | Detection type | Type |
|---|---|---|
| Possible attempt to access Primary Refresh Token (PRT) | Offline | Premium |
| Anomalous user activity | Offline | Premium |
| User reported suspicious activity | Offline | Premium |
| Additional risk detected | Real-time or Offline | Nonpremium |
| Leaked credentials | Offline | Nonpremium |
| Microsoft Entra threat intelligence | Offline | Nonpremium |
There are some important tasks you should complete to effectively monitor and control user risk in your environment.
Number 1 is to configure notification emails when a high-risk alert is created. High-risk users are a cause for concern as they normally attribute to a user becoming compromised and your IT team should be immediately notified.
Number 2 is to configure the user risk or sign-in risk policy which can be used to block access based on the risk level or give the user a chance for automatic remediation, by forcing a password change through the self-service password reset mechanism. This is also controlled through Conditional Access policies.
Number 3 is to ensure all users have multi-factor authentication configured with a strong method such as the Microsoft Authenticator app that can be used for self-service password reset. Just changing the password from the office portal will not remediate the user risk.
Topology for on-premise password changes
Although it might be obvious, it is worth saying that if you want your users to be able to remediate the risk level associated with their account by resetting their password on-premises, then you need to be running identity synchronisation, either with Microsoft Entra Connect or Microsoft Entra Cloud Sync. As well as this, you also need to ensure you are using Password Hash synchronisation with either version of the sync tool.
If you are using Microsoft Entra Connect, you can use PowerShell to check if you have Password Hash Synchronisation enabled with the following command.
Get-ADSyncAADCompanyFeatureOtherwise, if you are using Microsoft Entra Cloud Sync, you can check the same information from the Microsoft Entra Admin Center by following these steps:
2. Expand Identity > Hybrid Management and select Microsoft Entra Connect.
3. Select Cloud Sync > Configurations and select your Cloud Sync configuration.
4. On the Overview tab select Properties, from here you will see whether Password hash sync is enabled or disabled.
Enable 'Allow On-Premise Password Change to Reset User Risk' in Microsoft Entra
The Allow on-premises password change to reset user risk setting is found within the Identity Protection blade of the Microsoft Entra admin center, you can simply turn it on or leave it off from there. Follow the below steps to enable the setting:
2. Expand Protection and select Identity Protection.
3. Under the Settings heading, select Settings.
4. Check the box to enable the setting.
Using Microsoft Graph PowerShell
You can also programmatically enable this feature using Microsoft Graph PowerShell. If you haven’t installed the Microsoft Graph PowerShell modules yet, check out my tutorial: How To Install the Microsoft Graph PowerShell Module.
First, connect to Microsoft Graph with the necessary permissions: policy.readwrite.identityprotection
Connect-MgGraph -scopes policy.readwrite.identityprotectionAs there is no dedicated cmdlet for this change yet, we will have to use the catch-all cmdlet Invoke-MgGraphRequest.
$body = @'
{
"isUserRiskClearedOnPasswordReset": true
}
'@
$uri = 'https://graph.microsoft.com/beta/identityProtection/policy'
Invoke-MgGraphRequest -Uri $uri -Body $body -Method PATCH -ContentType "application/json" Resetting on-premise password to reset the user risk level example
Once this feature is enabled and your identity synchronisation topology supports password hash synchronisation the results will be pretty instantaneous.
For this test I have a user named Adsync User 2, I have simulated a high-risk sign-in by reporting a false MFA prompt within the Microsoft Authenticator app. A couple of minutes later the user appeared in the risky sign-in log.
A few moments after the risky sign-in log appeared, I returned to the workstation where the user was logged in to on-premises and reset the password with a simple CTRL + ALT + Delete and reset password. This log on a local domain controller demonstrates that the password was updated on-premises.
A few moments after the password was updated and it synchronised to Microsoft Entra ID, the risky sign-in log for Adsync User02 was changed to the remediated state and User changed the password on premises appeared in the log details.
