The Death of Compliance

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.

https://call4cloud.nl/2021/08/the-battle-between-aadj-and-aadr

However, after reading it again, I felt that it still needed some important information or examples. So here we go! And while at it, I will also show you how to fake compliance!

1. 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.

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 ensure only your compliant devices can 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

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 can ensure 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 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

https://call4cloud.nl/2021/04/alice-and-the-device-certificate

If you’ve read the blog above, you know the Intune MDM certificate is necessary for communication. Without this certificate, there would be no communication at all and no possibility of reporting back the device’s compliance. It’s a good thing that when you enroll your device in Intune, the device will automatically receive this certificate.

When reporting compliance, we can use this Graph API, shown below, to get the device’s compliance status. Of course, Microsoft probably has its own internal API to report 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 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 portals.

While explaining why we need the deviceID, I also need to summarize some information about it.

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 use the deviceid attribute 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 non-compliant device and a conditional access rule to ensure non-compliant devices are burned alive and have no access!….

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

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 note the device id! As we all have read, the device ID Claim determines authorization for conditional access based on device state or compliance!

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

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

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

• The MSAL module to change the compliance attribute.

I will show you both options!

1.Aadinternals

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

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 🙂