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

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!

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

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 recognizes 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. Like an 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 some times it takes a little bit longer…
  2. Please beware sysprepping the device, will not change the deviceid. If you clone a 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 in 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 complaint 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

Now let’s fake compliance and take a good look at what it does! 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

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 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!!

And within a few seconds, Onedrive and teams and all other stuff were syncing and working again

Afbeelding met plein  Automatisch gegenereerde beschrijving

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 tenant id and 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.) 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 😛 )

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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.