Note
Microsoft Cloud App Security (MCAS) has been renamed to Microsoft Defender for Cloud Apps (MDCA) at Ignite 2021. This post does not yet reflect that name change.
Conditional Access is great. However, when it comes to managed devices it only allows to check for Hybrid Azure AD join and Intune compliance. With Microsoft Cloud App Security (MCAS), we can also require a certificate to be present on the client to get access. In this post I’ll show you how to do that. So yes, Conditional Access using certificates is possible although we need help from Microsoft CASB solution.
What we will do in short: a Conditional Access policy will redirect our demo user Adele to be in scope of MCAS’ Conditional Access App Control. This will allow us to configure Session and Access policies in MCAS that are able to check for the client certificate.
Preparing Conditional Access to use certificates
The preparations on the Conditional Access side are quite simple. All we have to do is make sure that users are redirected to MCAS’ Conditional Access App Control with the “Use custom policy…” option.
That’s all I configured for Adele here. For all of her session she will be in scope of MCAS.
If you only want to have certain session in MCAS you can achieve this by defining other Conditional Access conditions like the device platform, location, or device filters.
Preparing Microsoft Cloud App Security
First, we need to add the root or intermediate CA to MCAS using the PEM format. Of course, the public key must be present in the file. You can upload it in Settings (1) > Device identification (2) > Add a root certificate (3):
Enter a name and description and you are good to go:
Now we need to create Session and Access polices. Session polices are meant to control browser access while Access policies cover mobile and desktop apps. I create one policy for each scenario:
Let’s have a look at the session policy. I kept it quite simple (if certificate is not present -> block file download), however, you can get more granular. The check for the certificate is done by the device tag filter as you can see at the bottom of the left screenshot:
The access policy is even shorter:
Note
You must select “Mobile and desktop” as a client app here, otherwise the access policy will also cover browser sessions. This might be the required behavior, however, if you want to allow browser access in read-only mode with blocked downloads this would be a problem.
As I said, I kept it simple. You can, however, also filter for:
- Cloud app
- Client app
- Device (Type / Tag)
- IP address (Raw IP / Category / Tag)
- Location
- Registered ISP
- User (Name / From group)
- User agent string
- User agent tag
In the browser-based session policies you can also specify file filters…
- Extension
- File name
- File Size
- Sensitivity label
… and an inspection method:
- Built-in DLP
- Data Classification Service
- Malware detection
This can be applied to uploads and downloads.
You can also restrict certain actions inside the browser session:
- Cut/Copy item
- Paste item
- Sent item
The user experience
Adele will now try to authenticate to the Outlook desktop client.
Unfortunately, the certificate is not present on her machine which MCAS will detect.
Luckily, adding the certificate to her user store will mitigate the issue. The client certificate must have been issued by the CA we uploaded earlier. For this test I just did a manual import but using a centralized distribution is also possible of course.
Unlike Conditional Access, MCAS reacts to changes near real-time. So after the certificate is imported (or deployed) it works right away on the next try.
Important aspects about Conditional Access and certificates
- The client certificate must be located in the user store.
- Microsoft say Cloud App Security uses Azure Data Centers around the globe, so user session could be hosted outside of the tenants region. I am not allowed to give compliance advice, so please read for yourself: Protect with Microsoft Cloud App Security Conditional Access App Control | Microsoft Docs
- MCAS session controls use TLS 1.2 or later. This is the default for Azure AD also starting June 30th 2021, so it shouldn’t be a problem.
- If you want to use session control and not just block access, the cloud app must support this. Most Microsoft 365 apps are in scope, for others have a look at this guide: Deploy Cloud App Security Conditional Access App Control for any apps | Microsoft Docs
I hope I could give you a quick introduction on how to implement Conditional Access using certificates. Thanks for reading!
Chris
Note
Please note that all content on this blog is provided ‘as is’ without any warranty.
Hi
Great article. I did have a query around the certificate template you used (assuming it was the internal CA it was generated from). As you placed the certificate in the user store, was the template used to generate the certificate based from a User or computer authentication template? I will be utilising specified non azure joined and non domain joined devices which will be, for our purposes, defined as “Managed” as we need them to download files from within browser sessions. Our hybrid azure joined devices work great – its just a handful of specified non domain/non azure joined win 10 devices I need mcas to also regard as managed, hence the query. Thanks
Hi Jim, sorry for the late reply. This is using a user certificate template. It is documented that way by Microsoft: “Make sure that the client certificate is installed in the user store and not the computer store.”
I had a similar use case where we just manually deployed the certificates to unmanaged devices.
Best regards
Christian
I tried to follow that guide, but it seems something is missing
As soon I try to in conditional access click on the “create custom policy” i am asked to create a conditional access app – I click “create” and then it pop´s up with SAML creation ? – which doesn´t make much sense to me, why SAML should be involved in this
I just want my office 365 enviroment to look for this cert
Hi! I think the problem is that this is using Session Control in MCAS (now called Defender for Cloud Apps (MDCA) since Ignite) which requires that you have accessed the apps you want to control at least once before you create a custom policy. Otherwise they are not onboarded to MDCA which might cause that SAML prompt. So I would use the built-in “Block Download” control in Conditional Access and then access the app in scope of your policy; this should onboard the app to MDCA and after that you can create a custom session/access policy.
Best regards
Chris
Hi,
Thanks for this great Tutorial.
Do we need EMS3 or EMS5 license for this?
Thanks!
Jonny
Hi Jonny, thank you very much!
Unfortunately, giving licensing advise is a bit tricky. 😉 What I can say is that this uses Microsoft Cloud App Security (named Defender for Cloud Apps since Ignite last week) so you definitely need to have a license for that.
Best regards
Chris
Have followed your article step by step, but somehow I get a different result.
When I open outlook and I type my email/password a notification shows up that I must select a certificate to connect and it shows only the mac machine certificate (which has nothing to do with that MCAS actually). If I select that it just shows there was en error on your account. The root certificate on the mac is only in the “system” keychain – so not local user keychain so it should block ?
also if I connect through a browser it ask me to select a certificate, but only shows me the machine certificate again. The strange this is, that I can select this machine certificate, and type my mac admin user/password and I get into webmail without any more issue
I followed your guide and looks fine
When I am logging in first time after enabling MCAS, it ask for certificate and I select mine and get into outlook
But If I try to remove the certificates on my device, close application and open again, I still get in ? – should that be possible ? Also tried to wait for hours which does not block me anymore ?
Is there any cache that first need to expire or shouldn´t MCAS at every login check that certificate is there
Hi Peder, from my experience it depends on other factors as well: session limitations in Conditional Access, Continuous Access Evaluation being turned on or off, Resilience Defaults turned on/off, and also the local client apps. Especially since Microsoft deprecated fixed values for token lifetimes this can be frustrating.
What if you sign-in out in a browser and try to get back in without the cert?
Hi Chris first of all thank you very much for this detailed write-up. This will be an excellent approach in case Intune Company portal does not work in your environment. This is the case in ours.
We are sending all the auth data through our zscalar proxy and company portal does not like it and tends to break and this is where we are seeing a lot of issue with the mac device. Hence we had to remove it from our environment.
by the looks of what you have done here is going to be very helpful for us.
Is there a way by which we can get in touch with you incase we need some help with this.
I think we can get in touch with MS on this as well and see if they can help us with this approach.
Hi Seetx, thank you for your comment. If you like, you can contact me at my company address: christian.mueller@skaylink.com
I am not freelancing next to my job at the moment, so this is the only way I can officially help you.
Best regards
Chris
Sometimes when Teams prompt for select certificate. I select it and MCAS then shows the blocking message for some reason ?
If I restart teams and I select the same certificate the access works fine ? – is this something you can explain, that I select the same certificate(there is only one, so cannot pick the wrong one), but the behavior is different
What I can say is that handing over a certificate to any Microsoft service (like MCAS) seems to be tricky. It happened to me several times to have some hiccups. It is highly dependant on browser versions and the certificate templates. Unfortunatelly I don’t have a real solution for it. You are using the Teams app right? Same behavior with browser access?
Actually we see this very often on clients.
1. We get many mails from MCAS alert, that sessions are blocked. But if contacting the user, they have not experienced anything blocked. So somehow false alert, that I don´t know where comes from ?
2.. Other times we see the issue, that people actually get the blocking message – and typically all office apps must be closed down and then opened again, before access works
Can this be applied on a Polycom Devices?
If the device can be managed by an MDM instance that allows you to deploy certificates: probably yes.