Skip to content
Menu
ChrisOnSecurity
  • Blog
  • Microsoft Security portals
  • Presentations
  • GitHub
  • About me
  • Impressum
  • Disclaimer
ChrisOnSecurity

Conditional Access – device identification using certificates

Posted on 24. June 202111. November 2021

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
  • Print
  • 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.

16 thoughts on “Conditional Access – device identification using certificates”

  1. jim says:
    16. October 2021 at 17:17

    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

    Reply
    1. Christian Müller says:
      11. November 2021 at 14:15

      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

      Reply
  2. Kim says:
    9. November 2021 at 14:50

    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

    Reply
    1. Christian Müller says:
      11. November 2021 at 14:09

      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

      Reply
  3. Jonny says:
    11. November 2021 at 13:50

    Hi,
    Thanks for this great Tutorial.
    Do we need EMS3 or EMS5 license for this?

    Thanks!
    Jonny

    Reply
    1. Christian Müller says:
      11. November 2021 at 13:53

      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

      Reply
  4. Kim says:
    17. November 2021 at 13:33

    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

    Reply
  5. Peder says:
    18. November 2021 at 09:30

    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

    Reply
    1. Christian Müller says:
      27. November 2021 at 11:24

      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?

      Reply
  6. Seetx says:
    25. November 2021 at 09:58

    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.

    Reply
    1. Christian Müller says:
      27. November 2021 at 11:17

      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

      Reply
  7. Jens Peterseon says:
    27. June 2022 at 13:17

    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

    Reply
    1. Christian Müller says:
      5. August 2022 at 08:36

      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?

      Reply
      1. Jens says:
        29. August 2022 at 09:14

        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

        Reply
  8. ash says:
    10. July 2022 at 02:20

    Can this be applied on a Polycom Devices?

    Reply
    1. Christian Müller says:
      5. August 2022 at 08:37

      If the device can be managed by an MDM instance that allows you to deploy certificates: probably yes.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

@ChrisOnSecurity@infosec.exchange

Recent posts

  • What’s new: Microsoft 365 Security & Compliance December 2022
  • What’s new: Microsoft 365 Security & Compliance November 2022
  • Counter MFA spam attacks with Azure Active Directory
  • Windows 11 security – a first look
  • Conditional Access – device identification using certificates

@ChrisOnSecurity

Tweets by ChrisOnSecurity

Recent posts

  • What’s new: Microsoft 365 Security & Compliance December 2022
  • What’s new: Microsoft 365 Security & Compliance November 2022
  • Counter MFA spam attacks with Azure Active Directory
  • Windows 11 security – a first look
  • Conditional Access – device identification using certificates

Tags

Administration Administrative Units Android AV Azure Active Directory Azure AD Azure Sentinel Client Security Conditional Access Conditional Access App Control Defender ATP Delegation EDR EMS Enterprise Mobility + Security Identity Protection Information Protection & Compliance Linux M365 M365 E3 Mail Security MCAS MDAPT MDATP MFA Microsoft 365 Microsoft 365 E3 Microsoft 365 Security Microsoft Cloud App Security Microsoft Defender ATP Microsoft Ignite Mobile Security Monitoring Network Control Office 365 Office ATP passwordless Perimeter Security Baseline Session Control Sysmon Unified Incidents User submissions Web Content Filtering Windows 10 Enterprise
©2023 ChrisOnSecurity | WordPress Theme by Superbthemes.com
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
Cookie settingsACCEPT
Manage consent

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary
Always Enabled
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Non-necessary
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
SAVE & ACCEPT