Protecting users and authentications with MFA is one of the most important things to do. Users need to identify their authentications with at least one additional factor when logging in. This is so important because everyone knows usernames and passwords are weak and stealing them is not so difficult. I could write tons of words why we should use MFA but we’re not doing this right now.
In fact. We’re talking about protecting users who are not protected by MFA. I’ve seen some environments where users are not protected by MFA by purpose. Although I still try to convince everyone from doing this their could be reasons for not having MFA. In that case.. this article might help!
Note: The topics below are my own perception on what and or how to handle these users. There are no official statements that this should be done or has to be done this way. Most of these topics can (or should) apply also to users who are protected by MFA. Consider these topics..
Block remote access
Shared accounts are often used in warehouses. These accounts could be used by several employees and are used for only specific tasks. These shared accounts probably don’t need external access and so we could block this with Conditional Access. This conditional access policy requires you to use Named Locations.
In Azure Active Directory (Azure AD), named locations are used to define and manage network locations or IP ranges that are associated with specific (geographic) locations. They provide a way to control access and security policies based on the location of the user or device trying to access Azure AD resources.
Named locations in Azure AD are primarily used in Conditional Access policies, which allow you to define access rules based on various conditions. By configuring named locations in Azure AD, you can create conditional access policies that restrict or allow access to resources based on the location of the user or device.
Our Conditional Access policy denies access for the included users from Any location except for the named locations. A named location could be an external IP address for example. The HQ and every branch office could be a single named location for example.
SETTING | VALUE |
Users and Groups | Include: Shared accounts / Warehouse accounts |
Exclude: None | |
Cloud Apps | Include: All cloud apps |
Exclude: None | |
Conditions | |
Condition: User risk | Include: Not configured |
Exclude: Not configured | |
Condition: Sign-in risk | Include: Not configured |
Exclude: Not configured | |
Condition: Device Platform | Include: Not configured |
Exclude: Not configured | |
Condition: Locations | Include: Any location |
Exclude: Trusted locations and/or Selected locations | |
Condition: Client Apps | ☒ Browser ☒ Mobile apps and desktop clients ☒ Exchange ActiveSync clients ☒ Other clients |
Condition: Filter for devices | Not Configured |
Access Controls | |
☒ Block access ☐ Grant access | ☐ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☐ Require one of the selected controls |
Session | Not configured |
Follow these steps to implement this policy:
- Navigate to https://portal.azure.com
- Navigate to Azure Active Directory -> Security -> Conditional access -> Policies
- Click New Policy
- Fill in a policy Name
- Selected the targeted users or groups.
- Select the targeted apps. All Cloud apps is recommended.
- Under Conditions -> Locations we select Any location and exclude the named locations (HQ and branch offices)
- Under Grant we select Block access
- Under Client apps we select all options
Exclude from SSPR (Self Service Password Reset)
Requiring MFA for password resets is recommended. Because the user has no MFA configured they should not be able to reset their password. For example with shared accounts. Excluding these users from SSPR removes the “More information is required..” step after the first authentication.
As of today it is still not officially possible to exclude users from your Self Service Password Reset configuration. The only options shown here are None, Selected, All.
As long as there is no exclude option we can only go for Selected or All.
Note: Using selected is not needed if you require MFA for resetting passwords. Assuming you do and have combined registration configured, the users without MFA are not able to reset their password using SSPR.
Allow device enrollment/registration without MFA
Modify the tenant wide configuration called “Require Multi-Factor Authentication to register or join devices with Azure AD”. It’s recommend to disable this setting and control this setting using a conditional access policy.
Navigate to https://portal.azure.com -> Azure Active Directory -> Devices -> Device settings. Set this setting to No.
Next: Implement a conditional access policy which requires MFA for device registration/join. Follow these steps to implement this policy:
- Navigate to https://portal.azure.com
- Navigate to Azure Active Directory -> Security -> Conditional access -> Policies
- Click New Policy
- Fill in a policy Name
- Include All users, exclude a group which holds the users without MFA
- Under Cloud apps or actions -> User actions -> Register or join devices
- Under Grant we select Require multifactor authentication
setting | value |
Users and Groups | Include: All users |
Exclude: Shared accounts / Warehouse accounts | |
Cloud apps -> User actions | ☐ Register security information ☒ Register or join devices |
Conditions | |
Condition: User risk | Not configured |
Condition: Sign-in risk | Not configured |
Condition: Device platforms | Not configured |
Condition: Locations | Not configured |
Condition: Client apps | Not Configured |
Condition: Filter for devices | Not Configured |
Access Controls | |
☐ Block access ☒ Grant access | ☒ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☒ Require one of the selected controls |
Session | Not Configured |
Note: Users without MFA should be able to enroll devices into Intune and/or register devices in Azure Active Directory. This is absolutely not recommended but we have to accept the fact that some users should be able to do this. If the users are working remote and/or should be able to fresh start their devices on remote locations we have to exclude the app Microsoft Intune Enrollment with object id d4ebce55-015a-49b5-a083-c84d1797ae8c.
Limit access using named locations
In Azure Active Directory (Azure AD), named locations are used to define and manage network locations or IP ranges that are associated with specific geographic locations. They provide a way to control access and security policies based on the location of the user or device trying to access Azure AD resources.
Named locations in Azure AD are primarily used in Conditional Access policies, which allow you to define access rules based on various conditions. By configuring named locations in Azure AD, you can create conditional access policies that restrict or allow access to resources based on the location of the user or device.
When defining a named location, you typically specify an IP address range that represents a specific geographic location. For example, you might define a named location called “United States” and provide the IP address range corresponding to the United States. You can create multiple named locations to cover different regions or countries.
Using named locations in Azure AD, you can enforce security policies such as multi-factor authentication (MFA) or require users to connect via a virtual private network (VPN) when accessing Azure AD resources from outside a trusted network location. This helps protect your organization’s resources by ensuring that access is granted only from approved locations.
It’s important to note that named locations in Azure AD are not physical locations, but rather logical representations of network locations based on IP address ranges. They are primarily used for access control and security purposes within Azure AD.
I recommend to create a named location for the HQ and every branch office based on their external IP address. The Block remote access policy shown before makes use of named locations. I’ll block access from everywhere except excluded named locations.
Require compliant device
When it comes to Microsoft Intune, requiring compliant devices is a perfect thing to do. This is a recommended for all users and not only for users who are not protected by MFA.
When your current device is not in the required state (e.g. compliant) access could be blocked automatically. Optionally you could exclude specific users, devices, locations (for example) from this policy.
Sign-in Risk
The Sign-in Risk policy under Identity protection should be migrated to a Conditional Access policy. The built-in policies under identity protection are not very flexible. The official migration documentation by Microsoft can be found here.
Users who have a higher risk state (e.g. medium or high) should be able to logon after they confirmed their identity using Multifactor Authentication. Because users without MFA are note able to to this, they won’t be able to logon.
setting | value |
Users and Groups | Include: All users |
Exclude: none | |
Target resources | |
Cloud Apps | Include: All cloud apps |
Exclude: None | |
Conditions | |
Condition: User risk | Include: Not configured |
Condition: Sign-in risk | Include: High, Medium |
Condition: Device Platform | Include: Not configured |
Exclude: Not configured | |
Condition: Locations | Include: Not configured |
Exclude: None | |
Condition: Client Apps | ☒ Browser ☒ Mobile apps and desktop clients ☐ Exchange ActiveSync clients ☐ Other clients |
Condition: Filter for devices | Not Configured |
Access Controls | |
☐ Block access ☒ Grant access | ☒ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☒ Require one of the selected controls |
Session | Not configured |
Note: If you have a user group containing all the users without MFA you could create an additional conditional access policy. This policy could explicitly deny access for the users if they have a medium or high risk state. Optionally you could exclude named locations and/or managed devices.
setting | value |
Users and Groups | Include: Non-MFA-protected users group |
Exclude: none | |
Target resources | |
Cloud Apps | Include: All cloud apps |
Exclude: None | |
Conditions | |
Condition: User risk | Include: Not configured |
Condition: Sign-in risk | Include: High, Medium |
Condition: Device Platform | Include: Not configured |
Exclude: Not configured | |
Condition: Locations | Include: Not configured |
Exclude: None | |
Condition: Client Apps | ☒ Browser ☒ Mobile apps and desktop clients ☐ Exchange ActiveSync clients ☐ Other clients |
Condition: Filter for devices | Not Configured |
Access Controls | |
☒ Block access ☐ Grant access | ☐ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☐ Require one of the selected controls |
Session | Not configured |
User Risk
The Sign-in Risk policy under Identity protection should be migrated to a Conditional Access policy. The built-in policies under identity protection are not very flexible. The official migration documentation by Microsoft can be found here.
Users who have a higher risk state (e.g. medium or high) should be able to logon after they confirmed their identity using Multifactor Authentication. Because users without MFA are note able to to this, they won’t be able to logon.
setting | value |
Users and Groups | Include: All users |
Exclude: none | |
Target resources | |
Cloud Apps | Include: All cloud apps |
Exclude: None | |
Conditions | |
Condition: User risk | Include: High, Medium |
Condition: Sign-in risk | Include: Not configured |
Condition: Device Platform | Include: Not configured |
Exclude: Not configured | |
Condition: Locations | Include: Not configured |
Exclude: None | |
Condition: Client Apps | ☒ Browser ☒ Mobile apps and desktop clients ☐ Exchange ActiveSync clients ☐ Other clients |
Condition: Filter for devices | Not Configured |
Access Controls | |
☐ Block access ☒ Grant access | ☒ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☒ Require one of the selected controls |
Session | Not configured |
Note: If you have a user group containing all the users without MFA you could create an additional conditional access policy. This policy could explicitly deny access for the users if they have a medium or high risk state. Optionally you could exclude named locations and/or managed devices.
setting | value |
Users and Groups | Include: Non-MFA-protected users group |
Exclude: none | |
Target resources | |
Cloud Apps | Include: All cloud apps |
Exclude: None | |
Conditions | |
Condition: User risk | Include: High, Medium |
Condition: Sign-in risk | Include: Not configured |
Condition: Device Platform | Include: Not configured |
Exclude: Not configured | |
Condition: Locations | Include: Not configured |
Exclude: None | |
Condition: Client Apps | ☒ Browser ☒ Mobile apps and desktop clients ☐ Exchange ActiveSync clients ☐ Other clients |
Condition: Filter for devices | Not Configured |
Access Controls | |
☒ Block access ☐ Grant access | ☐ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☐ Require one of the selected controls |
Session | Not configured |
Note: If you are comfortable with these conditional access policies you could combine them into a single policy for user and sign-in risk. Reminder that this does gives you less flexibility.
Combined User Risk & Sign-in risk
setting | value |
Users and Groups | Include: All users |
Exclude: none | |
Target resources | |
Cloud Apps | Include: All cloud apps |
Exclude: None | |
Conditions | |
Condition: User risk | Include: High, Medium |
Condition: Sign-in risk | Include: High, Medium |
Condition: Device Platform | Include: Not configured |
Exclude: Not configured | |
Condition: Locations | Include: Not configured |
Exclude: None | |
Condition: Client Apps | ☒ Browser ☒ Mobile apps and desktop clients ☐ Exchange ActiveSync clients ☐ Other clients |
Condition: Filter for devices | Not Configured |
Access Controls | |
☐ Block access ☒ Grant access | ☒ Require multi-factor authentication ☐ Require device to be marked as compliant ☐ Require Hybrid Azure AD Joined device ☐ Require approved clients app ☐ Require app protection policy ☐ Require all of the selected controls ☒ Require one of the selected controls |
Session | Not configured |