Skip to content

utils/sssd: set pwfield=x in local() to fix pam_unix auth with proxy domain - #265

Open
mmatsuya wants to merge 1 commit into
SSSD:masterfrom
mmatsuya:fix/proxy-local-pwfield
Open

utils/sssd: set pwfield=x in local() to fix pam_unix auth with proxy domain#265
mmatsuya wants to merge 1 commit into
SSSD:masterfrom
mmatsuya:fix/proxy-local-pwfield

Conversation

@mmatsuya

@mmatsuya mmatsuya commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Problem

SSSDCommonConfiguration.local() configures SSSD with id_provider=proxy and
proxy_lib_name=files, which is the standard setup for tests that need local
users (e.g. KCM tests via client.sssd.common.kcm()).

When sss appears before files in /etc/nsswitch.conf — which is the default
on many RHEL images — and SSSD is using the proxy+files domain with
proxy_pam_target=system-auth, SSH and su authentication for local users fails:

pam_unix(sshd:auth): authentication failure; user=tuser

This was observed in the upstream SSSD test
test_kcm__ccache_holds_multiple_and_all_types_of_principals
running on RHEL 9.6, where the test consistently fails with
SSHAuthenticationError when the client image ships with passwd: sss files systemd.

Root Cause

When proxy_lib_name=files is combined with a proxy_pam_target other than
sssd-shadowutils, SSSD returns * in the password field for NSS lookups
instead of x. This is a known SSSD behavior documented in
SSSD issue #5129.

The sequence of events:

  1. getent passwd tuser (via NSS with passwd: sss files) → SSSD proxy returns tuser:*:1001:...
  2. pam_unix sees * in the password field → treats account as locked
  3. Authentication fails, even though the user exists in /etc/passwd and /etc/shadow

The fix in SSSD 2.3.0 (ae5a2cd) set
pwfield=x automatically for proxy+files, but SSSD 2.3.1 scoped that back to only
apply when proxy_pam_target=sssd-shadowutils. Since local() uses
proxy_pam_target=system-auth, the * behavior persists in current SSSD versions.

Fix

Explicitly set pwfield=x in the domain configuration. This ensures pam_unix
receives x in the password field and correctly falls back to /etc/shadow for
authentication, regardless of the nsswitch.conf ordering.

[domain/local]
id_provider = proxy
proxy_lib_name = files
proxy_pam_target = system-auth
pwfield = x

Testing

Verified on RHEL 9.6 (sssd-2.9.4) with passwd: sss files systemd in
/etc/nsswitch.conf:

  • Before fix: test_kcm__ccache_holds_multiple_and_all_types_of_principals fails with SSHAuthenticationError
  • After fix (pwfield=x): authentication succeeds, test passes

…domain

When id_provider=proxy with proxy_lib_name=files is used with
proxy_pam_target other than sssd-shadowutils, SSSD returns '*' in the
password field by default (SSSD issue #5129). This causes pam_unix to
treat the account as locked, breaking SSH and su authentication for
local users when 'sss' appears before 'files' in /etc/nsswitch.conf.

Explicitly setting pwfield=x ensures pam_unix reads the actual password
hash from /etc/shadow, regardless of the nsswitch.conf ordering.

Signed-off-by: Masahiro Matsuya <mmatsuya@redhat.com>
@mmatsuya

mmatsuya commented Aug 3, 2026

Copy link
Copy Markdown
Contributor Author

Closing this PR — pwfield is not a valid SSSD option.

The intent was to keep the password field as x in the proxy/local domain so that pam_unix can authenticate local users. However, SSSD rejects the option with:

[rule/allowed_domain_options]: Attribute 'pwfield' is not allowed in section 'domain/local'. Check for typos.

This was confirmed by running an automated test (Jenkins job #15471) which showed 2 failed, 0 passed due to the invalid config option.

The correct fix needs a different approach, such as adjusting /etc/nsswitch.conf so that files appears before sss in the passwd: line when a local proxy domain is used. This ensures pam_unix queries libnss_files directly and receives x in the password field rather than the * that SSSD returns.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant