Intune Company Portal on Linux (install, broker versions & AUTHN_005)

Signing in to the Intune Company Portal (intune-portal) on Linux depends on the microsoft-identity-broker stack. Sign-in can fail at several distinct layers, and the error you see does not always point at the real cause. This page covers installation, the version-compatibility trap, fresh-install pitfalls, and how to separate a local broker failure from a server-side identity-provider failure.

Install (Ubuntu 24.04 / 26.04)

Packages come from packages.microsoft.com. Microsoft officially supports Ubuntu Desktop 24.04 LTS and 26.04 LTS for Intune on Linux.

sudo apt install -y curl gpg

# Ubuntu 26.04+ repos are signed with a newer key
if dpkg --compare-versions "$(lsb_release -rs)" ge "26.04"; then
  MS_GPG_KEY_URL="https://packages.microsoft.com/keys/microsoft-2025.asc"
else
  MS_GPG_KEY_URL="https://packages.microsoft.com/keys/microsoft.asc"
fi

curl -fsSL "$MS_GPG_KEY_URL" | gpg --dearmor | sudo tee /usr/share/keyrings/microsoft.gpg > /dev/null

sudo tee /etc/apt/sources.list.d/microsoft-ubuntu-$(lsb_release -cs)-prod.list << EOF
deb [arch=amd64 signed-by=/usr/share/keyrings/microsoft.gpg] https://packages.microsoft.com/ubuntu/$(lsb_release -rs)/prod $(lsb_release -cs) main
EOF

sudo apt update

sudo apt install microsoft-identity-broker intune-portal

sudo apt install openjdk-11-jre
sudo apt install microsoft-identity-broker=2.0.1 intune-portal=1.2603.31-noble
sudo apt-mark hold microsoft-identity-broker intune-portal

journalctl -u dbus --since "10 min ago" | grep -i microsoft

sudo systemctl reload dbus
sudo systemctl restart microsoft-identity-device-broker.service
systemctl is-active microsoft-identity-device-broker.service   # -> active

systemctl --user daemon-reload
systemctl --user enable --now intune-agent.timer
intune-portal

The circulating workaround (and when it does NOT apply)

A commonly shared fix reads:

If you have sign-in issues with Company Portal, install microsoft-identity-broker at 2.0.1 instead of 3.0.1 — 3.0.1 has a known sign-in bug. sudo apt install microsoft-identity-broker=2.0.1 && sudo apt-mark hold microsoft-identity-broker

Two important caveats:

Version compatibility trap: portal ↔ broker

intune-portal pins a minimum broker version in its Depends:. Check before pinning anything:

apt-cache policy microsoft-identity-broker intune-portal
apt-cache show intune-portal | grep -E 'Version|Depends'

Ubuntu 26.04 (resolute)

On 26.04 the only working stack is the current 3.0.2 broker + latest portal — broker 2.0.1's device-broker cannot start even if you hold an older portal.

Ubuntu 24.04 (noble)

If you pin broker 2.0.1, you must also install and hold intune-portal=1.2603.31-noble (the newest portal on noble that accepts >= 2.0.1).

To move back to the latest stack on 24.04:

sudo apt-mark unhold microsoft-identity-broker intune-portal
sudo apt install microsoft-identity-broker intune-portal

Layer 1 — the crash: device_broker_inactive

Symptom (portal): Something went wrong. [4u3gc], An unexpected error occurred.

Root cause: the user broker calls the system service microsoft-identity-device-broker.service over D-Bus to generate a device key.

On broker 2.0.1 running on Ubuntu 26.04, that system service exits 255/EXCEPTION immediately after Starting DBus Service… (its bundled dbus-java 3.3.0 can't register on dbus 1.16.2). Key generation then times out after 25s and the broker returns device_broker_inactive.

On broker 2.0.1 on Ubuntu 24.04, the same crash can appear right after install if OpenJDK 11 is missing (JAVA_HOME is set to an invalid directory) or if D-Bus was not reloaded after the broker package created its system user (see install steps above).

# The user broker logs the timeout + device_broker_inactive:
journalctl --user -u microsoft-identity-broker.service --no-pager -n 200 \
  | grep -iE 'device_broker_inactive|Failed to activate service'

# The system device broker crash-loops with status=255:
systemctl status microsoft-identity-device-broker.service --no-pager
journalctl -u microsoft-identity-device-broker.service --no-pager -n 50

Layer 2 — stale state: "session has expired or is invalid"

Symptom (portal): "It looks like your session has expired or is invalid. Please sign in (SSO) again." immediately after logging in.

If you've been switching broker versions, the on-disk broker databases and Intune registration are written by the old broker and are not valid for the new one. Wipe them and register fresh.

systemctl --user stop microsoft-identity-broker.service
systemctl --user stop intune-agent.timer intune-agent.service 2>/dev/null
sudo systemctl stop intune-daemon.service intune-daemon.socket \
                    microsoft-identity-device-broker.service
pkill -u "$USER" -f 'identity-broker/lib' 2>/dev/null

rm -rf ~/.local/state/microsoft-identity-broker/*      # account-data.db, broker-data.db, cookies.db
rm -rf ~/.local/state/log/microsoft-identity-broker/*
rm -rf ~/.config/intune                                 # registration.toml (old account hint)
rm -rf ~/.cache/intune-portal ~/.local/share/intune-portal

sudo systemctl daemon-reload
systemctl --user daemon-reload
sudo systemctl start microsoft-identity-device-broker.service
systemctl is-active microsoft-identity-device-broker.service   # -> active

Keyring prerequisite

The broker stores the PRT in the GNOME keyring (Secret Service). If the keyring is locked or its password doesn't match your login password (common with auto-login), the token can't be persisted and every session looks "expired/invalid". Verify read/write:

sudo apt install -y libsecret-tools
echo -n test | secret-tool store --label=itest itest itest && \
  secret-tool lookup itest itest && secret-tool clear itest itest && echo "KEYRING OK"

Layer 3 — the federated IdP: AUTHN_005

Symptom (portal): "It looks like your session has expired or is invalid. Please sign in (SSO) again." — with the code AUTHN_005.

How to confirm it's really the IdP and not the local stack:

# 1. Local stack healthy? device broker active, keys minted during the attempt:
systemctl is-active microsoft-identity-device-broker.service
journalctl -u microsoft-identity-device-broker.service --since "5 min ago" \
  | grep -iE 'getStkJwk|createVerifySignature|broker_version'

# 2. What the portal itself logs during interactive sign-in:
journalctl --user --since "5 min ago" | grep -iE 'oneauth|AUTHN|canceled|error'
#   errorCode 3402 / "User canceled sign in" / OneAuth error 7 == the login page
#   returned an error (e.g. Ping AUTHN_005) and the flow aborted.

# 3. Cross-check outside Intune: sign in to the same account in Microsoft Edge.
#    If that also bounces to Ping and fails, the issue is the federated IdP.

If the local stack is healthy but you still get AUTHN_005:

• Complete the entire sign-in within ~60s — the broker's D-Bus interactive flow times out after roughly a minute and reports a "cancel".
• Escalate to IT/helpdesk: confirm the Linux Company Portal / identity-broker webview is permitted by the org's Ping federation + Conditional Access policies, and whether device registration/compliance is required before the Ping session will validate.

Supported stack summary

Ubuntu 26.04 (resolute)

sudo apt-mark unhold microsoft-identity-broker intune-portal 2>/dev/null
sudo apt install --allow-downgrades microsoft-identity-broker intune-portal

Ubuntu 24.04 (noble) — broker 2.0.1 stack

sudo apt install openjdk-11-jre
sudo apt install microsoft-identity-broker=2.0.1 intune-portal=1.2603.31-noble
sudo apt-mark hold microsoft-identity-broker intune-portal
sudo systemctl reload dbus
sudo systemctl restart microsoft-identity-device-broker.service

Ubuntu 24.04 (noble) — current stack

Use the same install as 26.04 but package names carry the -noble suffix (e.g. 3.0.2-noble, 1.2605.16-noble). No holds needed unless you are deliberately pinning.

Key takeaways

• Read journalctl --user -u microsoft-identity-broker.service and the system microsoft-identity-device-broker.service logs before changing versions — the portal's error text is misleading.
• On Ubuntu 26.04 the 2.0.1 downgrade workaround is a dead end; use 3.0.2 + latest portal.
• On Ubuntu 24.04, broker 2.0.1 works but requires OpenJDK 11, a matching portal version (1.2603.31-noble), and often a D-Bus reload after first install.
• Hold both packages if you pin broker 2.0.1 so apt upgrade does not pull a portal that requires broker 3.0.x.
• AUTHN_005 is a Ping federated-IdP error, not a broker problem. No client-side version change will fix a server-side invalid-session rejection.