Attempting Device Authentication but prompted to "Create a local password"

[jbrucato-eci]

Running into an issue here (Ubuntu 24.04 fully patched). Auth seems to function when code is submitted, but I drop down into a local password loop:

_>>ssh username@domain.com@x.x.x.x
(username@domain.com@x.x.x.x) == Broker selection ==
1 - local
2 - Microsoft Entra ID
Select broker: 2
Insert 'r' to cancel the request and go back
(username@domain.com@x.x.x.x) Enter your local password:
(username@domain.com@x.x.x.x) == Authentication mode selection (use 'r' to go back) ==
1 - Local Password Authentication
2 - Device Authentication
Select authentication mode: 2
Scan the QR code or access "https://microsoft.com/devicelogin" and use the provided login code
https://microsoft.com/devicelogin
AQCEFPFAE

(username@domain.com@x.x.x.x) == Qr Code authentication (use 'r' to go back) ==
1 - Wait for the QR code scan result
2 - Request new login code
Select action: 1
Insert 'r' to cancel the request and go back
(username@domain.com@x.x.x.x) Create a local password:_

Periodically seeing the following in Authd logs:

Nov 12 18:02:06 MYSERVER systemd[1]: Stopping authd.service - Authd daemon service...
Nov 12 18:02:06 MYSERVER systemd[1]: authd.service: Deactivated successfully.
Nov 12 18:02:06 MYSERVER systemd[1]: Stopped authd.service - Authd daemon service.
Nov 12 18:02:06 MYSERVER systemd[1]: Starting authd.service - Authd daemon service...
Nov 12 18:02:06 MYSERVER systemd[1]: Started authd.service - Authd daemon service.
Nov 12 18:05:11 MYSERVER authd[3654]: 2024/11/12 18:05:11 WARN rpc error: code = NotFound desc =
Nov 12 18:10:11 MYSERVER authd[3654]: 2024/11/12 18:10:11 WARN rpc error: code = NotFound desc =
lines 48-79/79 (END)

Auth logs during attempt:
2024-11-12T18:16:26.427587+00:00 MYSERVER sshd[3891]: pam_aad(sshd:account): AadAuthorize, Version: 1.0.028680001; CorrelationId: XXXXXXX
2024-11-12T18:16:26.427804+00:00 MYSERVER sshd[3891]: pam_aad(sshd:account): This is an Azure machine
2024-11-12T18:16:26.578334+00:00 MYSERVER sshd[3891]: pam_aad(sshd:account): Login denied for user username@domain.com.
2024-11-12T18:16:26.578795+00:00 MYSERVER sshd[3888]: error: PAM: User account has expired for username@domain.com from x.x.x.x
2024-11-12T18:16:26.640504+00:00 MYSERVER sshd[3888]: fatal: monitor_read: unpermitted request 104

[3v1n0]

That's the expected behavior... Currently you need a local password to be set.

Technically I suppose it could be disabled adding an option to the broker for specific setups, but then you wouldn't be able to login in case of missing connection.

[dubK]

The problem is that after the local password has been set, it uses the local password to login, not my credentials in Azure. This cant be the expected behavior can it? I want to primarily talk to Entra ID and get MFA, but if that fails for some reason (i.e. no internet connection), then go ahead and use the local account as a fallback method.

[adombeck]

but if that fails for some reason (i.e. no internet connection), then go ahead and use the local account as a fallback method.

Making the user authenticate via OIDC each time they authenticate is significantly worse UX than the local password. If the user can circumvent that just by disconnecting from the internet, then what's the benefit of defaulting to OIDC?

[dubK]

First of all I would create a single local account on the server in case of emergency. I would not implement a fallback method that everyone can use separately to login to the machine by simply using their own weak passwords. A user would not be able to circumvent that, no.
That's like saying: 'I'm going to drive my car with all-season tires and have shitty tires all year around instead of having separate set of tires for when it's summer and when it's winter because it's significantly worse UX to have to change tires every 6 months.

There are many benefits of defaulting to EntraID. You could enforce different password policies, control conditional accesses and most importantly use MFA every login.

Let's turn the question around, what's the point of having authd if it's only going to prompt for a local password? What benefits do I get from using authd instead of just connecting my machine to the local AD server?

[adombeck]

What benefits do I get from using authd instead of just connecting my machine to the local AD server?

The advantage of authd is that you don't need to set up and maintain a local Active Directory service, but can allow users to log in directly via the identity provider.

We're considering supporting an option to disable the local password, i.e. to always enforce OIDC authentication, but we haven't made a decision yet.

[dubK]

We're considering supporting an option to disable the local password, i.e. to always enforce OIDC authentication, but we haven't made a decision yet.

Make a decision and listen to Nike: Just Do It!
Why not give us the option? That would honestly be a key feature and a game changer for a lot of businesses, including mine.
I can also see that I'm not the only one with these thoughts.

If you decide to implement the option for us to always enforce OIDC (ofc you will, right?) then I'd gladly use this so DM me!