Microsoft Intune and Conditional Access in a Co-management scenario


Last week I gave an example on how to leverage Microsoft Intune and Conditional Access to restrict access to Exchange Online for iOS devices. This week, I’m continuing the use of Microsoft Intune and Conditional Access, and will give an example on how to restrict access to company e-mail if not using a Windows 10 1803 device. All of this based on a computer co-managed with both Microsoft Intune and Configuration Manager.

So basically; no e-mails if not running on the latest and greatest version of Windows 10 on my co-managed device.

Read more…

Restrict access to Exchange Online using Microsoft Intune (and only grant access to company enrolled devices using the Outlook app)


Long title, but that’s actually what this post is going to cover; how you can secure the access to company e-mail accounts and only allow access to such, if coming from an enrolled (compliant) Intune device and that device uses the Outlook app.

In this scenario, we only uses iOS devices and of such only allow enrollment of iOS devices, but this can of course be android and Windows as well. Everything in this post is achievable with the use of Microsoft Intune and Conditional Access in Azure. Curious? Read on 🙂

Read more…

How to renew Apple Push Certificate in Microsoft Intune standalone


I have previously done a short post on how to renew the Apple Push Certificate when having Intune integrated with Configuration Manager (Hybrid). Since then, I’ve changed the MDM authority to Intune standalone and therefore the procedure changes slightly. Again, this is taken directly from an production environment and my certificate was due to expire in roughly 30 days. For the curious, this is the exact steps I went through to renew our Apple Push Certificate in Microsoft Intune standalone.

Picture of the front page of the Apple Push Certificate portal

Read more…

Flipping the switch, part 2.1: Exploit Guard challenges (Co-management with Intune MDM and SCCM)


Just quickly following up on my previous post, on how I moved some of the Endpoint Protection workloads into Intune MDM (in a Co-management scenario with Configuration Manager). More specifically, I moved the Exploit Guard capabilities and while walking through the process, I mentioned the possible impact of Exploit Guard in an enterprise environment.

Again, this post is to highlight the possible impact of turning on a very specific ASR (Attack Surface Reduction) rule in Exploit Guard. Turns out, that this specific rule is not documented by Microsoft (at least I can’t find it in the Exploit Guard documentation: and the impact is quite significant to those using Configuration Manager (and possible other stuff too). Curious? Keep reading 🙂

What Attack Surface Reduction rule?

The rule in question is having an ID of: D1E49AAC-8F56-4280-B9BA-993A6D77406C. This is not mentioned anywhere in the Exploit Guard documentation. In Intune, it’s the one I’m highlighting below:

Read more…

Flipping the switch, part 2: Moving Endpoint Protection workloads to Intune MDM (Co-management with SCCM)


Continuing the Co-management journey from last week, where I went through the steps required to setup co-management with Configuration Manager. This week I’m moving the Endpoint Protection workloads into Intune MDM. The ability to transition the Endpoint Protection workloads is brand new, and became available in Configuration Manager 1802. As of now, the endpoint protection workloads consists of following features:

  • Windows Defender Application Guard
  • Windows Defender Firewall
  • Windows Defender SmartScreen
  • Windows Encryption (BitLocker)
  • Windows Defender Exploit Guard
  • Windows Defender Application Control
  • Windows Defender Security Center
  • Windows Defender Advanced Threat Protection

Following walkthrough is exactly how I moved some of the Endpoint Protection features (more specifically Exploit Guard and some modifications to the Defender Security Center) into Intune MDM for at pilot group consisting of computers.

Endpoint Protection device configuration profiles

Read more…

Flipping the switch: How to enable Co-management in SCCM Current Branch (System Center Configuration Manager)


Co-management! This will be a quick post, because it’s actually quite easy to setup. It was announced last year at Ignite in Orlando and it’s being pushed heavily these days by Microsoft. For those who don’t know the ups and downs, co-management is basically (for those using ConfigMgr already) managing computers with both a Configuration Manager client and Intune MDM. There are different possibilities to achieve co-management, and even a possibility without ConfigMgr. It sounds complicated, but it’s not. I will walk you through the few steps required, as well as cover the precise prerequisites and how to troubleshoot issues if any. Note: This is precisely how I have done in a production environment. Curious? Read on 🙂

My 2 devices being co-managed

Read more…

Remove inactive devices in Intune automatically using Microsoft Graph API and Powershell (and a scheduled task)


Just like we do in Configuration Manager, Active Directory, Exchange and anywhere else (where possible), It’s a good idea to keep things clean (at least I think so). Clean in terms of removing inactive computers, objects, mailboxes and so forth. This brings me to Microsoft Intune and how we can leverage Microsoft Graph API through Powershell to automatically remove inactive devices, and doing so on a schedule through a scheduled task. Curious? Read on 🙂

Example of devices that haven’t checked in for 30 days

Read more…

Change device ownership in Microsoft Intune standalone using Microsoft Graph API and Powershell


When enrolling devices into Microsoft Intune using the Company Portal, the devices end up enrolling as personal owned. This can be changed manually on each device directly in the Intune portal after enrollment. Making sure that all devices are company owned refines management and identification, as well as enabling Intune to perform additional management tasks. Also, for additional security, you can configure device restrictions to block enrollment of devices that are not company owned.

But what if we don’t like to do stuff manually and have hundreds or thousands of devices? Automation through Microsoft Graph API and Powershell to the rescue.

Read more…

How to Conditional Access for Exchange Online OWA (Webmail) using Intune


While brewing on a much more detailed post on how I moved my devices from Intune Hybrid with ConfigMgr to Intune standalone, I thought I’d share how you can offer webmail for your users, while requiring MFA (Multifactor Authentication) if not coming from a company device, using Conditional Access.

In this post I will only cover the actual steps in Intune, but for this to work, you will have to have your Windows devices registered with Azure AD. There will be some requirement for your on-prem AD and for your ADFS, if that’s how you federate with Azure/O365. These requirements are explained in details in this Microsoft article:


  • Intune is now fully accessible through the Azure portal on – head over there and sign in
  • When signed in, look for More services in the menu and search for Intune

  • In the Intune section of the Azure portal, click on the Conditional Access menu button

  • Create a new Conditional Access policy on New policy and give it a name f.i. Conditional Access – OWA

  • Assign the new CA policy to a group consisting of users. For your inspiration, I’m syncing an on-premise security group consisting of users already assigned an EMS license, as Conditional Access in Intune requires an EMS license. This will probably vary depending on your needs, setup and design goals, but I recommend that there is some synergy between whom is assigned EMS licenses, and whom you are targeting with policies in Intune (for the sake of doing proper IT 🙂

  • Select Exchange Online in Cloud apps

  • As conditions, make sure that all device platforms are selected (as we’d like to target any browser on any platform) and select Browser in the Client apps menu.

  • In Access controls, select 1) Require MFA, 2) Require device to be compliant and 3) Require domain joined (hybrid Azure AD) and select that only one of these controls needs to be satisfied. Doing exactly this configuration, will make sure that if you are coming from a private device (hence not compliant and not domain joined) will trigger MFA when accessing webmail. On the other hand, coming from an Intune enrolled AND compliant device OR a domain joined PC will not require MFA.


Before enabling the policy, I recommend that you take a closer look at the new preview feature for Conditional Access, WhatIf. It will let you know the impact of your new CA policy by setting the desired conditions. It will also tell you, if you have configured any legacy CA policies in the old silverlight Intune portal which might interfere with your new CA policies.

Now, when signing into from my private computer, I’m required to approve the sign in request through my prefered MFA method.

Enjoy your new Conditional Access policy requiring MFA when signing into webmail (OWA) on a private device. 🙂