PAM モジュールが不明: 実際に失敗したのはどのプロセスか

その文言は、パスワードではなく、共有オブジェクトと関数ポインタについての記述として読んでください。同じ言葉は、OpenVPNプラグインからも、一つのサービス用に読み込まれた PAM スタックからも、RADIUS デーモンの内部からも出てきます。これらは三つの異なる調査であり、まずプロセスを特定してください。

以下の確認は、メッセージが VPN ログイン時の Linux-PAM 連携を通じて現れたことを前提としています。RADIUS サーバー自身の設定から出たものであれば、そのデーモンの証拠から始めてください。

パッケージを名指しする前にプロセスを名指しする

三つの構成要素がモジュールと呼ばれ、どれも互換ではありません。OpenVPN 認証プラグインは VPN デーモンが読み込み、そのデーモンのコールバックインターフェースを実装します。PAM モジュールは共有オブジェクトで、libpam が名前付きサービスのために読み込むものであり、次のようなエントリポイントを実装します: pam_sm_authenticate。FreeRADIUS モジュールはそのデーモン自身の設定の一部です。同じ言葉を含むメッセージは三つのどれからも出るため、最初の問いはどのログ行がそれを生んだかです。

失敗した一回の試行のタイムスタンプを VPN ログとシステム認証ログの間で突き合わせ、その後で要約より前の行を読んでください。具体的なローダーのメッセージはたいてい既にそこにあります。

読み込みエラーを読み、次にエントリポイントを読む

PAM は、選択した共有オブジェクトを読み込めないとき、または読み込んだオブジェクトがそのスタック項目の要求する関数を提供しないときに、不明なモジュールを報告します。これらは別々の修理であり、前者はパス、パッケージング、ABI の問題、後者は一致しないエントリポイントです。認証行には pam_sm_authenticate が必要で、アカウント行には pam_sm_acct_mgmt が必要であり、片方だけを実装したライブラリはもう片方で失敗することを、ディスパッチャのコードが示しています。ディスク上でファイルを見つけても、どちらも証明にはなりません。

似た名前のライブラリを別のディストリビューションや別の CPU アーキテクチャから持ってくるのは修理ではなく、そのプロセスが自分の libpam に対して一度も試されていないモジュールを読み込み続けることになります。何かを変える前に、意図したパスを所有するパッケージとファイルの実際のアーキテクチャを確認してください。

スタックが提供していた保証を保つ

このエラーを黙らせる最短の方法は最悪の方法でもあり、必須モジュールを任意として印を付ける、アカウント段階を削除する、あるいは無条件の許可を挿入することです。これらはいずれも、失敗した確認を存在しない確認に変えてしまい、ログインは誰も意図しなかった理由で成功します。パスワードの再設定や共有秘密の変更も、失敗がどの資格情報もバックエンドに届く前に起きるため、欠けた関数を補いません。

複数モジュールのスタックは、失敗した項目より前に別のバックエンドを実行していた可能性があるため、このエラーは RADIUS 要求が送られなかったことを証明しません。

モジュールではなくログインを検証する

不一致が修正されたら実際の受け入れ経路を試し、有効なアカウントは通り、無効な資格情報は依然として失敗し、禁止されたアカウントは依然として拒否されるべきです。証明書や追加要素の要件が今も適用されていることも確認してください。段階を飛ばす修理済みのスタックはクライアント側からは成功に見えるからです。

モジュールがきれいに読み込まれるのは前進であり、終わった試験ではありません。

どのサービス名、どのポリシーファイル、どのエントリポイントが関与したかを、証拠として使った一度の試行とともに記録してください。その記録が、次の発生を考古学の練習ではなく検索に変えます。