We value your privacy

We use cookies to analyse site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Intune and MDM
  3. Linux management
Microsoft Intune for Linux desktops, UAE

Intune manages Linux desktops. It does not manage them the way it manages Windows, and the difference is the whole conversation.

The Linux capability is compliance and Conditional Access, not full device configuration. Four distributions are supported, the user enrols their own device, and what Conditional Access protects is Microsoft 365 web applications in Microsoft Edge. Understood correctly it closes a real gap. Assumed to be Windows management, it disappoints.

Book a Linux management reviewSee what is actually supported
Microsoft Intune Linux desktop management for UAE organisations
  • Four distributionsUbuntu LTS 26.04 and 24.04, RHEL 9 and 10
  • Compliance firstDistribution, version, encryption, password
  • Bash scriptsCustom compliance for anything else
  • Edge, on LinuxWhere Conditional Access takes effect
What it does

Seven things that set the honest boundary of Linux management in Intune.

Microsoft describes three components powering Linux desktop management: Intune for device management and compliance, Entra ID for Conditional Access used alongside compliance policies, and Microsoft Edge as the browser providing protected access to Microsoft 365 web applications. That sentence defines both the capability and its limits.

Four distributions, and nothing else

Microsoft states enrolment is supported on Linux desktops running Ubuntu long term support version 26.04 and 24.04, Red Hat Enterprise Linux 9 and Red Hat Enterprise Linux 10. That list is short and specific. Organisations running Debian, SUSE, Fedora or an older Ubuntu release need a different answer, and finding that out first prevents a wasted evaluation.

Compliance is the control, not configuration

Compliance policies can be enforced based on Linux distribution type, version, device encryption or password complexity, with all available Linux compliance settings living in the Intune settings catalog. That is a genuine control and it is a different thing from configuring a device. The value comes from what compliance then gates rather than from what it sets.

Conditional Access protects Microsoft 365 web apps in Edge

Microsoft is precise about scope. Conditional Access protects and grants access to Microsoft 365 web applications in the Microsoft Edge browser for Linux, blocking non-compliant devices and granting access to compliant ones. It also states you must have a device compliance policy for Conditional Access to work with Linux devices at all.

Custom compliance through Bash scripts

Where the built-in compliance options do not cover a scenario, Microsoft supports writing your own Bash scripts, with a custom script identifying the settings and value pairs to be evaluated. That is the escape hatch, and in practice it is how organisations express requirements around specific packages, kernel versions or local configuration state.

Users enrol their own devices, and administrators enable nothing

Microsoft states that employees assigned Intune licences can enrol their personal Linux devices whenever they want, that during enrolment the device is registered with Entra ID and evaluated for compliance, and that as an administrator you do not need to do anything to enable enrolment beyond the prerequisites. That shapes the rollout as a communications exercise rather than a technical one.

Two client requirements the user installs themselves

The Microsoft Intune app for Linux, installed by the employee in the Terminal application, and the Microsoft Edge browser at version 102 or later. Both are user actions, which means the deployment plan is documentation, communication and a support path rather than a push from a management console.

Device identifiers changed with the new identity broker

Microsoft warns that versions 2.0.2 and later of the Microsoft Identity Broker introduce a major architectural change from the previous Java-based broker, that Intune automatically re-registers and re-enrols devices updating from earlier versions, and that this creates new Intune and Entra device identifiers. Anything relying on device identifiers has to be reviewed afterwards.

The change that silently breaks assignments

The new identity broker creates new device IDs, and anything keyed to the old ones stops matching.

Microsoft publishes this as an important note, and it is the kind of change that produces a policy that quietly stops applying rather than an error anybody sees.

  • Quoted: versions 2.0.2 and later of the Microsoft Identity Broker included with the Microsoft Intune app for Linux introduce a major architectural change from the previous Java-based broker.
  • Quoted: when Linux devices update from earlier broker versions, Intune automatically re-registers and re-enrols those devices and creates new Intune device IDs and Microsoft Entra device IDs for them.
  • Quoted: after devices update, review device-based assignments, filters, and Microsoft Entra ID group memberships that rely on device IDs to ensure that policies apply correctly.
  • The failure mode matters. A device that has been re-registered under a new identifier is not in the group it used to be in, so the compliance policy targeted at that group no longer reaches it, and the device continues working normally right up until Conditional Access refuses it. Checking after the update is a small task that avoids an unexplained access failure.
Ask us to review your device-based assignments
How we approach it

Four things that make a Linux rollout land properly.

The failure mode here is not technical. It is an expectation set at the start that Intune will manage Linux the way it manages Windows, followed by disappointment when it does something narrower and genuinely useful.

We set the scope honestly on day one

Compliance and Conditional Access for Microsoft 365 web applications in Edge. That is what the published guide describes and it is what we say. Positioned that way, it closes a real gap for organisations whose developers have been outside every control. Positioned as full device management, it produces a project that gets judged against something it was never going to do.

We use custom Bash compliance where the built-ins run out

Distribution type, version, encryption and password complexity cover a useful baseline and stop well short of what an engineering team might need to prove. Custom compliance settings with your own Bash scripts, identifying settings and value pairs, are where the specific requirements live, and they need the same review discipline as any other script.

We treat the rollout as communication, because it is

Users install the Intune app themselves in the terminal, install Edge themselves, and enrol themselves. Microsoft own guidance notes you will not be there when they do it, and recommends a communication plan. It also recommends telling people about encryption requirements before enrolment, since encrypting during operating system installation is easier and faster than afterwards.

We check device identifiers after the broker update

The move to identity broker 2.0.2 and later re-registers and re-enrols devices with new Intune and Entra device identifiers. Anything keyed to those identifiers, meaning device-based assignments, filters and Entra group memberships, has to be reviewed afterwards, and Microsoft says so directly. Skipping that check produces policies that silently stop applying.

Where this fits

Six UAE situations where Linux enrolment closes a real gap.

The pattern is consistent. A capable technical population running Linux by choice, outside the compliance and access controls that everybody else is subject to, and a security function that has no visibility of them at all.

A development team running Ubuntu by preference

Developers frequently hold the most sensitive access in an organisation and the least managed machines. Enrolling them brings distribution, version, encryption and password state into view, and Conditional Access ensures a non-compliant machine cannot reach Microsoft 365 web applications in Edge. Both are meaningful improvements on nothing.

A regulated firm asked about non-Windows endpoints

The uncomfortable audit question is not whether Linux is allowed, it is whether anybody can describe the security state of the Linux machines that exist. Compliance policies covering encryption and password complexity, with actions for noncompliance and a documented Conditional Access position, is a defensible answer where previously there was none.

A group that has quietly accumulated Linux machines

Usually through acquisitions, contractors or a team that made a decision years ago. Because enrolment is user initiated and needs no administrator enablement beyond the prerequisites, the rollout can be run as a communication exercise to a known population rather than as an infrastructure project.

An engineering business with Red Hat workstations

Red Hat Enterprise Linux 9 and 10 are both supported for enrolment. For organisations that standardised on Red Hat for engineering or laboratory workstations, that means the same compliance and Conditional Access model applies to those machines as to the rest of the estate, without a separate product.

An organisation with a specific technical control to prove

Custom compliance settings using your own Bash scripts address scenarios the built-in options do not cover, with a custom script identifying settings and value pairs. Where an obligation or an internal standard names a specific package, configuration file or service state, that is how it becomes an enforceable compliance condition.

An institution with research and lab machines

Academic and research computing runs on Linux, often on machines nobody centrally manages. Enrolment brings them into the same compliance view as the rest of the estate, and the noncompliance actions available, alerting, remote lock and retire, give a proportionate response rather than a binary allow or block.

Three positions

How UAE organisations handle Linux desktops today.

The middle column is the norm in engineering and development teams: capable people running their own machines, outside every control the rest of the organisation is subject to.
Device known to the organisation
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Encryption verifiable
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Password complexity enforced
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Distribution and version tracked
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Custom checks possible
Enrolled with compliance and Conditional AccessYes, via Bash
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Non-compliant devices blocked from work apps
Enrolled with compliance and Conditional AccessYes, in Edge
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Remote lock or retire available
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Users have a supported path
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNot applicable
Linux banned by policy, used anywayNo
Audit answer for Linux access
Enrolled with compliance and Conditional AccessEvidence
Unmanaged developer machinesNone
Linux banned by policy, used anywayPolicy only
Administrative effort
Enrolled with compliance and Conditional AccessLow
Unmanaged developer machinesNone
Linux banned by policy, used anywayNone
Feature
Enrolled with compliance and Conditional Access
Unmanaged developer machines
Linux banned by policy, used anyway
Device known to the organisation
YesNoNo
Encryption verifiable
YesNoNo
Password complexity enforced
YesNoNo
Distribution and version tracked
YesNoNo
Custom checks possible
Yes, via BashNoNo
Non-compliant devices blocked from work apps
Yes, in EdgeNoNo
Remote lock or retire available
YesNoNo
Users have a supported path
YesNot applicableNo
Audit answer for Linux access
EvidenceNonePolicy only
Administrative effort
LowNoneNone
The honest boundary

What Intune does for Linux, and what it does not.

Drawn from the published deployment guide. The second column is what the guide states, and anything it does not state is not claimed here.
CapabilityPosition for Linux
Supported distributionsUbuntu LTS 26.04 and 24.04, Red Hat Enterprise Linux 9 and 10
EnrolmentUser initiated, on personal devices, with no administrator enablement beyond the prerequisites
Device registrationRegistered with Microsoft Entra ID during enrolment, and evaluated for compliance
Compliance settingsDistribution type, version, device encryption and password complexity, all in the settings catalog
Custom complianceYour own Bash scripts, using a custom script that identifies settings and value pairs
Conditional Access scopeMicrosoft 365 web applications in the Microsoft Edge browser for Linux
Conditional Access prerequisiteA device compliance policy is required for Conditional Access to work with Linux devices
Actions for noncomplianceSending alerts, remotely locking devices, or retiring devices
Required client softwareThe Microsoft Intune app for Linux, and Microsoft Edge version 102 or later
Least privileged administrative roleThe built-in Policy and Profile Manager Intune role for enrolment tasks
How an engagement runs

Five steps, and most of the work is written rather than configured.

Typically three to six weeks. The Intune configuration is small. The communication material, the support path and the compliance design are what determine whether people actually enrol.
  1. 1

    Establish the population and the distributions

    Which machines exist, who has them, and which distributions they run against the supported set of Ubuntu long term support 26.04 and 24.04, and Red Hat Enterprise Linux 9 and 10. Anything outside that list needs a different answer, and knowing the proportion up front determines whether this is a full solution or a partial one.

  2. 2

    Confirm prerequisites and the administrative model

    Users and groups in place, Intune licences assigned, and the mobile device management authority set. Administration performed with the built-in Policy and Profile Manager role, which Microsoft names as the least privileged role that can complete device enrolment tasks, rather than a broader role used out of habit.

  3. 3

    Design compliance, including the custom checks

    Built-in settings covering distribution type, version, device encryption and password complexity, configured from the settings catalog. Custom compliance using Bash scripts where a specific requirement is not covered. Then the actions for noncompliance, choosing deliberately between alerting, remote lock and retire.

  4. 4

    Write the enrolment experience, then communicate it

    Instructions for installing the Microsoft Intune app from the terminal and Microsoft Edge at version 102 or later, a clear statement of the encryption requirement before enrolment so users can encrypt during operating system installation, and a support route for when something does not work. Microsoft own guidance recommends exactly this because you will not be present when people enrol.

  5. 5

    Enable Conditional Access and set the review rhythm

    A device-based or application-based Conditional Access policy protecting Microsoft 365 web applications in Edge, which requires a compliance policy to exist first. Then a rhythm for reviewing compliance state, and a check after any identity broker update that device-based assignments, filters and group memberships still match the new device identifiers.

Straight answers

What organisations ask about Intune for Linux.

Microsoft states enrolment is supported on Linux desktops running Ubuntu long term support version 26.04 and 24.04, Red Hat Enterprise Linux 9, and Red Hat Enterprise Linux 10. That is the published list. Organisations running other distributions, or older releases of these ones, need a different approach, and it is worth confirming what people actually run before planning.

No, and setting that expectation correctly is the most important part of this conversation. Microsoft describes three components: Intune for device management and compliance, Entra ID for Conditional Access alongside compliance policies, and Edge as the browser providing protected access to Microsoft 365 web applications. The capability is compliance and access control rather than full configuration management.

Microsoft 365 web applications in the Microsoft Edge browser for Linux. Microsoft states Conditional Access blocks non-compliant devices from accessing protected work applications in Edge and grants access to compliant devices, and that you must have a device compliance policy for Conditional Access to work with Linux devices at all.

Built-in settings cover Linux distribution type, version, device encryption and password complexity, and Microsoft notes all available Linux compliance settings live in the Intune settings catalog. Beyond that, custom compliance settings let you write your own Bash scripts to address scenarios not covered, using a custom script that identifies the settings and value pairs to evaluate.

The user does it. Microsoft states employees assigned Intune licences can enrol their personal Linux devices whenever they want, that the device is registered with Entra ID and evaluated for compliance during enrolment, and that as an administrator you do not need to do anything to enable enrolment beyond the prerequisites. It is a communication exercise rather than a deployment.

Two things, both themselves. The Microsoft Intune app for Linux, which they install in the Terminal application, and the Microsoft Edge browser at version 102 or later, which is required to access protected websites and files. After enrolling, they sign in to Edge with their work account to reach protected resources.

Yes, and Microsoft recommends it explicitly. If you require device encryption, tell employees prior to enrolment so that where possible they can opt to encrypt during operating system installation, which is easier and faster than encrypting afterwards. The same guidance suggests publishing your operating system and password complexity requirements so people do not have to go looking mid-enrolment.

Intune marks it as noncompliant and takes the action you configured. Microsoft names sending alerts, remotely locking devices and retiring devices as examples, and notes users must resolve compliance issues to get access to protected resources. Compliance checks happen during enrolment and thereafter whenever the device checks in with Intune.

Check whether the identity broker updated. Microsoft warns that versions 2.0.2 and later of the Microsoft Identity Broker introduce a major architectural change from the previous Java-based broker, that devices updating from earlier versions are automatically re-registered and re-enrolled, and that new Intune and Entra device identifiers are created. It advises reviewing device-based assignments, filters and group memberships afterwards.

Microsoft recommends the least privileged role needed and names it specifically: the built-in Policy and Profile Manager Intune role is the least privileged role that can complete device enrolment tasks. That is a better default than reaching for a broader role, particularly since Linux enrolment needs so little administrative intervention in the first place.

The published guide describes employees enrolling their personal Linux devices. That framing shapes the model: user initiated, licence based, with the device registered to the user in Entra. Where an organisation wants a corporate-owned Linux estate managed centrally, that is a wider architecture question we would work through rather than assume this capability covers it.

A Linux device compliance policy has to exist first, since Microsoft states Conditional Access will not work with Linux devices without one. After that, you create a device-based or application-based Conditional Access policy to protect and grant access to Microsoft 365 web applications in Edge. The published example is a user trying to reach Teams in Edge without first enrolling or securing their device being unable to sign in.

Frequently, yes, because the small number of Linux machines in an organisation is often held by the people with the most sensitive access. The administrative effort is genuinely low, since enrolment needs no per-device work, and the improvement is from no visibility and no control to verifiable encryption, password policy and a Conditional Access gate.

Three to six weeks in most organisations, and the technical configuration is a small part of it. Writing the enrolment instructions, communicating the encryption requirement before people enrol, establishing a support route, and designing compliance including any custom Bash checks, are what fill the time. The rollout itself happens as users act on the communication.

We scope per organisation, driven mainly by how many custom compliance checks are needed and how much communication material has to be produced. The population and distribution survey comes first, because if a significant share of your Linux machines are on unsupported distributions, that changes the answer before anything is designed.
Before you commit

Fifteen questions that keep expectations accurate.

The first group establishes whether the capability fits at all. The second and third are the rollout, which for Linux is unusually dependent on communication rather than configuration.

Does it fit

  • Which distributions do your developers run?
    Four are supported.
  • What are you actually trying to protect?
    Conditional Access covers M365 web apps in Edge.
  • Are these personal or corporate machines?
    The published model is personal device enrolment.
  • Do users have Intune licences?
    Required for them to enrol.
  • Is Edge acceptable as the work browser?
    That is where the protection applies.

Compliance design

  • Which built-in settings do you need?
    Distribution, version, encryption, password.
  • Do you need custom Bash compliance?
    For anything the built-ins do not cover.
  • Have you told users about encryption?
    It is far easier during OS installation.
  • What are the actions for noncompliance?
    Alert, lock, or retire.
  • How long is the grace period?
    It sets how disruptive the rollout feels.

Rollout and operations

  • Who writes the enrolment instructions?
    Users install the app themselves.
  • Where do users get help?
    You will not be there when they enrol.
  • Is the Policy and Profile Manager role used?
    The least privileged role for enrolment.
  • Have device IDs changed after a broker update?
    Review assignments and group memberships.
  • Who reviews compliance state?
    It is only useful if somebody acts on it.
Related reading

The pages around this one.

Intune compliance policies

How compliance works across platforms, and how Conditional Access consumes it.

Learn more

MDM solutions

The cross-platform view, including what is managed on Windows, Apple and Android.

Learn more

Conditional Access

The policy framework that turns Linux compliance state into an access decision.

Learn more
Next step

Find out which distributions your developers actually run.

Four are supported. If most of your Linux machines are on them, this is a short and genuinely useful project. If they are not, you need a different plan, and that is worth knowing before anybody designs anything.

Book a Linux management reviewCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Intune Compliance Policies

The default that lets unassessed devices through Conditional Access

Learn more

MDM Solutions Dubai

Device management across Windows, Apple and Android

Learn more

Entra Conditional Access

The control that decides who reaches your data

Learn more

Microsoft Intune

Device management and endpoint security

Learn more

Intune Configuration Profiles

Settings catalog, templates and conflict management

Learn more

Endpoint Security

Defender for Endpoint and Intune managed

Learn more

Device Enrolment

Which path, which reset, and what you can enforce after

Learn more

Microsoft Security Dubai

Entra, Defender, Purview, Sentinel, and what you already own

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support Dubai
  • IT AMC Dubai
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy