Use Entra Id password instead of local password

[0s0b4m4sk]

Hello, I would like to know if it is possible to use only Entra Id authentication to connect to our ubuntu session (created with Entra Id). Here the goal is to be able to manage passwords from Entra Id.

Currently I have the link between my Entra Id and my Ubuntu workstation, I have linked my user, I have authenticated via device (where I have to scan the QR code or go to Microsoft). Then I set my local password. From what I understand seen in this discussion (#655) , it will be possible by configuring the broker, to use only the password Entra Id.

If possible, do you have any documentation or advice to help me meet my needs?
Thank you, and have a nice day!

[MrJohanssons]

Yeah, I don't see why a local password is needed unless passwordless mode is used. Why is authd designed to be used with devicelogin instead of password login?
When using SSSD & on-prem AD users can use their normal username & password to logon and if they leave the network the account is cached.

Why is this not possible when it comes to EntraID?

[adombeck]

There are two slightly different features discussed here:

1. Being able to log in with the Microsoft Entra ID password instead of having to create a separate local password. We will look into that, but for now it's not planned.
2. Preventing users to log in when their Microsoft/Google account was disabled or doesn't have access to the tenant/project anymore. We could support that relatively easily by providing an option which requires the access token to be refreshed during login. See Feature: Disabling Local Passwords #726 (comment).

Would 2. help you with your use cases, @MrJohanssons, @dubK, @netean?

[MrJohanssons]

Would Option 2 mean that the user has to logon via microsoft.com/devicelogin at every login?

[adombeck]

@MrJohanssons not if we do what I proposed in #726 (comment), i.e. still let the user log in via a local password but, if the option is enabled, always check during login that the user still has access to the tenant/project by refreshing the access token.

[MrJohanssons]

@adombeck that sounds good but having the users logging on via microsoft.com/devicelogin in the first place is untenable. That means that they need a 2nd device to logon. Everyone has a phone but not everyone has a company issued phone and even those with company phones will have a hassle to logon since the QR code opens a browser to microsoft.com/devicelogin and very few people are logged on to their O365 accounts in the browser. Most people just use the O365 app and thus are authenticated there and not in the browser.

[adombeck]

Of the OIDC authentication methods, we can currently only support device authentication (or "Device Authorization Grant" as it's called in the spec). Web authentication (or "Authorization Code Grant" in the spec) would provide better UX, because it doesn't require a second device, but it requires a web browser which we can't use in the GDM login screen or in TTY login. For Microsoft Entra ID, there might be ways outside of the OIDC standard to log in directly with the Microsoft password - as you pointed out in #688 (comment), Platform SSO on macOS seems to support that (thanks for the pointer by the way). We might look into that in the future, but that will require a lot more effort than my proposal in #726 (comment) and solves a different problem.

[netean]

I'm currently testing Google Workspace authentication and it also requires a local password and can't use the G.W. one

[MrJohanssons]

Interesting. How does it work on Windows & Mac? Do you use passwordless solutions or is it just G. W. username & password?

[MrJohanssons]

Just talked to our Mac guy and he told me there is two solutions for Entra join.
Platform SSO & Secure Enclave.

Platform SSO is newer and allows user to logon with their EntraID username & password. Secure Enclave uses a local account, similar to authd.

If Platform SSO can manage EntraID logon via username/password I don't see why authd couldn't use the same approach unless it requires proprietary code from MS.

[dubK]

I just want to let you know that it ain't possible in the current state of authd to enforce OIDC authentication and disable local password login unfortunately. This is a huge bummer since, I at least, thought it would do exactly that.

Well, we'll have to wait and see if that option is coming or not. According to one of the developers they have yet to decide whether to add that option or not.

[netean]

I am genuinely baffled why authd even exists. What it provides is a one time authentication with Entra or Google that is never ever checked again. Users can be disabled from either directory and desktop login can continue.
You can't set up the user with sudo access via authd and therefore what it actually delivers currently is just worse than a regular setup via the adduser command or gui.

I'm not trying to bash the development, I'm certain that the dev(s) have put in a lot of work here I'm just not sure why they have been tasked with creating a tool that provides so little. What was the goal here, what problem were they aiming to solve ? I'll posit that it's the goal most of us were hoping it would solve - that is: Desktop authenticated login against Entra Id or Google Workspace for each and every login wasn't what they were tasked with.

[adombeck]

The use case which authd solves is that it allows members of an organization access to machines without requiring admins to manually create user accounts for them on those machines.

We see that automatically denying access to users who were removed from that organization is also a valid use case, and we plan to work on that in the next few weeks.

[Stibila]

The use case which authd solves is that it allows members of an organization access to machines without requiring admins to manually create user accounts for them on those machines.

This was solved years ago with solutions like LDAP, AD, FreeIPA.

What we were hoping for with authd was simple Entra ID login, like on Windows, for better corporate compliance. Instead, it looks like admins need to issue another compliant device just to let us log into the first one. And users need to set local passwords left and right. That's not exactly easy or what we expected for Entra ID integration.

Disabling local passwords would improve the user experience in some scenarios, especially when users log into numerous servers. Managing dozens of local passwords undermines the benefit of a single identity and feels like a step backward from LDAP solutions, but disabling local password mitigates that.

But that doesn't help the people who don't have another compliant device to even log in the first time. Honestly, the main thing to fix is making that initial Entra ID login smoother without needing a second device.

[MrJohanssons]

Hey guys, a colleague of mine suggested I try himmelblau. And I was very impressed, this is how I would like authd to work.

There are two great things about himmelblau:

1. The first time you login, you just enter your EntraID password. There is no need to involve microsoft.com/devicelogin and fiddle with external devices. You just login like you would on any another device!
2. There is no need to configure any client IDs or secrets. All you need to configure is the domain name of your EntraID domain.

Such a great implementation, but there is one caveat though. After first login you are prompted to a set a Windows Hello pin, this is what you will use for login instead of your EntraID password. So it's pretty similar to the local password thing in authd that we have been bashing in this dicussion. But from what I understand this is exactly how it works on Entra joined Windows PCs. They also use Windows Hello pin, so at least it's consistent.

@adombeck are you aware of this application? It's open source so I gather you could use parts of it to improve authd.

[adombeck]

Yes, we're aware of himmelblau. I agree that it has some nice features which authd is currently lacking. One of those is Entra ID device registration, which we're currently working on (see #697). The goal is to use libhimmelblau in authd to make use of the great work that was already done there.

There is no need to configure any client IDs or secrets. All you need to configure is the domain name of your EntraID domain.

As far as I know, that's not possible when you also want to fetch the user's groups, as authd does for supporting group management via Entra (https://documentation.ubuntu.com/authd/latest/reference/group-management/). We might be able to make the registration and configuration of a custom Entra app optional, so that it's only needed when you want to use group management.