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.

SUSEのSLESトラブルシューティングガイドを参照して、ローカル認証およびネットワーク認証のワークフローを確認してください。

2. SLESがユーザーを見つけられることを確認します。

PAMを変更する前に、システムの名前解決サービスがアカウントを解決できるかどうかを確認してください。

getent passwd user_name
id user_name

影響を受けるログインに置き換えてくださいuser_name。これらのコマンドがディレクトリ ユーザーのアカウントを返さない場合、PAM は正しく機能しているものの、ID ルックアップが失敗している可能性があります。構成済みの ID サービスが実行されていること、ホストがディレクトリにアクセスできること、およびユーザーがこのホストにサインインする権限を持っていることを確認してください。SSSD ベースの設定の場合は、デーモンと最近のログを確認してください。

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

SUSEのドキュメントによると、SSSDはNSSとPAMの両方のインターフェースを提供し、IDデータをキャッシュできるとされています。ユーザーから断続的な障害が報告された場合は、ローカルシステムの時刻とDNS解決をディレクトリまたはKerberos環境と比較してください。Kerberosは正確な時刻同期に依存しており、ネットワーク接続が正常に機能しているだけでは認証が成功するとは限りません。

名前の衝突がないかも確認してください。SUSEでは、ローカルとネットワークIDソースの両方に存在するユーザー名が、ネットワーク認証の問題の原因となる可能性があると指摘しています。PAMルールを編集する前に、どのIDソースがアカウントを所有しているはずなのかを確認してください。

3. PAMサービスファイルと共有スタックを検査する

SLES は、サービスごとの PAM ファイルを に格納します/etc/pam.d。 などのサービス ファイルには、 、、、/etc/pam.d/sshdなどの共有ファイルが含まれるのが一般的です。共有ファイル内の不正な行は複数のサービスに影響を与える可能性がありますが、あるアプリケーションのファイル内の不正な行はそのアプリケーションのみに影響を与える可能性があります。common-authcommon-accountcommon-passwordcommon-session

編集する前に、関連ファイルを読み、リンクを確認してください。

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

モジュール名のスペルミス、モジュールファイルの欠落、オプションの誤り、予期しない順序、および最近のパッケージまたは認証の展開中に行われた変更がないか確認してください。制御フラグは重要です。requiredエラーを記録しますが、スタックの処理を続行します。requisiteすぐに停止できます。sufficient以前の必須モジュールでエラーが発生しなかった場合、早期に成功を返すことができます。モジュールと制御フローを理解せずに、別のディストリビューションまたはSLESリリースからPAMスタックをコピーしないでください。

変更を加える前に、シンボリックリンクを保持したまま、現在のディレクトリのroot権限のみのバックアップを作成してください。

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

バックアップが存在することを確認し、変更したファイルを正確に記録してください。すべてのユーザーがロックアウトされている場合は、ログインプロンプトで即興的な操作を行うのではなく、サポートされているSLESの復旧手順を使用して、正常に動作することが確認されている構成から復元してください。

4. SLES上で、pam-configが共有ファイルを管理しているかどうかを確認します。

SUSEは、pam-configグローバルPAMファイルとサポートされているアプリケーション構成を維持するための機能を提供しています。サポートされているメソッドを追加または削除する場合、生成された共有スタックを手動で編集するよりも、この機能を使用する方が一般的に安全です。まず、利用可能なモジュールと現在のSSSD統合を確認してください。

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

サーバーが意図的に SSSD を使用しているにもかかわらず統合が欠落している場合は、SUSE のドキュメントsudo pam-config --add --sssにその追加方法が記載されています。この操作は、ディレクトリ認証の設計を確認し、現在のスタックをレビューし、バックアップを保持し、復旧ルートを確保した後にのみ実行してください。「認証失敗」が発生するたびに、これを一般的な解決策として実行しないでください。構成を再度照会し、別のセッションでテストしてください。

特に危険なコマンドは ですpam-config --create。SUSEによると、このコマンドは単純なUnix認証設定を生成し、 によって管理されていない既存の設定ファイルを上書きしますpam-config（ただし、 という接尾辞が付いたバックアップコピーは保持されます.pam-config-backup）。これは、単一のログイン失敗に対するルーチン的な修復ではありません。設定を意図的に再構築し、復旧計画を立てている場合にのみ使用してください。

組織が意図的にPAMファイルを手動で管理している場合は、その設計を一貫して守ってください。SUSEは、手動構成ではpam-configこれらのファイルを無効にする必要があると指摘しています。カスタムスタックでは、必要なセッションモジュールを保持し、該当する場合はオプションのセッションモジュールとしても保持する必要がありますpam_systemd.so。

5. SSH、ディレクトリ、デスクトップの問題を分離する

SSHのみがアカウントを拒否する場合

正常に動作することが確認されているSLES構成と比較し/etc/pam.d/sshd、ログイン失敗時のSSHデーモンのジャーナルを調べてください。アカウントがSSH自体の設定とアクセス制御、およびPAMによって許可されていることを確認してください。エラーを解消するためだけに、SSH認証を弱めたり、アカウントチェックを削除したりしないでください。

ディレクトリユーザーのみが失敗した場合

アカウント検索を確認しgetent、SSSD の状態とログをチェックし、ディレクトリの到達可能性、DNS、時刻同期、ホスト登録、およびユーザーアクセス ポリシーを検証します。別のディレクトリ ユーザーが成功した場合は、影響を受けるアカウントのグループ、シェル、ホーム ディレクトリ、およびホスト固有のアクセス ルールを比較します。SUSE の認証クライアント ガイドでは、YaST で管理される SSSD とその状態チェックについて説明しています。

コンソールログインは成功するが、グラフィカルセッションが失敗する

グラフィカルログインとセッションログ、ホームディレクトリの可用性、所有権、空きディスク容量、および暗号化されたホームのロック解除手順を確認してください。テキストコンソールへのログインが成功すれば、パスワードと基本認証パスが正しく機能していることを示す有用な証拠となり、デスクトップセッションまたはユーザー環境への注意を向けることができます。最初のステップとしてユーザーファイルを削除することは避けてください。SUSE のトラブルシューティングガイドでは、デスクトップ構成の問題を体系的に切り分けることを推奨しています。

6. ロックアウトのリスクを冒さずに修理を確認する

変更後、リカバリシェルが使用可能な状態のまま、新しいテストセッションを開きます。影響を受けたアカウントで影響を受けたサービスをテストし、次に別のアカウントとローカル管理者アカウントでテストします。ディレクトリ認証については、アカウント検索とサービスの正常性、およびログインの成功を確認します。テストがpam-config --delete完了したら、ジャーナルを再度確認して新しいPAMエラーがないか確認し、該当するオプションを使用して一時的なデバッグ設定をすべて削除します。

最後に、結果が問題のある段階を隠蔽するのではなく、適切に対処していることを確認してください。修正されたログインでは、意図したユーザーが認証され、意図したアカウントポリシーが適用され、正常なセッションが作成されるはずです。これらの結果を確認し、最終的な構成を文書化するまで、バックアップを保持してください。

レスキューモードを使用するために停止すべきタイミングはいつですか？

ルートアクセスが失われた場合、複数のサービスが同時に失敗した場合、共有スタックが上書きされた場合、またはどの構成マネージャがファイルを所有しているかを特定できない場合は、リモートでの変更を停止してください。SLES のドキュメントには、ルートアクセスを使用して構成を修復する方法と、通常のログインが利用できない場合にレスキューモードに入る方法が記載されています。管理対象の運用システムでは、共有認証スタックを再構築する前に、ID チームまたはプラットフォーム チームに連絡してください。

PAMファイルの正確な構造、モジュールフラグ、pam-config動作、および復旧手順については、バージョンに対応したSUSE SLES 15 SP7 PAMガイドとSUSE共通問題ガイドを参照してください。PAMスタックはセキュリティポリシーです。必要最小限の変更を加えた後、アクセス権限と制限の両方を確認してください。