Do you need a simple, but yet effective way of forcing people into updating iOS on their company enrolled Apple devices? Simply block access to company resources if iOS is not up to date. Here is how you can do that using Microsoft Intune and Conditional Access in Microsoft Azure.
Again, continuing the Co-management and flipping the switch journey, and moving the brand new Device Configuration workload to Intune MDM. This is the latest addition to the co-management world introduced in Configuration Manager 1806 (released 2 days ago at time of writing) and it’s absolutely amazing.
This means we finally (almost) can ditch group policies altogether and do our device configurations with Intune MDM. I will give you how to and an excellent example in this post. Read on. 🙂
This will be something completely different and new coming from my end. So please be aware; a lot of strong coffee is potentially needed. That be, because I usually talk about how to do something technically around Configuration Manager and MicrosoftIntune, or something technically related to those topics, and the typical reader would probably expect content in that context.
This time I’m going beyond that. “Why?” you may ask. Because I felt like giving back with a topic and content that I know that can make a difference. Not just limited to a specific technical topic, but as a whole, make a difference on how one will succeed in general with Configuration Manager and Microsoft Intune (and possibly other stuff too).
I believe in helping and promoting others, and as of such, I will give you 5 (and possibly some unique) advice on how you can improve and strengthen your SCCM and Intune knowledge. (No guarantees though, but the bullets mentioned in this post helped me a lot)
I have previously given a few examples on use cases for Conditional Access, and I admit, for the Conditional Access newbie, the options available can seem daunting. So how about a very simple scenario, where access to company resources are blocked, if not coming from a trusted IP?
Imagine service accounts running some Powershell scripts for automation in your Azure/O365 tenant or other accounts who are never meant to be used outside of your organization. Simply block those from authenticating in Azure/O365 if not coming from your headquarter public IP. This is how you can do just that, using Conditional Access.
Continuing on the Co-management and flipping the switch journey. I have previously been going through how to initially enable Co-management with Configuration Manager and Microsoft Intune, and how to move some of the Endpoint Protection workloads to Intune MDM.
This time I will walk you through how I moved the Software Updates workload from Configuration Manager to Intune MDM. Everything still based on a production environment and along the lines some additional ramblings on the topic.
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.
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 🙂
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.
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.
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:
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 workload is brand new, and became available in Configuration Manager 1802. As of now, the endpoint protection workload 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.