The Death of Compliance

Last Updated on June 14, 2022 by rudyooms

This blog will show you how Device-Based Conditional Access works and how it determines if your device is compliant or not!. I have been writing about this topic a little bit in one of my older blogs.

But after reading it again, I had the feeling that it was still missing some important information or examples. So here we go! And while at it, I will also show you how to fake compliance!

  1. Background information about Device based Conditional Access
  2. How does device based conditional access work?
  3. Let’s Fake Compliance !
  4. Results
  5. Conclusion

1. Background information about Conditional Access

When using cloud services, you really want to put up a Firewall between all the devices in the world and your Microsoft 365 tenant to determine who may access it and who not! That firewall would be Conditional Access

With Conditional Access, you can control the IF and THEN conditions. For example, IF an end-user tries to connect with the OneDrive App to your Tenant from a non-compliant device, THEN it will be blocked. 

When using conditional Access and using Office 365 apps from compliant and non-compliant devices, Azure AD will receive certain “signals” about the user and device, location, etc.

Conditional Access

One of the typical scenarios is to only grant access if the device used to access the service is marked as compliant. And that’s exactly what I will be talking about!

2. How does device Based Conditional Access work

When implementing device-based conditional access, you could make sure only your compliant devices could access your Microsoft 365 data. You could do so, by creating a Conditional Access to rule and requiring the device to be marked as compliant

Afbeelding met tekst

Automatisch gegenereerde beschrijving

So, when device-based Conditional access rules are configured you will need to make sure your devices are compliant otherwise communication will be blocked. I am not going to show you how to setup up compliance policies but I will “only” show you how it works.

To fully understand how you could make sure your devices are Intune enrolled and compliant, read the blog I mentioned at the beginning of this blog. To resume, your device needs to be enrolled into Intune (or another MDM) to get the device marked as compliant yes or no.

But how does Intune communicate with the Enrolled devices? Again, I have written a blog about this topic a while ago, please read it before continuing

When you’ve read the blog above, you will know by now the Intune MDM certificate is necessary for communication. Without this certificate, there would be no communication at all and no possibility to report back the compliance of the device itself. It’s a good thing when enrolling your device into Intune, the device will automatically receive this certificate.

When reporting compliance, we can use this Graph API as shown below to get the compliance status of the device. Of course, Microsoft probably has their own internal API to report the device compliance as this happens server-side.

Azure Active Directory integration with MDM – Windows Client Management | Microsoft Docs

First, let’s take a look at the “IsCompliant” attribute I showed above. This attribute describes the Trust Level and indicates if the device is compliant or not. To resume: if the “isCompliant” is set to: false… the device is marked as not compliant in Azure Ad!

Okay, so we need to have the Intune Device Certificate to report back/change the Compliance attribute, to begin with, to have a compliant device. So how does this flow looks like?

1. Intune will notify the Intune client to “phone home” (Sound like ET?)

2. The client connects to Intune (by using the Intune MDM Device Certificate) and receives a list of questions like “Is bitlocker enabled?” or “does your device has AV enabled?”

3. The client needs to answer them and will send back the “answers”

4. Intune compares these answers to the compliance policies targeted to the device and marks it compliant or not. This process happens on the server-side.

But when using the device based Conditional Access how does Azure Ad recognize this compliant device? Is it the Device name or something else?

It’s definitely not the device name, it’s the DeviceID!. You could look it up on the device itself by using dsregcmd /status

And of course, by looking at the Azure and Intune portal.

Afbeelding met tekst

Automatisch gegenereerde beschrijving

While showing why we need the deviceID I also need to sum up some information about the “deviceid”.

  1. The deviceID will change when the device state changes. For example, when a device was previously Azure AD registered but is now Hybrid Azure AD joined you’ll see duplicate entries in Azure AD’s Devices view. No worries… it will be automatically resolved over time…. and sometimes it takes a little bit longer…
  2. Please beware sysprepping the device, will NOT change the deviceid. If you clone an Azure ad joined device, the clone will have a new name but still has the same DeviceID and the same MDM Intune certificate!

Now, let’s sum up what we know by now!

The device needs to be Intune enrolled and by using the Intune MDM certificate it can communicate/patch the Compliance state.

When using Conditional Access, after authorization CA will check if the device is compliant to grant you access. To be sure the device is who it says it is, the DeviceID will be used.

But where is the deviceID stored and how does it get transferred? Here comes the Primary Refresh Token (PRT) and Access Token into play. The PRT is stored on the device and contains information about the device.

(For your information: The PRT is an opaque binary blob encrypted by Microsoft, so we don’t know exactly what it contains. However, we can be pretty sure it contains SOME information about the device)

When conditional access evaluation kicks off it will need to check the DeviceID to be certain if the device is who it says it is.

The device will request a new Access token by using the PRT (with probably the deviceID information in it) to get access to the specific requested service. After authentication, conditional Access will check the token and uses the deviceid attribute from it to check if the device is compliant by using the “isCompliant” information from Azure Ad. After it has checked the device and the attribute it will give you access (Only to the specific service you request access to) if the device is compliant.

In the blog about ADAL and MSAL I showed you how Bearer Access tokens looked like

3. Let’s fake Compliance

Now we know how Device Based Conditional Access and Compliance work, let’s take another look at the Link and the graph URL I showed you earlier to get the compliance status.

Azure Active Directory integration with MDM – Windows Client Management | Microsoft Docs

Looking at this “Note” you should expect that patching the compliance status is only possible from an Approved MDM app on a Windows 10 device. Let’s try it out as we can’t be sure without trying it for ourselves.

I have been testing this on my own Windows 10 testing VM (Not enrolled into this tenant!)

First, we need to make sure we have a device, which is not compliant and a conditional access rule to make sure non-compliant devices will be burned alive and have no access!….

Let’s open Onedrive first to be sure we have no access as the device is not compliant!

Afbeelding met tekst

Automatisch gegenereerde beschrijving

You will also notice a nice Sign-in error 53000 in the Azure Sign-In reporting stating the Device is not in a required device state)

When checking out the compliance state, please make a note of the device id! As we all have read, the device ID Claim is used to determine authorization for conditional access based on device state or compliance!

First, let’s find the device which is not compliant and open the device properties and search for the Azure Ad Device ID

Afbeelding met tekst

Automatisch gegenereerde beschrijving

Now we have got 2 options to fake/patch the compliance. We could use

  1. The great AAdinternals tools (by Nestori Syynimaa) to get the token and change the compliance part

2. The MSAL module to change the compliance attribute.

I will show you both options!

1.Aadinternals

Afbeelding met tekst, hand

Automatisch gegenereerde beschrijving

After we have the token… let’s check if the device is compliant…. Or not?

Now let’s change it!!

2.MSAL Method

The only thing you will need to change the “iscompliant” attribute, is Powershell and the MSAL module. And we all know by now in 2022 it will be bye-bye for ADAL and the Azure Ad module and the old graph endpoint… so please use MDAL and use graph.microsoft.com instead of graph.windows.net!

If you are interested in reading more about this, please visit my blog about this

After you have installed the needed MSAL module, just enter this script. (of course, you will need to change the device id)

$authResult = Get-MsalToken -ClientId '1b730954-1685-4b74-9bfd-dac224a7b894' -Scopes 'https://graph.microsoft.com/.default'

$header = @{
'Authorization' = 'Bearer ' + $authresult.accesstoken
'Content-Type' = 'application/json'
    'X-Requested-With'= 'XMLHttpRequest'
    'x-ms-client-request-id'= [guid]::NewGuid()
    'x-ms-correlation-id' = [guid]::NewGuid()
    }

$body =
'{
    "isCompliant":  "false"
}'
$apiurl = "https://graph.microsoft.com/v1.0/devices/e9a0b626-0ffc-4be3-8789-c14346d1a21a"

$Data = Invoke-RestMethod -Headers $header -Uri $apiUrl -Body $body -Method patch -ContentType 'application/json'
invoke-RestMethod -Headers $header -Uri $apiUrl -Method get

I have also created a video to show what happens

If you are wondering where the “clientid” stands for –> Azure Active Directory PowerShell

UPDATE:

I forgot to add this part… you will need to have proper permissions (admin level access in your MS Tenant.) to change this setting… changing it as a normal user “should” give you the 403 error (otherwise I guess I won’t be sharing this 😛 )

4. Results.

Now we have seen we can patch the compliance status ourselves, just try it out and let’s see what happens on a non-compliant device.

Within a few seconds, Onedrive and Teams and all other MS Apps were syncing and working again

Afbeelding met plein

Automatisch gegenereerde beschrijving

One reminder… When changing the compliance attribute in Intune we can immediately change the compliance status but the compliance status has a limited validity period. So changing the Compliance in Azure doesn’t mean the device will be compliant forever 🙂

Conclusion

Deploying device-based conditional access is one thing, but understanding how it works is definitely another cookie to eat. I want to give a shout-out to Dr Nestori Syynimaa

While writing and doing research for this blog, his blogs were a fantastic place to start and of course, he helped me out by checking if everything I said was true 🙂

GIF ufc 205 appreciate it appreciate - animated GIF on GIFER - by Juzuru

3 thoughts on “The Death of Compliance

  1. Hello,

    When turing the following on: Require device to be marked as compliant.

    How will this effect smartphones that are connecting to Email\Onedriv\Sharepoint. Will they also be blocked?

    I am talking about smartphones that are not connected to AzureAD.

    1. Hi… It depends if you configure the conditional access rule to also be targeting mobile devices instead or/and windows devices.

  2. Hi, this solution is saldy not working anymore. The isCompliant (Devices) or complianceState (managedDevices) is not changable with graph api anymore.

    https://learn.microsoft.com/en-us/graph/api/device-update?view=graph-rest-1.0&tabs=powershell#request-body

    https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-update?view=graph-rest-1.0#request-body

Leave a Reply

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

  +  83  =  91