In today’s hybrid work environment, securing access to cloud applications is more critical than ever. Microsoft Defender for Cloud Apps offers a powerful way to enforce granular access controls using different policies. Organisations want to ensure that only authorised and compliant devices can access sensitive cloud resources. Requiring device compliance can be achieved with Intune as an MDM and compliance policies. For those that do not have Intune deployed an alternative method is to use certificates to identify corporate devices. In these customer environments. there is typically an existing internal PKI deployment and user certificate enablement process which makes it easier to leverage certificates as the security control. If there is not an existing robust PKI, then it is probably better to invest the time in Intune rather than standing up a brandnew PKI with all of the associated hardware and management processes.
In the scenario where you want to use Defender for Cloud Apps (MDA) as a security control to block personal devices to Microsoft 365, this can be achieved by requiring a specific certificate to be present on the device.
Great - but there are considerations. This blog post explores an issue when configuring Defender for Cloud Apps to restrict access based on device certificates.
If you create an Access Policy to require TLS certificates using a policy like what is shown below, it will not apply to desktop applications, sometimes known as thick clients. The filter to scope the policy to a user can be set as per your environment requirements.
Before getting into the details, lets look at the lay of the land.
Lab Setup
On the test client machine, note that there are zero certificates in the user store. We are looking at the user store, and NOT the local machine store as this is where MDA expects the certificate to be installed. It will not check the local machine store.
Tip – use the shortcuts mentioned here to launch the relevant certificate MMC.
MDA uses the Conditional Access App Control to integrate with Conditional Access.
In this example we are targeting a specific test user and the session control is set to "use custom policy" which means that we then have to look at what policies are in scope in MDA.
Testing Defender for Cloud Apps Access Policy
When we test the Conditional Access App Control policy with the Access Policy in MDA in the browser we get the expected result; access is blocked.
You can also see that the URL was automatically redirected to the MDA proxy and we can see the tenant's domain name with the mcas.ms parent domain.
The first test was to M365 Copilot - access was blocked.
Second test was to Exchange Online. Access was again blocked.
So far so good.
But when we try the Outlook client, the connection is allowed.
The client is connected to EXO and is able to send/receive email along with Outlook's standard functions.
To prove that this is on the same machine at the same time, here is a screenshot showing that:
- M365 Copilot is blocked - top left
- Outlook is connected - bottom left
- OneDrive is connected - top right
- Teams is connected - bottom right
Enabling Desktop Apps In Defender for Cloud Apps Access Policy
In short we need to add the “Client App” rule filter.
Ok - we can do that. In the image below, you can see that a third line was added to the policy, and the client app is set to mobile, browser and also desktop.
However if you try to save the rule like this, then you will get an error.
The error is shown below, this is all the way at the bottom of the policy page and only the error text is show.
"Policy must contain at least one app when Client app filter is selected".
Go back and then add in the relevant application(s) to your scenario. In this case we want to protect M365, so an easy filter for that is to use the manual onboarding filter.
Final Testing
Now that we have added desktop client app filter, we can go and verify if desktop applications are blocked.
After the policy has synchronised, note that the user is unable to use Outlook.
Even though this is a desktop client, the login window displays the same status page and the custom error. In a production policy that could have more meaningful information to contact helpdesk or to refer to a particular IT policy.
Bootnote
If you read the documentation on access policies you would not see any mention of the requirement to add the client filter.
In the session policy documentation, the difference in behaviour is documented.
Cheers,
Rhoderick
