LAB: Microsoft Defender ATP and Conditional Access

The integration between Intune and Microsoft Defender Advanced Threat Protection (MDATP) has been there for a while now. It’s an interesting feature, as it allows the risk score assigned by MDATP to be utilized in CA policies. Most organizations I’ve worked with only use Intune for MDM and MAM and still use SCCM (or the like) for managing workstations. While Intune’s capabilities in workstation management are still limited, it’s constantly evolving – and with SCCM co-management supported, it’s becoming a very viable option to enroll also your workstations into Intune. In any case, I wanted to do a quick experiment on how the MDATP -> Intune -> CA integration works, and how quickly we can go from detecting an alert in MDATP into actually making access restrictions in Azure AD based on the incident.

In all its simplicity, the environment is depicted in the picture below. The laptop in this case is just a VM running in Azure but it will do the trick. The Windows 10 is directly joined to Azure AD (this would work equally well with hybrid scenarios, but I got lazy setting up the local infrastructure). The device will be enrolled into Intune and into MDATP (using Intune).

Setup: Intune + MDATP + CA

To begin with, you have to integrate Intune with MDATP. You’ll find the setting within the Intune management blade:

As well as in the advanced settings of the MDATP portal:

Once the tenant level integration is done, you need to create a device configuration profile for MDATP:

The next thing you need is a device compliance policy. This will determine at which MDATP risk level the device will be marked as non-compliant. In my case, I’ve set it to ”Low”, which means that any risk level higher than that will push the device out of compliance. We’ll see how the risk levels are shown in MDATP later.

On the compliance policy settings we want to make sure that devices with no compliancy status will be marked non-compliant:

And finally, you should set up a security baseline for MDATP. Although not strictly required for this experiment, it gives you a good idea which MDATP features you can centrally manage via Intune. If you’re running your Windows 10 remotely, be careful with the firewall configurations. The default settings in the baseline will make you lose RDP connectivity (been there…).

Finally, we’ll create a couple of conditional access policies. For testing purposes, I’ll create two policies:

  1. Access to SharePoint Online will require either a compliant device or MFA
  2. Access to Exchange Online will require both a compliant device and MFA (picture below)


Now we’re good to go! I start by joining the Windows 10 client to Azure AD, which will also automatically enroll it into Intune (as I have enabled the enrollment policy). After that, I’ll login with an Azure AD account and run the following command. This should generate an informational alert in MDATP, just to show that we’re getting the data.

The information in the MDATP portal lags a few minutes behind, you have to wait for a bit for the information to appear. But eventually, you should see this:

As you can see, the risk level is currently ”No known risks”, as this activity is not considered suspicious. Note, this view also shows the machines exposure level. MDATP assesses any vulnerabilities on the host, either due to missing security patches or known vulnerable configurations. The exposure level does not impact the devices compliance status, but provides very useful information about the security posture of the device.

At this point, we can see our device also in Intune, and it is compliant with all the defined policies:

When I access SharePoint Online, I’m able to get in with just username and password. And if I login to Exchange Online, I need to authenticate using MFA, but I’m able to get in. So everything is working as expected. Note: if you’re using Chrome, you need to have the Windows 10 Accounts extension enabled. Otherwise the device information will not get conveyed to Azure AD, and it will assume that you’re using a non-compliant device.

Infect me!

Now, let’s break things. In order to do that, I need to simulate an attack on my Windows 10 device so that MDATP will increase the risk level. For that purpose I’m using a Word document that is crafted for this purpose.

The document contains a macro that drops two files on the desktop (diy_rs3_jscript_executes_ps.js and WinATP-Intro-Backdoorexe.jpg). It will then establish persistence by modifying the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key. And finally, it starts a trusted process (RuntimeBroker.exe) and injects malicious code into it. This kind of pattern might go unnoticed from traditional anti-malware solutions, and that’s of course the point here.

Once I’ve opened the document, I’ll wait a couple of minutes and voilà! There’s not just one alert, but a bunch of them, and the device risk level jumped to High. We’ll briefly look into the forensics later, now we just want to see what happens with conditional access.

The information has also propagated to Intune via the integration and the device is no longer compliant (this took literally just a couple of minutes from the simulated infection):

At this point, I’m still able to use my open browser session as the access token is still valid (1 hour validity time). But I’m impatient so I just close my browser and reopen it. When I login to Exchange Online now, I get the following notice. In this case, it should say: ”Oops – you really shouldn’t have opened that document”.

I’m still able to access SharePoint Online but it now requires MFA. So the CA policies work just as expected.

Off the grid

One useful feature within MDATP is that you can completely isolate the client from the network. It might be that the device is currently in the corporate network, and therefore just restricting access through Azure AD might not be enough (unless you’ve implemented a full-blown zero-trust model).

Once I do that, it takes a minute or two and I lose my RDP connection. Luckily, that the device will still be able to communicate back to MDATP (well, it would be a pretty crappy feature otherwise). This way, once the remediation activities have been completed and, you can remotely allow the device back into the network. Also, I can still continue my forensic analysis while the device is safely off the grid.


So what would happen next? Obviously, at this point someone from the SOC team, or whoever is monitoring the alerts, would need to investigate what happend, and help getting the device back into compliance. There are a couple of MDATP features worth exploring at this point (we won’t go through everything). MDATP shows you the process tree during the incident, which gives a nice overview of what happened:

 You can also check on individual files, and where they have been seen in the organization, in this case I’m looking at the WinATP-Intro-Backdoorexe.jpg:

You can also take the file hash and use it to drill down to the data using the advanced hunting functionality. This allows you to search the data directly from the MDATP logs using Kusto query language (same that is used with Log Analytics). There’s also a community that has produced useful examples, both for generic use as well as for identifying specific exploits ( In this case, I’m just looking into all the events involving this particular file.

Another useful feature is the ”Collect investigation package”:

This will pull all sorts of useful information from the machine and allow you to download it in zip format. This can be very useful when doing the forensic analysis.


So let’s say we’ve now concluded our investigations and cleaned up the machine. What next? We have to decrease the risk level of the machine for it to become compliant again. To do that, we have to resolve the alerts in the portal. You can also link alerts into incidents, as in this case all the alerts originating from this machine should all be related to a single incident.

Once all the alerts have been resolved, the risk level goes back to ”No known risks”. At this point, if we have isolated the machine, we could release it from the isolation (it took a couple of minutes for me to be able to reconnect my RDP session after the release).

And as expected, device status in Intune is back to compliant:

And I’m able to read my email again!

That concludes today’s experiments.

Tips&Tricks- Securing Activesync Access to Exchange Online with 365 MDM

I’ve always felt that Office 365 MDM is obsolete option between doing just Exchange ActiveSync Policies, and going the whole nine yards with true MDM capabilities (Intune)

Today I realized that you can do at least one thing with o365 MDM, separating it from plain Exchange mobile policy, and that is securing ActiveSync enrollment



Most (or all) mobile OS’s apart from native iOS mail-client are missing modern auth capable native mail client, thus securing ActiveSync enrollment with 2FA is sometimes seen as bit of an question.

It’s usually addressed with one, or combination of some of the following ways:

  1. By using Outlook mobile app
  2. By using app passwords ( I wouldn’t recommend app passwords even to my worst enemy)
  3. By Intune enrollment requirement
  4. By bypassing activesync for 2FA, and requiring admin release from quarantine
  5. Just bypassing activesync for 2FA

Now I am adding one more option to the list, (6) –  Office 365 MDM – Which is pretty much my top recommendation, if you need to use non iOS native mobile clients and/or don’t have Intune available

  • If you’re using Azure AD Premium P1, or 3rd party MFA with AD FS, and wan’t to offer strong enrollment before allowing ActiveSync access, but don’t have Intune, then I see this as pretty tempting way of achieving some additional security for ActiveSync:

Client experience

  • After adding the ActiveSync profile to the mobile phone user receives very similar mail to the classic quarantine message. This is only item in the mailbox. Thus no data is exposed to the user until further verification (2 FA requiring enrollment is done)


Service side settings

And in order for this setup to work

  • Block non-Office365 MDM supporting devices


  • Company Portal App and device join (Intune) has to require second factor, otherwise the protecting qualities of this setup are done
  • If you wan’t to allow non-ActiveSync clients in AD FS 3rd party create filtering rule, or configure CA to filter out ActiveSync in ’Client Apps’ settings


Thats it!

Br, Joosua




Cheat sheet: AD FS and Azure AD Hybrid Conditional Access

What is so great about AD FS 2016 + Azure AD Hybrid Device Join?

  • You get absolutely the best SSO experience with it – In fact it’s preferred over any 1 of the existing methods in terms of the use experience when used with W10 (Standard licensing)ADFSss
  • It works as seamless second factor for Azure AD Applications with Azure AD Conditional Access (AAD P1)
  • You can use it as seamless factor for your on-premises federations by requiring the presence of trusted claims in the request. In the absence of these trusted claims you can fall-back into standard 2-Factor Auth (AAD P1)
  • Hybrid Device Registration with AD FS is not dependent on AAD Connect to enable SSO on the device (AAD P1)
    • AAD connect Synchronization links the device to corresponding Azure Device, once the on-prem device satisfies required filter conditions in metaverse


  1. Please note, that Azure AD join is not something that replaces initial Sign-on modes, it still requires that initial sign-in has taken place before the device is paired with Azure AD to obtain SSO experience based on the PRT tokens

Major tips to get it right

Do I need any on-premises pointing device registration records to accomplish the scenario presented?

  • Absolutely none – In fact, if you look at the Device Registration Logs, you will find out that it explicitly states that local endpoints will NOT be enabled


DRS is in Hybrid AAD mode, registration endpoints will NOT be enabled.

Do I need to enable Device Authentication in the Authentication policies for Intra/extranet? 

No – The device authentication claims in this scenario are emitted as part of Windows, or Forms authentication. This happens with the AD DS Device Object and its properties in conjunction with Primary Refresh Token, which is accounted for in the Windows Login process,

  • While you need to have Device Registration enabled, you don’t need to enable device authentication as method in the authentication policies.



  • If you look at the claims with forms authentication and Extranet login, you will see the Device Claims that were emitted as part of the FormsAuthentication



Take note of the PRT claim – You wont find it in the RP’s login trace pipeline, because it’s formed at Windows Login

If you want to peek under the hood, and understand how these DRS claims end up in the same pipeline, then check DRS trace logs

Here DRS is checking for device match


”GetDeviceKeyFromKeyCredLink” &  GetDevice(ID,DC): 




Is it multi-factor authentication method?

Not in the context of AD FS, but conceptually it’s Multifactor Auth (one factor more added to the on-going authentication sequence)

Is there single important action that help will me in achieving the goal?

  • Yes, start with the newest version of the AAD Connect. It now supports both AAD HDJ and Writeback configuration during the setup without manual scripts AAD Connect 1.1.819.0
    • (DISCLAIMER: Do always review the changes made to AAD connect, and estimate if there is any change existing Relying Party trusts or sync related settings before proceeding)

What should I confirm before debugging anything else?

Coarse flow description

Example policy using Device-Based Conditional Access

1. Requiring presence of ’known device’ when accessing on-prem federations

  • This policy will ensure, that unknown devices will have to perform standard multi-factor authentication, whereas known devices will be granted access based on the presence of the ’isknown’ claim with value=True


Do I need Web Application Proxy

In my experience not, if you have capable reverse proxy, and opt for the Azure AD joined Domain devices. For Example KEMP VLM that can impersonate WAP for most of the features, and forward IP and Proxy information to AD FS via the use of headers1

This would have been different with the non hybrid device registration which requires that SSL is terminated at the WAP's directly

Extra stuff:

  1. One very welcome addition is, that the shared W10 and Server 2016 Devices don’t reserve this feature to only single user. Thus you get for example in remote desktop installation the Azure AD join SSO for multiple users.


Br, Joosua!