Intune

Why are my Intune devices no longer compliant? Rolling out new compliance policies, raising minimum OS versions, or adjusting other controls can all cause devices to drift out of compliance. Ultimately, this impacts resource access whenever Conditional Access enforces a compliant device. If you forward the IntuneOperationalLogs to a Log Analytics workspace1, you can query, parse, and alert on non-compliance events with just a few lines of KQL: Anonymized example of noncompliant devices IntuneOperationalLogs | where OperationName == "Compliance" | extend Properties = parse_json(Properties) | evaluate bag_unpack(Properties) | where AlertType == @"Managed Device Not Compliant" | extend UserPrincipalName = iif(UserDisplayName != "System account", strcat(UserName, '@', UPNSuffix), "System account") // Extract the reason | extend ReasonRaw = tostring(split(Description, '||')[0]) // Parse the compliance Policy ID | parse ReasonRaw with ReasonParsed:string "_IID_" PolicyIdRaw:string | extend Reason = coalesce(ReasonParsed, ReasonRaw) | extend PolicyId = coalesce(PolicyIdRaw, 'DefaultDeviceCompliancePolicy') | project-away *Raw | project-reorder TimeGenerated, UserPrincipalName, DeviceHostName, IntuneDeviceId ,Reason, PolicyId Note The Properties column is a serialized JSON string that holds all the non-compliance details. The bag_unpack plugin2 expands every property in the bag into its own column, which keeps the rest of the query much simpler.

Did you know that the maester framework now supports Microsoft Intune checks? In this blog post, I’ll give you a quick overview of the new capabilities and how to get started. About Maester # Maester is an open-source security assessment framework that helps you evaluate the security posture of your Microsoft Entra ID and Microsoft 365 environments. It provides a collection of tests that can be run against your tenant to identify potential misconfigurations and security risks. After executing the tests, maester generates a detailed report that highlights the findings and provides recommendations for remediation: Intune Related Checks # The great thing about maester is that it’s highly extensible, allowing you to add custom tests and checks based on your specific requirements. To share some Intune best practices with the community, I contributed a set of Intune related checks to the maester framework. The following Intune checks are now available in maester: MT.1090 - Global administrator role should not be added as local administrator on the device during Microsoft Entra join MT.1091 - Registering user should not be added as local administrator on the device during Microsoft Entra join MT.1092 - Intune APNS certificate should be valid for more than 30 days MT.1093 - Apple Automated Device Enrollment Tokens should be valid for more than 30 days MT.1094 - Apple Volume Purchase Program Tokens should be valid for more than 30 days MT.1095 - Android Enterprise account connection should be healthy MT.1096 - Ensure at least one Intune Multi Admin Approval policy is configured MT.1097 - Ensure all Intune Certificate Connectors are healthy and running supported versions MT.1098 - Mobile Threat Defense Connectors should be healthy MT.1099 - Windows Diagnostic Data Processing should be enabled MT.1100 - Intune Diagnostic Settings should include Audit Logs MT.1101 - Default Branding Profile should be customized MT.1102 - Windows Feature Update Policy Settings should not reference end of support builds MT.1103 - Ensure Intune RBAC groups are protected by Restricted Management Administrative Units or Role Assignable groups MT.1105 - Ensure MDM Authority is set to Intune Example # To run the tests you can simply run:

Did you know that for the new Windows LAPS Azure AD is also maintaining the password history? The built in PowerShell commandlet relies on the Microsoft Graph PowerShell SDK and within this post I want to show you how to work with the Get-LapsAADPassword cmdlet. Kudos to Niklas Tinner as he brought this to my attention while working together. Where is this command originating from? # The Get-LapsAADPassword cmdlet is part of the LAPS PowerShell module that was baked into the Windows Operating system with the April 2023 quality updates. The module is maintained as part of the Operating System and builds the Interface to interact with Windows LAPS locally on a device. The module binaries reside within C:\Windows\system32\WindowsPowerShell\v1.0\Modules\LAPS and consist of DLLs and PowerShell files: Let’s retrieve some passwords # Before we can start retrieving passwords we need to make sure, that we have the appropriate Microsoft Graph PowerShell SDK module present. We can easily check this with the following PowerShell command: Get-Module -Name Microsoft.Graph -ListAvailable If you do not retrieve any output, you need to install the module with local Administrator privileges with:

Loooooong awaited and it’s finally here - the new Windows LAPS. With the previous announcement(s) of the integration into the native Windows operating system and support for Azure AD join this was a long-awaited feature. With the recent patch Tuesday the binaries were backed and delivered natively into the current Windows client and Server OS and today they also launched the Azure AD backend that can serve as the backup source for passwords. Within this post, I want to give you a quick impression of what the deployment experience currently looks like and where I needed some adjustments to get the expected result. Setup # Prerequisites # To deploy LAPS with Azure AD password backup and Intune you need licenses/access to those tools and Windows 10/11 devices with the latest April patches installed. A full list of prerequisites is provided by Microsoft here. Azure AD enablement # Unlike the on-premises AD LAPS enablement we do not need any schema extensions and can simply enable the following toggle within our Azure AD device settings:

Intune Endpoint Security Configuration Settings have become the way to go for configuring security features on various platforms. What did start with Microsoft Defender for Endpoint settings for Windows clients has evolved to settings for macOS, Windows Servers and is treated like a first class citizen. So it is important to guard those sensitive configurations as they control (and can potentially disable) vital security features on endpoints such as defender tamper protection, attack surface reduction rules, firewall and many more. Within this post I want to show you an approach to monitor changes to Intune Endpoint security settings with Microsoft Sentinel and watchlists that can be easily customised based on your environment and needs. My main idea is to classify the sensitive configurations in the environment and only creating incidents for those. Of course you could alert on every Intune configuration change but for most of the environments this would lead to many alerts without providing value. Prerequisites # Changes to the Intune Endpoint security settings area are visible like other changes within the Intune Audit Logs. To have the audit events within our Sentinel workspace we need to enable the forwarding for at least AuditLogs. This can be done within the Intune Tenant Administration > Diagnostic Settings blade.

The Microsoft Store for Business will be discontinued mid 2023 and Intune recently introduced the new Windows Store experience backed by winget to distribute apps to your Intune managed endpoints. To simplify the migration to the new Windows Store experience I created a PowerShell Script that migrates all currently assigned Windows Store for Business apps to the new Windows Store experience. Kudos to Sander Rozemuller for providing detailed instructions about creating winget apps as PowerShell code samples. Challenges # While scripting and extracting the existing Windows Store for Business (WSfB) apps I encountered the following issues: Not all apps in WSfB have valid privacy and information URLs, therefore I added a check whether the URL starts with http(s). Some apps have characters present (äöüë….) that require UTF-8 encoding. So I explicitly set the HTTP content-type header to UTF8. Script prerequisites # To run the script you need to have the Microsoft Graph PowerShell SDK modules installed on your machine. You can install them with the following command: Install-Module Microsoft.Graph.Authentication, Microsoft.Graph.Devices.CorporateManagement -Scope CurrentUser From a permissions perspective you need an Azure AD Application Administrator for the initial OAuth permission consent and for regular execution the Intune Administrator role.

A common pitfall in environments where Windows server is used for radius authentication is that Microsoft network policy server (NPS) does currently not support device based authentication for Azure AD joined devices. NPS always checks for the existence of a corresponding computer object in AD. For my home setup and lab I wanted to build a radius solution to enable 802.1x authentication on my Wi-Fi network. Disclaimer # This post describes my setup and does not cover prerequisites like certification authority, certificate revocation and client certificate deployment via SCEP. Furthermore you should be familiar with docker, network topics, dns and Intune. Available solutions # Well known commercial Network Access Control (NAC) solutions like CISCO ISE or Aruba Clearpass often ship with an integrated RADIUS server and the possibility to configure wheter LDAP lookups for computer accounts should happen. Important is, that the solution supports certificate revocation checks either via CRLs or OCSP to ensure network access is blocked when a client certificate is revoked. For my home and lab setup I wanted to leverage a free or open source solution and decided to use freeRADIUS, probably the most popular open source radius server. freeRADIUS supports EAP-TLS for 802.1x authentication out of the box and is well documented. Additionally, I was looking for a solution that can be deployed to both locallly in my network (e.g. on a raspberry pi) and also to PaaS offerings like Azure.

Android enterprise dedicated devices with the Microsoft Managed Homescreen app are a conenient way to provide devices with restricted functionality and customized look and feel to end users. Because the Managed Homescreen app acts as an overlay to the underlying Android certain prompts and features are not enabled by default unless you allow-list them by deploying the corresponding Android System App and add the app to the kiosk device restrictions. System Apps # System apps can be added as separate app type within MEM: It is important to deploy the desired system apps as required to your devices and also adding them within the kiosk configuration: List of commonly used System apps for Samsung devices # Based on a recent project where we had Samsung devices in place we allow-listed the following system apps within the kiosk configuration: Description App Bundle ID USB File Transfer Prompt Android Version < 12 com.samsung.android.MtpApplication USB File Transfer Prompt Android Version >= 12 com.android.mtp Android System UI (used for a variety of prompts) com.android.systemui Service Mode App (USB prompts) com.sec.android.app.servicemodeapp Knox license prompts com.samsung.android.knox.pushmanager Samsung Android update prompts com.wssyncmldm Knox smdms com.sec.enterprise.knox.cloudmdm.smdms Knox container core com.samsung.android.knox.containercore Knox attestation com.sec.enterprise.knox.attestation Keyboard changes com.samsung.android.honeyboard An indicator to decide wheter you need to add an app to the list is always when you can see the prompts outside of the managed homescreen app after leaving the kiosk mode. {: .notice–info}

When you are new to RESTful APIs and want to start with Microsoft Graph to automate tasks in your Endpoint Manager tenant all the stuff about app registrations, access tokens, pagination and request headers can be quite confusing. In this post I want to show you a quick tip to kickstart your Microsoft Graph API experience. Requirements # Cloud admin account with Intune Administrator role assigned Ability to install Modules from the PowerShell gallery JWT # Just because you can’t see it… doesn’t mean it isn’t there: Due to the naturality of OAuth 2.0 and OpenID connect (these are the protocols involved for authorization and authentication in a cloud environment) we can capture short lived access tokens, also called Json Web Tokens (JWTs) directly from a browser. Tokens are usually valid between 50 and 60 minutes - just what we need to get some hands on with Microsoft Graph API and MEM automation. The cool thing is actually that we don’t need any kind of app registration or additional permissions which can be quite some blocker in certain restricted environments (or staff unfamiliar with those technologies 😉).

App protection (also called MAM) policies have been around for a couple of years within MEM and I already used them in various projects to protect company data on unmanaged iOS and Android devices. One of the drawbacks with this approach is that we do not have full visibility about the usage and I tried to shed some light about this with a PowerShel reporting script that pulls data from the Microsoft Graph API. Information visible within the portal # In the MEM portal we can find report data about the number of users that have checked-in to any MAM policy grouped by the respective app. If we want to perform a wipe we will also be able to see the devices a user has registered: Of course I was curious which additional data is available on the Microsoft Graph API and found the following resource storing app protection policy check in details: /users/{ID}/managedAppRegistrations. Script # The script uses the Intune PowerShell SDK (could easily be ported to MSAL.PS because I wrote it already a couple of months ago) to enumerate all internal users within the tenant and will check the above mentioned managedAppRegistrations resource. At the end you are presented a flattened CSV report containig the following details: