ubuntu
Feature: Disabling Local Passwords
Is there an existing request for this feature?
- [X] I have searched the existing issues and found none that matched mine
Describe the feature
I want to enable authd to all machines in a larger PC room; however, I do not want the accounts to persist after a log out. This makes the need for a local password (kind of) obsolete. Ideally, authd should be configurable that no local password is needed.
Describe the ideal solution
By default, local passwords are enabled, but by adding use_local_passwd field to the broker config file (or somewhere else), these can be disabled. SSH will not prompt for a local password, and GDM won't either.
Alternatives and current workarounds
I have not found any workarounds. I suspect I could edit the PAM to make this work, but I do not know enough about PAM to do so.
System information and logs
Environment
- broker version: 0.1+267a15c.f272cc1
- authd version: 0.3.7
- gnome shell version: 46.3.1-1ubuntu1~24.04.1authd2
- Distribution: Ubuntu
- Distribution version: 24.04
Relevant information
No response
Double check your logs
- [X] I have redacted any sensitive information from the logs
This feature has also been requested in GitHub discussions:
- https://github.com/ubuntu/authd/discussions/655
- https://github.com/ubuntu/authd/discussions/688
We could support an option which forces authentication via OIDC during each login. That option would have major UX drawbacks though:
- The only OIDC auth flow which the authd brokers currently support is device authentication, which is quite tedious because it requires another device. At least for login via GDM, we won't be able to support other, more user-friendly OIDC auth flows in the foreseeable future (because we can't open a web view in GDM). In addition to the already poor UX of the device authentication flow, the user needs to log in to their account on the identity provider (Microsoft or Google), which often requires second factor authentication, making the OIDC authentication even more cumbersome. So I expect users to be unsatisfied with the login procedure if OIDC authentication is enforced during each login.
- If there is no network connection or the identity provider can't be reached for other reasons, the user won't be able to log in at all. It is possible to connect to Wi-Fi and wired networks in GDM via the system status menu, but it doesn't allow entering Wi-Fi passwords or configuring VPNs.
If we implement this feature, we should point out in the config file that login won't be possible without a network connection.
Furthermore, I think that even with that option enabled, we should only force OIDC authentication when the user logs in via GDM or SSH, but still support a local password for sudo, su, pkexec etc, because the UX would be even more impacted if the user had to perform OIDC auth each time they use one of these commands. We also disabled device authentication with polkit in https://github.com/ubuntu/authd/pull/768 because the UX was so poor, which we would have to undo if we would only support device authentication there.
It is possible to connect to Wi-Fi and wired networks in GDM via the system status menu, but it doesn't allow entering Wi-Fi passwords or configuring VPNs.
Note that @aleasto is keen to fix this soon, so that may not be a problem anymore
we should only force OIDC authentication when the user logs in via GDM or SSH, but still support a local password for sudo, su, pkexec
I feel that in these kids of scenarios the the users aren't even added to the sudo groups, so the issue is likely not to hit anybody.
At the same time, I wouldn't block someone who want a such annoying UX to provide it if they want.
We could support an option which forces authentication via OIDC during each login.
I have an idea which would also prevent users who don't have access to the identity provider anymore from logging in: We could support an option which requires that the access token is refreshed during each login. That would still require a network connection, but at least the UX isn't as bad, because users don't have to redo the device authentication each time. Would that be a solution for your use case, @RandyParedis?
@adombeck I am sorry for a late response; somehow I did not get notified of any comments...
The OIDC solution does seem like a viable solution for my use case. SSO users (in my setup) don't have any admin privileges, so the cumbersome setup of needing OIDC each time is really not a bother on my end. Not needing my users to be prompted with a password creation would therefore be ideal (they cannot change users, they cannot suspend, they cannot do superuser stuff...).
So I expect users to be unsatisfied with the login procedure if OIDC authentication is enforced during each login.
I do admit that my use case is very specific where I believe this will not be an issue. But, I do agree that most other users will be unsatisfied with such a UX.
So I expect users to be unsatisfied with the login procedure if OIDC authentication is enforced during each login.
Personally I don't think it's a problem for us, in the sense that if what an admin of authd wants to be, and we can easily provide it, we shouldn't care much about how efficient is the UX, since that's what an admin requested for (and they very likely prefer it to be complex instead of providing other ways).
@RandyParedis Thanks for the feedback! The use case you describe is valid, but we don't consider it to be high priority, so it might take some time until we get around to implement an option to disable the local password. PRs are welcome though.
Thanks! I would not know where to start with a PR for this, so... I guess I will wait 😅
Cheers!
@adombeck @3v1n0 Come to think of it, there might be another solution which (I hope) could be easier to implement... Would it be possible (for instance in the PAM, or wherever) to force a predefined password for all users? That way, the local passkey input field could be omitted?
Sorry @RandyParedis for not replying earlier. We don't think a predefined password would be a good solution, it would be more effort to implement than disabling the local password altogether. Do you still have the use case to disable the local password?
@adombeck No worries for the delay. Thanks for explaining.
I indeed still have the use-case, for which my bypass currently is a piece of paper that instructs the users to enter a specific password... Not ideal, of course.