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

Introduction

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: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/attack-surface-reduction-exploit-guard#attack-surface-reduction-rules) 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 ConfigMgr)

Introduction

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 Configuration Manager Current Branch

Introduction

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)

Introduction

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

Introduction

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

Introduction

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: https://docs.microsoft.com/da-dk/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup

Configuration

  • Intune is now fully accessible through the Azure portal on https://portal.azure.com/ – 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.

Finally

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 https://outlook.office365.com 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. 🙂