The diversity of devices present on business networks has increased drastically. Even if you’re only utilizing company-owned devices managed by a platform like Microsoft’s Intune, there’s still much to account for. Laptops, desktops, business phones, IoTs, and more – in order to secure your network, you have to know what’s on it and whether it should be there.
Digital certificates help establish device trust by providing in-depth context for every connection, beyond what you’d get from just a username and password. A certificate can contain a range of attributes that come from existing information contained in platforms such as Azure AD (Microsoft Entra ID) and Intune.
Compliance is an example of one such attribute from Intune. In this blog, we’ll explain what Intune compliance means and how you can use it with certificate-based authentication to establish device compliance-based access policies.
The Importance of Device Trust & Compliance-Based Policies
In short, device trust is the concept of knowing exactly what a device is and where it came from, and that it can safely be permitted to access your resources. It’s the difference between a guest’s phone – which might be infected with malware or lacking critical security updates – and a carefully managed company laptop tapping into your network.
To ensure device trust, many organizations turn to Mobile Device Management platforms such as Intune. Intune allows administrators to stipulate a range of policies that a company-owned device has to meet in order to be compliant.
The use of digital X.509 certificates for authentication purposes can also bolster device trust in an organization. In short, a digital certificate works like a virtual ID badge attached to users or devices. Each one is made from a template comprised of variable and detailed information, giving administrators significantly more visibility regarding the devices on their network. With SecureW2’s managed PKI, you can even create certificate templates that use the device compliance attribute, isCompliant.
However, before we get to how that works, let’s look at some of the qualities you can require to establish Intune compliance policies in the first place.
Defining Device Compliance in Intune
What makes Intune especially powerful is that administrators can choose from a diverse range of traits to determine whether a device is compliant. This gives organizations much more power over the security of devices accessing potentially sensitive resources.
The following is a list of qualities Intune compliance can be based on:
- Operating System Updates: Whether a user has the most current update for their operating system.
- Password Complexity: This determines what qualities a user’s passwords must meet.
- Network Security: A broader factor based on having the proper firewall settings and VPN to ensure that company resource access is monitored.
- Root Detection: Whether a device has been jailbroken or remains untampered with.
- Data Encryption: Requires users to encrypt their data in order to be compliant.
- Device Threat Prevention: Requirement of having particular antivirus, firewall, and network protocols configured on the device.
- Device Health Attestation: Requirement of Code Integrity, Secure Boot, and BitLocker Encryption to evaluate the device’s health.
In addition to determining whether a device is compliant or non-compliant, administrators can create a device compliance grace period setting in Intune. This allows devices a customizable amount of time to achieve a state of compliance before their resource access is revoked.
Compliant vs Non-Compliant in Intune
Compliance, as an attribute, comes down to two values: compliant and noncompliant. Whether it is compliant or not depends on the traits compliance is based upon.
For example, if you’ve based your Intune compliance policy on a device having an up-to-date operating system, then it will appear as compliant as long as its OS is current. If its OS isn’t current, then it will appear as non-compliant, which means its access to company resources will be revoked.
Compliance-Based Policy Examples
Certificate-based authentication gives even more granular access control to administrators, empowering them to leverage a number of attributes in certificate templates. In short, a digital certificate works like a virtual ID badge attached to users or devices. Each one is made from a template comprised of variable information.
A Public Key Infrastructure (PKI) is used to create certificates, and the flexibility of your certificate template may vary based on the PKI it came from. With SecureW2’s PKI, for example, templates are customizable and can use different attributes from your MDM, including Intune device compliance. Working with Cloud RADIUS and its innovative policy engine, the result is that administrators can implement diverse network access policies.
The simplest example is whether a device is granted or denied access to your Wi-Fi. If the device is compliant, it can be authenticated and given network access or simply revoked if it’s non-compliant.
Another example is requiring multi-factor authentication (MFA). It’s possible that you don’t want to completely deny a non-compliant device and prevent an employee from working. In that scenario, if their device was non-compliant, you could create a policy that requires them to submit another form of authentication.
How Cloud RADIUS Identity Lookup Works with Intune Device Compliance
The compliance attribute in Intune can be leveraged for wired, Wi-Fi, and VPN access with the right solutions. Cloud RADIUS, with its powerful Identity Lookup technology, can interface with Azure AD and Intune at the time of authentication to verify a device’s compliance status.
It starts by issuing certificates to your Intune-managed devices. SecureW2 makes certificate distribution simple with our managed device gateways that use SCEP to automatically enroll Intune devices for certificates. By customizing the certificate templates to include the Azure Device ID for each managed device, Cloud RADIUS can determine that device’s compliance status the next time it authenticates to your network.
Once the device presents its certificate to Cloud RADIUS, it checks in Azure AD and Intune using the device ID. Azure AD then returns the status to Cloud RADIUS, which can grant or deny access to the device.
Configuring Network Policies Based on Intune Device Compliance
Prerequisites
In order to leverage SecureW2’s passwordless network security with Intune’s device compliance attribute, you’ll need the following licenses and subscriptions:
- Azure AD License
- Intune License
- Microsoft 365
- Cloud RADIUS
- JoinNow Connector PKI
Additionally, you’ll need to have configured a few settings in Azure and Intune. The steps you’ll need to have completed in advance include the following:
- Established groups in Azure AD to apply compliance policies to
- Creating a notification template in Intune to notify non-compliant devices
- Adding your Intune as an Identity Provider in SecureW2
- Adding Azure as an Identity Lookup Provider in SecureW2
- Creating a SCEP certificate profile in Intune with the Azure Device ID in the subject alternative name (SAN) field
Configuring Policies Based on Intune Device Compliance in SecureW2
Now that you have defined what you want to base compliance on in Intune, it’s time to integrate Intune with SecureW2. First, we need to add the isCompliant attribute to our Azure Identity Lookup Provider (IDLP) in the JoinNow Management portal.
- Navigate to Identity Providers and click Edit on your Azure IDLP
- Go to the Attribute Mapping section and Add an attribute.
- In Local Attribute, enter isCompliant
- In Remote Attribute:
- Select User Defined as the value in the drop down
- Enter isCompliant as the value
- Click Update
- Click Update to save your Azure IDLP
Next, we are going to create a Role that will only apply to devices that are Compliant in Azure/Intune.
- Select Policy Management, and then Roles Policies from the dropdown.
- Click Add Role, then name the role appropriately. We recommend naming it something like Device Compliance Intune/Azure.
- Click Save.
- Select the Conditions button at the top and then choose your IDLP from the dropdown menu.
- Choose the Edit Attribute dropdown. Select isCompliant, and then Equals, and then True for the value.
- Click the Update button.
- Repeat steps 1-6, but change the attribute isCompliant to Equals False. This will allow you to create a separate failover policy for when a device fails the compliance check.
With these steps followed, Cloud RADIUS will now confirm through Identity Lookup at the time of authentication that a device is compliant. Your next step is to configure network policies that can utilize the compliant attribute we’ve just told it to check. To accomplish that, follow these steps:
- Select the Policy Management option, then choose Network Policy.
- Click the Add Network Policy button and name your policy. As we did previously, we recommend naming it something that references compliance. In this case, we’ve named the policy Compliance Check.
- Click the Save button. Two more buttons will appear at the top: Conditions and Settings.
- Select the Conditions option in the middle, and choose Add Rule.
- Click on the + button next to Identity to open the Identity menu.
- Check the box next to Role, then click the Save button.
- You will be brought to a screen where you can choose the role the policy applies to. Choose the applicable role related to compliance that we made in the previous set of steps, then click on the Update button.
- You will be brought back to a screen with your network policies. Choose the Edit icon on the policy we’ve just created.
- Click the Settings button at the top. Choose Deny from the Access dropdown.
- Click on the Update button to save the network policy.
If you’ve followed these steps, you’ve just created a role and network policy based on the Intune device compliance status in SecureW2. Now, when a user or device that belongs to the role authenticates to Cloud RADIUS, they will be denied network access if they are non-compliant in Azure and Intune.
Heightened Device Identity Context with SecureW2
Certificate-based RADIUS authentication can be simple with the right technology. SecureW2’s managed PKI and RADIUS services come together to create an elegant, easy-to-implement solution that works together with your existing infrastructure – including Azure AD and Intune.
Cloud RADIUS takes the security of certificate-based authentication a step further with our innovative identity lookup feature. Through Identity Lookup, Cloud RADIUS is capable of checking in Azure AD and Intune at the time of authentication, ensuring that only the most current policies are applied – including granting or denying access to resources based on a device’s current compliance status.
Want to see how it works yourself? Reach out to our support team today for a free demo.
