Microsoft Conditional Access: How to Enforce It with Certificates

Organizations can use a variety of signals when making decisions about allowing access to enterprise resources. Relying solely on authentication via password isn’t enough: According to data from Webtribunal, 50 percent of people use the same password across different accounts, and 51 percent use the same password for their personal and work accounts. Multifactor authentication (MFA) is often used as another layer of security, but even that doesn’t eliminate risk exposure.

Modern security systems can use a variety of other signals, such as location or device platform, in deciding whether or not to trust a device. As we’ve explained previously, one of the best such signals is the presence or absence of a digital certificate. 

Microsoft Conditional Access policies control access in an if-then fashion defined by the administrator, performing a series of checks and then granting or denying access based on the results. It can do so on a granular level, using different criteria (such as the presence or absence of a certificate) to gate different resources. You could, for example, require multifactor authentication before a user can access Microsoft 365 resources. Even if a user’s password has leaked and a bad actor somewhere is trying to authenticate into Office 365, they won’t be able to, because they don't have a certificate on their device that Microsoft requires to grant access to resources.

Defining Microsoft Conditional Access Policies

Setting up Microsoft Conditional Access starts with defining what your organization considers a compliant or trusted device. This is the set of rules and security policies that a device must meet in order to be granted access to specific resources. 

Compliance can be enforced in several ways. Microsoft compliance partner solutions can send compliance and device data directly to Azure Active Directory (Azure AD); this data can then be used by conditional access policies to determine whether or not a device will be allowed to access the resource. Alternatively, Microsoft Conditional Access can be utilized with Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security) to determine whether a device should be trusted by looking for the presence of a certificate deployed by your MDM solution.

As long as the certificate matches the Root CA or Intermediates on the Microsoft side then the certificate should be accepted by Microsoft, and the user should be able to authenticate into Office 365 or other Microsoft resources. The idea here is that if a device has the expected certificate installed and since MDM is delivering the certificate, it meets the requirement of the device needing to be managed. 

Configure Azure AD

To start, you need to ensure your Microsoft account subscription includes conditional access and Microsoft Defender for Cloud Apps. For license information on Azure AD features, see Azure Active Directory plans and pricing; for licensing info on Microsoft Defender for Cloud Apps, see the Microsoft Cloud App Security Licensing Datasheet.

Once you’ve verified your subscriptions, you can start configuring Conditional Access in Azure AD to work with certificates by using Microsoft Defender for Cloud Apps. That means logging in to Azure AD, then navigating to Security > Conditional Access. Create a policy and assign it to scoped users and apps. Finally, make sure your policy is set to use a custom session policy; learn more at Protect apps with Microsoft Defender for Cloud Apps Conditional Access App Control.

After you’ve configured Conditional Access, you can do the same for Microsoft Defender for Cloud Apps. That means going to the Microsoft Defender for Cloud Apps portal. There, you upload the Root or Intermediate CA to allow for device identification; you do this in Settings > Device Identification > Add a root certificate. Once the certificate is uploaded, you need to configure at least one of two policies: an access policy or a session policy. Access policies give you control over user logins to cloud apps; session policies let you control user activity in those apps. For documentation, see Access policies and Session policies.

With the policies configured, the certificates need to be present on users’ devices in order to establish trust and gain access to protected apps and resources. If a user tries to access a protected app or resource and the certificate is not present, they will receive a message that access is blocked by their organization’s security policy—which is exactly what you want.

Deploying the Certificate

Once these Microsoft pieces are configured, you now need to shift focus to your MDM solution to deploy the certificate. That can be done in a couple of different ways. 

One option is to use a Simple Certificate Enrollment Protocol (SCEP) profile. This management protocol helps IT administrators automatically deploy certificates by specifying a gateway URL and a shared secret that the device can use to obtain certificates automatically. You deploy a profile that configures the enrolled devices to receive or install the needed certificate.

Beyond deploying the certificate to establish trust, MDM can also enforce other settings that might be required for compliance. For instance, MDM can enforce FileVault, enforce a password policy, allow connections only to trusted networks, or set screen-lock time. For MDM solutions that have a macOS agent, the possibilities are even greater.

With Kandji, for example, you can ensure your macOS devices remain fully compliant with our agent auto-remediations. Additionally, maybe your compliance policies require you to block a certain app, deploy a script, meet CIS requirements, or manage a particular device setting. An agent should be able to help with all of that and more.

If your organization requires you to implement Microsoft Conditional Access for all devices that access corporate resources, but your MDM solution isn’t a Microsoft compliance partner, you can combine your MDM solution (to enforce compliance while leveraging certificates to establish device trust) with Microsoft Conditional Access with Microsoft Defender for Cloud Apps using certificates, and your organization can achieve a similar outcome.

For more details on how implement Microsoft Conditional Access using Kandji, see our support article How to Enforce Conditional Access using SCEP.

About Kandji

The Kandji team is constantly working on solutions to streamline your workflow and secure all of your Apple devices. With powerful and time-saving features such as zero-touch deployment, one-click compliance templates, and plenty more, Kandji has everything you need to bring your Apple fleet into the modern workplace.