How to Fix PAM Authentication Failures on SUSE Linux Enterprise Server

A “PAM authentication failure” message does not always mean the password is wrong. On SUSE Linux Enterprise Server (SLES), Pluggable Authentication Modules (PAM) form a stack that checks identity, account access, password changes, and session setup. A failure can come from a typo or disabled account, a broken PAM include, an unavailable LDAP or Active Directory service, a Kerberos clock or DNS problem, or a desktop session issue that occurs after authentication.

The safest fix is to identify which service and which PAM stage failed before changing configuration. This guide uses the SUSE Linux Enterprise Server 15 SP7 documentation as its reference. If you run another SLES service pack or a specialized appliance image, check the matching SUSE documentation and installed package versions before applying commands.

First, what is failing: one service or every login?

Record the user, exact time, host, and entry point for the failure: SSH, a local text console, graphical login, su, or an application. Test with a second known account if possible. If only SSH fails while console login works, focus on /etc/pam.d/sshd and the SSH service. If local users work but directory users fail, investigate SSSD, LDAP, Active Directory, Kerberos, DNS, or the host’s authorization policy. If a console login succeeds but the desktop rejects the user or returns to the login screen, the failure may be in the graphical session or home directory rather than password authentication.

Keep an existing root shell open while troubleshooting. If you are connected remotely, keep a second SSH session open and make sure you have console or rescue access before touching PAM. A syntax or control-flag error in a shared PAM file can block new logins for multiple services.

1. Read the journal around the failed attempt

SUSE’s troubleshooting guide recommends reviewing the system journal for messages from the login process and PAM. Query a short time window close to the failure so unrelated messages do not obscure the cause:

sudo journalctl -b --since "15 minutes ago"

For an SSH-only problem, narrow the view to the SSH daemon:

sudo journalctl -b -u sshd --since "15 minutes ago"

Look for the service name, PAM service name, module name, and whether the message refers to auth, account, password, or session. PAM’s auth stack checks the credentials; account checks whether the user is allowed to access that service; session prepares the user environment. A successful password check followed by an account denial points to a different problem than an unknown user or bad password. Avoid enabling verbose debugging on a production system unless needed; diagnostic logs may contain account names and other sensitive context.

See SUSE’s SLES troubleshooting guide for its local and network authentication workflow.

2. Confirm that SLES can find the user

Before changing PAM, check whether the system’s Name Service Switch can resolve the account:

getent passwd user_name
id user_name

Replace user_name with the affected login. If these commands return no account for a directory user, PAM may be functioning correctly while identity lookup is failing. Check that the configured identity service is running, the host can reach the directory, and the user is permitted to sign in on this host. For an SSSD-based setup, inspect the daemon and recent logs:

sudo systemctl status sssd
sudo journalctl -b -u sssd --since "15 minutes ago"

SUSE documents SSSD as providing both NSS and PAM interfaces and notes that it can cache identity data. If users report intermittent failures, compare the local system’s time and DNS resolution with the directory or Kerberos environment. Kerberos depends on correct time synchronization; a working network connection alone does not prove that authentication will succeed.

Also check for name collisions. SUSE lists a username that exists locally and in a network identity source as a possible cause of network authentication problems. Verify which identity source is expected to own the account before editing its PAM rules.

3. Inspect the PAM service file and shared stack

SLES keeps per-service PAM files in /etc/pam.d. A service file such as /etc/pam.d/sshd commonly includes shared files such as common-auth, common-account, common-password, and common-session. A bad line in a shared file can affect several services; a bad line in one application’s file may affect only that application.

Read the relevant files and inspect their links before editing:

sudo ls -l /etc/pam.d/common-*
sudo sed -n '1,160p' /etc/pam.d/sshd
sudo sed -n '1,160p' /etc/pam.d/common-auth
sudo sed -n '1,160p' /etc/pam.d/common-account

Check for misspelled module names, missing module files, incorrect options, unexpected ordering, and changes made during a recent package or authentication rollout. Control flags matter: required records a failure but continues through the stack; requisite can stop immediately; sufficient can allow success to return early when no earlier required module failed. Do not copy a PAM stack from another distribution or SLES release without understanding its modules and control flow.

Before changing anything, make a root-only backup of the current directory, preserving symbolic links:

backup_dir=/root/pam.d.backup.$(date +%Y%m%d-%H%M%S)
sudo cp -a /etc/pam.d "$backup_dir"

Confirm the backup exists and record exactly which files you change. If all users are locked out, use the supported SLES rescue procedure and restore from a known-good configuration rather than improvising at the login prompt.

4. On SLES, check whether pam-config manages the shared files

SUSE provides pam-config to maintain the global PAM files and supported application configurations. It is generally safer than hand-editing generated shared stacks when adding or removing a supported method. First inspect the available modules and current SSSD integration:

sudo pam-config --list-modules
sudo pam-config --query --sss

If the server intentionally uses SSSD and the integration is missing, SUSE documents sudo pam-config --add --sss as the way to add it. Do this only after confirming the directory-authentication design, reviewing the current stack, keeping the backup, and ensuring you have a recovery route. Do not run it as a generic remedy for every “authentication failure.” Query the configuration again and test in a second session.

A particularly risky command is pam-config --create. SUSE says this generates a simple Unix authentication configuration and overwrites existing configuration files not maintained by pam-config (while keeping backup copies with a .pam-config-backup suffix). It is not a routine repair for a single failed login. Use it only when you deliberately intend to rebuild the configuration and have planned recovery.

If your organization intentionally maintains PAM files by hand, follow that design consistently. SUSE notes that manual configuration requires disabling pam-config for those files. Custom stacks should preserve needed session modules, including pam_systemd.so as an optional session module where applicable.

5. Separate SSH, directory, and desktop problems

If only SSH rejects the account

Compare /etc/pam.d/sshd with a known-good SLES configuration and inspect the SSH daemon’s journal at the failed login time. Confirm the account is allowed by SSH’s own settings and access controls as well as by PAM. Do not weaken SSH authentication or remove account checks just to make the error disappear.

If only directory users fail

Confirm account lookup with getent, check SSSD status and logs, and verify directory reachability, DNS, time synchronization, host enrollment, and user access policy. If another directory user succeeds, compare the affected account’s groups, shell, home directory, and host-specific access rules. SUSE’s authentication client guide describes YaST-managed SSSD and its status checks.

If console login works but the graphical session fails

Check the graphical login and session logs, home-directory availability, ownership, free disk space, and any encrypted-home unlock step. A successful text-console login is useful evidence that the password and basic authentication path work; it shifts attention toward the desktop session or user environment. Avoid deleting user files as a first step. SUSE’s troubleshooting guide recommends isolating desktop configuration issues methodically.

6. Verify the repair without risking a lockout

After a change, open a new test session while the recovery shell remains available. Test the affected service with the affected account, then test a second account and a local administrator. For directory authentication, confirm account lookup and service health as well as a successful login. Check the journal again for new PAM errors, and remove any temporary debug settings with the matching pam-config --delete option when testing is complete.

Finally, confirm that the result addresses the failing stage rather than hiding it. A fixed login should authenticate the intended user, enforce the intended account policy, and create a normal session. Keep the backup until you have verified these outcomes and documented the final configuration.

When should you stop and use rescue mode?

Stop making remote changes if root access is lost, multiple services fail at once, the shared stack has been overwritten, or you cannot determine which configuration manager owns the files. SLES documentation describes using root access to repair configuration and entering rescue mode when normal login is unavailable. For managed production systems, involve the identity or platform team before rebuilding a shared authentication stack.

For the exact PAM file structure, module flags, pam-config behavior, and recovery steps, use the version-matched SUSE SLES 15 SP7 PAM guide and SUSE common-problems guide. PAM stacks are security policy; make the smallest justified change, then verify both access and restrictions.