Feature: Selectively disable local password auth based on the calling PAM service (e.g., sshd, gdm-password)

[DevDawn]

Is there an existing request for this feature?

• [x] I have searched the existing issues and found none that matched mine

Describe the feature

As an administrator of an internet-facing server, I am frustrated that authd's PAM module allows a user to authenticate using either the online OIDC flow (e.g., Entra ID) or their local password during an initial login session (like sshd).

This creates a significant security vulnerability. The entire purpose of using authd for a public server is to enforce strong, multi-factor authentication (MFA) via the cloud provider. By offering the local password as an alternative, authd allows this MFA to be completely bypassed by a single-factor (the local password).

The existing force_provider_authentication = true option does not solve this. That option only forces an online check after the local password flow is chosen; it does not prevent the user from choosing the local password flow in the first place.

I need a way to configure authd to be "smarter" — it should only offer the OIDC/online flow for initial logins, but still allow the local password to be used for in-session actions like sudo or unlocking the screensaver.

Describe the ideal solution

The ideal solution is for the authd PAM module to inform the authd-broker of which service (e.g., sshd, sudo, gdm-password) is requesting authentication. This "service context" allows the broker to enforce different logic for different scenarios.

1. New Configuration in broker.conf A new configuration option should be added to the broker (e.g., authd-msentraid-broker's broker.conf),like this: require_online_auth_for_services = sshd,gdm-password
2. Pass PAM_SERVICE from authd to broker This is the most critical part. The architecture must be modified so that the broker knows what service is calling. authd : Must read the PAM_SERVICE environment variable (e.g., "sshd", "sudo", "gdm-password"). D-Bus API: authd must pass this serviceName string as a new argument in its D-Bus call to the broker when requesting authentication. broker: The broker receives this serviceName. When deciding which auth methods to offer the user, it checks its new config,and decide to provide which kinds of auth method. This solution allows administrators to enforce a true "zero-trust" login policy for public servers, while retaining the usability of local passwords for sudo and lock-screen operations.

Alternatives and current workarounds

There are no viable workarounds for this at the moment.

[adombeck]

Thanks for the detailed description! That does sound like a useful feature. Unfortunately, I doubt we will find time to implement it this cycle (until 26.04) because we already planned quite a lot of other work. I'm putting it in our backlog.

[adombeck]

Dumping some more thoughts:

• We could name the setting disable_local_password and support values true/all, sshd, gdm, ...
• It might make sense to default to sshd for new installations

Contributions are welcome, but implementing this will require touching a lot of authd components (PAM module, authd, broker, protobuf files, config file, ...) so probably not a good candidate for new contributors.