Linux devices in Intune (Ubuntu, RHEL): enrollment, compliance and common errors

Linux desktops are managed in Intune through one app, the Microsoft Intune app (package intune-portal), working together with the Microsoft identity broker and Microsoft Edge. When something breaks, the cause is usually an unsupported distribution, an agent that stopped checking in, or a compliance setting the device can't meet. In this post I'll cover what's supported, how enrollment and compliance work, where the logs are, and how to fix the common errors.

Symptoms#

• The Intune app says registration finished, but the device never shows up in Intune, or it shows compliance as Not evaluated.
• After a broker update to 2.0.2 or later, the device has new Intune and Entra device IDs, and assignments tied to the old IDs miss it.
• The device is Not compliant, and the Intune app's compliance issues page tells the user what to fix, such as encrypting the drives or using a stronger password.
• Microsoft 365 web apps in Microsoft Edge are blocked by Conditional Access:

AADSTS53000: Device is not in required device state: compliant. Conditional Access policy requires a compliant device, and the device is not compliant.

• After an in-place distribution upgrade, registration fails and the device broker's journal shows the following line (reported by admins):

Unable to derive key material as unable to find the derivation key for alias

Why it happens#

The device isn't on the supported list#

Microsoft's current list (re-check it, because it changes with each LTS release) is Ubuntu Desktop 24.04 LTS or 26.04 LTS on a physical or Hyper-V machine with x86/64 CPUs, and Red Hat Enterprise Linux 9 or 10. Anything else, such as older releases, Ubuntu Server, Arm hardware or VMs on other hypervisors, may install the app and then fail in unpredictable ways.

How enrollment and check-in work#

The user signs in to the Intune app, which registers the device in Microsoft Entra ID and enrolls it in Intune. After that, the app checks in through a background task while the computer is on and a user is signed in. Microsoft Edge, signed in with the same work account, relies on the identity broker to prove the device's identity to Conditional Access. If the user never signs in to the desktop session, or the user services fail, the device stops reporting, and after the tenant's Compliance status validity period it's marked not compliant.

A broker update re-enrolled the device#

Devices that update to broker 2.0.2 or later get new device IDs, so device-based assignments, filters and Entra group memberships that relied on the old IDs can stop applying. Users must also be allowed to join devices to Microsoft Entra, not only register them.

Compliance settings the device can't meet#

Linux compliance policies are built from the settings catalog:

Tenant-wide compliance settings also apply; see the default device compliance policy explained.

How to fix it#

1. Confirm the platform. ID and VERSION_ID must match the supported list, the architecture must be x86_64, and virtualization must be none (physical) or microsoft (Hyper-V):
   Bash

   grep -E '^(ID|VERSION_ID)=' /etc/os-release
   uname -m
   systemd-detect-virt

2. Update the Intune app and Edge from packages.microsoft.com:
   Bash

   # Ubuntu
   sudo apt update && sudo apt install --only-upgrade intune-portal microsoft-edge-stable
   # RHEL
   sudo dnf upgrade intune-portal microsoft-edge-stable

3. Check the services and read the logs. List the Intune and broker units first, because names change between versions. Packages with the older Java-based broker install a user-level intune-agent timer and service plus microsoft-identity-broker, and a system-level microsoft-identity-device-broker:
   Bash

   systemctl --user list-units --all 'intune*' 'microsoft-identity*'
   systemctl list-units --all 'intune*' 'microsoft-identity*'
   journalctl --user -u intune-agent.service --since today
   sudo journalctl -u microsoft-identity-device-broker.service --since today

   Failed units or repeated errors on every check-in point you to the broken component.
4. Check the Entra and Intune side. The user needs an Intune license, the Microsoft Entra setting Users may join devices to Microsoft Entra (Devices › Device settings) must allow them, and they must be under the device limits in Entra ID and Intune. After a broker update, fix targeting tied to the old device IDs. Delete stale records for the same machine (see device cleanup rules).
5. Reset a broken registration. On Ubuntu, sudo apt remove intune-portal followed by sudo apt purge intune-portal removes the app and the local registration data. On RHEL, sudo dnf remove intune-portal removes only the app; Microsoft's install page lists separate rm -rf commands for the registration data. They delete folders under /opt/microsoft/mdatp and related paths, which Microsoft Defender for Endpoint also uses, so check them before running them on a device with Defender. Reinstall, restart and register again, then delete the old device record. For the derivation-key error after a distribution upgrade, admins report that purging microsoft-identity-broker as well before reinstalling clears it.
6. Fix encryption. Check every writable partition: encrypted ones sit on a crypto_LUKS partition with a crypt device above them.
   Bash

   lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT

   Encrypting after installation is possible but slow, and Microsoft recommends enabling encryption during OS installation, so reinstalling with encryption is often the quickest fix.
7. Fix the password rules. Make the device enforce complexity at least as strict as the policy. That normally means the pam_pwquality settings in /etc/security/pwquality.conf; RHEL uses the module by default, while on Ubuntu you install libpam-pwquality first. Negative values mean "at least this many":
   Text

   minlen = 12
   dcredit = -1
   ucredit = -1
   lcredit = -1
   ocredit = -1

8. Fix the policy itself. Add an Allowed distributions entry for every distribution and version you support, and test custom compliance scripts as described in custom compliance with discovery scripts and JSON.
9. Fix browser access. Users must open Microsoft 365 in Microsoft Edge, signed in to a profile with their work account. In the Microsoft Entra sign-in log, an empty device ID means the browser didn't pass the device identity (another browser, or an Edge profile without the work account); a device ID with Compliant: No means the problem is compliance. More codes are in the AADSTS quick reference.

Verify the fix#

• In the Intune app, select Refresh on the device details or compliance issues page to start a check-in; if the app is closed, opening it and signing in does the same. The device should show as compliant.
• In the Intune admin center, under Devices › By platform › Linux, the device shows Compliant with a recent check-in time.
• The Microsoft Entra sign-in log for an Edge sign-in shows the device as compliant and managed, with Conditional Access Success.
• The intune-agent journal shows check-ins without repeated errors.

Prevent it next time#

• Allow only supported releases in your compliance policy, and test a new LTS before raising the maximum version.
• Turn on encryption when you install the OS, not afterwards.
• Treat in-place distribution upgrades on enrolled devices as a change that may need re-registration, and test them first.
• Before broker 2.0.2 arrives, allow users to join devices to Microsoft Entra and list the assignments, filters and groups needing the new IDs.
• Keep intune-portal, the identity broker and Edge updated from Microsoft's repository.

References#

• Get the Microsoft Intune app for Linux (Microsoft Learn)
• Device compliance settings for Linux in Intune (Microsoft Learn)
• Deployment guide: manage Linux devices in Microsoft Intune (Microsoft Learn)
• Microsoft single sign-on for Linux (Microsoft Learn)