View Blog

Welcome to Part 2 of this article series in which we take a look at the primary policy types that you can create and utilize in Microsoft Endpoint Microsoft (Intune).  In Part 1 we looked at Configuration Profiles and how they are the rough equivalent of GPOs in a traditional AD on premise domain in which some things were hidden, others revealed.  Here we will examine some of the other major components of MEM, all pertaining to security.

Security Baselines

Also referred to Security Profiles, Security Baselines are sets of Windows settings that are preconfigured by Microsoft Security engineers.  There are currently 3 Security Baselines as is shown below.  They are

• Windows 10 Security Baseline
• Microsoft Defender ATP Baseline
• Microsoft Edge Baseline

The baselines by themselves don’t really do anything until you use one of them to create a security policy.  To create a profile you simply click on the appropriate baseline and then create your desired policy.  Baselines should be looked at as minimum security standards, although for most enterprises, they would work admirably.  You can change any of the settings, but keep in mind that when you unconfigure a setting, you are making it less secure.  In most cases, you should simply accept the settings as is and deploy the policies to their targeted users and devices.  The screenshot below shows the preconfigured BitLocker settings within the Windows 10 Security Baseline.

Compliance Policies

Compliance Policies are used to determine whether a device is compliant with a pre-defined baseline.  Compliance Policies vary on the platform of the device.  Some examples of Windows 10 compliant baselines can include the following:

• BitLocker enabled
• Minimum OS version
• Password qualities
• Firewall enabled and configured
• Location of the device

You can then select a noncompliance action such as an email notification sent to the user informing them of their device’s noncompliance state.  You can even lock or retire a device that has been noncompliant for a specified duration.  An example of a Compliance Policy requiring a minimum Windows 10 OS version is shown below:

Conditional Access Policies

Conditional Access Policies work hand-in-hand with Compliance Policies.  They prevent access to noncompliant devices.  For instance, you can prevent devices connecting from anywhere outside of the U.S. for instance.  You can also list other conditional access requirements such as the installation of approved applications or MFA as shown in the screenshot below.  You should always test your Conditional Access Policies first as you could deny everyone access including yourself. 

Enrollment Restrictions

Although not a “policy” per se, Enrollment Restrictions play an important role in MEM security.  By default, authorized users can enroll 2 devices into the MEM portal.  If don’t want the default, you can create enrollment restrictions that will allow users to enroll anywhere from 1 to 15 devices.  You can also assign Device Type Restrictions that will prevent users from enrolling either personal devices, or designated device version platforms as is shown in the screenshot below.

Creating a MEM Strategy

As you can see, there are a lot of moving parts in MEM.  The key is to ensure that all of your policies and restrictive settings work in conjunction of one another in order to safeguard your organization as well as ensure that your users can perform their required digital workloads.  While MEM alone falls short of the granular setting coverability of Group Policy, it can play an important role for new startups and established companies that have significant numbers of mobile and remote devices.