This blog is a series of guides which aim to run through the Conditional Access (CA) templates which Microsoft has published under the title Conditional Access templates (Preview). The templates get you up and running with CA but what is the impact of turning on the policies on devices, how can you adjust the templates to work in your environment and what does the end user experience look like on the endpoint?
The series is co-written by Paul Winstanley, a six times Enterprise Mobility MVP based in the UK and Mike Marable, an active member of the MEM community, based in the US.
Conditional Access Overview
Conditional Access rules are a type of if-then statement. If a user wishes to access something then they must complete an action to be able to access. Conditional Access rules get enforced once first-factor authentication has been completed.
Conditional Access use signals to make a decision and then enforce the decision to allow or deny access as per this diagram from the Microsoft documentation.
Microsoft introduced the Conditional Access templates at the end of 2021 as convenient method to deploy policies. These 15 templates cover five different deployment scenarios:
- Secure foundation
- Zero trust
- Remote work
- Protect administrators
- Emerging Threats
This series will cover the 15 templates in detail.
- Part 1 – Block access for unknown or unsupported device platform
- Part 2 – Require multifactor authentication for all users
- Part 3 – Require multifactor authentication for admins
- Part 4 – Require multifactor authentication for guests
- Part 5 – Require multifactor authentication for Azure Management
- Part 6 – Require Password Change for High Risk Users
- Part 7 – Require multifactor authentication for risky sign-ins
Risk
Azure AD Identity Protection includes the ability to identify suspicious actions related to user accounts. Risks can be related to either the user or sign-in. When risks are identified a risk score is attributed and this risk level/state is located in the Risk users or Risky sign-ins reports in the Azure Active Directory\Security blade of the Azure portal.
For both user risk and risky sign-ins, there are two types of detection/calculation. These are Real-time and Offline. Note that your level of reporting on these risks is determined by the Azure Premium licence which you hold as some of these risks are available to Azure AD Premium level 2 licences. There is, also, free risk detection, which is available if you don’t have any Azure AD Premium licencing.
The amount of time a risk is a reported in the console is determined by it’s type. For example, a real-time detection could be in the reports within 5-10 minutes, whilst an offline could take up to 48 hours to appear.
User Risk
Microsoft has published the user risk detections in the following article here. They are presented in this blog for completeness.
Premium user risk detections
| Risk detection | Detection type | Description |
|---|---|---|
| Possible attempt to access Primary Refresh Token (PRT) | Offline | This risk detection type is detected by Microsoft Defender for Endpoint (MDE). A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication on Windows 10, Windows Server 2016, and later versions, iOS, and Android devices. A PRT is a JSON Web Token (JWT) that’s specially issued to Microsoft first-party token brokers to enable single sign-on (SSO) across the applications used on those devices. Attackers can attempt to access this resource to move laterally into an organization or perform credential theft. This detection will move users to high risk and will only fire in organizations that have deployed MDE. This detection is low-volume and will be seen infrequently by most organizations. However, when it does occur it’s high risk and users should be remediated. |
| Anomalous user activity | Offline | This risk detection baselines normal administrative user behavior in Azure AD, and spots anomalous patterns of behavior like suspicious changes to the directory. The detection is triggered against the administrator making the change or the object that was changed. |
| User reported suspicious activity | Offline | This risk detection is reported by a user who denied a multifactor authentication (MFA) prompt and reported it as suspicious activity. An MFA prompt that wasn’t initiated by the user may mean that the user’s credentials have been compromised. |
Nonpremium user risk detections
| Risk detection | Detection type | Description |
|---|---|---|
| Additional risk detected | Real-time or Offline | This detection indicates that one of the premium detections was detected. Since the premium detections are visible only to Azure AD Premium P2 customers, they’re titled “additional risk detected” for customers without Azure AD Premium P2 licenses. |
| Leaked credentials | Offline | This risk detection type indicates that the user’s valid credentials have been leaked. When cybercriminals compromise valid passwords of legitimate users, they often share those credentials. This sharing is typically done by posting publicly on the dark web, paste sites, or by trading and selling the credentials on the black market. When the Microsoft leaked credentials service acquires user credentials from the dark web, paste sites, or other sources, they’re checked against Azure AD users’ current valid credentials to find valid matches. For more information about leaked credentials, see Common questions. |
| Azure AD threat intelligence | Offline | This risk detection type indicates user activity that is unusual for the user or consistent with known attack patterns. This detection is based on Microsoft’s internal and external threat intelligence sources. |
Note that to be able to identify certain risks, such as leaked credentials, you need to have implemented password hash synchronisation. Details on how to achieve this are available here.
User risk is scored in risk level. These are low, medium and high. Conditional Access rules can be configured to work with these risk levels and the Require Password Change for High Risk Users does just this.
Require Password Change for High Risk Users
This Conditional Access policy requires multifactor authentication to be satisfied when users access Cloud Apps, use User Actions or Authentication context.
It is created in the Azure Portal under the Conditional Access\Policies blade, or in the Microsoft Endpoint Manager console under Devices\Conditional Access.
Click the New policy from template (preview) link.
The policy is available in the Zero trust and Remote Work scenarios, or you can click All to display all the templates.
You can click the View option to view the default settings for the policy.
These are the settings for the Require Password Change for High Risk Users template.
| Users: | All Users are Included – The current user creating the policy will be excluded |
| Apps: | All apps |
| User Risk: | Risk levels: High |
| Access Control: | Grant access – Require multifactor authentication AND Require password change |
When the policy is created it is set as Report-Only. This is good practice, as the impact of enabling the policy can be assessed before doing so.
For our testing, we have created a group called CA Test User Group and added our test users to it. In the policy, under Users, we have chosen Select users and groups and picked the group to filter for. The user creating the policy via the template is excluded by default, but it is recommended to ensure you have a break glass account which can be used to access should the rule cause problems.
In the Access controls\Grant section of the rule, you can see that Require multifactor authentication AND Require password change are selected as the controls.
The user risk is defined under the Conditions view and is set to High for User risk.
When you are ready to move from the Report-Only mode, switch the toggle to On.
The state of the policy will be reflected in the console.
Report suspicious activity configuration in Azure AD
As a pre-requisite of testing the policy, we had to configure Azure AD to be able to Report suspicious activity. This is a simple task to undertake, so that we could test the following detection of user risk.
‘User reported suspicious activity – This risk detection is reported by a user who denied a multifactor authentication (MFA) prompt and reported it as suspicious activity. An MFA prompt that wasn’t initiated by the user may mean that the user’s credentials have been compromised.’
To set up reporting of suspicious activity, in the Azure portal go to Azure Active Directory\Security\Authentication Methods\Settings.
The default state of the setting will be Disabled.
Click the State drop down and select Enabled. Choose to apply to All users. For our demo, we have selected our CA Test User Group. Click Save.
Denying Sign in Request via MFA
With the reporting of suspicious activity now configured in Azure AD, the user is able to report on this during a MFA prompt.
When prompted, the user clicks NO, IT’S NOT ME.
and now the user is able to REPORT the suspicious activity. Without previous configuration place, this prompt would not appear.
In the Risky users report, under Azure Active Directory\Security\Risky users, the user risk will be reported. In our testing, we noted that this was very quick to update in the console. Note that the Risk level is High.
Azure admins who are configured for email reports, such as Security Administrators, will receive an email about the user risk.
Clicking into the risk in the console, we can see Basic info about the Risk state, Risk level and the time the Risk last updated.
In Detections not linked to a sign-in, it is reported as Detection type, User reported suspicious activity.
When clicking the User’s risk detections link
there is more information listed, with the Source being End User Reported, Detection timing reporting as Real-time and the actual Detection time of the risk.
Impact of enabling the policy
For our test user, Neil Redfearn, to be able to report a suspicious log in attempt, we also re-enabled the Require multifactor authentication for all users rule so that a MFA prompt occurred and the user could report this.
The following tests were undertaken on the Windows and Android platforms, the end result expected would be that we were prompted for MFA , the user would report this as suspicious activity. The user would then need to MFA and reset their password when next authenticating. We tested the policy by authenticating into office.com.
Windows
When the user authenticated, after the initial report of suspicious activity had occurred, the user was immediately denied the request to authenticate with a Request denied message.
Checking the sign-in logs against the user account. The log in was reported as MFA denied; user is blocked.
Checking in the Azure AD, under Azure Active Directory\Security\Multifactor authentication\Block\unblocker users, the account was indeed reporting as blocked. Therefore, this particular method of reporting the user risk requires admin intervention to Unblock the account.
Clicking the Unblock link allows the admin to enter a Reason for unblocking.
When the user was unblocked, Neil re-authenticated to office.com and received a MFA prompt which was approved.
Neil was then asked to change his password to satisfy the Require Password Change for High Risk Users Conditional Access rule.
Once the password is changed the user was remediated and removed from user risk.
Android
The same flow of events occurred when authenticating into an Android device. The user was blocked in Azure AD and the admin had to unblock.
When re-authenticating the user was prompted for MFA.
and then presented with the Update your password screen to complete the sign-in and to remove the user risk.
Checking the Sign-in Logs
When it comes to investigating Conditional Access policies, we refer to the Sign-in logs in Azure Active Directory. You can check the sign-ins against an individual user by going into the the Azure Active Directory blade and selecting Users. Search for the user and select, then click the Sign-in logs menu entry.
For the Require Password Change for High Risk Users sign ins, our user Neil gets an interruption in the sign in flow. Note the Status is listed as Failure. The Failure reason states Password change is required due to a conditional access policy.
Under Conditional Access, the Require Password Change for High Risk Users rule is a Failure.
If we click the link for this failed rule, we can view more detailed information on the failure. Grant Controls are Not satisifed.
The user changes their password and the user is granted access. A few Success events take place as the rest of the authentication finishes up the process.
Further reading
Take a look at the following Microsoft documentation if you want to read some more on Risk, User Risk and Conditional Access.
- What is Conditional Access? – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/overview
- Common Conditional Access policy: User risk-based password change – https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-policy-risk-user
- What is risk? – https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks
- Remediate risks and unblock users – https://learn.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-remediate-unblock
Look out for the next part of the blog where we cover sign-in risk.
SCCMentor - Paul Winstanley 
7 comments