ubuntu
Issue: Ubuntu 24.04 LTS: Issues with Entra ID (authd) and Intune (intune-portal) Integration Causing Login and Enrollment Problems
Is there an existing issue for this?
- [X] I have searched the existing issues and found none that matched mine
Describe the issue
I am using a clean installation of Ubuntu 24.04 LTS and have configured the authd service and Intune Portal following the official documentation for both systems.
The installation and configuration steps I followed are detailed in the script available here: https://justpaste.it/authd-intune-portal-ubuntu24
This script reflects the exact step-by-step instructions provided in both the authd and Intune Portal documentation, which I adhered to rigorously.
The observed behavior is as follows:
With a local user: After logging in with a local user on the machine, I can open the Intune Portal application without any issues. The application successfully presents the option to register the device in Intune, and the registration completes without errors.
With an Entra ID user: When logging in using an authd (Entra ID) authenticated user, I open the Intune Portal and attempt to register the device. Initially, the process appears to work as I am prompted to provide:
Username (Entra ID) Password Two-factor authentication code However, after correctly entering these details, I receive the following error code on the Intune Portal interface: [4u3gb].
Additional Notes: It is important to highlight that when logging in with a local user, I can authenticate and register the device without any issues. The problem only occurs when using an Entra ID user. I have confirmed that my application has all the necessary permissions as described in the documentation. This issue seems to affect the combined use of authd (Entra ID) and Intune Portal on Ubuntu 24.04, particularly with device registration when using Entra ID users.
Script used: https://justpaste.it/authd-intune-portal-ubuntu24 Article (authd): https://canonical-authd.readthedocs-hosted.com/en/latest/ Article (intune): Microsoft Intune (App Linux): https://learn.microsoft.com/en-us/mem/intune/user-help/microsoft-intune-app-linux
ATTENTION/NOTE: I found other people facing the same issue, but no one has managed to solve it yet. This issue is very important to me because I was the one who convinced the company to adopt Linux. Now, with internal policies, we are required to use EntraID with the Intune Portal. I need to solve this quickly to avoid everyone having to migrate to Windows.
Steps to reproduce
Steps to Reproduce: Perform a clean installation of Ubuntu 24.04 LTS. Install and configure authd by following the official procedure: https://canonical-authd.readthedocs-hosted.com/en/latest/ Install the Intune Portal application by following the official guide: https://learn.microsoft.com/en-us/mem/intune/user-help/microsoft-intune-app-linux Restart the machine after completing the installations. Log in to the system using an Entra ID authenticated user (via authd). Open the Intune Portal application. Log in to the Intune Portal with the Entra ID user credentials, providing: Username Password Two-factor authentication code Observe the error that occurs during this process. Specifically, the following error code is displayed on the Intune Portal interface: [4u3gb].
System information and logs
cat authd-system-info-1Jqsbg.md
authd version
authd 0.3.7
authd-msentraid broker version
name: authd-msentraid
summary: MSEntra ID broker for authd
publisher: Canonical**
store-url: https://snapcraft.io/authd-msentraid
license: GPL-3.0
description: |
This is the MS Entra ID broker snap for authd to provide MS Entra ID OIDC
based authentication on Ubuntu with authd.
services:
authd-msentraid: simple, enabled, active
snap-id: vS3oJLMss6lgWwoFcPqYDUA2HB20I1Dc
tracking: 0.x/stable
refresh-date: today at 12:10 -03
channels:
0.x/stable: 0.1+267a15c.f272cc1 2024-12-10 (89) 18MB -
0.x/candidate: ^
0.x/beta: ^
0.x/edge: 0.2.0-pre1+f8f25eb.77053b4 2025-01-15 (117) 19MB -
installed: 0.1+267a15c.f272cc1 (89) 18MB -
gnome-shell version
gnome-shell:
Instalado: 46.3.1-1ubuntu1~24.04.1authd2
Candidato: 46.3.1-1ubuntu1~24.04.1authd2
Tabela de versão:
*** 46.3.1-1ubuntu1~24.04.1authd2 500
500 https://ppa.launchpadcontent.net/ubuntu-enterprise-desktop/authd/ubuntu noble/main amd64 Packages
100 /var/lib/dpkg/status
46.0-0ubuntu6~24.04.5 500
500 http://br.archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages
46.0-0ubuntu6~24.04.3 500
500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages
46.0-0ubuntu5 500
500 http://br.archive.ubuntu.com/ubuntu noble/main amd64 Packages
Distribution
Distributor ID: Ubuntu
Description: Ubuntu 24.04.1 LTS
Release: 24.04
Codename: noble
Logs
-- No entries --
authd broker configuration
/etc/authd/brokers.d/msentraid.conf
# This section is used by authd to identify and communicate with the broker.
# It should not be edited.
[authd]
name = Microsoft Entra ID
brand_icon = /snap/authd-msentraid/current/broker_icon.png
dbus_name = com.ubuntu.authd.MSEntraID
dbus_object = /com/ubuntu/authd/MSEntraID
authd-msentraid configuration
[oidc]
issuer = https://login.microsoftonline.com/<UUID redacted>/v2.0
client_id = <UUID redacted>
# Client secret is needed for some specific auth flows depending on the provider.
# Only enable it if this is needed for your particular configuration.
# client_secret = <CLIENT_SECRET>
[users]
# The directory where the home directory will be created for new users.
# Existing users will keep their current directory.
# The user home directory will be created in the format of {home_base_dir}/{username}
# home_base_dir = /home
# The username suffixes that are allowed to login via ssh without existing previously in the system.
# The suffixes must be separated by commas.
# ssh_allowed_suffixes = @example.com,@anotherexample.com
ssh_allowed_suffixes = @convertcompany.com.br,@convert.app.br
Double check your logs
- [X] I have redacted any sensitive information from the logs
ATTENTION / MORE INFORMATION:
I came across this post: [https://techcommunity.microsoft.com/discussions/microsoft-intune/ubuntu-24-04-lts--entra-id-authentication--intune-enrollment/4360127]
It’s the same issue I’m facing, experienced by another user in the same situation.
I discovered that manually installing Microsoft Edge on Ubuntu, If you manually install Edge, it asks you to create a password for a keychain.
I’d like to reiterate that, without using authd (EntraID) and with a local user, we can register the device normally in Intune without needing this process. The issue only arises when authd (EntraID) is used together with Intune.
After installing the Edge package separately, I was surprised when I first opened the browser and was prompted to create a default keyring and set a password. This doesn’t seem right to me, as the keyring control would be in the hands of the local user, which contradicts the security model we want to maintain.
After completing this step and creating the keyring password, I was able to access the Intune Portal again, and finally, Intune allowed the device registration without the previous error. However, this creates a significant problem: the keyring control would be with the user, and the process, which should be automatic, becomes a manual and cumbersome one, requiring the user to enter the password every time the system is rebooted. The user would be prompted to unlock the keyring to authenticate and start monitoring the machine through Intune.
I consider this solution inadequate, as there is no mention of this step in the official documentation, and the user experience is severely impacted. If this process continues as it is, every time the system is restarted, the user will need to unlock the keyring with a password that has no relation to EntraID, preventing automatic access to Intune until the password is provided.
I want to emphasize the importance of addressing this issue, as, at the company where I work, we managed to convince several users to adopt Linux. However, now, due to the need to comply with internal security policies, we are being blocked by this limitation. To avoid a forced migration to Windows, it’s crucial that this situation is resolved.
We don't have access to an Intune subscription, so I don't see a way for us to debug this. What you could do to help us debug this is to:
- Install Ubuntu again
- Test that Intune does indeed work in that Ubuntu installation
- Follow the authd installation and configuration steps and after each step, test if Intune still works. Report after which step Intune stopped working. The steps I would try in particular:
3.1 Install authd (without the broker):
sudo apt install authd gnome-shell yaru-theme-gnome-shell3.2 Install the broker:sudo snap install authd-msentraid3.3 Configure authd and the broker (https://canonical-authd.readthedocs-hosted.com/en/latest/howto/configure-authd/#configure-authd) 3.4 Log in via authd in a terminal (sudo login <USER>) but then try running Intune as the non-authd user 3.5 Log in via authd in GDM and then try running Intune as that user
With that information, we might get a better understanding of what causes the issues with Intune and might be able to find a solution (after some more debugging, which you will probably have to help with again).
Hello, I can confirm the issue is related to the combination of MS Edge and default keyring.
So, I installed a fresh copy of Ubuntu 24.04.1 LTs on the HP EliteBook 850 G8 and installed it with default LUKS +LVM encryption. Successfully installed and configured authd according to documentation and successfully signed in via corporate account which is in linux-sudo group, and yes, the sudo accesses are working. After that, based on official MS documentation: https://learn.microsoft.com/en-us/mem/intune/user-help/enroll-device-linux https://www.microsoft.com/en-us/edge/?cs=1873324239&form=MA13FJ https://learn.microsoft.com/en-us/mem/intune/user-help/microsoft-intune-app-linux
I installed MS Edge via .dep package, but on the first start it asks to create a new password and a new keyring called "Default Keyring". If I try to close that window it will continue opening MS Edge, but in the next MS Edge start it will ask the same. When I created that "Default Keyring" with a new password, after every OS reboot and MS Edge start it asks to enter the password to unlock the keyring. Since MS Intune uses MS Edge components, when I run the MS Intune app it also asks to unlock the "Default Keyring" to continue, and after the OS reboot the MS Intune app will ask the same again.
If you need my help, we can make a call and provide access to my test device, via MS Teams or any other convenient software. Screenshots attached.
Just a little suggestion, in fact, you don't need to fix the Intune, you need to fix MS Edge access to Keyring. You just need to download and install the MS Edge app under an authd authenticated user account and you will see the Keyring issue. And yes, there is no Keyring issue under the local account.
Yes, after several tests, I verified that the problem is indeed with the authd together with keyring.
In the local user account, upon logging in, there is already a default keyring that is unlocked during the login process in the GDM interface...
This does not happen with the configured entra-id...
I even performed the manual Edge process, but if I try to remove the password, it causes issues every time. It always prompts for the creation of a new keyring after restarting and opening Edge. If I keep the password created during the first initialization, I have to type it in, as it is not unlocked when authenticating the user via GDM with entra-id (authd). So the manual process becomes a hassle.
Sorry, unfortunately having the keyring unlocking bound to authd is just not possible at the moment, due to the gnome-keyring nature (this will change in future ideally as upstream is already integrating that differently).
This is because the keyring requires a passphrase, now while it's true that the entra-ID broker always requires you to store a local password, and so we could use it for the keyring too, this is not true in general for authd nature, given that a broker may potentially just depend on password-less authorization systems, and in such case we'd not have a passphrase to use for the keyring...
One option in such case would have been to make authd to generate a random passphrase for each user to be used for the keyring, but that would lead to the problem that then if the keyring is locked, then the user wouldn't be able to unlock it anymore without logging out/in again...
So, this is something we've been thinking about, but right now there's not a good solution that is future-proof IMHO.
I was surprised when I first opened the browser and was prompted to create a default keyring and set a password. This doesn’t seem right to me, as the keyring control would be in the hands of the local user, which contradicts the security model we want to maintain.
As mentioned a way to handle it would be having the daemon to control the keyring password, that's doable, but it wouldn't make it possible to lock/unlock it to the user (and being user-owned I feel it should be something an user should control in general).
So maybe, it's something that could be done optionally on per-broker settings basis.
Sorry, unfortunately having the keyring unlocking bound to authd is just not possible at the moment, due to the gnome-keyring nature (this will change in future ideally as upstream is already integrating that differently).
This is because the keyring requires a passphrase, now while it's true that the entra-ID broker always requires you to store a local password, and so we could use it for the keyring too, this is not true in general for authd nature, given that a broker may potentially just depend on password-less authorization systems, and in such case we'd not have a passphrase to use for the keyring...
One option in such case would have been to make authd to generate a random passphrase for each user to be used for the keyring, but that would lead to the problem that then if the keyring is locked, then the user wouldn't be able to unlock it anymore without logging out/in again...
So, this is something we've been thinking about, but right now there's not a good solution that is future-proof IMHO.
How could I do this? I need at least a temporary solution because either I automate the process and deliver it here at the company, or we’ll have to remove all the Linux systems (Desktop)...
I think the best solution is to have a mechanism that will tie the keyring autounlock function to local password, it also must take into account that the password can be rested on sign in screen by Entra ID authentication, so it must be capable to change already created keyring password with the fresh password.
And so we are slowly approaching the point of having another mechanism that will manage passwords, set their service life and their complexity, perhaps such a solution is already in the plans? According to the roadmap, Ubuntu 25.04 will support PIN, possibly in conjunction with TPM? And perhaps the same mechanism will be able to handle local passwords and Keyring? I wonder how Keyring unlocking will work if the user does not have a local password, but will have a PIN associated with TPM and Passvrlrdless authentication in Entra ID?
How could I do this? I need at least a temporary solution because either I automate the process and deliver it here at the company, or we’ll have to remove all the Linux systems (Desktop)...
I could try hacking a patch, but then you'd need to maintain that for now, as I don't think we've plans for now...
And perhaps the same mechanism will be able to handle local passwords and Keyring?
Yeah, basically that's what gnome-keyring will do: https://blog.hansenpartnership.com/tpm-enabling-gnome-keyring/
How could I do this? I need at least a temporary solution because either I automate the process and deliver it here at the company, or we’ll have to remove all the Linux systems (Desktop)...
I could try hacking a patch, but then you'd need to maintain that for now, as I don't think we've plans for now...
And perhaps the same mechanism will be able to handle local passwords and Keyring?
Yeah, basically that's what gnome-keyring will do: https://blog.hansenpartnership.com/tpm-enabling-gnome-keyring/
For me, it would be great, because at the moment what’s most important to me is delivering what I was asked to stay within the compliance required by the company. This way, I can keep the Linux... I wouldn't see any problem if, when logging in with the created local password, it already unlocks the keyring using the same one. I don't know!
Yeah, the main issue would arise in case the user changing the password through passwd though, since we don't have a graphical way to handle it, this would put the keyring out of the loop, leading to the keyring password not being synchronized...
This is not a problem for normal users, since they can change the password from control center, but it's not the case for authd-managed users. So... there are various caveats to consider.
There have been no further updates on this?
There have been no further updates on this?
As @3v1n0 explained, it's not an easy problem to solve. Not many users reported that they are affected by it. We have limited resources, so we need to prioritize what we're working on. Given that this is a hard problem to solve and apparently few users want it to be solved, it's not particularly high priority for us.
Sorry, but I can't agree! I can reproduce this issue anytime for you, not only on VirtualBox, but also on 3 Ubuntu certified laptops. I have 500 active Ubuntu users with potential of 2500, so I need to fix this issue, since most of our users are forcefuly pushed to switch to Linux by client need, so they are even not familiar with the terminal, and it will be hard to explain them, why they need to unlock the keychain after every Reboot to be able to use Google Chrome, MS Edge, or Intune. More over, we already switched to passwordless mode, so it will be hard to explain why they must create and remember a password for keychain. By the logic, there must be a local password only, with the fingerprint option, this will bring macOS like experience, or a PIN, with the fingerprint option, this will bring Windows like experience. We need a smooth experience for switching from other OS to Ubuntu, and not explanation of limitations.
We do plan to explore ways to improve the UX with Microsoft Entra in the next months. You mention multiple problems and I agree that these are problems. I would love to be able to solve all them today, but it's not that easy and as I said, we have limited resources and need to allocate them carefully.
Of course you are Right! It is a hard, complex, and time-costing job. If you need a tester for this functionality in the future, just ping me!
Hello, I've got this exact problem too. It is kind of annoying since we've got 40 Ubuntu machines in our enterprise, and I can't add those to Intune. It's either opening the sessions through Entra ID with authd or enrolling Ubuntu computers in Intune. We may not be a lot to complain about this, but when we do, we usually have a lot of computers. Anyway, it's going in a good direction. Thanks for your work!
Our (large) organisation is impacted by this; we have had to abandon using Intune for Linux for the tim being, as using an Entra account via Authd triggers the Edge keyring issue.
Authentication is earlier in the process, so we have had to make a decision and opt for Authd over Intune for the time being, which is less than ideal.
@adombeck @3v1n0 is this roadmapped anywhere? Compliance is an equally import part of a Linux desktop solution, so having both features working in tandem would be great. Many thanks all for your hard work!
Same here. I'm working on providing an ubuntu solution thats going to start out with about 30 machines, but may blow out further down the track. Right now I can either have intune OR authd... I cant do both.
The same for me, we need to switch from image making + puppet management to provisioning + Intune management, and we strongly want to use authd, but we have two main stoppers, the issue with the keyring autounlock and the inability to use the fingerprint option under authd management. All devices are Ubuntu certified HP EliteBook 840/850/860 G8-G11.
Following up on my message last month on this topic, we’ve decided to continue using Authd despite the keyring issue, hoping it will be resolved later. In the meantime, we are continuing to manage things with Ansible.
Since it seems this is the only place I can somewhat relate to enrollment not working. We recently got into a similar issue, however even with a manual install the system responds with "an expected error has occurred" - console output with the intune-portal showing:
Non-retryable error encountered while attempting to enroll
error=HTTP client error: https://fef.msub06.manage.microsoft.com/TrafficGateway/TrafficRoutingService/LinuxMDM/LinuxEnrollmentService/enroll?api-version=1.0&client-version=1.2503.10: status code 500
Interestingly enough it had been working and then gotten this on new machines.
ATTENTION / MORE INFORMATION:
I came across this post: [https://techcommunity.microsoft.com/discussions/microsoft-intune/ubuntu-24-04-lts--entra-id-authentication--intune-enrollment/4360127]
It’s the same issue I’m facing, experienced by another user in the same situation.
I discovered that manually installing Microsoft Edge on Ubuntu, If you manually install Edge, it asks you to create a password for a keychain.
I’d like to reiterate that, without using authd (EntraID) and with a local user, we can register the device normally in Intune without needing this process. The issue only arises when authd (EntraID) is used together with Intune.
After installing the Edge package separately, I was surprised when I first opened the browser and was prompted to create a default keyring and set a password. This doesn’t seem right to me, as the keyring control would be in the hands of the local user, which contradicts the security model we want to maintain.
After completing this step and creating the keyring password, I was able to access the Intune Portal again, and finally, Intune allowed the device registration without the previous error. However, this creates a significant problem: the keyring control would be with the user, and the process, which should be automatic, becomes a manual and cumbersome one, requiring the user to enter the password every time the system is rebooted. The user would be prompted to unlock the keyring to authenticate and start monitoring the machine through Intune.
I consider this solution inadequate, as there is no mention of this step in the official documentation, and the user experience is severely impacted. If this process continues as it is, every time the system is restarted, the user will need to unlock the keyring with a password that has no relation to EntraID, preventing automatic access to Intune until the password is provided.
I want to emphasize the importance of addressing this issue, as, at the company where I work, we managed to convince several users to adopt Linux. However, now, due to the need to comply with internal security policies, we are being blocked by this limitation. To avoid a forced migration to Windows, it’s crucial that this situation is resolved.
I know this is old but, it was the first search result. I got here because I received the same error when trying to login to the portal. A restart seemed to take care of that but, I have a thought on Edge forcing you to login. I wonder if that might be due to a MAM policy. It makes me think of my iPhone when I try to connect to one of my apps, it makes me enter a PIN or use face ID. Those authentications are local to the iPhone.
