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:

  1. Navigate to https://portal.azure.com
  2. Navigate to Azure Active Directory -> Security -> Conditional access -> Policies
  3. Click New Policy
  4. Fill in a policy Name
  5. Selected the targeted users or groups.
  6. Select the targeted apps. All Cloud apps is recommended.
  7. Under Conditions -> Locations we select Any location and exclude the named locations (HQ and branch offices)
  8. Under Grant we select Block access
  9. 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:

  1. Navigate to https://portal.azure.com
  2. Navigate to Azure Active Directory -> Security -> Conditional access -> Policies
  3. Click New Policy
  4. Fill in a policy Name
  5. Include All users, exclude a group which holds the users without MFA
  6. Under Cloud apps or actions -> User actions -> Register or join devices
  7. Under Grant we select Require multifactor authentication
settingvalue
Users and GroupsInclude: All users
Exclude: Shared accounts / Warehouse accounts 
Cloud apps -> User actions☐  Register security information
☒  Register or join devices
Conditions
Condition: User riskNot configured
Condition: Sign-in riskNot configured
Condition: Device platformsNot configured
Condition: Locations  Not configured
Condition: Client appsNot Configured
Condition: Filter for devicesNot 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
SessionNot 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.

By using compliant devices, you ensure that devices meet specific security requirements and configurations set by your organization. This helps protect sensitive data and mitigate the risk of unauthorized access or data breaches. Think of: Require BitLocker, require Secure Boot, require Firewall, require TPM, require Antivirus, require Microsoft Defender Antimalware, require Microsoft Defender Antimalware security intelligence up-to-date, require Real-time protection and many more. Even custom compliance policies can be created which can do almost everything you like.

Intune integrates with other Microsoft services, such as Azure Active Directory and Microsoft Defender for Endpoint. Compliant devices can leverage these integrations to enhance security and management capabilities further. For example, a compliant device can benefit from single sign-on capabilities, advanced threat protection, and seamless integration with other Microsoft productivity tools.

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.

settingvalue
Users and GroupsInclude: All users
Exclude: none
Target resources
Cloud AppsInclude: All cloud apps
Exclude: None
Conditions
Condition: User riskInclude: Not configured
Condition: Sign-in riskInclude: High, Medium
Condition: Device PlatformInclude: Not configured
Exclude: Not configured
Condition: LocationsInclude: Not configured
Exclude: None
Condition: Client Apps☒  Browser
☒  Mobile apps and desktop clients
☐  Exchange ActiveSync clients
☐  Other clients
Condition: Filter for devicesNot 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
SessionNot 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.

settingvalue
Users and GroupsInclude: Non-MFA-protected users group
Exclude: none
Target resources
Cloud AppsInclude: All cloud apps
Exclude: None
Conditions
Condition: User riskInclude: Not configured
Condition: Sign-in riskInclude: High, Medium
Condition: Device PlatformInclude: Not configured
Exclude: Not configured
Condition: LocationsInclude: Not configured
Exclude: None
Condition: Client Apps☒  Browser
☒  Mobile apps and desktop clients
☐  Exchange ActiveSync clients
☐  Other clients
Condition: Filter for devicesNot 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
SessionNot 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.

settingvalue
Users and GroupsInclude: All users
Exclude: none
Target resources
Cloud AppsInclude: All cloud apps
Exclude: None
Conditions
Condition: User riskInclude: High, Medium
Condition: Sign-in riskInclude: Not configured
Condition: Device PlatformInclude: Not configured
Exclude: Not configured
Condition: LocationsInclude: Not configured
Exclude: None
Condition: Client Apps☒  Browser
☒  Mobile apps and desktop clients
☐  Exchange ActiveSync clients
☐  Other clients
Condition: Filter for devicesNot 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
SessionNot 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.

settingvalue
Users and GroupsInclude: Non-MFA-protected users group
Exclude: none
Target resources
Cloud AppsInclude: All cloud apps
Exclude: None
Conditions
Condition: User riskInclude: High, Medium
Condition: Sign-in riskInclude: Not configured
Condition: Device PlatformInclude: Not configured
Exclude: Not configured
Condition: LocationsInclude: Not configured
Exclude: None
Condition: Client Apps☒  Browser
☒  Mobile apps and desktop clients
☐  Exchange ActiveSync clients
☐  Other clients
Condition: Filter for devicesNot 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
SessionNot 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

settingvalue
Users and GroupsInclude: All users
Exclude: none
Target resources
Cloud AppsInclude: All cloud apps
Exclude: None
Conditions
Condition: User riskInclude: High, Medium
Condition: Sign-in riskInclude: High, Medium
Condition: Device PlatformInclude: Not configured
Exclude: Not configured
Condition: LocationsInclude: Not configured
Exclude: None
Condition: Client Apps☒  Browser
☒  Mobile apps and desktop clients
☐  Exchange ActiveSync clients
☐  Other clients
Condition: Filter for devicesNot 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
SessionNot configured

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

17 + eleven =